28.10.2014 Views

SQL Injection Attacks and Defense - 2009

SQL Injection Attacks and Defense - 2009

SQL Injection Attacks and Defense - 2009

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

184 Chapter 4 • Exploiting <strong>SQL</strong> <strong>Injection</strong><br />

Or maybe your user has only read access to the data, but the aim of your test is to check<br />

whether data can be modified in an unauthorized manner.<br />

In other words, you have to deal with the fact that the user performing the queries is<br />

just a regular user, whose privileges are far lower compared to the DBA’s.<br />

Due to the limitations of regular users, <strong>and</strong> to fully unleash the potential of several of the<br />

attacks you have seen so far, you will need to obtain access as an administrator. Luckily for<br />

us, in several cases it is possible to obtain these elevated privileges.<br />

<strong>SQL</strong> Server<br />

One of an attacker’s best friends when the target is Microsoft <strong>SQL</strong> Server is the<br />

OPENROWSET comm<strong>and</strong>. OPENROWSET is used on <strong>SQL</strong> Server to perform<br />

a one-time connection to a remote OLE DB data source (e.g., another <strong>SQL</strong> server). A DBA<br />

can use it, for instance, to retrieve data that resides on a remote database, as an alternative<br />

to permanently “linking” the two databases, which is better suited to cases when the data<br />

exchange needs to be performed on a regular basis. A typical way to call OPENROWSET<br />

is as follows:<br />

SELECT * FROM OPENROWSET('<strong>SQL</strong>OLEDB', 'Network=DBMSSOCN; Address=10.0.2.2;<br />

uid=foo; pwd=password', 'SELECT column1 FROM tableA')<br />

Here we connected to the <strong>SQL</strong> server at the address 10.0.2.2 as user foo, <strong>and</strong> we ran the<br />

query select column1 from tableA, whose results will be transferred back <strong>and</strong> returned by the<br />

outermost query. Note that ‘foo’ is a user of the database at address 10.0.2.2 <strong>and</strong> not of the<br />

database where OPENROWSET is first executed. Note also that to successfully perform the<br />

query as user ‘foo’ we must successfully authenticate, providing the correct password.<br />

OPENROWSET has a number of applications in <strong>SQL</strong> injection attacks, <strong>and</strong> in this case<br />

we can use it to brute-force the password of the sa account. There are three important bits<br />

to remember here:<br />

■■<br />

■■<br />

■■<br />

For the connection to be successful, OPENROWSET must provide credentials<br />

that are valid on the database on which the connection is performed.<br />

OPENROWSET can be used not only to connect to a remote database, but also<br />

to perform a local connection, in which case the query is performed with the<br />

privileges of the user specified in the OPENROWSET call.<br />

On <strong>SQL</strong> Server 2000, OPENROWSET can be called by all users. On <strong>SQL</strong> Server<br />

2005, it is disabled by default.<br />

This means that on <strong>SQL</strong> Server 2000 you can use OPENROWSET to brute-force the<br />

sa password <strong>and</strong> escalate your privileges. For example, take a look at the following query:<br />

SELECT * FROM OPENROWSET('<strong>SQL</strong>OLEDB', 'Network=DBMSSOCN;<br />

Address=;uid=sa;pwd=foo', 'select 1')

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!