Tuesday, January 19, 2010
Database Authentication
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#
No comments:
Post a Comment