Careto (The Mask), la ciber-arma (posiblemente) española tenía "fecha de caducidad" (y otras curiosidades)

lunes, 17 de febrero de 2014

Kaspersky lo ha vuelto a hacer (suele ser el laboratorio que detecta e investiga la mayoría de amenazas sofisticadas). Ha desvelado la existencia de un malware interesante. Aunque ya estamos acostumbrados a este tipo de "ciber-armas" (se usa el sufijo "ciber" para darle un aire de sofisticación al malware que ha pasado desapercibido demasiado tiempo), Careto contiene (más allá de ciertas anécdota) características muy interesantes. ¿Algo que no se haya dicho aún? Vamos a intentarlo.

Por qué fue detectado

Careto intentaba utilizar un fallo en versiones no recientes de Kaspersky, por las que (tras enviar un comando especial al driver del antivirus) no se detectan ya los procesos con nombre "services.exe". Esto es lo que llamó la atención de la casa antivirus afectada cuando ninguna detectaba uno de sus componentes. Sin embargo, resulta una técnica un poco inútil por parte del atacante, puesto que para llegar a este punto y manipular el antivirus, otros componentes de la infección ya han tenido que someterse a análisis y podían haber sido detectados. Además, después de intentar este truco, ni siquiera usaban ni renombraban ningún proceso de esa manera. Por último, este fallo está arreglado en 2008, y no es nada habitual en malware intentar explotarlo, por lo que encendió todas las alarmas en Kaspersky. Un intento ingenioso de pasar desapercibido, que precisamente les ha valido la detección.

Cómo se expandía

A través de correos específicos, que intentaban que la víctima visitase una web. Una vez visitada, se redirigía a una página que contenía los exploits. Se intentaban aprovechar diferentes vulnerabilidades en el navegador y sus componentes (cómo no, Java principalmente), intentando ejecutar código de forma transparente. Hasta aquí, como cualquier otro. Luego la víctima era redirigida a páginas falsas de periódicos en subdominios tipo elpais.linkconf.net, www.publico.linkconf.net, y subdominos de tercer nivel con nombres de secciones de los periódicos.

Los detalles de la vulnerabilidad no son públicos
Fuente: http://www.securityfocus.com/archive/1/522413
Lo realmente interesante es que usaban un exploit especial: CVE-2012-0773. Una ejecución en código en Flash. Fue el primer exploit conocido capaz de eludir la sandbox de Chrome. Lo hizo VUPEN para ganar el concurso “pwn2own” hace dos años. Pero los ganadores no dieron detalles del exploit. VUPEN es una "controvertida" empresa que vive de crear exploit y venderlos a gobiernos para el espionaje.

A quién ha afectado

Kaspersky ha "secuestrado" servidores de los atacantes, y así han comprobado cuántas víctimas se han intentado conectar a ellos. Así han concluido que la mayoría provienen de Marruecos, Brasil y Reino Unido, aunque España es una constante en varios de los servidores. 1000 víctimas en 31 países (aunque obviamente habrá y ha habido más). Se comprueba a través de las IP que principalmente se interesaban por instituciones gubernamentales y diplomáticas. Almacenaban los datos de las víctimas en un directorio llamado "ClientsDirectory".

¿Un malware con fecha de caducidad?

Firma sin contrafirma... no se ven los detalles del certificado
Como el buen malware sofisticado, muchos ficheros que componían el malware estaban firmados criptográficamente. En este caso, por TecSytem Ltd (supuestamente de Sofia, Bulgaria). Lo curioso es que no se tiene la certeza de si es una compañía legítima o no, aunque el certificado sea válido y firmado por Verisign. Se han observado dos certificados en el malware; uno válido de desde el 28 de junio de 2011 al 28 de junio de 2013. Otro válido desde el 18 de abril de 2013 al 18 de julio de 2016. Curiosamente, la firma de los ficheros, según se deduce de la imagen de Kaspersky, no se encuentran contrafirmada (no tiene timestamping). Para las muestras no contrafirmadas, significaría dos cosas:

  • No sabemos exactamente cuándo fueron firmados esos binarios.
  • Condena a la firma criptográfica a no ser válida después de la fecha de caducidad del certificado, y por tanto, a que el archivo firmado sea rechazado después de ese día. La contrafirma sirve para precisamente, dar por válido un binario firmado aunque el certificado esté caducado puesto que la contrafirma certifica que se firmó durante el periodo válido del certificado.

