Latest Tweets

Finding and exploiting SQL-i vulnerable servers


SQL-i is well-known inside the pentesting community. There are plenty of tools than can automate the SQL-i testing and exploitation procedures, such as sqlmap, sqlninja, sqlsus and so on. One rule is to find a probable SQL injection point by means of testing a server manually, and once one has a good clue of what sort of SQL-i that particular server does have, launch an automated database takeover tool to speed up the process of data extraction. The normal approach when pentesting a web server and looking for SQL-i injection points is, basically, test a particular server that belongs to the client that has hired the pentester. However, every now and again some servers appear to be compromised, more often than not thanks to an SQL-injection point that no pentester has ever been hired to detect. That is, cyber-criminals are constantly looking for servers that can be exploited to use them for their obscure and criminal activities. Therefore an obvious question comes to mind: how do they find these servers in the first place?

 Google Hacking

 The easiest way to find vulnerable SQL-i servers is using Google. We know that, when an SQL-injection point tends to appear, an sql error is normally reported on the webpage. Depending on the database engine behind the server, that particular message can vary. So let’s assume, for instance, that we are particularly interested in servers that are running the PHP engine and mySQL databases in the .es domain. This google search will do just fine:

site:es and filetype:php and intext:”You have an error in your SQL syntax”

This will show more than 4,400,000 results, according to Google. Obviously, not all of them would be vulnerable servers. The following screenshot shows the first results-page for our previous search. The actual names for the webpages have been stroke out to preserve their integrity:

Probable SQL-i vulnerable servers found using Google.

Probable SQL-i vulnerable servers found using Google.

Testing for the SQL-i injection point

After getting the results from Google, we have to test some of the servers to determine if they are vulnerable to SQL-i and what sort of injection they are vulnerable to. We need to cover our tracks before attempting this, so using an anonymous proxy is mandatory. There are a few that can be used for free:

Again, it is extremely important to remark that these proxy servers, though maybe really anonymous, cannot be trusted at all. If conducting a real pentest for a company, using any of these proxies would certainly expose the company’s data to external attacks or even worse: to real intrusions.

Once we have chosen a working proxy, we have to make sure that our actual Ip address is completely hidden. A good way to achieve that is to visit, and look for the fields “Ip Address” and “Proxy”, as shown below:

Hiding our identity behind and anonymous (not transparent) proxy.

Hiding our identity behind and anonymous (not transparent) proxy.

Browsing to the vulnerable server with our internet browser and conducting a trivial first check would be the next step. When dealing with SQL-i, the first approach is always to feed the web application’s parameters with a character and study its behaviour. In our example, let’s suppose we have done that on one of the servers in the previous results-page list. The server returns a malformed page with this SQL error clearly on display:

[You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘\” at line 5]

Crystal clear: this server does have an SQL-i vulnerability.

Determining the SQL-i injection type

 Before automating the data extraction, we need to make sure what sort of SQL-i we are about to exploit. To do that, all we have to do is feed the vulnerable parameter with different payloads, and analyse its behaviour. Let’s suppose we can feed the vulnerable web application with such a parameter where there is no error:

So far so good; now we need to inject different payloads to determine the type of SQL-i we can exploit later on.

Traditionally, SQL injection has been divided into three main types:

    • Error-based
    • UNION-Based
    • Blind SQL injection.

Thus, let’s try if our vulnerable server is prone to Error-based SQL-i attacks by injecting this payload: or 1 group by concat_ws(0x3a,version(),@@hostname,USER(),@@datadir,@@version_compile_os,floor(rand(0)*2)) having min(0) or 1

The web server responds with a new error, clearly displayed on the web page:

  [Duplicate entry ‘5.1.73-log:hostname:mysql_user@IP_Address:/db/mysql/:pc-linux’ for key ‘group_key’]

Therefore, we have undoubtedly determined that this web server is vulnerable to Error-based SQL-i vector attacks. Not only that; we have been capable of gathering some important information about the vulnerable server, as shown above: the mySQL database’s version, the hostname where it is installed, the username accessing it, the directory where the databases are stored and the sort of OS where it has been compiled on.

Automating the data extraction process

Now that we know what parameter is prone to an SQL-i vulnerability and of what kind, we can use sqlmap to automate the database extraction process. The idea behind this is get valid data we can use to compromise the entire system, such as usernames and passwords. Sometimes we could even get really lucky and read files outside the web application’s scope. Traditionally, another try would consist on opening a remote shell to send commands to the underlying operating system on the vulnerable host. Whatever the main purpose we were intended to, sqlmap can just be fed with the exact parameter and kind of error so that it can omit some of the noisy automated vulnerability tests and just start extracting data right away:

sqlmap –batch –random-agent –proxy=PROXY –dbms=mysql -pvulnParameter –technique=E -u –dbs

Sqlmap detects the vulnerable parameter as an Error-based SQL-i type, and gets the database names with no problems at all:

sqlmap identified the following injection points with a total of 0 HTTP(s) requests:

Place: GET
Type: error-based
Title: MySQL >= 5.0 AND error-based – WHERE or HAVING clause
Payload:vulnParameter=2 AND (SELECT 7112 FROM(SELECT COUNT(*),CONCAT(0x7167697471,(SELECT (CASE WHEN (7112=7112) THEN 1 ELSE 0 END)),0x7171726771,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a)

available databases [2]:
[*] database_compromised
[*] information_schema


 SQL-i is a real threat to companies. It is shockingly surprising the amount of companies that does have at least one SQL-injection point. And the most devastating of all is that they don’t know. Using Google (among other web searchers and crawlers) to determine if our servers are listed is a good start to minimize our level of exposure to external threats and cyber criminals. Running automated tools such as the one described here must be the last step on any single pen testing task. First of all, we have to understand what sort of vulnerability there is, if there is any.

I am in the process of writing a tool to search for hypothetical vulnerable SQL-i servers on the Internet. Stay tuned.