SSHD rootkit in the wild | ptrace CVE-2013-0871

Existe un fallo en el kernel Linux, el cual permite escalar privilegios y así plantar un rootkit.
El fallo en sí, lo investigué y verifiqué y es tal y como se cuenta.
No afecta solo a distros RPM como se comenta, sino a todos.
Que quede claro, afecta a TODOS los Linux Kernel que estan descriptos en el CVE, los unicos no afectados son los igual o superiores a los descriptos mas adelante.

El vector de ataque, es el descripto aquí, y es un fallo de kernel Linux:

https://bugzilla.redhat.com/show_bug.cgi?id=911937

Se utiliza para ganar acceso y plantar el rootkit de SSHD que describen aquí:

https://isc.sans.edu/diary/SSHD+rootkit+in+the+wild/15229

Referencias del bug, ataque y parches:

https://access.redhat.com/security/cve/CVE-2013-0871
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0871
http://www.cvedetails.com/cve/CVE-2013-0871/
http://seclists.org/oss-sec/2013/q1/326
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9899d11f654474d2d54ea52ceaa2a1f4db3abd68
En este changelog se ve el fallo corregido
http://www.openwall.com/lists/oss-security/2013/02/15/16

En el link cvedetails, pueden ver todos los kernel afectados, que no son solo 2.6.32 de RHEL, sino también cae Debian y otras distro (trolleo para Nineain).

Básicamente es una falla en Linux Kernel, NO es un error específico de RHEL o CentOS, que se entienda bien. Para tranquilidad de los admin, es local, de acceso local!, ojo, que local puede ser tambien ganando acceso mediante una phpshell metida por un CMS con fallos, y eso tambien es acceso local.
Lo que quiere decir que no es explotable por red TCP/IP sin estar logueado, ok?.

Los kernel no afectados son, igual o mayor que:

3.4.32, 3.7.7 y 3.8rc6, que son los que ya tienen el parche al fallo aplicado desde upstream.
Parece que los únicos afectados son los 32 bit x86, pero es probable, no seguro, dado que el exploit solo se ha probado en esa arquitectura.

Ahora bien, vamos a lo que nos compete, ahi tienen los link con el codigo y demas.

Para mitigar este 0day, tenemos algunas opciones en sistemas RHEL o otros Linux.

1.- Usar un kernel de los descriptos
2.- Mirar bien la actividad en nuestros pc/server
3.- Recompilar el kernel de nuestra distro con el parche que se muestra en el link de seclist.
4.- Usar SELinux para denegar ptrace

Me voy a enfocar en sistemas RHEL que es lo que me compete.
Mi consejo, primeramente, es usar el kernel de elrepo, que segun la version no esta afectado, dado que los demas no están: http://elrepo.org/linux/kernel/el6/i386/RPMS/kernel-ml-headers-3.8.0-1.el6.elrepo.i386.rpm

Ese es el camino mas facil para sistemas productivos hasta que el bug en bugzilla se de como cerrado.
Otra opción es bajar el src del kernel CentOS o lo que usen, modificar ptrace.c con el codigo dado en seclist y recompilar.
Para denegar ptrace usando SELinux: http://fedoraproject.org/wiki/Features/SELinuxDenyPtrace


Como se si he sido infectado?


Para verificar si han sido afectados, hagan esto:

# rpm -q keyutils-libs

Que en mi caso devuelve: keyutils-libs-1.4-4.el6.i686
Ahora bien:

# rpm -Vv keyutils-libs-1.4-4.el6

Que en mi caso devuelve:
.........    /lib/libkeyutils.so.1
.........    /lib/libkeyutils.so.1.3
.........    /usr/share/doc/keyutils-libs-1.4
.........  d /usr/share/doc/keyutils-libs-1.4/LICENCE.LGPL

Ahora, a cada archivo de esos, le hacen rpm -qf, y debe decirles esto:

keyutils-libs-1.4-4.el6.i686, si no lo hace, es que esa libreria, no fue instalada, sino colocada (rootkit).

También pueden directamente hacer:

# rpm -qfV /lib*/libkeyutils*
file /lib/libkeyutils.so.1.4 is not owned by any package

En ese caso, ven que libkeyutils.so.1.4 sería el trojano (es un archivo creado mediante touch para demostrar)

Opcionalmente a eso, puede ejecutar un script para verificar que cosas no pertenecen a un paquete, que entonces, esas "cosas" serian un rootkit:

#!/bin/sh

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
BASE=$(echo "$1" |grep ^/)
RPML=$(mktemp -t rpml.XXXXXXXXXX) || exit 1

if [ -z "$BASE" ] ; then
 echo "Usage: $0 /directory"
 exit 1
fi

if ! [ -d "$BASE" ] ; then
 echo "Usage: $0 /directory"
 exit 1
fi

echo "Searching in $BASE"

rpm -qla |sort > "$RPML"

for TARGET in $(find "$BASE" -type f |grep -v "/proc/"| sed s/\\[/\\\\[/g )
do
 if ! grep -x "$TARGET" "$RPML" 1>/dev/null ; then
  echo "$TARGET"
 fi
done

if [ -f "$RPML" ]; then
 rm "$RPML"
fi

exit 0

Si les dice que esa libreria no es de nada o nadie, o no tiene owner, ese es un rootkit y no fue instalado mediante .rpm.