Reading Time: 7minutes
I've noticed some kind of script kiddie gained access somehow on one of the servers, I administrate. A MS-SQL Scanner tool called sslog, was downloaded in tmp and run with root user credentials.
The cracked victim host is running Debian Linux Squeeze and last security update, I've made about few months ago. Inside /tmp/.a/ directory, I've found 0day MS-SQL scanner called mysqljackpot. Maybe the tool is still private exploit scanner because on the Internet I couldn't find it anywhere.:
# ls -al /tmp/.a
drwxr-xr-x 5 root root 4096 Oct 29 01:10 ./
drwxrwxrwt 10 root root 36864 Oct 29 14:46 ../
drwxr-xr-x 3 root root 4096 Oct 27 21:46 mysqljackpot/
drwxr-xr-x 3 root root 4096 Oct 28 16:58 new/
drwxr-xr-x 3 root root 4096 Oct 29 12:48 pass-multe/
# ls -al /tmp/.a/new/
drwxr-xr-x 3 root root 4096 Oct 28 16:58 ./
drwxr-xr-x 5 root root 4096 Oct 29 01:10 ../
drwxr-xr-x 3 root root 4096 Oct 29 00:58 mysqljackpot/
After further investigations, I've realized ./sslog is actually a frontend scanner program (Synscan 5.02):
Synscan 5.02 (http://www.digit-labs.org/files/tools/synscan/)
by John Anderson
./sslog: getuid(): UID or EUID of 0 required
As you see in order for the scanner to run it requires to be root with superuser privileges.
mysqljackpot is actually a brute force tool which as explained in a file (README.mysql), found in its directory :
Here is content of README.mysql:
MySQL Login Scanner
REQUIRES A FAST SCANSERVER!!! DONT TRY TO RUN THIS FROM A SLOW CONNECTION! ***
Scans for open mysql servers with the following credentials:
Runs on linux.
Requirements: mysql development libraries and headers
Compile (try one of the following depending on your system):
$ ./configure LIBS=-lmysqlclient
$ ./configure LIBS="-L/usr/lib/mysql" -lmysqlclient
$ ./configure LIBS="-L/usr/lib64/mysql" -lmysqlclient
$ ./configure CFLAGS="-lmysqlclient"
$ make linux
./synscan -b <ip block> -p 3306
Inspect Logfile "mysqljack.pot" for open servers.
Oracle MySQL on Windows Remote SYSTEM Level Exploit zeroday
All owned By Kingcope
1. Install mysql client libraries and headers (UNIX)
RedHat based (e.g. CentOS):
yum install mysql mysql-devel
2. Compile the standalone exploit
gcc mysqljackpot.c -o mysqljackpot -L/usr/lib/mysql -lmysqlclient
3. Compile the reverse shell payload (this is required!)
required because the connect back ip and port are hardcoded in the dll:
use mingw on windows or wine
change REVERSEIP and REVERSEPORT to suit your needs. If you change REVERSEPORT you have
to change the port in mysqljackpot.c too (default port: 443).
gcc -c payload.c
gcc -shared -o payload.dll payload.o -lws2_32
copy the payload.dll into the mysqljackpot exploit folder
4. Run The Exploit
./mysqljackpot -u root -p "" -t 22.214.171.124
A valid database admin user and his password are required
for the exploit to work properly.
This exploit is especially useful when used in connection
to a MySQL login scanner, see scanner/README.mysql inside this package.
Be sure to have the firewall open on the desired reverse port
on the attacking machine.
5. Enjoy your SYSTEM Shell!!!
Here is also the header from mysqljackpot.c mysql username brute force tool:
/* Oracle MySQL on Windows Remote SYSTEM Level Exploit zeroday
* Copyright (C) 2012 Kingcope
* Thanks to danny.
Cracker entered directly via SSH after sniffing somehow the root password.
After however, a review of last cmd, I've concluded this case is not very likely, e.g.:
# last |grep -i root
did not found any logs, of unusual root logins, neither there seem to be any unusual activity with logins with other non-root users. Of course it is possible someone logged in as root and used some tool to clean, his tracks with some kind of user log-cleaner tool like the one I've written in past in bash
# mkdir " "
instead of the so trivial
# mkdir /tmp/.a/
Also the name of the directory containing the script kiddie tool /tmp/.a is not selected intelligently, but just done in a hurry, hence I even assume /tmp/.a, is created by some automated SK tool writen in hurry by some Romanian SK Cracker 🙂
On the host there was webmin and usermin running. So;
- my second assumption was it could be someone sniffed a login password via encrypted SSL connection, whether the root logged in via webmin, or somehow exploited usermin (though I should say usermin (which listens by default on port number 20000)
TCP port 20000 on which usermin listens by default is filtered by an iptables rules for all hosts incoming connections, whether webmin logins are permitted only from few IP addresses. Thus this scenario, though more possible than a direct SSH login with root sniffed password still seems to me not very probable.
- Therefore as a third scenario (most likely what happened), I assume some of the PHP forms on the server or some other undefined PHP excecutable via Apache variable script was missing definition.
Actually saw in /var/log/apache2/error.log plenty of re-occuring warnings of existing undefined variables:
[Mon Oct 29 16:30:43 2012] [error] [client 126.96.36.199] PHP Notice: Undefined variable: not_assign in /home/site_dir/www/modules/start.mod.php on line 121, referer: http://site-domain-name.com/start?qid=3&answered_id=4
[Mon Oct 29 16:30:43 2012] [error] [client 188.8.131.52] PHP Notice: Undefined variable: counter_cookie in /home/site_dir/www/modules/start.mod.php on line 130, referer: http://site-domain-name.com/start?qid=3&answered_id=4
[Mon Oct 29 16:30:43 2012] [error] [client 184.108.40.206] PHP Notice: Undefined variable: campaign_cukie in /home/site_dir/www/modules/start.mod.php on line 135, referer: http://site-domain-name.com/start?qid=3&answered_id=4
[Mon Oct 29 16:30:43 2012] [error] [client 220.127.116.11] PHP Notice: Undefined index: actions in /home/site_dir/www/counter/count.php on line 11, referer: http://site-domain-name/start?qid=3&answered_id=4
[Mon Oct 29 16:30:43 2012] [error] [client 18.104.22.168] PHP Notice: Undefined variable: flag2 in /home/site_dir/www/counter/count.php on line 52, referer: http://iqtest.bg/start?qid=3&answered_id=4
Taking this in consideration, I assume the attacker, entered the system finding about the undefined variables, defining them and somehow achieving access to the www-data Apache user shell, and through this shell running some 0day Linux kernel exploit to gain root access and download and install mysqljackpot exploit scanner tool.
Logically as it is common in situations like this, I used rkhunter, chkrootkit and unhide tools to check if the server's main binaries and kernel modules are compromised and is there a rootkit installed (earlier written a post on that here)
In short to do checks, installed rkhunter, chkrootkit and unhide with apt-get (as this is a Debian Squeeze server):
apt-get install --yes rkhunter unhide chkrootkit
Afterwards run in a row:
# for i in $(echo proc sys brute); do unhide $i; done
# rkhuter --check
Reports, of the three ones are like so:
[*]Searching for Hidden processes through /proc scanning
# for i in $(echo proc sys brute); do unhide $i; done
[*]Starting scanning using brute force against PIDS with fork()
[*]Searching for Hidden processes through kill(..,0) scanning
[*]Searching for Hidden processes through comparison of results of system calls
[*]Searching for Hidden processes through getpriority() scanning
[*]Searching for Hidden processes through getpgid() scanning
[*]Searching for Hidden processes through getsid() scanning
[*]Searching for Hidden processes through sched_getaffinity() scanning
[*]Searching for Hidden processes through sched_getparam() scanning
[*]Searching for Hidden processes through sched_getscheduler() scanning
[*]Searching for Hidden processes through sched_rr_get_interval() scanning
[*]Searching for Hidden processes through sysinfo() scanning
HIDDEN Processes Found: 1
Found HIDDEN PID: 4994
Found HIDDEN PID: 13374
Found HIDDEN PID: 14931
Found HIDDEN PID: 18292
Found HIDDEN PID: 19199
Found HIDDEN PID: 22651
[*]Starting scanning using brute force against PIDS with Threads
Found HIDDEN PID: 3296
Found HIDDEN PID: 30790
# chkrootkit -q
/usr/lib/pymodules/python2.5/.path /usr/lib/pymodules/python2.6/.path /lib/init/rw/.ramfs
# rkhunter –check
System checks summary
File properties checks…
Files checked: 137
Suspect files: 0
Rootkits checked : 245
Possible rootkits: 2
Rootkit names : Xzibit Rootkit, Xzibit Rootkit
All checks skipped
The system checks took: 1 minute and 5 seconds
All results have been written to the log file (/var/log/rkhunter.log)
One or more warnings have been found while checking the system.
Please check the log file (/var/log/rkhunter.log)
Reports from unhide and chkrootkit, not seem troubling, however I was concerned about the report from rkhunter – Rootkit names : Xzibit Rootkit, Xzibit Rootkit.
To get some more info on why chkrootkit, thinks, system is infected with Xzibit (which by the way is an artistic alias of a RAP singer from the 1980's 🙂 I check in /var/log/rkhunter.log
# grep -i xzibit /var/log/rkhunter.log
[16:52:48] Checking for Xzibit Rootkit...
[16:52:48] Xzibit Rootkit [ Not found ]
[16:52:56] Found string 'hdparm' in file '/etc/init.d/hdparm'. Possible rootkit: Xzibit Rootkit
[16:52:56] Found string 'hdparm' in file '/etc/init.d/.depend.boot'. Possible rootkit: Xzibit Rootkit
[16:53:01] Rootkit names : Xzibit Rootkit, Xzibit Rootkit
Onwards I checked content of hdparm and .depend.boot and there I don't see nothing irregular. They both are files from legitimate Debian install, I've checked if they belong to a deb packages as well if they are existing on other Debian Squeeze servers I administer as well as on my Debian Desktop notebook, everywhere they're present, hdparm is part of hdparm deb and .depend.boot is loaded by /etc/init.d/rc script, containing some user string references:
# grep -rli .depend.boot *
# dpkg -S /etc/init.d/hdparm
# hdparm: /etc/init.d/hdparm
# dpkg -S /etc/init.d/.depend.boot
dpkg: /etc/init.d/.depend.boot not found.
Another troubling thing was unhide's return:
HIDDEN Processes Found: 1
After a close examination of the system as well as research on the internet, I've figured out this is also a false positive. For sake of not distributing, Script Kiddie tools, which might put in danger other system administrators I will not put a download link to mysqljackpot publicly. Anyways if someone is willing to have it for study purposes, just drop me a mail and I will post you temporary download link to it.
Also as webmin and usermin is not frequently used, I've decided to completely stop and disable them to load on boot.
I've done also a clamav scan with (lowered priority) over the whole file system with:
# nice -19 clamscan -r /*
in order to determine, if there is no PHPShell or some kind of other remote admin Script kiddie script in perl / php etc. installed.
Tomorrow, I will continue investigatin what is happening and hopefully once I got, how the abuser entered the server will update this post.