David Litchfield Reveals His Process for Security Research

In our ongoing series of interviews, this week David Litchfield answered a few questions and pulled back the curtain a bit on the methods, tools and motivation for the work he does.

David Litchfield is recognized as one of the world’s leading authorities on database security. He is the author of the Oracle Hacker’s Handbook, co-author of the Shellcoder’s Handbook, the Database Hacker’s Handbook, SQL Server Security. He is a regular speaker at a number of computer security conferences and has delivered lectures to the National Security Agency, the UK’s Security Service, GCHQ and the Bundesamt für Sicherheit in der Informationstechnik in Germany.

In 2010, David was listed by CRN as a “Security Superstar” and in 2003 he was voted as the “Best Bug Hunter” by Information Security Magazine. In the same year he discovered and developed two methods to bypass the exploit prevention mechanisms built into Microsoft’s Windows 2003 Server and consequently worked with Microsoft to improve them. He has found and helped to fix 24 security flaws in SQL Server, including the vulnerability that was exploited by Slammer; 17 in IBM’s DB2; 22 in Informix and over 100 in Oracle. In February 2008 David discovered a new class of vulnerability in Oracle that can lead to “Lateral SQL Injection” and, in the November of 2006, another new class of vulnerability in the same RDBMS that can lead to “cursor snarfing” attacks. Both are general programming flaws, that can lead to data compromise. David pioneered major advancements in Oracle forensics and has authored seven technical papers since March 2007 on the topic.

David recently founded v3rity, a new venture. v3rity develops breach investigation software to examine compromised database servers. Until February 2010, David was Chief Research Scientist at NGSSoftware, a UK computer security services and software company he founded in 2001. NGSSoftware was acquired by NCC Group in November 2008. In 2007 NGSSoftware was awarded the Queen’s Award for Enterprise, and was listed as one of the UK’s fasted growing tech companies by both Deloitte and the Sunday Times. NGSSoftware was winner in the Best Security Company category in the 2008 European SC Magazine Awards and runner up in 2007. Previously David was Director of Research at @stake after his first company, Cerberus Information Security, was acquired in July 2000.

What motivates you to find security vulnerabilities?

Originally it was the game. In the early days, it was fun finding flaws and working out how to exploit them. I remember before knowing how to exploit buffer overflows I found one in the Windows NT Remote Access Service Manager service caused by an overly long entry in the phone book. An access violation occurred and I know it sounds funny to say it now, but at the time, that was one of the most exciting things I’d experienced — the debugger kicking off with an instruction could not be read error at 0x41414141 and I knew that to be the “hallmark” of an overflow. So then I set about learning how to exploit it and the result was my first real exploit. I documented the process as I went resulting in my first white paper — “Exploiting Windows NT 4 Buffer Overruns – A case study: RASMAN.EXE”. Later on of course, looking for flaws became part of my job.

What are the primary tools you use, and how do you use them?

My main tool is a C compiler which enables you to create your own specific tools for the job at hand. Learning how to code will help you enormously if you’re interested in vulnerability research. But of course there’s no point in re-inventing the wheel where you don’t need to and so I frequently used tools such as Sysinternal’s Filemon, Regmon, ProcessExplorer on Windows (all great for instrumenting and peering into what’s going on) and lsof, strace, ptrace on *nixes. As a debugger, my preferred choice was Visual Studio C++ on Windows and gdb on *nixes. For database flaws I’d use tools such as sql*plus and Query Analyzer.

How do you choose your target of investigation? Do you pick your target application and look for bugs, or look for a genre of bug in many different applications?

In my early days I focused more on web servers and applications which eventually led me to database servers. I install a particular server and give it a thorough going over. When I’d get tired of looking at one particular aspect, say SQL injection, I’d then shift to say overflows then architectural flaws then back to SQL injection and so on. There was no rhyme or reason I guess — just whatever took my fancy. Up until about 2008 you could get away with this and still come away with a bumper crop of bugs, but it’s getting harder these days and a more considered approach is required making sure to cover as much as possible. Always be ready to switch directions though if you feel you’re getting stale.

How do you handle disclosure? Which vendors have been good to work with and which have not?

When I find a flaw and have confirmed my research I’ll send it to the vendor in question. More often than not I’m happy to leave it at that once it’s in their system but occasionally a vendor and I won’t see eye to eye on a particular issue. More often than not it would be Oracle and they’d rate a flaw as low impact when clearly it wasn’t — for example, unauthenticated PL/SQL injection flaws in Oracle Application Server that allowed internet based attackers to gain full control over the backend database servers. We butted heads publicly a few times over such differences.

What are you working on currently?

Right now I’m not doing any vulnerability research and started a firm called V3RITY, researching and developing tools for database breach investigations. There’s a wealth of evidence left after a breach when it comes to DBs and traditional forensics tools miss this stuff. The tools I’m writing allow investigators to discover, collect, collate and manage this evidence.

Which of the Oracle bugs that you have discovered was your favorite?

Oh, there’s so many, it’s difficult to say. 😉 Seriously though, I’d say it comes down to the extproc attack. Essentially the extproc attack allows a remote, unauthenticated attacker to trick Oracle into executing operating system commands by causing the listener to launch the extproc program which then loads a DLL of the attacker’s choosing and executes an attacker specified function. For example, you could load msvcrt.dll or libc and execute the system() function passing it arbitrary OS commands. When Oracle fixed this, they added logging so when an attempt occurred it’d log the attack. This was vulnerable to a buffer overflow flaw with an overly long library name. They patched this by doing a length check. This new fix was also broken. After doing the length check and envariables in the string were expanded allowing us to exploit the overflow again. Oracle had a terrible history of such shoddy fixes. It took them five years and many new bug reports to fix the mod_plsql bypass flaws in Oracle Application Server. Each time they’d issue a fix I’d find a new way to bypass it. Crazy. The best flaw in Oracle though is not one I found — my brother, Mark found it: the Oracle RDBMS suffered from a trivially exploitable overly long username buff overflow — this an EAL4+ certified product.

How do you feel about Oracle security in 2011?

They’ve made great strides (or perhaps they were dragged kicking and screaming) in improving their security response and improving the quality of their code. Where as in the mid to late 2000s you could sit down for an hour or so and find 20 flaws with ease, it now takes a good day or so of digging to find a decent flaw in the RDBMS. This is a good thing.