El misterio de Duqu: Parte VI (Los servidores de comando y control)

Durante las últimas semanas hemos estado ocupados investigando la infraestructura de Comando y Control que usa Duqu.

Ya sabemos ahora que las muestras originales de Duqu usaban un servidor de Comando y Control en India, con un proveedor de Internet llamado Webwerks. Desde entonces, se ha descubierto otro servidor de Comando y Control de Duqu, alojado en un servidor de Combell Group Nv, en Bélgica.

En Kaspersky Lab hemos catalogado e identificado más de 12 distintas variantes de Duqu. Estas se conectan con el servidor de Comando y Control de India, con el de Bélgica, y también con otros, particularmente dos situados en Vietnam y uno en Holanda. Aparte de los mencionados, se usaron otros muchos servidores como parte de la infraestructura, y algunos se usaron como proxys de Comando y Control principales, mientras que otros los usaron los atacantes para saltar alrededor del mundo, dificultando así su rastreo. En general, estimamos que ha habido más de una docena de servidores de Comando y Control activos en los últimos tres años.

Antes de continuar, debemos admitir que aún no sabemos quiénes son los responsables de Duqu y Stuxnet. Aunque hemos analizado algunos de los servidores, los atacantes han cubierto sus rastros con bastante eficacia. El 20 de octubre de 2011, se lanzó una importante operación de limpieza de la red de Duqu. Los atacantes borraron cada uno de los servidores que habían estado utilizando desde 2009, en India, Vietnam, Alemania, Reino Unido, etc. Sin embargo, a pesar de la limpieza masiva, podemos explicarnos cómo funcionaba la red de Comando y Control.

Servidor ‘A’, Vietnam

El Servidor ‘A’ estaba localizado en Vietnam y se usaba para controlar ciertas variantes de Duqu detectadas en Irán. Se trataba de un servidor Linux con plataforma CentOS 5.5. En realidad, todos los servidores de Comando y Control de Duqu que hemos encontrado funcionan con CentOS, versiones 5.4, 5.5 o 5.2. No sabemos si se trata de una coincidencia o si los atacantes tienen cierta afinidad (¿exploit?) por CentOS 5.x.

Cuando comenzamos a analizar la imagen del servidor, lo primero que notamos fue que al menos la carpeta “raíz” y la carpeta de archivos de registro del sistema ‘/var/log/’ tenían un timestamp “última modificación” del 2011-10-20 18:07:28 (UTC+3).

Sin embargo, ambas carpetas estaban casi vacías. A pesar de la modificación fecha/hora en la carpeta raíz, no se encontró en ella ningún archivo modificado ni siquiera próximo a esta fecha. Esto indica que se realizaron ciertas operaciones (probablemente eliminaciones / limpieza) el 20 de octubre alrededor de las 18:07:28 GMT+3 (22:07:28 hora de Hanoi).

Resulta interesante que, mientras que en Linux a veces es posible recuperar archivos borrados, en este caso no encontramos nada en absoluto. No importa cuánto buscamos, los sectores donde deberían estar los archivos se encontraban vacíos y llenos de ceros.

El análisis forzado del espacio residual (no usado) en la partición ‘/’ nos permitió recuperar partes del archivo ‘sshd.log’. Fue algo inesperado y una buena lección sobre Linux y el interior del sistema de archivos ext3: la eliminación de un archivo no significa que no queden partes o rastros, a veces antiguos. La razón para que esto ocurra es que Linux constantemente reasigna los archivos más usados para reducir la fragmentación. Entonces, es posible encontrar residuos de versiones antiguas de un determinado archivo, aun cuando se lo haya eliminado por completo.

Tal como podemos ver en este registro, el root user ingresó dos veces desde la misma dirección IP el 19 de julio y el 20 de octubre. El último registro es bastante próximo a la última modificación de los timestamps en la carpeta raíz, lo que indica que se trataba de la persona responsable de la limpieza del sistema. ¡Bingo!

Entonces, ¿qué hacía exactamente este servidor? No podríamos haber respondido a esta pregunta hasta que analizamos el servidor ‘B’ (ver abajo). Sin embargo, encontramos algo realmente interesante. El 15 de febrero de 2011, openssh-5.8p1 (el código de origen) se copió a la máquina y después se instaló. La distribución es “openssh_5.8p1-4ubuntu1.debian.tar.gz” con un MD5 de ‘86f5e1c23b4c4845f23b9b7b493fb53d’ (distribución de stocks). Podemos suponer que la máquina ejecutaba openssh-4.3p1 que estaba incluido en la distribución original de CentOS 5.2. El 19 de julio de 2011 OpenSSH 5.8p2 se copió al sistema. Se lo compiló y los binarios se instalaron en carpetas (/usr/local/sbin). La distribución de OpenSSH fue nuevamente el stock uno.

