JlJmIhClBsr: La curiosa historia de cómo la NSA se delataba a sí misma con EternalBlue

lunes, 31 de julio de 2017

No hay error ni errata en el titular. Y tampoco vamos a hablar de las mismas teorías ya tan machacadas una y otra vez. La cadena de texto en el titular delata en cierta forma cómo creó la NSA el EternalBlue y cómo por extensión WannaCry introducía (probablemente sin querer) una especie de marca que hacía que ambos ataques pudieran haber sido detectados antes de producirse. Y a partir de ahí, una curiosa (por momentos paranoica) historia de una cadena de texto que pasó, de forma interesante como veremos, a convertirse una firma de red de tráfico malicioso.

Ya sabemos todos la historia de EternalBlue. Un exploit entre tantos (parcheado con MS17-10) muy potente de la NSA robado por ShadowBrokers y que sirvió como difusor de WannaCry. Pero no repitamos lo de siempre. EternalBlue es en realidad un fallo en la función SrvOs2FeaToNt del protocolo SMBv1 de Windows. El "kit" del exploit usado por la NSA se descubrió en forma de framework de trabajo en Python, que lanzaba ejecutables ya compilados. Había que utilizar (y retocar) el framework para usar el ataque. Nuestra compañera Sheila Berta ya lo hizo aquí. Uno de estos ejecutables era EternalBlue2.2.0.exe (4e80fa7d98c8e87facecdef0fc7de0d957d809e1). Un fallo que a través de una petición por SMBv1 a un Windows, permitía la ejecución de código. Días después de hacerse público el ejecutable, fue rápidamente analizado

El nivel de detalle en el análisis fue el suficiente como para que poco después se hiciera muy popular la técnica gracias a su difusión como módulo en Metasploit-


Cuando apareció el exploit detallado en forma de módulo en Mestasploit, nos llamaron la atención un par de detalles.
  • El exploit no necesita SMBv2 para funcionar. Aunque envía paquetes disfrazados de este protocolo, no es realmente necesario para nada. Se cree que esta opción era simplemente una cortina de humo de la NSA en el exploit, para confundir (cosa que consiguió puesto que muchos al principio mezclaban SMBv2 como actor en el discurso del ataque, o se le atribuía directamente toda la responsabilidad). Lo pudimos comprobar en el laboratorio por el uso de estas cabeceras que marca el protocolo.
 "\xfeSMB" # SMB2
"\xffSMB" # SMB1

Modificando las cabeceras, el efecto era el mismo. Nuestras pruebas en el laboratorio confirmaron que deshabilitando SMBv2 en el destino, el exploit seguía funcionando. El fallo era exclusivo de SMBv1. Parecía que la NSA se había molestado en introducir SMBv2 para "despistar" y los sucesivos portes a Metasploit y otros lenguajes respetaron este protocolo aunque no fuese realmente necesario.

Muchos todavía afirman que EternalBlue explota un fallo en SMBv2 (así se creía al principio)

  • Por otro lado, algo mucho más interesante. Observando detenidamente el exploit de Metasploit. Vimos este comentario del creador del módulo Metasploit (actualmente han eliminado esta línea en la nueva versión, pero podéis encontrarla en los diferentes repositorios):

Una cadena que era sustituida por x41, al resultar "una firma IDS existente"

