Una muestra de Regin estaba firmada con un certificado inválido

martes, 9 de diciembre de 2014

De nuevo, poco se puede aportar sobre Regin, ("el nuevo Stuxnet") sobre qué es y cómo funciona. Lo cierto es que varias veces se ha utilizado ese calificativo para amenazas profesionales muy dirigidas, pero pocas veces se está tan cerca. Veamos algunas curiosidades técnicas sobre Regin.

Desde 2010 en el que apareció un la primera "ciberarma", varias veces se ha hablado de "el nuevo Stuxnet", cada vez que se anunciaba malware de características muy avanzadas. Lo cierto es que se han descubierto muchas amenazas similares, todas con sus cualidades más o menos avanzadas en comparación con el "primero" que causó estupor. A pesar de que pocos podrán superar a Stuxnet en su capacidad para explotar vulnerabilidades (sabía explotar hasta cuatro vulnerabilidades desconocidas previamente para Windows, y eso vale mucho dinero), parece que otros le superan en la capacidad de pasar desapercibidos. Regin, con su peculiar uso del registro y su infección "por fases" es sin duda un buen ejemplo de inteligencia en este campo. También en su fórmula para espiar GSM. Veamos otros aspectos interesantes.

Certificados... todo por defecto

Si bien Stuxnet usaba certificados válidos robados y TheFlame sorprendió aún más a todos con la generación de certificados válidos de Microsoft aprovechando una debilidad en su infraestructura PKI... Regin cojea en este sentido. Para cubrir su "primera etapa" en sistemas de 64 bits, Regin utiliza ejecutables firmados. Podría pensarse que se firman para dar credibilidad al fichero e incitar a que el usuario víctima lance el ejecutable... pero luego veremos que no es así. Los certificados son falsos, creados a nombre de "Microsoft Corporation" y "Broadcom Corporation", el 25 de noviembre de 2011. También los ficheros se firmaron y se contrafirmaron en ese momento.
Uno de los certificados usados por Regin

La contrafirma sirve para que un tercero verifique: que el hash del fichero existía en el momento de la contrafirma; que es posterior a la creación del certificado; y que fue creado durante su validez. Así, aunque el certificado caduque, gracias a la contrafirma, la firma del fichero podrá considerarse válida. Para contrafirmar se pueden usar servidores de cualquier CA que disponga de este servicio. A esta le llega una petición de contrafirma desde donde se esté firmando. Al tratarse de Microsoft en este caso, revisando los logs podrían saber desde dónde se solicitó la contrafirma de ese fichero... si es que no se ocultaron.

Con respecto a los certificados, también cabe destacar que los atacantes hicieron algo poco elegante. Puesto que los certificados eran inventados, no los enviaron a firmar por una CA, sino que tenían que crear una CA propia o firmarlos ellos mismos. Para que los certificados fueran válidos en la máquina de las víctimas, estas debían confiar en esa CA, o sea, estar en su listado de certificados raíz de confianza. Regin inyectaba este certificado de CA falso en el manejador de certificados de Windows. Esto implica que, antes de lanzar ese ejecutable firmado, ya confiaba en tener cierto poder sobre la máquina (primero debían poder ejecutar algo para meter el certificado en la lista). Esto resulta cuando menos curioso, y se deduce que existe una "primera etapa antes de la primera etapa" que debe ser la de "infección" (probablemente a través de alguna vulnerabilidad).

Sin embargo, una de las muestras, resulta especialmente peculiar en este sentido.

Certificado raíz y hoja real de una muestra de Regin
"Root Agency" es algo muy característico de la herramienta makecert.exe de Windows, que crea con ese emisor un certificado si se dejan todos sus valores por defecto. También es muy característico porque todos los creados por defecto caducan el 1 de enero de 2040.

Es muy sencillo reproducir estos valores:

Comando para generar un certificado completamente por defecto en Windows. Muy parecido al de Regin

En la muestra, el certificado hoja (emitido por "Root Agency" pero sin valor en su CN) es del 3 de diciembre de 2009, y el raíz, el 28 de mayo de 1996. Algo interesante (como también apuntaba Didier Stevens), es que este último certificado es un viejo conocido: FEE449EE0E3965A5246F000E87FDE2A065FD89D4. Los Windows lo tienen en su carpeta de entidades intermedias de confianza, de forma predeterminada, desde hace años... y ya no es válido. Desde mediados de 2012, Microsoft publicó una actualización que invalida los certificados que usen claves RSA de longitud 512. Este certificado, además, está validado usando MD5 (no en vano fue creado en 1996) por lo que es inválido en todos los Windows. ¿Por qué se sigue distribuyendo en cada sistema operativo?

¿Por qué un certificado inválido?  

