Page tree
Skip to end of metadata
Go to start of metadata

Este documento fue actualizado el 24 de febrero de 2014.

Descripción general

Lamentablemente, el departamento de soporte de cPanel ha detectado dos tipos de problemas de seguridad:

  • RPMs comprometidos en los binarios OpenSSH.
  • El directorio libkeyutils comprometido

En ambos casos, los archivos que estos directorios y binarios contienen fueron "troyaneados". Le exortamos encarecidamente a los administradores de sistema que lean este documento para determinar el estado de sus sistemas. Si usted tiene cualquier problema mientras usted realiza estas verificaciones, comuníquese con el soporte técnico para obtener asistencia.

RPMs comprometidos

Hemos determinado que algunos sistemas fueron comprometidos con binarios OpenSSH que fueron "troyaneados". Los binarios OpenSSH parecen contener el troyano Ebury

Ojo:

El tráfico de red que crean los binarios OpenSSH y libkeyutils "troyaneados" son similares.

En cuanto a los sistemas CentOS y Red Hat, hemos determinado que los binarios sshd, ssh, ssh-keygen y sshaskpass aparentan contener código troyano. Este código se usa para obtener credenciales de autenticación para las conexiones entrantes y salientes. Creemos que las claves SSH que estos binarios generan también fueron capturados.

Las características de los troyanos de los RPMs de OpenSSH

Las características más distintivas de los RPMs de OpenSSH "troyaneados" son:

Los RPMs contienen números de versión de 3 dígitos para prevenir que las actualizaciones los sobrescriban.

El siguiente ejemplo indica la salida deseada:

[user@host ~]$ rpm -qa | grep -i ssh
[...]
openssh-clients-5.3p1-81.el6_3.x86_64
openssh-server-5.3p1-81.el6_3.x86_64
openssh-5.3p1-81.el6_3.x86_64

Los siguientes tres ejemplos indican un sistema comprometido:

  • En el siguiente ejemplo, 730 es el número de versión: 

    openssh-askpass-4.3p2-730.el5_67.3
  • En el siguiente ejemplo, 721 es el número de versión: 

    user@host ~]$ rpm -qa | grep -i ssh
    [...]
    openssh-4.3p2-721.el5_61.65
    openssh-clients-4.3p2-721.el5_61.65
    openssh-server-4.3p2-721.el5_61.65
  • En el siguiente ejemplo, 209 es el número de versión: 

    openssh-5.3p1-209.el6_10.41.x86_64
    openssh-clients-5.3p1-209.el6_10.41.x86_64
    openssh-server-5.3p1-209.el6_10.41.x86_64

Los registro de cambios para los RPMs no contienen entradas para la versión instalada.