El 19 de julio es importante porque indica cuándo se compiló en el sistema el nuevo OpenSSH 5.8p2. Inmediatamente después, los atacantes ingresaron, probablemente para verificar si todo estaba bien.
Una buena forma de mirar el servidor es verificar las eliminaciones de archivos y colocarlas en un gráfico de actividades. En los días que sucedían notables operaciones, se podía ver un pico:

En el caso particular de nuestro servidor, la presencia de varios picos levantó sospechas de inmediato: el 15 de febrero y el 19 de julio, cuando se instalaron las nuevas versiones de OpenSSH, el 20 de octubre, cuando se realizó la limpieza del servidor. Además, también detectamos picos el 10 de febrero y el 3 de abril, cuando sucedieron algunos acontecimientos importantes. Logramos identificar colapsos del “dovecot” en esas fechas, aunque no podemos asegurar que hayan sido causados por los atacantes (¿un exploit remoto para ‘dovecot’?) o por simples inestabilidades.

Por supuesto, respecto al servidor ‘A’ quedan tres grandes preguntas:

• ¿Cómo accedieron los atacantes a este ordenador?
• ¿Cuál era exactamente su propósito y cómo lo (ab)usaron?
• ¿Por qué los atacantes reemplazaron el stock OpenSSH 4.3 con la versión 5.8?
  Al final responderemos a algunas de estas preguntas.

Servidor ‘B’, Alemania

Este servidor estaba situado en Alemania, en un centro de datos que pertenece a una compañía búlgara de alojamiento. Los atacantes lo usaban para acceder al servidor de Comando y Control vietnamita. Las evidencias también apuntan a que hace mucho se lo usaba como servidor de Comando y Control de Duqu, aunque no hemos podido determinar la variante exacta de Duqu que lo hacía.

Al igual que al servidor en Vietnam, a este se le realizó una limpieza profunda el 20 de octubre de 2011. La carpeta “raíz” y la carpeta “etc” tienen timestamps de esta fecha, lo que sugiere de nuevo la eliminación/modificación de archivos en esta fecha. Inmediatamente después de limpiar el servidor, los atacantes lo reiniciaron y volvieron a penetrarlo para asegurarse de que había desaparecido toda evidencia y rastro.

Una vez más, el análisis forzado del espacio residual (no usado) en la partición ‘/’ nos permitió recuperar partes del archivo ‘sshd.log’ . Estas son las entradas relevantes:

Primero, sobre la fecha, el 18 de noviembre. Por desgracia, “sshd.log” no contiene el dato del año. Entonces, no podemos estar seguros si era 2010 o 2009 (sí sabemos que NO fue 2011) a partir solo de este dato. Sin embargo, pudimos encontrar otro archivo de registro que indica la fecha, 2009:

Lo que vemos arriba es un fragmento de una entrada “logwatch” que indica la fecha de la intrusión (23 de noviembre de 2009), cuando el root user ingresó desde la dirección IP desde el 19 de noviembre, en el “sshd.log”. Los otros dos mensajes también son importantes, ya que son errores de “sshd” que indican un intento de desvío en los puertos 80 y 443. Sin embargo, estos se encontraban ocupados. Entonces ahora sabemos cómo se usaban estos servidores como servidores de Comando y Control: los puertos 80 y 443 se desviaban por sshd hacia el servidor del atacante. Estos servidores de Comando y Control de Duqu nunca se usaron como tales, sino más bien como proxys para desviar el tráfico hacia el verdadero servidor de Comando y Control, cuya ubicación aún ignoramos. Este es el cuadro completo:

Respuestas a las preguntas

