HACK THE SYSTEM: SSHD rootkit in the wild | ptrace CVE-2013-0871

RSS

 Seguime por RSS

22 feb 2013

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.


4 comentarios:

  1. jejeje gracias por la info pero como soy nuevo no entendi mucho igualmente gracias por mantenernos informados se te agradece muchoo

    ResponderEliminar
    Respuestas
    1. Es facil de entender. Básicamente hay una vulnerabilidad de kernel linux que permite a un atacante local elevar privilegios e instalar un rootkit en sshd.
      Los kernel superiores a 3.4.32, 3.7.7, 3.8rc6 no son afectados.

      Eliminar
  2. keyutils-libs-1.5.5-3.fc18.x86_64

    ......... /lib64/libkeyutils.so.1
    ......... /lib64/libkeyutils.so.1.4
    ......... /usr/share/doc/keyutils-libs-1.5.5
    ......... d /usr/share/doc/keyutils-libs-1.5.5/LICENCE.LGPL

    Todas las salidas de rpm -qf devuelven: keyutils-libs-1.5.5-3.fc18.x86_64

    Todo joya en Fedora 18 64; Kernel 3.7.9-201.fc18.x86_64.

    Saludos

    ResponderEliminar
    Respuestas
    1. Entonces todo esta correcto!. Me alegro que no andés infectado.
      Igualmente, los mas propensos son los server con kernel 2.6.32.x que corren algun CMS con bug frecuente como lo es Wordpress o Joomla, este ultimo menos pero no esta excento, de los que conozco Drupal es el de menos fallas frecuentes.

      Eliminar

Dejá tu comentario