[Previous entry: "Oracle October CPU pre-release analysis"] [Next entry: "Nice paper on time based blind SQL"]
Creating a SYSDBA backdoor
October 15th, 2007 by Pete
Post to del.icio.us
Post to Furl
Today Paul has released a new paper on his web site titled "Oracle SYSDBA backdoor" showing how a hacker might create a SYSDBA connection in the database and hide it. This is an interesting paper and it highlights the issue known for a long time that there is a disjoint between the password file and the database. I have seen this on a number of professional audits where the contents of the password file are out of step with the database. This is often caused by application vendors installing canned versions of their application and also snapshots of databases that include password files.
Paul shows how to create a hacker user in the database and then grant it SYSDBA rights; no commit needed when you create a user Paul :-) and then goes on to show how the fixed view gv$pwdfile_users can be modified in the binary to hide the hacker user. This technique was first shown in a great paper "Undocumented Oracle - What They Didn't Teach You At Oracle" that shows how to modify a v$ view - its referenced on my undocumented Oracle page.
The hack calls for the copying of the password file at the OS level, whilst this can be done from within the database as a SYSDBA user is creates a much bigger footprint of evidence when its done; Paul's example shows it done at the OS level which is simpler.
Also the database has to be restarted for the modified binary to come into play although as Paul suggests this may be possible to avoid. Stopping and starting the database will obviously also create a big footprint in the evidence world. The stop and start will create entries in the alert log, the sysdba connection will be recorded in the SYSDBA action trace files (cannot be turned off) and more.
As Paul suggests checksumming is a good idea in the database and on the OS binaries with a tool such as Tripwire. The hack can be seen to work, its not trivial remotely and it would be reasonably "noisy" to do.
A simpler solution to the problem is to set remote_login_passwordfile = NONE as i recommend to clients as this would prevent the remote authentication as SYSDBA. If SYSDBA connections are needed for RMAN or OEM then this is harder to avoid. It would not be too difficult also to limit SYSDBA connections from remote sites using a firewall as the TNS packets identify a SYSDBA connection also valid_node_checking can be used to limit the database connections at the TNS level.
Nice interesting paper though Paul and worth a read.
