Hack Oracle - Part 2
Continued from the last post, let's look at some more ways of hacking Oracle.
5.Privilege Escalation
In a nutshell "privilege escalation" involves using the existing usually underprivileged account in tricky, sneaky or nefarious ways to gain greater privileges or even the DBA privileges!
Here's an example, using one of the CREATE ANY grants. The access to the database via a user SEAN who has CREATE ANY TRIGGER, so we can create a trigger in any schema. If you can track down a table which any user can write to, create a trigger in SYSTEM which executes when you the unprivileged user, INSERT or UPDATE that publicly writeable table. The trigger you write calls a stored procedure you also write, which, and here's the rub, executes with AUTHID CURRENT_USER. That means it'll have the privileges of the SYSTEM user when it executes *YOUR* procedure. Now inside your nefarious stored procedure you include "EXECUTE IMMEDIATE 'GRANT DBA TO SEAN'"; Voila!
Now :
1. Insert into the public table (the trigger fires)
2. The trigger is owned by SYSTEM
3. SYSTEM calls the change_privileges stored procedure, which is AUTHID CURRENT_USER
So although *I* could not have executed to change my own privileges I managed to get SYSTEM to execute it, and that user *DOES* have the privileges, so I am now granted DBA!!
What's a Database Administrator to do? Well for starters, you should audit your database for CREATE ANY privileges and remove the ones that aren't required. Secondly, you should scan the forums such as http://www.securityfocus.com/ for the latest vulnerabilities surrounding privilege escalation. Lastly, it might not hurt to enable auditing of certain types of activities so the database will help you help yourself. While it audits things like GRANT DBA you can monitor that audit log for malicious or unexpected activity.
Here's an example, using one of the CREATE ANY grants. The access to the database via a user SEAN who has CREATE ANY TRIGGER, so we can create a trigger in any schema. If you can track down a table which any user can write to, create a trigger in SYSTEM which executes when you the unprivileged user, INSERT or UPDATE that publicly writeable table. The trigger you write calls a stored procedure you also write, which, and here's the rub, executes with AUTHID CURRENT_USER. That means it'll have the privileges of the SYSTEM user when it executes *YOUR* procedure. Now inside your nefarious stored procedure you include "EXECUTE IMMEDIATE 'GRANT DBA TO SEAN'"; Voila!
Now :
1. Insert into the public table (the trigger fires)
2. The trigger is owned by SYSTEM
3. SYSTEM calls the change_privileges stored procedure, which is AUTHID CURRENT_USER
So although *I* could not have executed to change my own privileges I managed to get SYSTEM to execute it, and that user *DOES* have the privileges, so I am now granted DBA!!
What's a Database Administrator to do? Well for starters, you should audit your database for CREATE ANY privileges and remove the ones that aren't required. Secondly, you should scan the forums such as http://www.securityfocus.com/ for the latest vulnerabilities surrounding privilege escalation. Lastly, it might not hurt to enable auditing of certain types of activities so the database will help you help yourself. While it audits things like GRANT DBA you can monitor that audit log for malicious or unexpected activity.
6.Listener
Oracle's listener is setup out of the box so that one can remotely administer it. What if the attacker sets the logfile of the listener to be the Unix .rhosts file? Well the attacker can effectively WRITE to the .rhosts file. This file on Unix configures who is allowed to login without a password using the rsh, rlogin, and rcp commands. You can imagine what happens next!
This is really the tip of the iceberg in terms of security surrounding Oracle's listener. There are also buffer overflows and a lot more to look at. In fact, Litchfield's Oracle Hacker's handbook has a whole chapter on the topic!
From the prevention side of the house, Oracle has made some strides to allow better security if only you put it in place. For starters, set a password for administrating the listener. Burdened by an ever-growing set of passwords to manage, this might seem like too much, but consider the threat before you look the other way. Oracle has also added ADMIN_RESTRICTIONS, which prevent certain things from being done remotely. For instance, you would then have to be local to set the location of logfiles.
This is really the tip of the iceberg in terms of security surrounding Oracle's listener. There are also buffer overflows and a lot more to look at. In fact, Litchfield's Oracle Hacker's handbook has a whole chapter on the topic!
From the prevention side of the house, Oracle has made some strides to allow better security if only you put it in place. For starters, set a password for administrating the listener. Burdened by an ever-growing set of passwords to manage, this might seem like too much, but consider the threat before you look the other way. Oracle has also added ADMIN_RESTRICTIONS, which prevent certain things from being done remotely. For instance, you would then have to be local to set the location of logfiles.
7.Operating System Commands & Security
Hackers aren't always logged into your system at a shell prompt. In fact, we hope they never are! Nevertheless, that doesn't mean they can't pretend. By coaxing the Oracle database to run commands at the Operating System level though, we're effectively giving the hacker a way to have just that, a method for running commands. Those commands could delete or corrupt files, overwrite logs (to hide their tracks), create accounts, or anything else that one could potentially do at the command line. So, how do they do it?
Although there are a number of ways, the easiest is through languages like Java or PL/SQL. Often the ability to create external stored procedures is available. By default, it is anyway. This can allow a stored procedure, which performs a system call to execute. This system call then can execute with the privileges of the "oracle" account by which Oracle was installed in the first place. So from there you can see where it goes.
Although Oracle has made some strides to protect against these types of things, your best bet in terms of prevention is monitoring. By keeping an eye on the activities inside your system, you're better able to be proactive if an attacker tries something malicious like this.
Although there are a number of ways, the easiest is through languages like Java or PL/SQL. Often the ability to create external stored procedures is available. By default, it is anyway. This can allow a stored procedure, which performs a system call to execute. This system call then can execute with the privileges of the "oracle" account by which Oracle was installed in the first place. So from there you can see where it goes.
Although Oracle has made some strides to protect against these types of things, your best bet in terms of prevention is monitoring. By keeping an eye on the activities inside your system, you're better able to be proactive if an attacker tries something malicious like this.
8.Filesystem Security
Access to the filesystem is one area that is a tricky one to get your head around. The "oracle" OS user owns all of the Oracle software, and datafiles of your database, so if or when a user inside the database accesses files on the filesystem using the UTL_FILE package, they have access to many things they wouldn't have access to inside the database, because their GRANTs and ROLEs constrain them. If they create read datafiles, they can affectively gain access to the raw binary data that make up your tables and indexes, and with some work can deduce the content therein. They may also be able to write to those files and affectively corrupt them. Dangerous indeed.
Oracle has made some strides to prevent this by introducing the DIRECTORY object. One must have a DIRECTORY object defined to do certain types of reading and writing now in 10g. That means a user must have CREATE DIRECTORY privilege, which we've seen previously can be attained by various methods of privilege escalation. Even given all of this, there are still ways to gain access to the filesystem and read and write files via PL/SQL or Java.
Oracle has made some strides to prevent this by introducing the DIRECTORY object. One must have a DIRECTORY object defined to do certain types of reading and writing now in 10g. That means a user must have CREATE DIRECTORY privilege, which we've seen previously can be attained by various methods of privilege escalation. Even given all of this, there are still ways to gain access to the filesystem and read and write files via PL/SQL or Java.
0 comments:
Post a Comment