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.
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 | |
Tidak ada komentar:
Posting Komentar