In his presentation Litchfield walked his audience through a demonstration of an Oracle database hack, from gaining access into the database, to escalating privilege, to modifying data, and showed the types of evidence left behind by these attacks and how that evidence could be collected by the tool for the purpose of forensics.
Leading up to the demo, he explained how no one is really taking responsibility for database forensics and incident response because the convergence of databases and forensics puts the subject well out of the comfort zones of experts in either field.
“There seems to be this no-man’s-land where no one’s doing it simply because the forensics and IR people understand very well their own technologies, whereas with databases you have to understand things like SQL. You have to understand the architecture. So they leave it to the database guys to do it,” Litchfield said, “whereas the database guys are probably thinking, ‘Wow, I understand databases, but the whole forensics thing is way out of my depth, so I’ll leave it to the other guys. ‘”
Additionally, he said, there were no commercially available tools for doing effective database forensics.
“Until now, that is,” Litchfield said, explaining that the big gap in forensics was what lured him away from researching vulnerabilities in databases to developing tools under V3rity Software, a company he founded a little more than a year ago.
According to Litchfield, plenty of forensics data is laying around a database infrastructure to do a proper investigation, particularly for Oracle. Litchfield said that even though Oracle has a long way to catch up with SQL Server in terms of security posture — pointing to a comparison between the number of critical patch updates as evidence — he believes Oracle offers the most information necessary to piece together an incident after the fact.
“Evidence is everywhere in Oracle — that’s one of the best things it has done. There is so much redundancy built into it that there is a wealth of information about what’s taking place,” he said. “They have all this juicy information to a forensics investigator.”
Some places where incident response teams should look include system metadata, datafiles, redo logs, transaction logs, undo segments, and memory and trace files. Log files are also good, but only with caution because the hackers can manipulate them.
It is all a matter of extracting that data without changing any system states so that it can be read in a human understandable format. Litchfield says his new tools do that for Oracle version 8 through present time. He encourages forensics people to contact him for the free tools, with the understanding that it is still unpolished.
“Right now the tools are all held together by bubblegum and cello tape,” he said, ” so you have to lick everything together.”
Have a comment on this story? Please click “Discuss” below. If you’d like to contact Dark Reading’s editors directly, send us a message .