Get Your Umbrella, Because Its Raining MySQL 0-day's

Most of us probably have already seen or heard about the released 0day exploits by ‘kingcope’. For MySQL version 5.1 up unitl 5.5 five exploits where released and a FreeBSD exploit. In this post I’ll focus on the MySQL 0-day exploits. All the exploits can be found here:

Both the remote exploits and the privilege escalation exploit are usable. The buffer an heap overrun give you control over the code execution flow but do not provide a usable payload. It is most likely these exploits are not in this state anymore. This means that at the moment there are 3 working remote exploits and 2 almost done exploits that are causing a risk to fully patched MySQL installations.

This sounds very scary but before we go into total “Team America hands up in the air” panic mode ( lets have a quick look at all the exploits to see what they do:

Privilege escalation exploit (Unix):

* Connect to the MySQL Server
* Create a table named rootme for the trigger
! Create the trigger file in /var/lib/mysql//rootme.TRG
! Crash the MySQL Server to force it to respawn and recognize the trigger file (by triggering the stack overrun)
* INSERT a value into the table so the trigger event gets executed
* The trigger now sets all privileges of the current connecting user in the mysql.user table to enabled.
! Crash the MySQL Server again to force it reload the user configuration
! Create a new mysql user with all privileges set to enabled
! Crash again to reload configuration
* Connect by using the newly created user
* The new connection has ADMIN access now to all databases in mysql
* The user and password hashes in the mysql.user table are dumped for a convinient way to show the exploit succeeded
* As said the user has FULL ACCESS to the database now

The lines starting with the ! character are very clear indicators that something strange is going on on your server. These are indicators you can look for (crashing services and new users). Standard monitor software (like Zabbix) alerts when services are restarted.

Buffer and heap overrun (Unix)

Both these exploits will work post-authentication. Overrun in the buffer_overrun exploit:

grant file on $a.* to 'user'\@'%' identified by 'secret';

Overrun in the heap_overrun exploit:

             "CREATE TABLE table_name (c CHAR(1))", "DROP TABLE t", "ALTER TABLE t DROP c",
             "DELETE FROM t WHERE 1=1", "UPDATE t SET a=a","SET PASSWORD=PASSWORD('p')");

foreach my $command (@commands) {
    for ($k=0;$kquery($c);

As you can see here, both the exploits run one or multiple SQL commands to trigger the vulnerable state.

Remote exploits (Windows):

Both the remote exploits for MySQL only work on the Windows platform. mysqljackpot needs a valid login Both exploit rely on “INTO DUMPFILE”

Summary: As you can see the exploits have a significant impact. As you probably also noticed the lower the exploit is in this blog post the harder they get to detect. Unfortunately this is all the knowledge I have about defending against 0day exploits. But I do think the exploits show behavior that can be monitored in a reasonable fashion until patches have been released. The advantage you have at the moment is that you can checkout what the exploits look like, how they work and what they need to work. Monitor these characteristics and monitor account creation on your server (not just the MySQL service but also Unix/Windows system accounts). Using an IDS – example: snort – should give you a hand with detecting these attacks withing a reasonable amount of time – no updated rules set has been released yet when I wrote this blog post.

Questions? Please do ask. Defending is a difficult job. Maybe on my own I’m not able to give you the information you need but I’m sure we can find an answer. Also, are you someone who has more info or additional information on how to defend against these attacks? Please do contact me so I can add your information to this post.

Cheers, Ruben.