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]

Message-ID: <BLU163-W52A221CCF9D1121CD5FB1CB4B50@phx.gbl>
Date: Mon, 5 Dec 2011 12:15:00 -0600
From: John Jacobs <flamdugen@...mail.com>
To: <tim-security@...tinelchicken.org>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: one of my servers has been compromized

> Why take the risk? You don't know what the attacker actually did
> until you do some analysis. If you do analysis before capturing a
> disk image, you're destroying evidence.
>
> Rebuilding a server is not hard. It has a known quantity of effort
> involved and reliably prevents further intrusion which leverages the
> access previously gained.
>
> On the other hand, conducting an investigation to the point where you
> are reasonably sure an attacker can't continue to leverage that access
> costs a lot of time and money.

I'm conflicted here, though I do agree with what you say.  A simple attack lacking any sophistication whose goal is simply to drop an IRC bot and nothing more may result in undue expense through effort and analysis.  Conversely, assuming that former does not confirm the scope of attack or impact...  I'm conflicted but I agree with your assessment.

Perhaps in this situation one would be more likely to fall back on the output of the defense in depth tools previously recommended.  In this case they are not available so perhaps caution is wise as you have suggested.

I think it reasonable to assume a documented and vulnerable out of date world-accessible version of PHPMyAdmin is likely the initial attack vector.  The Apache/PHP logs should prove this to be the case, so rebuilding a box and disabling PHPMyAdmin may be a reasonable response to this incident without the need for forensic analysis... depending on the organization.  If this box is a singular VPS I think it reasonable, if it's a part of a larger system which could be leveraged as a launching platform to attack other LAN or organizational-owned boxes then by all means a comprehensive analysis should be undertaken.

Tim thanks for your thoughts and reply.

Thanks,
John

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