Se observa en los comentarios que esa zona del paquete SMB ("echo data") que está creando al vuelo para lanzar a la víctima, se asume como "una firma IDS ya existente" y se tomaba la libertad de anularla. A partir de aquí, un montón de preguntas. ¿Una firma de IDS? ¿Por qué habría de contener ExternalBlue una firma de IDS en su código? ¿Quién había introducido eso? ¿Por qué lo eliminaba el creador del exploit en Metasploit? ¿Esta firma se encontraba también en WannaCry? Nos llamó poderosamente la atención, y empezamos a investigar. Preguntamos a uno de los creadores del módulo (Sean Dillon), que rápida y amablemente nos respondió que parecía una amalgama de caracteres que la propia NSA eligió para rellenar ese campo del exploit (I think it was just a random SMB "ping" packet the NSA chose. I haven't seen the same packet before this). Con respecto a la pregunta de por qué la eliminó sustituyéndola por el carácter x41, la política de Metasploit es limpiar los exploits tanto como sea posible siempre que queden funcionales, para que las soluciones que deben detectar los ataques, no se distraigan con firmas sencillas, sino que vayan al grano. Loable por su parte.

Pero… ¿de verdad esa cadena era aleatoria y la eligió la NSA?

Tenemos por tanto una cadena que aunque aparecía en un campo del exploit original, no le aporta nada (es más, facilita la tarea de detección), y que parecía inventada por la NSA… No cuadra con la filosofía de ocultarse o despistar (usando protocolos innecesarios como SMBv2) y pasar desapercibido. Vayamos más allá. Lo primero era comprobar si realmente esa cadena se encontraba en el EternalBlue original y en otros paquetes:

La cadena se encuentra en los binarios de EternalBlue y EternalCore que hizo públicos ShadowBrokers

La cadena estaba en el binario, y en el tráfico de los exploits, claro. Se encontraba asociada al campo "Echo Data" de SMB... Parecía un valor concreto de ese campo que debía significar algo, pero era extraño porque no aportaba nada al exploit... ni al protocolo en sí. ¿Qué sentido tiene introducir una firma IDS que ya existía, o sea, conseguir que el tráfico fuera fácilmente identificable? El siguiente paso fue comprobar si esa cadena se encontraba también en el tráfico de WannaCry original. Y sí, efectivamente allí estaba, en la captura de una infección lateral.

La cadena en una captura de tráfico de infección lateral de WannaCry,
lo que indica una clara inspiración en el EternalBlue original


Efectivamente, el creador de WannaCry se inspiró en el exploit original, no en el del módulo de Metasploit, porque este último apareció el 14 de mayo… O sea, el creador de WannaCry tampoco reparó en esta cadena que hubiera permitido identificar el ataque.

Teníamos que averiguar qué era esa cadena y qué significaba. \x4a\x6c\x4a\x6d\x49\x68\x43\x6c\x42\x73\x72\x00 es en realidad, “JlJmIhClBsr”. Hicimos varias búsquedas teniendo en cuenta todas sus posibles variables.

Búsquedas de la cadena en sus diferentes formatos

Muy pocos resultados en general. Buscado como cadena hexadecimal (5 resultados), todos relacionados precisamente con EternalBlue o WannaCry. ¿Había la NSA creado un exploit con firma IDS incorporada? No tenía sentido. Buscado la cadena en otro formato, vemos un resultado de 2014 y 2010, aunque solo dos. Si lo buscamos como cadena, encontramos algunos resultados más (415) incluso tan remotos como en tráfico de la BlackHat 2003. Esto se ponía interesante

Indagando en los resultados

Indagando en las coincidencias encontradas en Google, vemos usuarios que compartían pcaps de incidentes en 2010, 2014…, pero nada extraño, nada aparentemente relacionado con el malware. En este momento podría parecer que o bien la NSA había hecho circular el exploit antes de 2017, o bien (más probable) que esa cadena no pertenecía exclusivamente a EternalBlue.. O sea, la cadena existía desde antes de EternalBlue y era emitida en algún punto del protocolo SMB pero parecía que solo bajo circunstancias muy concretas. O, al menos, no resultaba muy común ver esta cadena así como así.

En este formato aparecen más resultados, no muchos, y casi todos asociados a WannaCry
 
Buscando con esta fórmula, obtenemos el mayor número de resultados (aunque no muchos, 1160). La inmensa mayoría, resultan ser reglas Snort para detectar WannaCry. Así que a muchos IDS no les pasó desapercibida esa cadena como detector de WannaCry. Incluso a alguno no les pasó inadvertida como detector de EternalBlue, aunque fue a los que menos. Fijaos en esa última entrada del 5 de mayo (antes de WannaCry, que fue el 12) donde ya se ofrece una regla de Snort basada en esa cadena. Pero si hay evidencias de que esa cadena existía años atrás (2003, 2014, 2010... desarrolladores o usuarios con problemas en SAMBA), ¿por qué todo el mundo la asocia a WannaCry y algunos incluso a EternalBlue como si le perteneciera en exclusiva?

La respuesta…pertenece en cierta forma a un campo poco usado del protocolo SMB

Vamos al grano entonces. JlJmIhClBsr efectivamente es una cadena aparentemente aleatoria (o no, quién sabe si significa algo), pero no ideada por ningún atacante, ni mucho menos por la NSA. Es una cadena creada por Microsoft, y que pertenece en principio a versiones antiguas de Driver Kit oficial de Windows. En estos kits se suele adjuntar fuentes en C de ejemplos de implementaciones. En concreto, esta cadena se encuentra en el ejemplo base de un mini redirector SMB (MRXSMB) de la parte de drivers de sistema de ficheros. En este kit, encontramos un fichero concreto llamado SRVCALL.C, al menos desde 1999.

En este fichero aparece la cadena por primera vez, como parte de código oficial de Microsoft


Este redirector SMB es una especie de cliente SMB de Windows, un ejemplo para que un desarrollador se base en él a la hora de crear sus drivers o clientes derivados. De hecho, y esto es curioso igualmente, el archivo mrxsmb.sys (un driver oficial de Windows) contiene la cadena.

La cadena se encuentra en los drivers MRXSMB de Windows XP y 8, por ejemplo

Lo tenemos igual en un XP que en un Windows 8. No en Windows 10. MRXSMB.SYS dejó de contenerlo tal y como lo hacía en 2010. De hecho está "deprecated" en cierta manera. Se eliminó del WDK en su versión 7600 (posterior al WDK de 2008). La razón para eliminarlo es que usaba el Transport Driver Interface para comunicarse, cosa que está de nuevo en vías de extinción desde Vista en favor del Winsock Kernel.

Pero que se encuentre en el código fuente de un driver oficial de Windows no significa que se utilice durante el proceso de negociación del protocolo y se transmita por la red. Probablemente podrías analizar tráfico SMB de Widnows durante mucho tiempo y no toparte con ese conjunto de caracteres. Tanto es así, que parece que nadie se ha quejado hasta el momento de que, ahora que se le conoce como una cadena de red que identifica a WannaCry, se hayan dado falsos positivos. Aunque claro que los habrá. De hecho los ejemplos encontrados en la red anteriores a 2017, de capturas legítimas de datos previas a EternalBlue, serían hoy por hoy en su mayoría detectadas erróneamente como un ataque EternalBlue o WannaCry a causa de esa cadena.

¿Conclusiones?

De esta curiosidad se pueden desprender algunas conclusiones. Es posible que quien creó el EternalBlue original se basó en el ejemplo del WDK en su versión 7600 de aproximadamente 2008. Buscó un ejemplo de implementación de cliente SMB oficial y trabajó sobre él. Esto a su vez hace pensar que quizás no utilizó técnicas de fuzzing, que puede ser lo más habitual, sino que creó su propia arma desde un kit de desarrollo, lo que podríamos calificar de comportamiento quizás no muy habitual entre los exploiters.

También podemos concluir que al encontrarse una constante en un ejemplo de implementación (y en el código fuente del propio driver oficial de Windows), lo más sensato desde el punto de vista de un atacante sería averiguar para qué sirve y eliminarla, como hicieron los programadores del módulo de Metasploit. Desde ese punto de vista, fue un error de la NSA, porque la cadena no tiene utilidad, es poco conocida, singular y por tanto muy delatora para los IDS. Otro misterio es para qué la usa Windows exactamente (si es que la usa).

Puede que la NSA la dejara allí como despiste cuando se basó en el código fuente del driver, pero en el caso del creador de Wannacry se trata de un error heredado que lo ha hecho fácilmente identificable. De hecho, ya existían reglas Snort (del 5 de mayo) públicas para detener EternalBlue, que hubieran detenido WannaCry si estas reglas se hubiesen adoptado. Otro incomprensible comportamiento que añadir a la poca profesionalidad demostrada de WannaCry en general.

Otra curiosidad es que parece que una cadena original de Windows, se ha convertido en una firma IDS oficial/oficiosa de WannaCry y EternalBlue, sin tener en cuenta los posibles desarrollos legítimos que pueden verse afectados por estar basados en ese drivers y que contienen la cadena. Debe haber muy pocos para que no se haya llamado la atención sobre potenciales falsos positivos. Y esto incluye el propio driver MRXSMB de Windows, que lo incorpora pero parece no emitirlo por la red. Quizás esto habría que analizarlo mucho mejor para entender exactamente el funcionamiento del ejemplo y los drivers.

Bola Extra: Entramos en modo paranoico

De esta curiosidad se puede ir más allá y entrar en modo paranoico. Titulares del tipo "La NSA tuvo acceso a parte del código fuente de Windows para crear EternalBlue" podrían llegar a ser portada si se dejan atrás ciertos matices, detalles y escrúpulos. Y ya que estamos en modo paranoico, el siguiente ejemplo nos llamó igualmente la atención. Conficker es un gusano del que se sabe muy poco y que explota una vulnerabilidad muy similar a EternalBlue, pero parcheada en MS08-67. Investigando, nos detuvimos en una captura de un pcap en 2014 que se llamaba "badguy_traffic".

Conseguimos el pcap de 2014 y efectivamente contiene malware y la cadena en cuestión. Pero no eran pruebas de la existencia EternalBlue en 2014. Bien es cierto que resulta en un intento de explotación de una vulnerabilidad en SMB en la víctima 94.242.232.132 a través de su puerto 445… y tras volcar el binario de esa captura, parece que el ejecutable que descarga este tráfico es una variante de Conficker explotada a través de SMB. En este caso concreto el atacante proviene de 190.56.249.98, de Guatemala. Pero lo curioso es que el exploit SMB aprovechado por Conficker, (habitualmente y en los miles de muestras analizadas desde 2008), no usa esta cadena "JlJmIhClBsr" en su código como campo de "echo data". Al contrario que para WannaCry, esta cadena no está asociada como IDS de Conficker de forma generalizada.. Se trata pues de una implementación muy concreta del método de difusión de un Conficker.

Tráfico de 2014 con la cadena y la descarga del binario Conficker

Otra curiosidad. Existe un fichero "dump" de memoria que fue enviado sin posibilidad de compartición (por tanto eludió VirusTotal, por ejemplo) a un par de páginas de análisis de malware. Esto ya denota cierto nivel de secretismo no muy habitual. Aunque no tiene sentido por otro lado analizar como ejecutable un volcado de memoria… En un dump de este tipo se puede encontrar cualquier cosa mezclada de un proceso de memoria. Aunque no podamos descargar el fichero, las páginas de análisis realizan un "strings" y extraen las cadenas legibles. En este caso en concreto, que data de octubre de 2016, encontramos tres elementos muy significativos. Por supuesto JlJmIhClBsr, pero además también texto público sobre cómo aprovechar un fallo del kernel de Windows. Y además, por varios indicios como por ejemplo el tipo de letra usado, podemos concluir que el usuario era Coreano.

Un "dump" de memoria con la cadena, y visitando páginas de vulnerabilidades probablemente desde Corea

Y para rematar, el modo paranoico más extraño. Esta cadena JlJmIhClBsr, está presente en una página de un organismo gubernamental de Atlanta, donde debería en realidad encontrarse un correo electrónico. ¿Cómo acabó allí?



Sergio de los Santos
Innovación y laboratorio
ssantos@11paths.com

3 comentarios:

  1. Es muy interesante ver de donde ha salido la cadena "JlJmIhClBsr". Gracias por el aporte. La investigación sigue en cuanto su utilización...

    ResponderEliminar
  2. Un excelente anzuelo para falsos positivos, ¡exprofeso!

    ResponderEliminar