Lo que se deduce es que los atacantes crearon con makecert.exe, un certificado el 3 de diciembre de 2009, sin nombre en su CN, pero sin autofirmar. Con esto, lo que consiguieron es que Windows lo firmase con FEE449EE0E3965A5246F000E87FDE2A065FD89D4. Desde 2012, se observa que Windows envía un mensaje de que no se puede garantizar la integridad del certificado. Pare recrear lo que hicieron los creadores de Regin, es tan sencillo como hacer esto:

Recreación para crear el certificado que firmaría una muestra de Regin

Extraña también el uso de un nombre CN (Common Name) "en blanco", cuando en otras muestras han usado algo más llamativo como "Microsoft Corporation". Lo realmente curioso, es que en 2009, este certificado firmado tampoco era válido, pero por otras razones. Si bien por entonces se aceptaban certificados de 512 bits y con MD5, el problema es que este certificado está en certificados de "confianza intermedia" y no en "emisoras raíz de confianza".  Por ejemplo, en un sistema sin la actualización de Windows que invalida los certificados con RSA de 512 bits (previo a 2012), este es el mensaje que aparece.

Certificado usado en Regin, antes de ser inválido en Windows después de una actualización de 2012

Entonces, ¿para qué sirve?

Al parecer, Windows utiliza estos certificados en modo "Test de firma" del sistema operativo. El modo de test significa que cargará cualquier driver en el sistema, aunque no esté convenientemente firmado. Para entrar en el modo "test de firma", es necesario modificar el BOOT.INI. En Windows Vista y posterior será así:

bcdedit.exe -set TESTING ON

y reiniciar. Aparecerá una marca de agua en el escritorio. Cuando Windows se distribuye en modo "Solo para pruebas" ("For test purposes only"), este certificado actúa junto con otro certificado raíz muy conocido cuyo nombre lo dice todo... pero que no se encuentra en los Windows por defecto, solo en los que son "para pruebas":

Certificado Raíz de pruebas de Windows

Pero todo esto no es problema para los atacantes. Si alguien infectado lanzó el programa de forma "manual", sin elevar privilegios, no recibió ninguna alerta por estar firmado por un certificado inválido, ni en 2009 ni en 2012. Solo una comprobación "manual" o lanzarlo con UAC, daría una pista de un certificado inválido. También lo hubiera evitado una previa y correcta configuración de Authenticode y reglas de ejecución adecuadas. ¿Por qué lo hicieron así los creadores de Regin? No existe explicación lógica aparente más que el descuido o que no les parecía algo vital en su objetivo.

Pero este certificado no era el único usado en Regin. En otros casos, como ya se ha mencionado, se supone que debía inyectar en el repositorio de certificados de confianza de la víctima un certificado para validar el ejecutable. Pero nadie aclara cómo se hacía. Obviamente, las víctimas también deberían tener totalmente prohibida la instalación por parte de terceros, de certificados de confianza última en un sistema. Desde el punto de vista del malware, los errores cometidos son:
  • Hubiera sido fácilmente detectable ante una auditoría periódica de certificados instalados.
  • Se hubiera podido evitar eliminando los permisos de instalación o limitando la posibilidad de añadir nuevos certificados de confianza.
En este caso, los atacantes fueron muy descuidados también al utilizar certificados tan fácilmente identificables.

La forma de salir hacia los C&C

Esta característica de Regin nada tiene que ver con los certificados, pero queríamos resaltarla. Es sencillamente genial y sin embargo, ha pasado desapercibida. La comunicación con el C&C no era directa. El atacante había preparado sistemas infectados en la red interna de la víctima, que actuaban como "salidas" al C&C, de forma que el atacado no lanzaba tráfico nunca directamente. Pero no solo eso, sino que las rutas de salida e incluso el protocolo usado iban cambiando. Un ejemplo de fichero de configuración:


El tráfico va saltando hasta dar con un C&C real, en 203.199.89.80. Los códigos después de la palabra reservada "transport", indican qué protocolo se utiliza. Desde ICMP, hasta SMB, pasando por HTTPS...

Creaban redes "virtuales" entre máquinas infectadas para concentrar por ahí el tráfico y que muchas salieran al C&C "todas de una vez". Así se minimiza el tráfico hacia el sistema de control.

Esto además desacopla totalmente el tráfico sospechoso entre el infectado y otros sistemas quizás menos vigilados. En ocasiones, usaban la red de la propia compañía para, por ejemplo, salir por otra oficina en otra parte del país, muy lejos de donde se encontraba el sistema infectado.

En resumen, Regin lo ha hecho muy bien para pasar desapercibido desde hace muchos años (¿2003?) ,pero desde luego, no gracias al uso de sus certificados (punto fuerte de TheFlame) ni vulnerabilidades desconocidas (punto fuerte de Stuxnet), sino a su instalación "por etapas" y fórmula de contacto con los C&C.


Sergio de los Santos
ssantos@11paths.com

No hay comentarios:

Publicar un comentario en la entrada