Call: +44 (0)7759 277220 Call
Blog

Pete Finnigan's Oracle Security Weblog

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

[Previous entry: "Oracle 0-day exploit to be released - Blackhat Washington DC database security presentations"] [Next entry: "Oracle TNS Protocol downgrade attacks"]

How to hack SYS password without logging into the database



I have just posted a new paper to my website written by Miladin Modrakovic and titled "Fixing SYS for hacking purposes" which details how the SYS password hash can be changed in the database without logging into the database. This is of course done using the BBED tool. The paper starts:

"How to change Oracle SYS password without having to login into a database? Possible?
Yes. All you need is some knowledge about Oracle internals.

This document is to be used only for testing purposes and not to be used in production environment. Purpose is to show audience how hackers can gain access to your system without knowing it and how to prevent it.


As I said earlier I am not going to use SQL to access production database. In order to get necessary information about SYS user I will copy production system datafile to my test server using rcp, sftp or any other utility (assumption here is that we already have gained access to database server)."


I have updated my Oracle internals and undocumented Oracle page to include this paper.

There has been 4 Comments posted on this article


February 17th, 2007 at 11:42 am

Noons says:

Quite frankly, I see very little value in these explanations and demonstrations that "security can be broken, if it is already broken".

That is essentially the proposition here.

If someone can break into the db server as dba user, then they can change the dba password without logging in to the database?

Big deal! That's been the case with ANY database and ANY operating system for the last, oh let me see: 40 years?



February 19th, 2007 at 07:26 am

Guto says:

Well, there is another workaround (I tried it, and it works). You'll have to have access to system.dbf only (it doesn't matter if database is up or not). For testing purposes, database is down, You examine system.dbf (ie. with Aul - DUL alternative), find rough block number (with hex editor), modify system.dbf with BBED(according to excellent paper by Graham Thornton), replace original system.dbf with modified, and start database. It works, but what security hole is that when someone can access Your datafiles ???
Greetings,
Guto



February 19th, 2007 at 04:57 pm

Pete Finnigan says:

Hi Guto and Nuno

The issue as far as I am concerned is that the BBED is dangerous. I reported this tool to Oracle some years ago as a security bug and suggested it was not shipped. The issue with BBED is that a user of the server who does not have the oracle account, is not in the OSDBA group and is not root could in theory use this tool to gain access to the database. Its a small issue as you need server access but an issue nontheless. Also the tool can be used off line to corrupt backups, steal from backups, install trapdoors..... Just because someone has server access doesnt mean they can hack Oracle datafiles, this tools helps them do that so should be restricted.

cheers



February 20th, 2007 at 06:20 am

Guto says:

Hi Pete,
Agree with You, but just some remarks - if You have access to datafiles, You can - not in theory - gain access to database. Including tool (with Oracle installation) that can be used by proffesionals can lead to unattended database coruption. Why not then ship DUL too ?