Latest Tweets

The perils of sharing a mysql server among multiple nginx vhosts.

Introduction

Let’s imagine you find a website that suffers from an SQL-injection vulnerability. Using sqlmap, you extract a list of all the available databases from the vulnerable server. Surprisingly enough, there are plenty. It is quite uncommon to find such a setting: normally, whenever you can exploit an SQL-i vulnerability successfully, you end up having a couple of databases: the information_schema database, and the database feeding the web application. And yet, this time that vulnerable server showed us a list of more than 10 different databases, including the mysql database itself!

Virtual Hosts

After giving it some thought, we realized that almost every single database belonged to a particular virtual server. Thus, let’s suppose we got a list of n databases from the server, such as:

[*] db1
[*] db2
[*] db3

In the previous listing we have renamed the databases, for obvious reasons. In this particular setting, we can infer that there are at least three different virtual servers:

db1.vulnerableserver.domain
db2.vulnerableserver.domain
db3.vulnerableserver.domain

However, some of the databases were not directly associated with a valid internet host name in this fashion. Concretely, we had a database, say, dbx. There was not a dbx.vulnerableserver.domain valid virtual host we could access to from the browser. And yet, according to the internal database and Virtual Host structure analysed, we knew that every single database had to be associated with a valid virtual host.  In order to determine what the valid hostname could be, we asked robtex:

A list of the shared hostnames for the vulnerableserver.domain.

A list of the shared hostnames for the vulnerableserver.domain.

We could clearly see, then, that there was a certain www.dbx.vulnerableserver.domain hostname sharing the same address IP. That one was the Virtual Host we were looking for, so having some valid credentials extracted from the database, we could access as an Administrator inside their web management module.

Uploading a shell

Once we had a valid hostname and some administrative credentials, and seeing that we could upload pdf files, the next logical step would be to upload a php-shell. However, when we tried it the first time we got an error message:

file: shell.php. This is not a valid extension or the filesize is greater than nKb

Of course, some additional checkings had been deployed by the developer to prevent the uploading of PHP scripts. After trying every documented technique to bypass the file extension, and not being able to upload the php shell, we resolved to alter the MIME-type associated with the php file using Burp Suite. So, we replaced:

Content-Type: application/x-php

with

Content-Type: application/pdf

and we left the php shell filename as it was: shell.php. This time, of course, we could upload the php-shell script to the vulnerable server.

 To conclude

It is okay to have a bunch of virtual hosts serving different web applications, but it is a terrible security mistake to have them sharing the same mysql database server. Just one vulnerable web application can allow an external attacker to access all the databases and, in doing so, being able to steal more credentials from other web applications. This way, it is feasible to break the security of robust  web applications running on the same nginx web server even when these web applications are, apparently, secure.