☩ Walking in Light with Christ – Faith, Computing, Diary

I’ve been hired, just recently by a company to make them a quick security audit analysis as they complain of having severe Denial of Service problems against an online e-store.

As a mean of securing the local network of the company, the old Linux server had to be replaced with a freshly installed one, which I had to configure to run smooth firewall and create DMZ zone.
The company System Administrator has installed Debian Linux and brought up sshd to allow me to futher take the lead and secure the server
After few hours, I’ve noticed unusual activities. For example processes like:

./a 207 as well as processes like ./ssh 212

debian:~# ps axu|grep -i ./ssh|wc -l
216

On the server and after checking in /etc/shadow I found that users like admin, test had a password string assigned , interestingly even system users like postgresql and man was enabled and ready for login and had a password hash assigned in /etc/shadow

I’ve seen the ./ssh shit before and I know pretty well this is a famous romanian script kiddies tools which circulates in the wild for at least 5 years already.

A quick look up in the usual places, where script kiddies store their files, like: /var/tmp, /tmp, /proc, /sys and /var/run has helped me find the ssh brute forcer the kiddie has issues on the machine in my case it was located in /var/run/2012 inside I found of course the usual sk bad stuff:

root@debian:/var/run/2012# ls1 3 5 a data.conf find internet.txt pass_file screen ssh stricat.txt vuln.txt
2 4 64.37.find.22 atack derbedeu.txt full mfu.txt ronet13.txt ss start tefac.txt x

As well as an archive in /var/run/2012.tgz which was obviously quickly extracted and the brute force ssh tool was started to lookup for some more targets.

As I like keeping script kiddie stuff to expose and share with people, to help them get a better understanding what they can expect on their servers I made a copy of the 2012.tgz brute forcer tool, download the romanian ssh brute forcer shit is here if somebody wants to take a look, though I suggest to be very careful with it as some files might contain rootkits and other unwanted tool.
If someone wants to give it a try be sure not to launch it as root.

Anyways, after finding the abuser I quickly removed all the active users, which were not supposed to be existent on the newly installed system from /etc/shadow changed the server root password, give a reinstall the openssh-server and openssh-client (as I was not if they had not been substituted with some rootkited version), e.g.:

debian:~# apt-get install --reinstall openssh-client openssh-server

Consequentially I killed all the active ./ssh and ./a processes to assure the script kiddie ssh brute forcer is no longer running on the server as well killed all connections to the ssh server manually with kill cmd to the unknown IPs.

Finally to make sure, the server is not rootkited or not backdoored I run some tests with chkrootkit, rkhunter and unhide :

On Debian the 3 tools are available as packages, so this saved me time and I proceeded installing like so:

debian:~# apt-get install rkhunter unhide chkrootkit
...

In few seconds the tools were installed so I used them to check if the server is irreversably damaged or root kitted by the kiddie.

1. unhide

First I used unhide to make sure there are no hidden backdoor processes listening on the server:

for i in $(echo proc sys brute); do unhide $i; done
Unhide 20100201
http://www.security-projects.com/?Unhide
[*]Searching for Hidden processes through /proc scanning
Unhide 20100201
http://www.security-projects.com/?Unhide
[*]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
Unhide 20100201
http://www.security-projects.com/?Unhide
[*]Starting scanning using brute force against PIDS with fork()
[*]Starting scanning using brute force against PIDS with Threads

The above command checks with unhide in /proc and /sys for hidden processes as well as next uses brute option to try to brute force all PIDs on the server attempting to locate listening backdoors processes.

There are 2 more unhide binaries that can be used to check for hidden backdoors, unhide-posix and unhide-tcp

For some reason unhide-posix sys detected the /usr/sbin/rsyslogd -c4 process as some kind of hidden process, which is most probably a false positive, though I can’t be one hundred sure until I try to scan completely the server remotely after mounting the filesystem via ssh and scan it with clamav chkrootkit and rkhunter and even maybe with drweb .

I assume the HIDDEN Processes Found: 1 bells the alarm, however even though I did profound look up on the server with lsof, netstat and fuser cmds I cannot find nothing suspicious any more.

2. chkrootkit scan

Next I used chkrootkit to check if some common rootkit is not installed on the server:

debian:~# chkrootkit
ROOTDIR is `/'
Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not found
Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `crontab'... not infected
Checking `date'... not infected
...

The chkrootkit output displayed thanksfully failed to detect that the system is rootkitted.

3. rkhunter

Finally, tested with rkhunter to assure chkrootkit to expand the range of rootkits the system is scanned for:

debian:~# rkhunter --check
[ Rootkit Hunter version 1.3.6 ]

Checking system commands…

Performing ‘strings’ command checks
Checking ‘strings’ command [ OK ]

Performing ‘shared libraries’ checks
Checking for preloading variables [ None found ]
Checking for preloaded libraries [ None found ]
Checking LD_LIBRARY_PATH variable [ Not found ]
…

After a long screen of consequential rootkit tests, each of which requires the user to press enter rkhunter was unable to detect any rootkits installed on host as well.

Finally to make sure for one more time there are no some backdoors left or some unwanted users still connected to the server I used netstat:

debian:~# netstat -tanp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 7269/sshd
tcp 0 0 192.168.0.1:22 83.228.93.76:54913 ESTABLISHED 24545/1
tcp 0 0 192.168.0.1:22 83.228.93.76:50240 ESTABLISHED 7059/0
tcp6 0 0 :::22 :::* LISTEN 7269/sshd

As the output shows, I coulnd’t find anything suspiciou, still I can’t be 100% percent sure the system is clean and there is no something left from the cracker, probably the Debian server will be re-installed as it doesn’t matter since it’s newly installed Debian machine.

What is amazing is that the server was compromised immediately after it was installed. This means that either the very easy default root password the admin who installed the server was cracked, or his whole network has been compromised by the script kiddie.
Tomorrow will have to investigate further to assure the security breach is closed hopefully once and for all.