Entonces, ¿cómo accedieron los atacantes a estos servidores? Una teoría loca apunta a una vulnerabilidad de día-cero en OpenSSH 4.3. Buscando en Google “openssh 4.3 0-day”, encontramos algunos datos interesantes. Uno de ellos es (https://www.webhostingtalk.com/showthread.php?t=873301):

Esta entrada del usuario “jon-f” fechada en 2009, indica una posible vulnerabilidad día-cero en OpenSSH 4.3 en CentOS; incluso publicó registros interceptados del exploit en acción, aunque están codificados y su análisis es difícil.
¿Es este el caso? Conociendo a los autores de Duqu y su inacabable reserva de exploits día-cero, ¿significa también que tienen un Linux día-cero para OpenSSH 4.3? Por desgracia, no lo sabemos.

Si vemos el “sshd.log” del 18 de noviembre de 2009, podemos obtener algunas pistas interesantes. El root user intenta ingresar varias veces con una contraseña desde una IP en Singapur, hasta que finalmente lo logra:

Observa cómo el root user intenta ingresar a las 15:21:11, fracasa un par de veces, y 8 minutos y 42 segundos después lo logra. Esto apunta más a un forzado de la contraseña que a un día-cero. Entonces, la respuesta más probable es que se forzó la contraseña raíz.
Sin embargo, aún queda la tercera pregunta: ¿Por qué reemplazaron los atacantes el stock OPenSSH 4.3 con la versión 5.8? En el servidor de Alemania pudimos recuperar residuos del archivo “.bash_history” justo después de que penetraran en el servidor:

Los comandos relevantes son “yum install openssh5” y “yum update openssh-server”. Tiene que haber una buena razón para que los atacantes estén tan interesados en actualizar OpenSSH 4.3 a la versión 5. Por desgracia, no sabemos por qué. Observamos algo interesante: los atacantes en realidad no conocen la sintaxis de la línea de comandos “iptables”. Además, tampoco parecen estar seguros sobre el formato del archivo “sshd_config”, así que tuvieron que solicitar el manual (“man sshd_config”) y el del Linux ftp client estándar. ¿Qué pasa con el archivo “sshd_config”, la configuración sshd? Una vez más, al buscar en el espacio no utilizado (slack) logramos identificar lo que buscaban. En particular, cambiaron las dos siguientes líneas:

GSSAPIAuthentication yes
UseDNS no

Mientras que la segunda es importante para la rapidez, especialmente cuando se realiza la dirección de puertos por túneles, la primera permite la autentificación de Kerberos. Hemos podido determinar que en otros casos se aplicaron exactamente las mismas modificaciones.

Conclusión

Hemos analizado sólo una fracción de los servidores disponibles de Comando y Control de Duqu. Sin embargo, hemos logrado determinar ciertos hechos sobre el funcionamiento de la estructura:

1. Los servidores de Comando y Control de Duqu empezaron a operar desde noviembre de 2009.
2. Se piratearon muchos servidores en muchos países, como Vietnam, India, Alemania, Singapur, Suiza, Reino Unido, Holanda, Bélgica, Corea del Sur. La mayoría de los ordenadores capturados funcionaban con CentOS Linux. Se penetraron máquinas de 32-bit y 64-bit.
3. Al parecer penetraron en los servidores forzando la contraseña raíz. (No creemos en la teoría del día-cero para OpenSSH 4.3; ¡sería aterrador!).
4. Los atacantes parecen ansiosos por actualizar OpenSSH 4.3 a la versión 5 tan pronto como se hacen del control del servidor capturado.
5. El 20 de octubre de 2011 se realizó una operación global de limpieza. Los atacantes borraron todos y cada uno de los servidores que usaban desde hacía mucho tiempo (2009). El servidor de Comando y Control más interesante, en India, se había limpiado apenas horas antes de que la compañía de alojamiento decidiera hacer una imagen. Si la imagen se la hubiese hecho antes, es posible que ahora conoceríamos mucho más sobre el funcionamiento interno de la red.
6. El “verdadero” servidor nodriza de Comando y Control de Duqu sigue siendo un misterio, así como la identidad de sus dueños.

También nos gustaría plantear unas preguntas a los administradores de Linux y a los expertos en Open SSH en todo el mundo: ¿Por qué actualizarías OpenSSH 4.3 a la versión 5.8 nada más penetrar un ordenador que funciona con la versión 4.3? ¿Qué hace que la versión 5.8 sea tan especial en relación a la 4.3? ¿Tiene esto que ver con la opción “GSSAPIAuthentication yes” en el archivo de configuración?
Esperamos que mediante la cooperación y el trabajo conjunto podamos desentrañar algo de este gran misterio que es el troyano Duqu.
Kaspersky Lab desea agradecer a las compañías PA Vietnam, Nara Syst y a la unidad búlgara Cybercrime por su gentil apoyo en esta investigación. Este trabajo no sería posible sin su participación.
Puedes ponerte en contacto con el equipo de investigación Duqu de Kaspersky Lab en la dirección ““stopduqu ARROBA Kaspersky PUNTO com”.