HomeCalendarCertificationsColumnsFeaturesForumResourcesVitals
 
Image
 
linkedin_logo.png rss_logo.jpg
twitter_logo.png youtube_logo.jpg
Latest Additions
 
EH-Net Login
Welcome Guest.
Lost Password?
No account yet? Register
Who's Online
We have 49 guests and 1 member online
 
Advertisement

You are here: Home arrow Ethical Hacking Discussions and Related Certificationsarrow Malwarearrow Strange findings on a server compromised by perl.Bossworm (CVE-2010-0738).
EH-Net
May 24, 2013, 02:07:45 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Go back to The Ethical Hacker Network Online Magazine Home Page
 
   Home   Help Calendar Login Register  
Pages: [1]   Go Down
« previous next »
  Print  
Author Topic: Strange findings on a server compromised by perl.Bossworm (CVE-2010-0738).  (Read 2614 times)
0 Members and 1 Guest are viewing this topic.
Negrita
Sr. Member
****
Offline Offline

Posts: 299



View Profile
« on: December 30, 2011, 05:19:44 PM »
I've come across numerous servers over the past month which have been compromised by perl.Bossworm (CVE-2010-0738). All the servers had the same behaviour; they all had hundreds of instances of the pnscan port scanner running looking for JBoss in the HTTP headers of /16 address blocks and dumping them to /tmp. They all had the fly.pl, linda.pl, line.pl and other files associated with this worm all doing their thing.

But one server which was running RHEL 5.4 had some other strange behaviour which was not on the other servers and which I've never seen before. Unfortunately this was the first server that I'd seen with this worm and so I did not think this behaviour strange until I noticed that the others were different. By the time I got suspicious my customer had already formatted and rebuilt their server so I can't do any futher investigating.

The difference between the regular infections and this one all have to do with the passwd and shadow files;

Code:
[root@server1 bin]# cat /etc/shadow
root:$1$gm9ykhCF$5SclI2Qg5qAojg64vLhbG.:15253:0:99999:7:::
root:$1$gm9ykhCF$5SclI2Qg5qAojg64vLhbG.:15253:0:99999:7:::
daemon:*:14672:0:99999:7:::
adm:*:14672:0:99999:7:::
lp:*:14672:0:99999:7:::
sync:*:14672:0:99999:7:::
shutdown:*:14672:0:99999:7:::
halt:*:14672:0:99999:7:::
mail:*:14672:0:99999:7:::
news:*:14672:0:99999:7:::
uucp:*:14672:0:99999:7:::
operator:*:14672:0:99999:7:::
games:*:14672:0:99999:7:::
gopher:*:14672:0:99999:7:::
ftp:*:14672:0:99999:7:::
nobody:*:14672:0:99999:7:::
nscd:!!:14672:0:99999:7:::
vcsa:!!:14672:0:99999:7:::
pcap:!!:14672:0:99999:7:::
rpc:!!:14672:0:99999:7:::
mailnull:!!:14672:0:99999:7:::
smmsp:!!:14672:0:99999:7:::
rpcuser:!!:14672:0:99999:7:::
nfsnobody:!!:14672:0:99999:7:::
sshd:!!:14672:0:99999:7:::
dbus:!!:14672:0:99999:7:::
haldaemon:!!:14672:0:99999:7:::
avahi-autoipd:!!:14672:0:99999:7:::
avahi:!!:14672:0:99999:7:::
ntp:!!:14672:0:99999:7:::
xfs:!!:14672:0:99999:7:::
gdm:!!:14672:0:99999:7:::
sabayon:!!:14672:0:99999:7:::
hacluster:!!:14672::::::
admin:$1$5Mq6lUXu$h6E9E0Am3s.UwK82spdNn/:15253:0:99999:7:::
user:$1$UNIM0eKr$ysqyzTeEZ1MoK7UavDM1O.:15291:0:99999:7:::
egg:$1$kTJWkCDt$Ls8.Xyik.Ao4wQMdLlBXn.:15264:0:99999:7:::
 
