Are you prepared for the attack of the MySQL worm?

Did you ever think of a worm that could crawl from MySQL server to MySQL server, infecting systems all over the world? MySQL 5.1 adds a feature that makes this scenario possible. I'm not talking about some sort of buffer overflow or similar attack vectors that need knowledge of machine language to be exploited. I'm talking about a worm written completely in pure SQL.

The idea was in my head for a little bit more than a year. But now that I did a proof of concept together with Markus Popp tonight at the MySQL Conference in Santa Clara and words started to spread quickly, I think it's better to just publish this right away (now that MySQL 5.1 is not in production yet).

The idea is actually pretty simple, you just need two components to implement a worm spreading from server to server with pure SQL:

  1. A way to connect to a remote MySQL server from within MySQL: That's what the FEDERATED storage engine can be used for (around since 5.0).
  2. A way to execute a remote procedure without any external help on the side of the target system: That's where EVENTs come into play (added in 5.1, currently in beta).

EVENTs are stored SQL commands that are run by the MySQL server on a configurable schedule (similar to cron jobs on Unix or the Windows task scheduler). They are usually created using the specific CREATE EVENT statement. MySQL however stores all of the information regarding EVENTs in an ordinary table (mysql.event) and can as such be accessed by a remote server through the FEDERATED storage engine.

The worm at work

A MySQL worm is basically just a stored routine that scans the Internet for other MySQL servers by creating FEDERATED tables against random host addresses (or maybe with a more clever pattern than random selection). It has to guess administrative accounts (user name and password) with brute force attacks, which could be implemented quite efficiently in a stored routine. As soon as it gets access to a remote server, the worm inserts its own code into the mysql.event table there and schedules itself for execution.

There's actually one slight problem for the worm: MySQL's event scheduler keeps its information in an internal structure and doesn't check the mysql.event table for updates on a regular basis. The worm needs some patience: Not later than after a reboot of the server the event scheduler will have to reload its internal structure from the table and the worm will be executed.

After that, the possibilities are endless: The MySQL worms could easily communicate with each other through FEDERATED tables, segmenting other ranges of the Internet to scan, sharing updates of itself and coordinating further attacks. Once installed and running, no worm has to wait for a reboot or similar actions again.

Mental exercise or serious threat?

This might all look just like a funny mental exercise. But is it really? Just do a port scan over a small portion of the Internet and realize how many MySQL servers there are that answer, a lot of them with probably not so strong passwords.

I'd like to stress that this should actually not be considered a security hole of MySQL. The worm still needs weakly administered systems to be able to spread. It's more like with those e-mail clients that just make it very easy for the user to click on something wrong. More features means more power, be it for useful or for evil things.

What to do about it?

This all said, I still think it would be a very wise decision to restrict some of the features a little bit to play it safe, even if it's probably not gonna be so simple.

The usual place to actually counter such an attack would be on the targeted server. But that server has actually no idea it's federated to. A connection from a federating server just looks like any other connection from an ordinary client. And you don't want to restrict those other client's possibility to schedule EVENTs.

Of course everything would be solved if the mysql.event table wouldn't be exposed as a table at all and EVENTs could only be scheduled through the dedicated commands to which a federated table has no access. But this would make it much harder to take backups of scheduler settings.

Remains the source of the connection: The FEDERATED storage engine could actually be patched to just disallow any connections to mysql.event tables (and probably the other system tables as well). This would be a restriction that shouldn't be too limiting for users.

But of course an important part of the precautionary measures is also to be taken by those users and administrators, that probably means by you:

  1. It's obvious but probably still has to be stressed again: Disable all default accounts on any installation immediately (yes, even if those default accounts wouldn't allow for a remote connection) and follow the next rules even if you just set up a test account (yes, even if your server is currently not connected to the Internet). You never know what your server might be used for in the future and what you then might to forget to adjust.
  2. Use strong passwords for any account.
  3. Preferably also use stronger user names for your administrative accounts, root and admin are probably the first ones to be tried.
  4. Disable network access to MySQL completely if you don't need it (add skip-networking to your my.cnf file).
  5. Use the host feature of the MySQL GRANTs system to restrict any account to the source addresses it really needs.
  6. Never allow an administrative account (with the SUPER privilege or write access to the mysql system database) to be connected to from any remote host (%).
  7. If your MySQL port has to be open to the Internet, always use a firewall that restricts access to it by source addresses.

If you do follow these rules, you really should be pretty safe regarding remote attacks using brute force to crack your accounts. The more other people also follow the same rules, the lower the probability that such a worm could really start to spread on a wide scale.

By the way, maybe you'd like to attend my session on The Declarative Power of VIEWs today (Wednesday, April 25) at 11:50 in Ballroom C, if you're at the MySQL Conference. I promise not to talk about any worms there.