jd@goat:~/$ rpm -q --changelog openssh-5.3p1-209.el6 | head -10
* Thu Aug 12 2010 Jan F. Chadima <jchadima@redhat.com> - 5.5p1-20
- set correct socket name length in abstract socket (#621691)

Es posible que los RPMs no estén firmados.

La siguiente salida muestra una firma vacía, lo que puede indicar que el RPM no está firmado: 

jd@goat:~/$ rpm -q -i openssh-clients
Name        : openssh-clients
...
Signature   : (none)
...

Advertencia:

Variaciones nuevas de este troyano aparecerán como que están firmadas, y por ende esta verificación sola no es suficiente para determinar si un sistema está comprometido.

Los registros YUM del sistema no tienen un expediente de la instalación de los RPMs.

Ojo:

En una instalación típica de cPanel & WHM, hay varios RPMs que no están firmados y que no contienen registros de cambios enteros. Con la excepción de OpenSSH, un RPM sin firmar no indica un sistema comprometido.

Información importante sobre la arquitectura de su servidor

Antes de ejecutar estos comandos, tome en cuenta que usted recibirá información diferente según la arquitectura de su servidor.

Los sistemas de 32-bit usan lib. Los sistemas de 64-bit usan /lib64. Es posible que /lib64 también tenga un directorio lib que contiene bibliotecas de 32-bit para propósitos de compatibilidad. Si usted no está seguro de la arquitectura de su servidor, usted puede usar el comando arch

[user@host ~]$ arch

Una salida de x86_64 significa que usted usa un servidor de 64-bit. Una salida de i386, i686 o algo similar significa que usted usa un servidor de 32-bit.

Cómo revisar su sistema para buscar el troyano en libkeyutils

Le recomendamos que usted ejecute cada uno de los siguientes comandos para determinar plenamente el estado de su servidor. Aún si usted recibe la salida deseada, le recomendamos que usted continúe ejecutando los otros comandos.

Comando 1

Verifique el paquete keyutils-libs.

Idealmente, no ocurrió un cambio en su sistema sin su consentimiento. Si no ocurrió un cambio, usted debe recibir una salida en blanco.

La siguiente salida indica que su sistema no está comprometido:

[user@host ~]$ rpm -V keyutils-libs
[user@host ~]$

Sin embargo, la siguiente salida indica que algo cambió. Si usted recibe esta salida, usted debe investigar más a fondo: 

 [user@host ~]$ rpm -V keyutils-libs
....L...    /lib64/libkeyutils.so.1

Comando 2

Verifique cuál es el archivo enlazado al archivo libkeyutils.so.1.

Ejecute el siguiente comando para ver cuál archivo está enlazado al archivo libkeyutils.so.1:

[user@host]$ ls -l /lib64/libkeyutils.so.1

El siguiente ejemplo muestra la salida deseada:

lrwxrwxrwx 1 root root 18 Feb 20 12:15 /lib64/libkeyutils.so.1 -> libkeyutils.so.1.3*

Si el archivo /lib64/libkeyutils.so.1 apunta a un archivo con uno de los siguientes nombres, entonces es posible que el servidor esté comprometido:

  • libkeyutils.so.1.9
  • libkeyutils.so.1.3.2
  • libkeyutils-1.2.so.2

Comando 3

Revise las cadenas para todas las bibliotecas libkeyutils.* en busca de elementos relacionados a la creación de redes (networking).

El archivo predeterminado libkeyutils.so.1.3 no debe contener las siguientes cadenas:

  • connect
  • socket
  • inet_ntoa
  • gethostbyname

La siguiente salida indica que su servidor no está comprometido

[user@host ~]$ strings /lib64/libkeyutils.so.1.3 | egrep 'connect|socket|inet_ntoa|gethostbyname'
[user@host ~]$

La siguiente salida indica que es posible que su servidor esté comprometido

[user@host ~]$ strings /lib64/libkeyutils.so.1.9 | egrep 'connect|socket|inet_ntoa|gethostbyname'
gethostbyname
socket
inet_ntoa
connect

Comando 4

Revise si alguno de los procesos sshd actualmente usan segmentos de memoria compartidos.

Ejecute el siguiente comando: 

[root@host ~]# ipcs -mp

La siguiente salida indica que no hay programas que usan segmentos de memoria compartidos: 

[root@host ~]# ipcs -mp

------ Shared Memory Creator/Last-op --------
shmid      owner      cpid       lpid

La siguiente salida indica que hay programas que usan segmentos de memoria compartidos: 

------ Shared Memory Creator/Last-op --------
shmid      owner      cpid       lpid
1769472    root       1975       1975
2129921    root       2931       2940
1736706    root       1965       1965
2162691    root       2931       2940
2195460    root       2931       2940
2228229    postgres   4011       6813

Si hay programas que usan segmentos de memoria compartidos, usted puede usar el comando ps para revisar si cualquiera de los elementos en las columnas cpid y lpid corresponden con los procesos sshd

[user@host ~]$ ps aux | grep 1975
root     1975  0.0  0.0  64080  1172 ?        Ss   Feb17
0:00 /usr/sbin/sshd

Ojo:

Aunque no es típico que sshd use segmentos de memoria compartidos, usted debe investigar más para ver si esto indica que hubo un compromiso.

Comando 5

Usted debe usar un sniffer de red, como tcpdump, para monitorizar el tráfico saliente de UDP del puerto 53 mientras usted entra al shell.

Ejecute el siguiente comando: 

[root@host ~]# tcpdump -Annvvs 1500 -i any udp and dst port 53

Es normal ver el tráfico DNS entre su servidor y sus resolvers locales del archivo /etc/resolv.conf (y posiblemente a otros servidores). Sin embargo, no es normal ver tráfico que contiene cadenas extrañas alfanuméricas, seguidas por la dirección IP desde donde usted entró al sistema.

La siguiente salida indica un compromiso.

Ojo:

Los asteriscos indican elementos importantes a notarse.

El ejemplo del paquete anterior muestra que el servidor de cPanel en 1.2.3.4 envía un paquete UDP en el puerto 53 al host en 72.156.139.154. Usted debe notar la siguiente consulta falsa del ejemplo anterior:

6196g8f43a4facd3561de4gec736fb.5.5.5.5

La cadena 6196g8f43a4facd3561de4gec736fb es una contraseña codificada, y 5.5.5.5 es la dirección IP que fue usada para entrar al servidor de cPanel. Esto indica que el host malicioso en 72.156.139.154 ha aprendido la siguiente información:

  • La dirección IP usada para entrar al servidor, y
  • La contraseña usada para entrar.

Ojo:

Es posible que usted vea dos de estos paquetes en un sucesión rápida: un paquete contiene el nombre de usuario que se usó para entrar al sistema, mientras que el otro paquete contiene la contraseña. El contenido de ambos paquetes será extremadamente similar.
07:54:48.233159 IP (tos 0x0, ttl  64, id 31281, offset 0, flags [DF],
proto: UDP (17), length: 91) **1.2.3.4.43089** > **72.156.139.154.53**:
[bad udp cksum d7a9!]  4619+ A?
**6196g8f43a4facd3561de4gec736fb.5.5.5.5**. (63)

Comando 6

Verifique que cada biblioteca a la que sshd está enlazada pertenece a un paquete conocido.

Usted puede usar el comando ldd para ver con cuáles bibliotecas está enlazado sshd

[user@host ~]$ ldd /usr/sbin/sshd
   linux-vdso.so.1 =>  (0x00007fffb5dfd000)
   libfipscheck.so.1 => /lib64/libfipscheck.so.1 (0x00002aaabc550000)
   libwrap.so.0 => /lib64/libwrap.so.0 (0x00002aaabc753000)
[...]


Los elementos a la derecha de la flecha son bibliotecas hacia las cuales se enlaza sshd. En este ejemplo, las bibliotecas son:

  • libfipscheck.so.1
  • libwrap.so.0

Verifique que estas bibliotecas pertenecen a un paquete válido. Ejecute el siguiente comando con las bibliotecas incluidas: 

[user@host ~]$ rpm -qf /lib64/libfipscheck.so.1
fipscheck-lib-1.2.0-7.el6.x86_64

[user@host ~]$ rpm -qf /lib64/libwrap.so.0
tcp_wrappers-libs-7.6-57.el6.x86_64
  • No labels