[GRLUG] Linux Systems Compromised

[Michael Mol]

On Mon, Aug 18, 2008 at 4:47 PM, Casey DuBois <casey at grlug.org> wrote:
> Hey GRLUG,
> I received the attached information and thought it may be useful to
> some on the list.
>
> -------- Original Message --------
>
> linux rootkit in a wild...confirmed cases from our friends from other
> universities...
>
> check your boxes...
>
> -------- Original Message --------
>
> -------------------------------------------------------------------------
> DFN-CERT is the emergency response team of the German Research network.
> We are currently handling compromises of linux based grid-clusters at
> German and international research sites. The attackers gained access
> by stolen ssh keys and used local kernel exploits to gain root access.
> Rootkits were installed and SSH keys have been systematically stolen
> and used to compromise further sites.
> A description of the rootkit we found on the compromised hosts we
> examined, is attached below.
> The attackers were stealing ssh keys to compromise more accounts and
> machines. The keys the attacker gained access by are obviously
> compromised.
> If the attacker got root all keys might be compromised if not further protected.
> Artifacts found on compromised hosts:
>   .p2rc       some sort of config file setting aliases for copying
>               stuff by ssh and with ssh-keys provided
>   .phalanx2   loader of the rootkit and probably backdoor
>   .sniff      sniffer log
>   sshgrab.py  python script for collecting ~/.ssh dirs and shell
>               histories of all users if readable There has been a
> rootkit called phalanx for some time which can be found at
> packetstorm:
> http://packetstormsecurity.nl/UNIX/penetration/rootkits/phalanx-b6.tar.bz2
> What we found seems to be a newer version of that rootkit. It also
> uses /dev/mem to manipulate the kernel and modify the hooks for some
> system calls. /dev/shm is used for staging, storing some of the file.
> The same directory is used by the python script.
> If the rootkit was used with the same configuration on your host, you will
> find:
> o The directory '/etc/khubd.p2/' is not listed by 'ls /etc' but can
>   be entered with 'cd /etc/khubd.p2/'
>   Alternatively, the directory '/etc/lolzz.p2' has been used in the
>   incident
> o In '/dev/shm/' there might be files of the attackers o If you create
> a directory named 'khubd.p2' it will also not be
>   shown by 'ls' but you can enter it
> The attackers could use a different configuration. Then the above
> tests will fail. There are some generic signs that a 'phalanx2'
> rootkit is installed on your system:
> o A process with id <PID> is hidden and will not be listed by 'ps'
>   or by 'ls /proc'. But the process will still accept signals and
>   the directory '/proc/<PID' can be entered.
>   Below you find a short script which searches for hidden processes
>   according to these assumptions. (Can I send signal & is the process
>   visible in /proc?)
>   I tested it but of course I can't give a guarantee that it does
>   not yield false positives or false negatives.
> o If there is a hidden directory in '/path' (e.g. '/path/secret')
>   then the link count in '/path' is too high - e.g.:
>     user at linux:/tmp$ ls -al | grep "^d"
>     drwxrwxrwt  7 root root 296 2008-08-01 15:05 .
>     drwxr-xr-x 32 root root 864 2007-12-23 12:58 ..
>     drwxrwxrwt  2 root root  72 2008-07-08 08:23 .font-unix
>     drwx------  2 user user  80 2008-07-25 23:16 ssh-eToaww5944
>     drwx------  2 user user  80 2008-07-08 08:24 ssh-wMQEEV1371
>     drwxrwxrwt  2 root root  72 2008-07-08 08:23 .X11-unix
>     user at linux:/tmp$
>   There are 6 directory references, so the link count should be 6
>   and not 7. If the filesystem is not ext2/3 the link count trick
>   might not work anymore.
> #!/bin/bash
> for PID in `seq 1 65535`; do
>  if kill -0 ${PID} 2>/dev/null
>  then
>    if ls /proc/*/task/*/cmdline | grep "/${PID}/cmdline" >/dev/null
>    then
>      true
>    else
>      CMD=`cat /proc/${PID}/cmdline`
>      echo "PID ${PID} versteckt?! cmdline: '${CMD}'"
>    fi
>  fi
> done
>

Very interesting, but rootkits are nothing new.  They've existed for
well over ten years now; What's interesting about this is the breaking
of the web of trust.  One rooted system gave access to SSH keys that
gave access to more systems, which garnered more SSH keys.  It's worth
noting that a properly-setup

This makes me wonder about the wisdom of using ssh keys to bypass
password restrictions.  It's obviously safer to use ssh keys with
passwords tied to them.

-- 
:wq