Quedará más claro en un ejemplo. El segundo certificado de Careto va desde 18 de abril de 2013 al 18 de julio de 2016. Si se firma un fichero en 2014, pero no se contrafirma, cuando Windows ejecute ese binario el 19 julio de 2016 o cualquier fecha posterior, comprobará la firma y la rechazará por estar fuera del periodo de validez. Si se hubiera contrafirmado, nadie se quejaría, aunque el certificado ya habrá dejado de ser válido (y no se podrá hacer ya nada con él). Esto es lo más habitual para que los programas siembre sean válidos independientemente de que caduque un certificado ¿Por qué no contrafirmar? La contrafirma la valida una empresa externa (VeriSign, por ejemplo), habitualmente, a la que se le envía un hash del fichero y esta devuelve una estructura PKCS#9 que atestigua "esta cadena de bits que representa al binario existía al menos en esta fecha, porque me la enviaron. y así lo firmo yo". Si está dentro del periodo de validez del certificado, siempre se dará por válido el fichero. Quizás querían pasar más desapercibidos aún sin enviar el hash a nadie. En cualquier caso, no disponemos más detalles sobre esta teoría.

¿Desde 2007?

Se ha dicho que este malware ha pasado inadvertido unos siete años. Para estas estimaciones, se suele acudir a la fecha de compilación de los ficheros binarios en sus cabeceras. Esto no es muy fiable, y puede ser modificado. De hecho, suele ser modificado por los atacantes. Así, han encontrado un componente de 2007, aunque la mayoría tiene fecha de compilación de 2012. Uno de los dominios utilizados en los ataques, también fue comprado en 2007.

Componentes de puerta trasera

Todo el malware actual necesita ser controlado en remoto, y para ello se vale de una puerta trasera. La de Careto es especialmente sofisticada, puesto que funciona en Windows de 32 y 64 bits y Mac OS X. Aunque se está diciendo que posiblemente existan versiones para iPad e iPhone, nadie ha visto ninguna muestra concreta. Solo se han visto user-agents de iPads e iPhones en la lista de infectados, pero ya en el C&C como texto... lo que es un indicio, pero ninguna prueba. Puede que una presunta víctima visitara algún C&C sin estar infectado, o que tuviera el user-agent modificado.

Qué podía hacer

De todo. Aquí es bastante sofisticado. Entre "lo típico" está robar las pulsaciones de teclado, tráfico SSL, capturas de pantalla... pero también robaba todo tipo de información criptográfica: VPN, claves PGP, claves SSH, fichero s RDP (para conexiones de escritorio remoto), conversaciones de Skype... y se hacía con una larga lista de ficheros según su extensión.

Cómo estaba estructurado

Algunos de los módulos de SGH, muy extensible
En primer lugar, el componente "Careto", que representaba a los componentes a nivel de usuario. Recibía información (y ejecutaba lo que le indicaba) del C&C, también robaba los ficheros. El otro componente llamado SGH, es el rootkit que operaba a bajo nivel, más sofisticado. Operaban normalmente juntos.

Por último, y basándose en "Shadowinteger's Backdoor" (sbd), que a su vez se basa en el código libre de un clon netcat, implementa otra puerta trasera. Este backdoor estaba preparado para Windows, Mac y Linux. Para instalarse en Linux y Mac OS X, se usaban extensiones de Firefox llamadas af_l_addon.xpi. El SGH es lo que resulta más sofisticado. Sirve como sistema de espionaje completo y además es muy extensible. Por ejemplo, utiliza sistemas de fichero virtuales cifrados para operar, donde guarda logs y extensiones. Se encontraba autocifrado en RC4 con la conocida contraseña "Caguen1aMar".

