Lateral SQL Injection Revisited - No Special Privs Required

David Litchfield david@davidlitchfield.com Copyright 2007, David Litchfield tag:www.davidlitchfield.com,2008-07-18:%2Fblog%2Farchives%2F00000044.htm David Litchfield david@davidlitchfield.com At the end of April 2008 I published a paper about a new class of flaw in Oracle entitled "Lateral SQL Injection". The paper can be found here: <A HREF="http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf">http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf</A> Essentially the paper details a way in which the attacker can manipulate the environment to trick an Oracle database into using arbitrary SQL in DATE functions and data. A number of people at the time dismissed it as irrelevant because the attacker required the ALTER SESSIOn privilege. Well, as it turns out, you don't need the ALTER SESSION privilege at all. Here's why: there are certain ALTER SESSION statements that can be executed even though the user doesn't have the ALTER SESSION privilege. The statements that can be executed without the privilege include those that relate to National Language Support. Thus a user without ALTER SESSION privileges can change the date format and so employ a lateral SQL injection attack. The script below shows this in action. We connect to a fully patched 11g server and confirm we only have CREATE SESSION privileges - i.e. the minimum we need to connect to the server - everyone gets this privilege. We then issue an ALTER SESSION statement to try set SQL_TRACE to true. As expected this fails with an insufficient privileges error. But then we issues an ALTER SESSION to set the NLS_DATE_FORMAT and this succeeds. Lastly we call the SYSDATE function to confirm it took. C:\>sqlplus /nolog SQL*Plus: Release 11.1.0.6.0 - Production on Fri Jul 18 14:47:17 2008 Copyright (c) 1982, 2007, Oracle. All rights reserved. SQL> connect testuser1/testuser1 Connected. SQL> select * from session_privs; PRIVILEGE ---------------------------------------- CREATE SESSION SQL> alter session set sql_trace = true; alter session set sql_trace = true * ERROR at line 1: ORA-01031: insufficient privileges SQL> alter session set nls_date_format='"'' and myfunc()=1--"'; Session altered. SQL> select sysdate from dual; SYSDATE ------------------ ' and myfunc()=1-- SQL> Thus we can see that no special privileges are required to effect a lateral SQL injection attack. Posted by David On 18/07/08 At 07:05 AM 2008-07-18T14:05:36Z 2008-07-18T14:05:36Z Lateral SQL Injection Revisited - No Special Privs Required tag:www.davidlitchfield.com,2008-07-18:%2Fblog%2Farchives%2F00000043.htm David Litchfield david@davidlitchfield.com Oracle has released a <A HREF="http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpujul2008.html">critical patch update</A>. This update fixes a number of serious issues including a Oracle Application Server PLSQL injection flaw I found in October 2007. This flaw will serve as an excellent example for my upcoming <A HREF="http://www.blackhat.com/html/bh-usa-08/train-bh-usa-08-dl.html">Hacking Oracle PLSQL</A> training course at Blackhat in Vegas this August. Posted by David On 15/07/08 At 01:38 PM 2008-07-18T14:05:36Z 2008-07-18T14:05:36Z Oracle have released a Critical Patch Update tag:www.davidlitchfield.com,2008-07-18:%2Fblog%2Farchives%2F00000042.htm David Litchfield david@davidlitchfield.com So after publishing <A HREF="http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf">my paper</A> the other day I've received a number of mails and comments from people who clearly don't quite "get it". Let me correct some of the more common comments and misconceptions. 1) You have to be highly privileged to do this. No, you don't - in a multistage attack you can get what you need. To effect an attack, as described in the paper, you need to acquire the ALTER SESSION privilege. You can get this by exploiting another flaw such as DB04 in the April 2008 Critical Patch Update. This is a injection flaw into a ALTER SESSION statement. Furthermore, prior to Oracle 10gR2 the CONNECT role had the ALTER SESSION privilege. 2) You need direct access to the database to effect this attack No, you don't. The attack described in the paper can be launched via the web through Oracle Application Server for example. Again, it's a multistage attack, but easily doable. Just use any one of the 5 bypass techniques I've published over the past few years and if the app server is patched against all those then look for an initial inject point in the custome app and use any of the facilitator methods I've described in the past. 3) This is simply second order SQL injection. No, it's not, but it is similar. Second order SQL injection is where you load up a table with your attack SQL. At some later point this SQL is selected as data from the table and embedded in a dynamic query. The attack described in my paper doesn't deal with stored data. It manipulates the way the date and time is treated. 4) This paper is pointless as you should be using bind variables for dynamic queries, anyway. Many developers only use bind variables when dealing with varchar data and input as they are known to be dangerous. They won't use bind variables when it comes to DATE or NUMBER data types. The whole point of the paper is to prove that DATA and NUMBER data types can be dangerous and that bind variables should be used. 5) <A HREF="http://blogs.oracle.com/security/2008/04/28">This paper is mostly academic</A> No, it's not. This presents a potential threat to PL/SQL applications. Developers should take heed. Suggesting otherwise is irresponsible. Posted by David On 29/04/08 At 12:22 AM 2008-07-18T14:05:36Z 2008-07-18T14:05:36Z Look before you leap... tag:www.davidlitchfield.com,2008-07-18:%2Fblog%2Farchives%2F00000041.htm David Litchfield david@davidlitchfield.com I've just released some research that demonstrates a new class of vulnerability in Oracle and how it can be exploited by an attacker. You can grab the paper from here: <A HREF="http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf">http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf</A> Posted by David On 24/04/08 At 09:44 AM 2008-07-18T14:05:36Z 2008-07-18T14:05:36Z A New Class of Vulnerability in Oracle: Lateral SQL Injection tag:www.davidlitchfield.com,2008-07-18:%2Fblog%2Farchives%2F00000040.htm David Litchfield david@davidlitchfield.com Tonight, <A HREF="http://www.ngssoftware.com/">NGSSoftware</A> won the Best Security Company category of the <A HREF="http://www.scmagazine.com/uk/awards/">SC Magazine 2008 European Awards</A>. Woohoo! Thanks to all the guys at NGS - it was thoroughly a team triumph <img src="http://www.davidlitchfield.com/blog/emoticons/smile.gif" alt="smile" /> Posted by David On 22/04/08 At 06:35 PM 2008-07-18T14:05:36Z 2008-07-18T14:05:36Z Citius, Altius, Fortius! tag:www.davidlitchfield.com,2008-07-18:%2Fblog%2Farchives%2F00000039.htm David Litchfield david@davidlitchfield.com I've been wrong in the past on a few occasions but never until last Firday was I wrong so honouredly. For a brief moment in Internet time I was wrong according to <A HREF="http://securitywatch.eweek.com/">Ryan's</A> facebook status. [Thanks, <A HREF="http://hellnbak.wordpress.com/">Steve</A> <img src="http://www.davidlitchfield.com/blog/emoticons/wink.gif" alt="wink" />] But I wasn't wrong. With all due respect to Ryan he misunderstood my <A HREF="http://www.davidlitchfield.com/blog/archives/00000038.htm">post</A>, and in this case, is the person who is wrong. He thought my post was defending public vulns counts as a true and accurate measure of SDL's success. My post wasn't about this at all and was simply a correction of something <A HREF="http://spiresecurity.typepad.com/spire_security_viewpoint/2008/04/microsofts-sdl.html">Pete</A> said which I think know is not true. Boiling it down to the basics, as part of a much larger post, Pete said that Microsoft have paid the top researchers for their permanent silence which is why he thinks the public vuln count is down. My post said that this wasn't the case and that NGS can and do still release advisories - refer to both posts for the gory details <img src="http://www.davidlitchfield.com/blog/emoticons/smile.gif" alt="smile" /> So I wasn't wrong after all, but anyway, let's tackle the larger issue: using public vuln counts as a metric for the success of SDL - can we or can't we - should we or shouldn't we? To me the guts of these question are, at release time how many bugs are in the software? More or less than one would expect? Here's a potentially true or false statement: (1) Public vuln count is down meaning that there are (2) less bugs in release-day code meaning that (3) SDL works. For those that think this is false it's because point 2 doesn't necessarily follow from point (1). For Pete, it doesn't follow because he thinks the researchers have been gagged. Even if this were true, which it's not (see my post), there's a problem - remembering that the vuln count is down what happened to the flaws that the researchers found but kept quiet? Either they were fixed or they're still in the code. If the latter, then why haven't they been found by other good researchers who baulk at the very idea of working for Microsoft and would love to see nothing more than Microsoft being embarrased or by made a name for themselves by getting out an advisory or two or sold them to Verisign or Tippingpoint's ZDI? Given that this hasn't happened we must assume the bugs supposedly found by gagged researchers were fixed silently and therefore the bugs are no longer in the code. This bring us to silent fixes. Silent fixes are another reason why some people (Ryan for example) think point (2) above doesn't necessarily follow point (1). We all know that given some patched software and some unpatched software hackers have learned how to find the bugs that have been silently fixed. A really juicy flaw would soon be found and end up in Metasploit or Canvas and I'm sure some modules have come through this route but nowhere near the numbers of flaws we'd need to make up the difference given the current public vuln counts. Here's another thing about silent fixes and quoting from an email from Ryan: "we know [silent fixes] exist because the SDL requires that SWI [the MS internal security team] looks in adjoining areas for code dependencies and those are fixed but never documented [publicly]." This is true. Whilst Ryan doesn't think it, to me this doesn't say anything bad about using public vuln counts as a metric for measuring the success of SDL; in fact it says something good about it. If SDL dictates that when a new bug is found externally, SWI looks for similar flaws then this surely leads to more bugs being found internally, meaning less are found externally, meaning the potential public vuln count diminishes. QED <img src="http://www.davidlitchfield.com/blog/emoticons/wink.gif" alt="wink" /> But seriously, and wrapping this up for good (at least from my perspective), I don't claim public vuln counting is an accurate metric for measuring the success of SDL. It may or may not be accurate. However it is a measure nonetheless and shows the direction of the trend. There is an expectation that software developed under SDL will make the code in the final released product more secure and have less security bugs. Given that there are less bugs it is reasonable to assume that the public vuln count will be less, too. Lastly, let's consider this: if the public vuln count was up, even marginally, you could bet that everyone would be screaming from the rooftops that SDL was a failure. Given that most people (even Pete and Ryan) think SDL was a success, why is it so hard to believe the opposite? Posted by David On 20/04/08 At 05:51 PM 2008-07-18T14:05:36Z 2008-07-18T14:05:36Z I'm wrong. Supposedly... tag:www.davidlitchfield.com,2008-07-18:%2Fblog%2Farchives%2F00000038.htm David Litchfield david@davidlitchfield.com Some people are arguing that you shouldn't/can't use publicly disclosed vulnerability counts as a metric to the success of the SDL. The major sticking point is best codified with a quote from <A HREF="http://spiresecurity.typepad.com/spire_security_viewpoint/2008/04/microsofts-sdl.html">Pete Lindstrom's blog</A>: "Microsoft has systematically hired and/or contracted with every one of their most vocal critics (and most seasoned bugfinders) to do the work behind the scenes and they don't count those vulns!" This quote suggests a lack on understanding about what really goes on "behind the scenes" so this blog posting should hopefully make things clearer. Firstly, some definitions: a "pre-release product" is a product not yet shipped and at any given moment is under-going some part of the SDL process. A "shipped product" is a product that has undergone the SDL processes and whose code has been finalized. Now, the main aim of Microsoft's Security Development Lifecycle (SDL) is to deliver to their customers shipped products whose code is as robust and secure as possible. As part of this process there is a Final Security Review (FSR). This is where Microsoft hire an external 3rd party that are sent to give the pre-release product and code a beating up - code commandos if you will <img src="http://www.davidlitchfield.com/blog/emoticons/wink.gif" alt="wink" /> This FSR serves two important purposes from my point of view. Firstly, for each problem found questions are asked as to how the problem got through as far as it did. The answers to these questions allow the tools and processes behind SDL to be refined and improved meaning that, next time around, instances of the same class of issue shouldn't get so far again. The second purpose of the FSR, and most obvious, is to ensure that there are fewer security problems in the final, shipped product because they are found and fixed. In other words, the use of a FSR, which is part of SDL, means that the final product is more secure (by which I mean has less security flaws) than a hypothetical product that did not undergo the FSR. Now down to counting vulnerabilities as a metric... You only start counting bugs when the code has been finalized and the product ships. You don't start counting before - as it's a pre-release product undergoing security review. This should be obvious. So even if during the FSR of a given product a gazillion bugs were found then, with regard to the vulnerability count, this is entirely irrelevant because these bugs were in a pre-release product and not a shipped product and were found as part of the SDL process. Now what happens if one of Microsoft's hired code commandos finds a flaw in a shipped product? I think this question is the root cause of Pete's and people of his ilk's lack of trust when it comes to vulnerability counting as a metric. His assumption is that these are quietly swept under the carpet and therefore not counted. Let me put him straight. This does not happen. The reason it doesn't happen is two fold - firstly, NGSSoftware don't want to be or be seen as Microsoft lackeys and secondly Microsoft doesn't want to, or be seen to be, hiring lackeys. In the former case it would affect our independent status and in the latter it would undermine Microsoft's attempts to improve their software's security and convince their customers that this is the case. To that end, NGSSoftware asked for and was whole-heartedly given the right to continue to research and publish flaws in Microsoft products - shipped products - even those we have done work on when they were pre-release. Here are some MS alerts from the past two years that NGS have been credited in: http://www.microsoft.com/technet/security/bulletin/ms06-nov.mspx http://www.microsoft.com/technet/security/bulletin/ms06-aug.mspx http://www.microsoft.com/technet/security/bulletin/ms06-jun.mspx http://www.microsoft.com/technet/security/bulletin/ms06-mar.mspx http://www.microsoft.com/technet/security/bulletin/ms06-jan.mspx http://www.microsoft.com/technet/security/bulletin/ms07-apr.mspx http://www.microsoft.com/technet/security/bulletin/ms07-jul.mspx http://www.microsoft.com/technet/security/bulletin/ms07-dec.mspx http://www.microsoft.com/technet/security/bulletin/ms08-feb.mspx Furthermore, we don't do any MS sponsored reviews after the product has been shipped so if we find a security flaw at this stage there will be an alert. Let me state this as clearly as I can. If I found a flaw in SQL Server 2005 tomorrow, I would report it to secure@microsoft.com, it would be fixed and an alert would be publicly issued. If SQL Server 2005 wasn't so secure, I would find one just to prove this - but I can't - because it is secure and SDL, every part of it, is responsible. So, when it comes to using publicly reported vulnerabilities in shipped products as a metric for SDL, rest assured, the results aren't as skewed as some would have you believe. I personally think, and I hope this blog posting will help convince others, that as any measure goes in an imperfect world, this one's "pretty good". Posted by David On 18/04/08 At 10:24 AM 2008-07-18T14:05:36Z 2008-07-18T14:05:36Z Code Commandos, SDL and Metrics XML::Atom::SimpleFeed 2008-07-18T14:05:36Z David Litchfield's blog