Message-Id: <ABBB809E-CDA0-4505-BBB6-ED3845CAA916@zero-internet.org.uk>
Date: Mon, 5 Dec 2011 17:36:53 +0000
From: James Condron <james@...o-internet.org.uk>
To: John Jacobs <flamdugen@...mail.com>
Cc: full-disclosure@...ts.grok.org.uk, lucio@...web.org
Subject: Re: one of my servers has been compromized

John,

All good thoughts but can we show the server was rooted?

In otherwords; instead of an attacker getting root and then adding this to a botnet this way is it not more likely that the original attack added the server in one step to avoid the need to do this?

Attackers, from my experience, don't need to worry about rooting when they can find a vuln, exploit and add to a botnet- they don't need to be able to SSH in, nor do they need a shell; the IRC channel takes care of all they need.

Additionally suppose we're looking at your old fashioned shellcode payload- probably  a fair assumption. What happens if this is not using bash, perhaps sh isn't pointing to bash, suppose even csh or zsh.

Lets  also not forget without a proper disassembly of the server pma is only a likely vector.

In this case I tend to suggest that OP takes a stab at the time of compromise to get a backup that can be trusted, takes a new hard drive, restore from backup and upgrade everything that can be possibly upgraded (and so on- the same repair stuff we all do in our sleep; nothing new) and uses the old data to go through the logs, go through the dumped data from memory, assuming fmem and understanding of /proc/iomem



On 5 Dec 2011, at 17:20, John Jacobs wrote:

> 
>> For future reference, and for the benefit of people searching for
>> solutions to similar problems: You've made the most common rookie
>> mistake. You have already trashed potentially critical information
>> about the attack by trying to clean up the server first. Don't do
>> that.
> 
> Tim, while I do believe there is some truth in what you are saying here, I respectfully disagree in that this tends to be a run-of-the-mill IRC bot as evidenced by the Undernet advisory.  This looks like a skiddie-de-jour attack against PHPMyAdmin and nothing to be concerned with regarding cloning disk images and full forensics.  I do respect your input and thoughts though for a more targeted attack; not an IRC bot in /tmp.
> 
> That being said, I strongly believe in preserving bash_history as well as vital log data.  It's best/wise to ship this off to a separate Syslog server.  If you're paranoid turn up stunnel between the devices.  For example and as evidenced by many of the documented attacks here purging of bash_history is common ala 'history -c' after fun.  To thwart this I like the idea of logging to syslog often, ensure permissions are strict for the syslog messages, and shipping the syslog data off to a separate box.  I like to:
> 
> 1) Generate an E-Mail alert when someone logs in, by adjusting /etc/bash.bashrc (or similar based on distribution) to:
> 
> #Email alert for login
> echo -e "Subject: Login from $(/usr/bin/whoami) on $(/bin/hostname) at $(/bin/date)\n\n$(/usr/bin/last -ian 10)\n"|/usr/sbin/sendmail recipient@...mple.com
> 
> 2) Preserve, via Syslog, commands executed at the prompt, by adjusting /etc/profile.  Adjust /etc/syslog.conf or /etc/rsyslog.conf to forward these syslog messages off-box to another asset.  If you're paranoid use stunnel.
> 
> export PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND ; }"'echo "$$ $USER $(history 1)"|/usr/bin/logger -p user.alert -t bash_history'
> readonly PROMPT_COMMAND
> 
> 3) Preserve bash_history by adjusting /etc/profile:
> 
> #Secure the Bash History
> export HISTSIZE=1500
> export HISTCONTROL=''
> export HISTIGNORE=''
> export HISTTIMEFORMAT='%F %T '
> readonly HISTFILE
> readonly HISTFILESIZE
> readonly HISTSIZE
> readonly HISTCONTROL
> readonly HISTIGNORE
> readonly HISTTIMEFORMAT
> 
> 4) Optionally use chattr to set ~/.bash_history to append-only:
> 
>   #Secure .bash_history (poke fun of the while subshell if you wish)
>   /usr/bin/find / -maxdepth 3|/bin/grep -i bash_history|while read line; do /usr/bin/chattr +a "$line"; done
> 
> 5) Use of an IP Recorder, something like daemonlogger, in ring-buffer mode, as a way to record all ingress/egress traffic using a percentage of the disk.  See http://www.snort.org/users/roesch/Site/Daemonlogger/Daemonlogger.html
> 
> I am eager to hear any additional thoughts or methods for security information such as this.
> 
> 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/

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

Powered by blists - more mailing lists