-
-
17:05
»
David Litchfield's blog
<P> At the end of April 2008 I published a paper about a new class of flaw in Oracle entitled "Lateral SQL Injection". <br /><br /> 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><br /><br /> 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. <br /><br /> 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.<br /><br /> <br /> C:>sqlplus /nolog<br /><br /> SQL*Plus: Release 11.1.0.6.0 - Production on Fri Jul 18 14:47:17 2008<br /><br /> Copyright (c) 1982, 2007, Oracle. All rights reserved.<br /><br /> SQL> connect testuser1/testuser1<br /> Connected.<br /> SQL> select * from session_privs;<br /><br /> PRIVILEGE<br /> ----------------------------------------<br /> CREATE SESSION<br /><br /> SQL> alter session set sql_trace = true;<br /> alter session set sql_trace = true<br /> *<br /> ERROR at line 1:<br /> ORA-01031: insufficient privileges<br /><br /> <br /> SQL> alter session set nls_date_format='"'' and myfunc()=1--"';<br /><br /> Session altered.<br /><br /> SQL> select sysdate from dual;<br /><br /> SYSDATE<br /> ------------------<br /> ' and myfunc()=1--<br /><br /> SQL><br /><br /> Thus we can see that no special privileges are required to effect a lateral SQL injection attack. </p> <p>Posted by David On 18/07/08 At 07:05 AM</p>
-
17:05
»
David Litchfield's blog
<P> 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.<br /><br /> 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. </p> <p>Posted by David On 15/07/08 At 01:38 PM</p>
-
17:05
»
David Litchfield's blog
<P> 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.<br /><br /> 1) You have to be highly privileged to do this.<br /> 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.<br /><br /> 2) You need direct access to the database to effect this attack<br /> 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.<br /><br /> 3) This is simply second order SQL injection.<br /> 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. <br /><br /> 4) This paper is pointless as you should be using bind variables for dynamic queries, anyway.<br /> 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 <I>should</I> be used.<br /><br /> 5) <A HREF="http://blogs.oracle.com/security/2008/04/28">This paper is mostly academic</A><br /> No, it's not. This presents a potential threat to PL/SQL applications. Developers should take heed. Suggesting otherwise is irresponsible. </p> <p>Posted by David On 29/04/08 At 12:22 AM</p>
-
17:05
»
David Litchfield's blog
<P> 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> </p> <p>Posted by David On 24/04/08 At 09:44 AM</p>
-
17:05
»
David Litchfield's blog
<P> 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" /> </p> <p>Posted by David On 22/04/08 At 06:35 PM</p>
-
17:05
»
David Litchfield's blog
<P> 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" />]<br /><br /> 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 <I>true and accurate</I> 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" /> <br /><br /> 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?<br /><br /> <br /> 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?<br /><br /> Here's a potentially true or false statement:<br /><br /> (1) Public vuln count is down meaning that there are (2) less bugs in release-day code meaning that (3) SDL works.<br /><br /> 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 - <I>remembering that the vuln count is down</I> 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 <I>but nowhere near the numbers of flaws we'd need to make up the difference given the current public vuln counts.</I><br /><br /> 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]."<br /><br /> 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" /><br /><br /> 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 <I>is</I> 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 <I>success</I>, why is it so hard to believe the opposite?<br /> </p> <p>Posted by David On 20/04/08 At 05:51 PM</p>
-
17:05
»
David Litchfield's blog
<P> 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>:<br /> <B><br /> "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!"<br /> </B><br /> 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.<br /><br /> Now down to counting vulnerabilities as a metric...<br /><br /> 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 <I>part</I> of the SDL process.<br /><br /> 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.<br /><br /> 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:<br /><br /> http://www.microsoft.com/technet/security/bulletin/ms06-nov.mspx <br /> http://www.microsoft.com/technet/security/bulletin/ms06-aug.mspx <br /> http://www.microsoft.com/technet/security/bulletin/ms06-jun.mspx <br /> http://www.microsoft.com/technet/security/bulletin/ms06-mar.mspx <br /> http://www.microsoft.com/technet/security/bulletin/ms06-jan.mspx <br /> http://www.microsoft.com/technet/security/bulletin/ms07-apr.mspx<br /> http://www.microsoft.com/technet/security/bulletin/ms07-jul.mspx<br /> http://www.microsoft.com/technet/security/bulletin/ms07-dec.mspx<br /> http://www.microsoft.com/technet/security/bulletin/ms08-feb.mspx<br /><br /> Furthermore, we don't do any MS sponsored reviews <I>after</I> the product has been shipped so if we find a security flaw at this stage there will be an alert. <br /><br /> 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".<br /><br /> <br /> </p> <p>Posted by David On 18/04/08 At 10:24 AM</p>
-
-
23:38
»
David Litchfield's blog
<P> 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.<br /><br /> 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. </p> <p>Posted by David On 15/07/08 At 01:38 PM</p>
-
23:38
»
David Litchfield's blog
<P> 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.<br /><br /> 1) You have to be highly privileged to do this.<br /> 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.<br /><br /> 2) You need direct access to the database to effect this attack<br /> 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.<br /><br /> 3) This is simply second order SQL injection.<br /> 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. <br /><br /> 4) This paper is pointless as you should be using bind variables for dynamic queries, anyway.<br /> 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 <I>should</I> be used.<br /><br /> 5) <A HREF="http://blogs.oracle.com/security/2008/04/28">This paper is mostly academic</A><br /> No, it's not. This presents a potential threat to PL/SQL applications. Developers should take heed. Suggesting otherwise is irresponsible. </p> <p>Posted by David On 29/04/08 At 12:22 AM</p>
-
23:38
»
David Litchfield's blog
<P> 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> </p> <p>Posted by David On 24/04/08 At 09:44 AM</p>
Aviv Raff On .NET
(18 unread)
CGISecurity.com: Your Web Site and Application Security Resource (74 unread)
christian's weblog (25 unread)
Irongeek's Security Site (125 unread)
Jeremiah Grossman (74 unread)
milw0rm.com (440 unread)
Packet Storm Security Advisories (373 unread)
SecuriTeam.com (184 unread)
Security Vulnerability Research & Defense (36 unread)
SecurityFocus News (139 unread)
Securityvulns news channel (336 unread)
Taking Network Security to the Streets (28 unread)
The Register - Security (388 unread)
IceСμbeς (15 unread)
Linmagazine (186 unread)
netcraft Bytes :) (38 unread)
Digg (4021 unread)
----- Anti-Malware ----- Analysis and Defense (15 unread)
Apple Fun (25 unread)
Technorati Search for: aviv.raffon.net (201 unread)
Determina Zero-Day Protection (6 unread)
Security - RSS Feeds (179 unread)
Exploit Prevention Labs (28 unread)
Software Vulnerability Exploitation Blog (22 unread)
F-Secure Antivirus Research Weblog (74 unread)
George Ou (10 unread)
heise security (342 unread)
invisiblethings' blog (35 unread)
JScript Blog (16 unread)
PandaLabs (35 unread)
SecuriTeam Blogs (65 unread)
Security Fix (115 unread)
HP ASC Portal (30 unread)
Sunbelt Blog (216 unread)
Wired: Threat Level (454 unread)
WabiSabiLabi's blog (22 unread)
WatchGuard Wire (48 unread)
Errata Security (81 unread)
PaulDotCom Community Blog (10 unread)
Billy (BK) Rios (19 unread)
Farfromr00tin (23 unread)
aut disce, aut discede (17 unread)
pwn* (16 unread)
SecurityDot Vulnerabilities (421 unread)