Forensics On a Cracked Linux Server
This blog entry is the step-by-step process that one administrator followed to figure out what was going on with a cracked Linux server. It's quite interesting to me, since I have had the exact same problem (a misbehaving ls -h command) on a development server quite a while back. As it turns out, my server was cracked, maybe with the same tool, and this analysis is much more thorough than the one I was able to do at the time. If you've ever wondered how to diagnose a Linux server that has been hijacked, this short article is a good starting point.
On the other hand, shutting down the box ASAP makes it much harder to find the guy.
i ng_case_2004-2005
For example, one of Vodafone Greece's first reactions to finding that some of their switching systems had been rootkitted was to remove the offending software. This removal was one of the main contributing factors to the authorities having no chance to ever find the group that had compromised the system, that along with a couple of other screwups led to Vodafone getting fined a pretty hefty sum.
http://en.wikipedia.org/wiki/Greek_telephone_tapp
IEEE Spectrum had a recent article that had MUCH better information than Wikipedia though, I don't have it with me at the moment unfortunately.
retrorocket.o not found, launch anyway?
I had a co-lo rental from Pipex. Linux 2.2. They noticed it was broken in to, cut us off, charged us to re-image the box on which they had left a tar of the drive. OK sounds fair enough, but they re-imaged it with EXACTLY the same Linux 2.2 install and it was infiltrated again by the time I got the email telling me it was back on. I fixed it by hand and never told them lest they charge the company again. Happily I quite soon after.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
[~]:apache$ .bash_history -> /dev/random
.edu).
/tmp.
/usr/bin/hdiutil create -size 1t -fs HFS+ -type SPARSE -encryption -stdinpass -volname objc_sharing_ppc_23 data
/usr/bin/hdiutil attach -readwrite -private -mountroot /tmp -nobrowse -stdinpass "/Library/Application Support/LiveType/LiveFonts/Pro Series/Script.ltlf/data.sparseimage"
/usr/bin/hdiutil detach /tmp/objc_sharing_ppc_23 >> /dev/null
/Library/.
lrwxr-xr-x 1 root wheel 11 Dec 20 2006
I'm pretty sure it is. I didn't use any crazy exploits or anything. It's an old computer that I once had access too when I was in school. It's just a lesser used machine and all I use it for is bit torrent (on a
I created a few users such as "apache" and "sendmail". I'm not claiming to be a haxor by any means, and I just use it, like I said, for bit torrent.
'apache's root directory is actually a mounted DMG file that I have mounted to
With OSX it's pretty easy.
Create DMG:
Attach DMG:
Detach DMG:
128 bit encryption on that home directory. No one really questions large files in
I work in a large, low-end datacenter. Almost all the servers there are rented buy non-technical people, who for some reason feel qualified to run web hosting businesses. There are so many exploits going on there at any given time, we can't really do anything about it--especially as theoretically the customer is responsible. So when they call in because their server is running slow, we usually find a php hijack happening, tell them their server has been compromised, and suggest that they do something about it.
It's pretty appalling. We would need an army of sysadmins--an army which is currently employed already--to really do something about it. Most of what we see are primitive script kiddie hacks, but guess what--that's good enough, and rarely are the perpetrators hunted down.
Who knows what the more sophisticated hackers are up to!
expandfairuse.org
I'm afraid that most software tools are not inherently better than those in 1997: most attackers, and even most successful attacks, are by script kiddies with tools. Even skilled crackers like Mitnick consistently make foolish mistakes. (In Mitnick's case, it was leaving messages mocking his victims and getting the FBI really, really mad at him,, angry enough to actually prosecute.) There are plenty of vaunted crackers who make other amazingly stupid mistakes, both programming and social.
The IRC-bot creators seem to be among the worst of the script kiddies. Frankly, IRC should go the way of open relays. Too much of the traffic is illegitimate to justify allowing it through any firewalls or any ISP provided system. It should be blocked even before non-ISP-server bound SMTP, simply for damage control.
I've seen root's .bash_history symlinked to /dev/null used on a couple of incidents - at least the date of the symlink creation can be used to tell you exactly how long they've been there...
Why can't I mod "-1 Idiot"?
If I suspect something is wrong with my home machines and I didn't care to figure out what happened, I'd just revert the relevant virtual machine to a clean snapshot, disconnect the network connections and patch, restore data etc.
:). Once x86 hardware gets more efficient at running VMs (including IO), I think I'll run everything virtualized. You can't get away with doing that red pill, blue pill thing to my system if I do it first :).
If I did care, I could either suspend the virtual machine or make a snapshot of it.
Virtual machines are cool
If you don't run machines in a VM, I believe the proper way to do forensics is to pull the plug (not sure if attackers would tamper with fsync) then make a copy of the drive using hardware that is certified to block writes to the drive - there are few vendors about selling such hardware and software to go with it. Google should show up a few.
If you do it any other way, any evidence gathered could be considered suspect or tampered with by the defense, or you could accidentally destroy your evidence, or you could be allowing the attacker to destroy the evidence.
Doing what the chap did in the article is definitely not "forensics", anymore than stomping all over a murder scene while touching everything is forensics or a proper investigation.