Cómo se escondía

Una de las técnicas es muy interesante. El malware conseguía registrarse como un módulo COM (ECD4FC4D-521C-11D0-B792-00A0C90312E1, relacionado con el Explorer de Windows), suplantándolo. Todo proceso que pidiera este componente, quedaba "infectado" con el malware inyectando una DLL. Desde ahí, conseguía hacerse pasar a su vez por una DLL conocida, elegida entre un conjunto de nombres legítimos.

Esto significa que a efectos prácticos, a un investigador que observara las DLL cargadas por un proceso le aparecían nombres de DLL y rutas "habituales" del sistema. Pero lo que ocurría es que el malware había conseguido reemplazar en memoria alguna de ellas. Esto es muy novedoso, porque normalmente el malware común se carga como DLL en un proceso, pero sin cuidar su nombre o ruta.

Este componente del malware, hookeaba entonces el creador de procesos y se enganchaba al navegador, actuando ligeramente distinto si se lanzaba iexplore.exe, firefox.exe, opera.exe, netscape o chrome.exe, pero infectándolos a todos. También se enganchaba a nombres como emule.exe.

Otras características y curiosidades


Los nombres de los módulos hacen referencia a "chef" (que implementa la conectividad), "waiter", (camarero) y "dinner" (cena). Los atacantes se ocupaban de cerrar los manejadores en memoria y programar de forma cuidadosa, algo poco usual, pero da una idea de lo estable que querían las máquinas los atacantes. También de que sus servidores pasaran desapercibidos, usando ficheros .htaccess para ahuyentar a ciertas compañías de seguridad e incluso para defenderse de un problema de DoS en Apache que descubrió Kingcope en 2011.


Como anécdota, el uso de ciertas expresiones "muy españolas" ha sido lo más comentado en redes sociales
Indicios muy curiosos sobre la procedencia española del malware.
.De las más sofisticadas

A pesar del uso de estas contraseñas (que podría dar la idea de una programación castiza, casera o descuidada dentro de un ambiente desenfadado) y de la poca profesionalidad que se desprende del uso de un inglés pobre, nos quedamos con esta importante frase en las conclusiones del informe de Kaspersky "In terms of sophisticated, we put Careto above Duqu, Gauss, RedOctober or Icefog, making it one of the most complex APT we observed. For Careto, we observed a very high degree of professionalism in the operational procedures of the group behind this attack, including monitoring of their infrastructure, shutdown of the operation, avoiding curious eyes through access rules, using wiping instead of deletion for log files and so on."


Sergio de los Santos
ssantos@11paths.com

7 comentarios:

  1. Caguenlamar... quién lo iba a decir... ;)

    ResponderEliminar
  2. Por poner Uinstalling ya es un inglés pobre? Enga ya hombre !!

    ResponderEliminar
  3. ¿No era que los comentarios no se compilan? Me mentiste wikipedia cómo pudiste :(

    Y sí, inglés pobre.. "it's" en lugar de "its" o "a"..

    Buen artículo!

    ResponderEliminar
  4. @Anonymous de las 9:44. En este caso, esos comentarios parece que vienen del servidor web donde se recogían los datos, no al código en sí, de ahí que se vean en "texto claro". ¡Gracias!

    ResponderEliminar
  5. Muy sofisticado, por eso han tardado tantos años en encontrarlo.
    Tiene tooooda la pinta de haber sido hecho en españa.

    Un saludo.

    ResponderEliminar
  6. perdonad mi ignorancia, que utilidad tiene obtener el trafico ssl? ;)

    ResponderEliminar
    Respuestas
    1. El tráfico SSL/TLS incluye datos del tipo de contraseñas, cuentas de correo, nombres de usuario y demás. Facebook, por ejemplo, utiliza una capa de SSL/TLS para encriptar los datos de sus usuarios (entre otras cosas).

      Eliminar