Call: +44 (0)1904 557620 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: "Permissions required to run my PL/SQL Oracle password cracker"] [Next entry: "Pete Finnigan's presentation slides available from UKOUG conference"]

Oracle forensics paper - part 7 and an Oracle datablock dump tool



I was actually just browsing for one of Davids recent forensics papers to mention them in an answer to a question on my Oracle Security forum about how to delete data completely and whether it is actually possible without rebuilding the database. This is sort of the ant-thesis to Oracle forensics. Oracle forensics is possible because Oracle tends to leave a huge trail of evidence all over the database memory and the files it uses and produces. This is quite useful for finding evidence when no audit trail exists but it is not useful if you actually want to make sure no trace of data is left.

The forum post is titled "Overwriting Data or Wiping?" and is actually a very interesting question. I posted an answer:

"This is a very good question but one I am afraid we probably do not have a quick easy answer for. If you could move the table to its own tablespace you would control the datafile and could then drop it, secure delete and then recreate BUT as you have already said the problem is the data in the existing datafile.

I am sure that you have seen the many papers on Oracle forensics that discuss the issues of data recovery from Oracle data blocks. Oracle has a tendancy to not overwrite existing data for some time after its updated or deleted. This is great for forensics but not if you want rid of the data completely.

The second problem with Oracle is its tendancy to replicate data all over the place, shared memory, redo, archivelogs, flashback, actual data files, audit trails....

Maybe; maybe you are coming at the problem from the wrong end. You seem to want to update application authentication but remove old authentication details / data at the same time - presumably because they are either in clear text or very simply encoded/hashed/encrypted.

Why not do your update to the new algorithm/storage but force all users to have new passwords that also must be expired to force change on use. This way any data that could be read from datafiles, memory, redo, archivelog etc is redundant; no longer valid; therefore no use to anyone who can read it?"


Then I went off to look for links to David's forensics papers and found by chance that he has just released a new part 7 in his series on Oracle Forensics. The new paper is called http://www.databasesecurity.com/dbsec/oracle-forensics-scns.pdf - (broken link) Oracle forensics part 7 - using the Oracle system change number in forensic examinations. The paper also includes two tools that are demonstrated in the paper. The first is oratime which is mapping SCN's to timestamps but from the raw data in the block. Also David has released a tool called orablock that allows you to dump data and other details from Oracle data blocks including deleted data. The key thing for orablock is that unlike BBED (Oracle's tool) it doesn't allow changes to data. The other key factor is that David also includes the C source code to both utilities. The code and binaries for Windows can be found http://www.databasesecurity.com/cadfile.zip - (broken link) here.

Thanks David, nice tools and paper, glad I was distracted to have a look for your links to your old papers today!