full-disclosure - Re: one of my servers has been compromized

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 5 Dec 2011 10:16:16 -0800
From: Tim <tim-security@...tinelchicken.org>
To: Lucio Crusca <lucio@...web.org>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: one of my servers has been compromized

> Well, I actually made 2 mistakes and the second compensated the harm the 
> first did...
> 
> My second mistake I did not mention before was to overlook various other 
> folders in /tmp that were older than /tmp/.m and contained lots of other 
> crap (so they are even more useful in finding the original attack vector, 
> being older).
> 
> However I did save the original launcher found in /tmp and all that older 
> stuff too for analisys.

As soon as you started reading the files in /tmp, you would have
overwritten access times.  Maybe those wouldn't have been useful,
maybe they would have been, who knows.  Basically, as soon as you're
reasonably sure a compromise happened, acquiring forensic images is in
order.

> > If you don't have budget to bring in a professional to do the
> > investigation, then capturing memory is probably not practical (it is
> > easy to do it wrong and trash useful information on disk).  
> 
> Using dd on /dev/mem and piping results through netcat it's not that 
> difficult, and a bit of google explains how to do it the right way, but in 
> my case there are two other problems:

Sending memory image data over the network, such as with netcat is
very important, so it is good you realize that.  Writing to disk (even
an external drive) causes you to lose evidence.

> 1. The attack took place several days ago and it's likely the system ram has 
> been overwritten several time since then

Don't be so sure.  If there are any processes that were running
several days ago and are still running now, they may have unallocated
data in the stack or heap that is related to the attack.  The attacker
may have executed programs that are running but have since been
deleted from disk.  If the system has had a rootkit installed, having
memory available can make analysis a lot easier.

> 2. My server runs in a OpenVZ container (it's a hosted vps)... /dev/mem 
> exists but it's obviously not accessible.

Yes, there are many difficulties with acquiring reliable physical
memory images from Linux hosts these days.  If your system is a VM,
the best way to do it is to simply pause the VM or take a snapshot and
then backup the memory image file that was created on the host.  You
can also just take a copy of the VM's disks and use them as your
forensic image, no DD required.

Outside of that, if you're not familiar with the risks involved with
acquiring a memory image from within a running system though, I would
recommend against it.

tim

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/