[root@server1 bin]# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/bash
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/etc/news:
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
gopher:x:13:30:gopher:/var/gopher:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
nscd:x:28:28:NSCD Daemon:/:/sbin/nologin
vcsa:x:69:69:virtual console memory owner:/dev:/sbin/nologin
pcap:x:77:77::/var/arpwatch:/sbin/nologin
rpc:x:32:32:Portmapper RPC user:/:/sbin/nologin
mailnull:x:47:47::/var/spool/mqueue:/sbin/nologin
smmsp:x:51:51::/var/spool/mqueue:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:4294967294:4294967294:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
haldaemon:x:68:68:HAL daemon:/:/sbin/nologin
avahi-autoipd:x:100:101:avahi-autoipd:/var/lib/avahi-autoipd:/sbin/nologin
avahi:x:70:70:Avahi daemon:/:/sbin/nologin
ntp:x:38:38::/etc/ntp:/sbin/nologin
xfs:x:43:43:X Font Server:/etc/X11/fs:/sbin/nologin
gdm:x:42:42::/var/gdm:/sbin/nologin
sabayon:x:86:86:Sabayon user:/home/sabayon:/sbin/nologin
hacluster:x:90:90:heartbeat processes:/var/lib/heartbeat/cores/hacluster:/bin/bash
admin:x:501:500:Admin:/opt/admin:/bin/bash
user:x:0:504::/home/user:/bin/bash
egg:x:502:502::/home/egg:/bin/bash

1. A new user called "user" had been added with root privileges.
2. A new user called "egg" had been added. I presume this means an eggdrop had been installed.
3. The database user had been deleted. This is how I discovered that the server had been compromised in the first place. :-)
4. The application server user had been deleted.
5. The most curious thing (and the reason I opened this thread in the first place) is that the shadow file had 2 root users both with the same password hash and other properties, while passwd has only one root user.

I suspect that this server was being used as a C&C master instead of a zombie which is why the additional users had been added (in particular the egg user). I don't quite understand why the cracker would want to delete the database and application server users as this immediately caused things to malfunction and caused the customer to open the support case.

What I really want to know from the *NIX guru's here is what effect having 2 root users in the shadow file has on the servers functionality and user authentication?
« Last Edit: December 30, 2011, 05:29:59 PM by Negrita » Logged
CEH, CCSA NG/AI, NNCSS, MCP, MCSA 2003

There are 10 kinds of people, those that understand binary, and those that don't.
unicityd
Full Member
***
Offline Offline

Posts: 156

Bored IT Manager, Crypto Nerd


View Profile WWW
« Reply #1 on: December 30, 2011, 05:52:45 PM »
I don't think the second "root" in the shadow file will affect anything, although I'd still delete it just to be sure.  Since the password is the same for both, there's no question as to which password will be used.  If the passwords were different, I think it would use the first one but there's no defined behavior for that.  The 'pwck' utility can be used to find/remove duplicate entries.

Having duplicate users in /etc/passwd with the same name and different UIDs can be problematic since you won't be sure which of the named users actually owns a file, process, etc.  You can have different users with the same UID and different names; they will end up sharing ownership of files, but their group memberships won't necessarily match since they're determined by name. 
Logged
BS in IT, CISSP, MS in IS Management (in progress)
ziggy_567
Sr. Member
****
Offline Offline

Posts: 361


View Profile
« Reply #2 on: December 31, 2011, 07:42:57 AM »
My first guess as to why there are two 'root' entries in the shadow file is that the script used to modify the passwd/shadow files has a mistake in it. There's really no reason to input the second entry. "pwconv" would fix the issue.

As to why the app/db users were deleted. Maybe its based on the same mistake. Otherwise, I can't see why anyone would remove those users? Did either of the app/db users have uid 503 or 504? It looks like the "user" user had a uid 504 at one point since the group membership is 504. At some point the script edited the uid field to be 0, so its possible the script replaced the db/app user if one of them was uid 504. (that's just a guess)

Another somewhat unusual thing about the passwd file is that there's no user with uid 503. Dunno. That may not be odd in your environment. I also noticed that the 'admin' user has uid of 501 with group membership of 500. Again, this may be normal, but it strikes me as odd as with the default behavior of the useradd command is to have the same uid/gid number.

Good luck!
Logged
--
Ziggy


eCPPT - GSEC - GCIH - GCUX - RHCE - SCSecA - Security+ - Network+
Pages: [1]   Go Up
  Print  
« previous next »
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines
Joomla Bridge by JoomlaHacks.com 		Valid XHTML 1.0! Valid CSS!
Page created in 0.074 seconds with 22 queries.
 
Exclusive Deal

sansfire13_245x90_cw90.jpg
SANSFIRE 2013
June 15 - 22

5% Off w/ Code: EHN_5

SANS Deals 4 EH-Netters
5% OFF Any SANS Course in Any Format!
Coupon Code: EHN_5 Including SANS Rocky Mountain 2013 & SANS Boston 2013
Polls
Compared to this year, 2013 will be:
 
Recent Forum Topics
EH-Net News Feeds
Latest Additions
 
         
Advertisement

© 2013 The Ethical Hacker Network
Joomla! is Free Software released under the GNU/GPL License.