domingo, 21 de mayo de 2017

Entonces... ¿Se pueden recuperar los archivos o no? - WannaCry


Estamos tan sólo a poco más de una semana de la primera infección de WannaCry, sin embargo, pasaron tantas cosas en el medio, tantos análisis, tantas hipótesis, tantos reversings, que parece haber sido mucho más tiempo… o al menos esa sensación tengo yo. Entre tanto que se habló durante la semana, han salido algunas herramientas para descifrar y/o recuperar los datos de los equipos afectados por WannaCry. La intención de esta nota, es aclarar varias cuestiones sobre estas herramientas, ya que incluso he visto hasta especialistas en TV decir que ya se había encontrado una forma 100% funcional de recuperar los archivos, y tal afirmación hoy por hoy, lamentablemente, no es del todo cierta.

Para poder entender cualquier mecanismo de recuperación que presentan tales herramientas, es necesario primero comprender cómo funciona WannaCry desde el punto de vista criptográfico.
Tras un análisis y esfuerzo de comprender esto, el martes pasado publiqué en twitter un diagrama que explica la implementación de algoritmos criptográficos que realiza WannaCry. A continuación expongo dicho diagrama y aprovecharé que aquí tengo más caracteres para explicarlo mejor :)




Al infectar un equipo, uno de los primeros pasos de WannaCry, es generar un par de claves RSA-2048 para ese sistema. Luego, por cada archivo que se pretende cifrar, el ransomware genera una clave random AES-128 y la utiliza para cifrar su contenido. La clave AES-128 es cifrada a su vez, por la clave pública de las llaves RSA-2048 generadas en un principio para ese equipo.

Entonces, el contenido del archivo original del usuario (sin cifrar) pasa a ser ahora un nuevo archivo con extensión “.WNCRY”, en cuya estructura se encuentra el contenido original cifrado y la clave AES-128 utilizada, cifrada por la RSA pública. Si quisiéramos descifrar cada archivo, necesitaríamos conocer la clave AES-128 random que se ha generado y utilizado para cada uno. Como esa clave está cifrada por la RSA pública, necesitamos la RSA privada de ese par, para finalmente obtener ese preciado dato.

Ahora bien, ese par de llaves RSA-2048 ¿No fue generado en el equipo infectado? Si y de hecho, allí se encuentra. La clave RSA pública es almacenada en un archivo denominado “00000000.pky” y la clave privada se encuentra en otro archivo, llamado “00000000.eky”. El detalle, es que ese archivo con la clave RSA privada, también está cifrado.

Existe un par de llaves RSA “Master”. La clave RSA pública master es utilizada para cifrar el archivo “00000000.eky”, la mala noticia es que la clave RSA privada master, la conocen sólo los autores del ransomware.

Cuando un usuario paga para recuperar sus documentos, el archivo “0000000.eky” es enviado a los autores y ellos lo descifran con la clave RSA master y entregan al usuario un nuevo archivo denominado “00000000.dky” que es la clave RSA-2048 privada, ahora descifrada.
Ese archivo es utilizado por el “@WanaDecryptor@.exe” para descifrar y restaurar los archivos del usuario.

Podríamos decir entonces, que la implementación de los algoritmos se ha utilizado correctamente. No tenemos debilidades de implementación donde por ejemplo, se utilice una misma clave hardcodeada en alguna parte del código del ransomware o algo que permita fácilmente obtener las claves utilizadas y recuperar los archivos. Entonces… ¿Cómo funcionan las herramientas que intentan recuperar los documentos cifrados?...

Una de ellas es “WanaKiwi” de Benjamin Delpy (@gentilkiwi) que busca en memoria los números primos utilizados para generar la clave privada RSA-2048, e intenta recalcularla. Esto se basa en una debilidad detectada al menos en Windows XP sobre la Cripto-Api de Windows. Entonces, si tienes XP y no has reiniciado el equipo luego de ser infectado, dicha tool es una excelente opción para tratar de recuperar tu información.

Algunas horas después los autores han confirmado que funciona también en Windows 7, pero en lo personal no estoy muy segura de eso, no sé qué otras circunstancias son necesarias para que funcione en ese entorno. Lo he probado en mi test lab con diferentes arquitecturas y samples, y no he logrado que funcione. No soy la única que le ha pasado, varios amigos han hecho sus propios test labs y tampoco han logrado que dicha tool les funcione en Windows 7, sin embargo, si ha funcionado en Windows XP (algo es algo :)).

Descarga de WanaKiwi:  https://github.com/gentilkiwi/wanakiwi/releases.

Por otro lado, la empresa para la que trabajo (Eleven Paths) presentó una herramienta llamada WannaCry File Restorer que puede ayudar a recuperar los archivos de un equipo infectado, si el mismo fue reiniciado/apagado/hibernado inmediatamente después de la infección.
¿Cómo funciona? Sencillamente, se aprovecha de un comportamiento “extraño” del ransomware cuando entra a la subrutina de eliminar los archivos originales (no cifrados) del sistema. WannaCry, en primer lugar, cifra todos los archivos de la forma en que explicamos anteriormente. Luego, mueve todos los archivos no cifrados a la carpeta “temp” (el usuario vé que sus archivos ya no están más, solo quedan los cifrados con extensión .WNCRY) y pasado un breve momento (entre 30 segundos y 1 minuto), el ransomware "vacía" la carpeta temp, o sea, elimina permanentemente los archivos originales.

Si el equipo fue reiniciado/apagado/hibernado inmediatamente después de que el ransomware copia todos los archivos originales a la carpeta temp, entonces WannaCry no llegará a tiempo de eliminarlos. Por ende, quedarán todos los archivos no cifrados en esa carpeta y podrán ser recuperados. La herramienta WannaCry File Restorer, automatiza el proceso de buscar los archivos en dicha carpeta y restaurarlos.

Aquí en un tweet, dejé un video que muestra esta herramienta en acción.
Descarga: https://github.com/ElevenPaths/Telefonica-WannaCry-FileRestorer-Desktop/releases.

En conclusión, si has sido infectado y tu equipo usa un Windows XP (y no has reiniciado) tienes grandes posibilidades de recuperar tu información con WanaKiwi. Si por el contrario, tienes un Windows más moderno y has reiniciado inmediatamente después de la infección, puedes utilizar el WannaCry File Restorer.

Si tu caso no se encuentra en ninguno de los anteriores, entonces, busca tu backup más reciente y sigue adelante :) no borres los archivos que te han cifrado, quizás algún día los autores del ransomware sean arrestados y se publiquen las llaves RSA master que pueden descifrar y recuperar la información de todos.

¡Nos leemos pronto!.
Author: Sheila A. Berta.
Tw: @UnaPibaGeek.
Web: www.semecayounexploit.com.

domingo, 14 de mayo de 2017

WannaCry - Kill Switch o No Kill Switch?


Sin dudas, este fue un fin de semana muy particular. Tal como dije en este Tweet, cuando todo ocurrió, me encontraba dando una charla en CharruaCon, un evento en la ciudad de Montevideo – Uruguay.
Desde allí, no había mucho que pudiera hacer… esa misma noche regresé a Buenos Aires pero acarreando una gripe que no me ha dejado dedicarle el tiempo que me hubiese gustado a este tema.

Sin embargo, mi amiga Gaby (@rove4ever) ha estado aquel viernes aquí y escribió una nota muy interesante sobre este asunto. Esta vez, escribo yo algunas cosas más, de lo que pude analizar sobre los samples de WannaCry que estuve mirando. Aunque tal como mencioné, debido a la gripe bastante molesta que tengo, no es mucho lo que he podido ver.

Cuando en el día de ayer por fin pude meterme en el tema, las discusiones giraban entorno al Kill-Switch de WannaCry. Tal como se explicó en la nota anterior, “Kill-Switch” es una medida anti-sandbox, donde el ejecutable se basa en la respuesta del intento de conexión a una URL para determinar si se encuentra dentro de un sandbox o no. Esto es porque, en un entorno de sandbox, todas las URLs responden como si estuvieran registradas; entonces, si el ejecutable intenta conectarse a un dominio que sabe que realmente no existe, y sin embargo la respuesta es positiva, sabrá que se encuentra en un sandbox y evitará ejecutar su código malicioso.

Los primeros samples de WannaCry que se propagaron, realizaban el kill-switch consultando la siguiente URL: iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com
Claramente, una URL que para ese entonces, nadie había registrado. Si el ejecutable recibía una respuesta positiva al intentar conectarse, entonces, definitivamente se encontraba dentro de un sandbox y el código del ransomware nunca se ejecutaba.

Para ver esto, podemos abrir uno de los primeros samples, por ejemplo el 6a1da955b2eb6be429b2e3b4b515436f5f76fd62802d4e2aa79dc63770d80be0 y dirigirnos a la RVA 004313D0.



Allí se puede identificar la URL utilizada para el “Kill-Switch”.
Como bien ya se comentó en numerosas publicaciones, dicha URL fue finalmente registrada, evitando que una gran cantidad de otros equipos fueran infectados. Ante esta situación, un nuevo sample empezó a circular, en donde se modificaron 2 bytes de ese dominio, ahora la URL era: ifferfsodp9ifjaposdfjhgosurijfaewrwergwea.com

Si consultamos el sample 32f24601153be0885f11d62e0a8a2f0280a2034fc981d8184180c5d3b1b9e8cf y nos dirigimos a la RVA 004313D0 podemos ver dicha modificación.


Después de esto, se comenzó a hablar sobre una variante que no realizaba un Kill-Switch, fue Costin de Kaspersky el primero en decir que tenía samples sin este mecanismo; y sobre eso, “thehackernews” escribió un artículo titulado “WannaCry 2.0 arrives”. Sin embargo, algunas horas después Costin se retractó llegando a la conclusión de que aún no había versiones de WCry sin Kill-Switch.

Pasadas algunas horas más, el investigador Matthieu Suiche muestra un sample con hash 07c44729e2c570b37db695323249474831f5861d45318bf49ccf5d2f5c8ea1cd que se encuentra patcheado para no ejecutar un kill-switch.

Al conseguir dicho sample, consulté la RVA 004313D0 y efectivamente el código del Kill-Switch se había "patcheado" reemplazando su código por 0’s.



Sin embargo, esta versión patcheada de WannaCry funciona parcialmente. Por lo tanto, al menos hasta este momento (noche del domingo), podríamos decir que no se ha encontrado una versión sin Kill-Switch de WannaCry que esté funcionando y propagándose correctamente.

Veremos como continua la novela, por el momento, quería arrojar aclaraciones sobre el asunto del Kill-Switch :-) Saludos!

Author: Sheila A. Berta.
Tw: @UnaPibaGeek
Web: www.semecayounexploit.com.

sábado, 13 de mayo de 2017

¿Qué pasó ayer? Crónicas de un ataque anunciado.

La NSA contaba con una serie de herramientas, entre ellos un exploit conocido como EternalBlue, el cual explota una vulnerabilidad de Windows vinculada al protocolo SMB (Server Message Block) de capa de aplicación, el cual permite tener acceso compartido a archivos, impresoras, etc. y que corre sobre el puerto 445 o por Netbios sobre los puertos 137,138 y 139. Esto significa que si una máquina que está dentro de una red es infectada, esa infección se puede propagar a todas las máquinas que estén en esa red siempre y cuando esas máquinas no estén parchadas. También contaban con un backdoor llamado DoublePulsar que generalmente se instala luego de explotar la vulnerabilidad con EternalBlue.

Un grupo llamado Shadow Brokers consiguió esas herramientas de la NSA y las compartieron en internet en protesta supuestamente por los ataques de Trump a Siria en Abril. Como afectaba a Microsoft hizo un parche para esta vulnerabilidad (parche: MS17-010).



Lo que paso ayer, fue que hubo una campaña presunta de emails que propagaban un malware, el cual estaba programado para escanear el puerto 445 en busca de DoublePulsar y si no estaba, usaba el exploit de EternalBlue y quedaba corriendo en el sistema como un servicio con permisos elevados a la espera de que otras máquinas se conecten a la red y así poder infectarlas. Una vez hecho esto, trataba de conectarse a un dominio especifico mediante un request de HTTP y si se podía comunicar, no hacía nada, pero si no se podía comunicar, infectaba la maquina con un ransomware conocido como WCry o WannaCry, el cual cifra la información de la máquina y pide un rescate a cambio de recuperar los archivos.  

El problema fue que muchos sistemas no estaban parchados y fueron afectados por esta vulnerabilidad. Es altamente recomendable que tengan actualizados los sistemas para evitar esta y cualquier otro tipo de vulnerabilidad.

¿Qué se puede hacer ante este tipo de situaciones, donde el problema ya está instaurado? Aplicar técnicas de Incident Response y Threat Intelligence. A continuación vamos a describir algunos pasos que a tener en cuenta para actuar ante este tipo de situaciones. Es importante destacar que la idea no es buscar a los culpables, sino mitigar el problema, erradicarlo, y lograr que los sistemas función como deberían nuevamente.

En un primer momento, se tiene bastante desconocimiento sobre qué está pasando; solamente se tiene un indicio de que algo anda mal ya que los sistemas no funcionan de la forma en la cual deberían hacerlo.

A partir de ese momento, se inicia una investigación. En el caso del ransomware, es fácilmente detectable ya que el acceso a los archivos queda restringido. En este caso, el ransomware es de tipo “Crypto”, lo que significa que los archivos de las maquinas infectadas quedan cifrados y a menos que se disponga de la llave correcta (o que haya una vulnerabilidad en el algoritmo utilizado para cifrar los datos) los archivos no se pueden recuperar fácilmente y se debe pagar una suma de dinero a cambio de recuperar el acceso a ellos.

El primer paso luego de detectar que el sistema fue infectado con este tipo de amenaza, es tratar de determinar a qué familia pertenece. Puede suceder que no sea tan fácil encontrar el archivo que se usó para infectar las maquinas porque puede suceder que luego de infectar las maquinas el archivo se borre, o puede pasar que la amenaza corra directamente en memoria por lo cual es más difícil encontrar artefactos que permitan analizarlo. Por estas razones, que recurrir a otros métodos. Los ransomware generalmente dejan una nota, en formato .txt, .png o .html que dan más información a la víctima sobre qué pasó y como puede recuperar los archivos. Una vez localizado estos archivos se trata de vincular a una familia existente o se trata de determinar si es una amenaza nueva. En este caso, los archivos cifrados quedaron con extensión “.wncry” y se observaron las siguientes imagenes:



Haciendo un breve análisis buscando en fuentes públicas, se puede concluir rápidamente que la amenaza se trató en este caso de WCry o WannaCry. Esta amenaza se reportó por primera vez en Marzo de 2017 y cifraba los archivos dejándole como extensión “.wcry”. Este dato en conjunto con otros nos pueden dar un indicio de que la amenaza que se detectó ayer es una variante de WCry, ya que se detectan cambios respecto a la versión original, pero pertenece a la misma familia ya que su comportamiento es similar.

Una vez identificada la familia, se puede tratar de buscar si existe ya algún tipo de programa que permita descifrar los archivos fácilmente. En este caso, no se encontró aun un programa que ayude a descifrar los archivos. También se trata de determinar si la amenaza se trata de un ataque dirigido a una víctima particular o si es un ataque masivo. En este caso, se pudo determinar que era un ataque masivo. El siguiente paso es encontrar indicadores que nos puedan ayudar a entender mejor cómo es que la amenaza logró entrar a los sistemas y cómo fue que las soluciones de seguridad no lo pudieron detectar o frenar a tiempo. En este caso, se lograron encontrar indicadores (hashes, bitcoin wallet, etc.) que nos permitieron crear reglas de YARA para poder alertarnos sobre cualquier muestra subida a internet que esté vinculada con este ataque. Así, se pudieron estudiar las muestras y entender mejor cómo funcionaba. Algo importante a tener en cuenta también, es tomar una computadora infectada y fijarse el log de eventos para detectar cualquier actividad sospechosa. En este caso, se pudo determinar en qué momento se dieron las actividades sospechosas y como estaba corriendo la amenaza (corría como un servicio con accesos privilegiados).

Teniendo las muestras, se realizaron análisis para determinar cómo funciona la amenaza y se pudo observar que había muestras que solamente cifraban la información, y otras muestras que trataban de conectarse a un dominio particular y luego cifraban la información.


Esto nos dio la pauta de que se trataba de un malware que tenía dos componentes; que no era puramente un ransomware sino que había otro módulo que realizaba otras acciones, y este módulo tenia embebido el ransomware que luego era “droppeado” en el sistema.

Realizando análisis sobre este dropper se pudo determinar que lo que estaba haciendo es explotar la vulnerabilidad antes mencionada; el servicio corría en los sistemas en busca de nuevos máquinas para explotar y droppear el ransomware. El dominio era utilizado para decidir si iba a infectar o no los sistemas con el ransomware. Primero realizaba un GET al dominio y si no se podía conectar, comenzaba la infección. Si no, no infectaba los sistemas con el ransomware. Lo que sucedió, es que este dominio estaba sinkholeado (caído) entonces al tratar de realizar la comunicación y no encontrar respuesta, infectaba los sistemas.  Afortunadamente, un investigador de seguridad registró el dominio, evitando que muchos otros sistemas que eran vulnerables fueran víctimas de esta infección. A esta medida se la menciona “Kill Switch”.


Esta medida es conocida ya que también la implemento un malware conocido como Necurs y se cree que se la utiliza como medida anti-sandbox. Al analizar una amenaza que se conecta a una URL en un sandbox, lo que sucede es que si la URL está registrada o no, el sandbox responde igual, por lo cual la amenaza se podría dar cuenta fácilmente si está siendo sandboxeada. Al registrar este dominio, lo que sucedió es que se generó este efecto: La amenaza al recibir una respuesta de ese dominio, pudo interpretar que estaba siendo sandboxeada con lo cual se finalizaba en vez de infectar el sistema.

Desafortunadamente, si los sistemas usan un proxy, no van a poder encontrar el dominio con lo cual se infectarían. A su vez, hay investigadores que encontraron variantes de esta amenaza que no cuenta con el “Kill Switch” por lo cual si no están protegidos, se infectarían de todas formas.

Entendiendo ya como funciona la amenaza, habiendo hecho todo este trabajo de Threat Intelligence, se pueden entonces decidir qué medidas tomar al respecto. Las medidas a tomar dependen de cada organización, la cual evaluará que decide perder o ganar a corto plazo para poder erradicar la amenaza. Algunas de las medidas que se podrían haber tomado incluyen aplicar el parche pero sin conectar la computadora a la red infectada, ya que el exploit infectaría la computadora antes que el parche sea implementado, con lo cual esto se debería hacer en una red limpia o mediante un dispositivo como un pendrive de manera offline. Esta medida evita que los sistemas que no fueron vulnerados se infecten, pero para aquellos que ya fueron vulnerados no sirve. Otras medidas incluyen bloquear puertos (con la consecuencia de perder funcionalidad en los sistemas), crear reglas con los indicadores para que una vez detectados puedan bloquearse, etc.

Para finalizar, es importante reflexionar sobre el ataque, el cual tuvo lugar gracias a que una herramienta desarrollada por la NSA, que mientras estuvo en sus manos no tuvo trascendencia y que luego de que fuera propagada masivamente cause semejantes estragos.

Esperemos que este suceso haya servido para concientizar a la gente respecto a la importancia de aplicar medidas de seguridad en sus sistemas, y que no hay una sola forma de resolver las cosas.

Autor: Gabriela Nicolao.
https://twitter.com/rove4ever

sábado, 6 de mayo de 2017

Reversing III: Expandir secciones del ejecutable

En la segunda entrada de esta serie de notas de reversing estuvimos viendo las cabeceras PE, una de ellas es “Image Section Header” que contiene información sobre las secciones del ejecutable. Nuestro objetivo esta vez será alterar cierta información de esa cabecera para que podamos expandir una sección ya existente dentro del ejecutable ¿Para qué? Para tener el espacio suficiente para inyectar código propio dentro de cualquier .exe.

Cabe mencionar que hacer esto no es necesario si el código que planeamos inyectar cabe sin problemas en algún espacio que pudo haber quedado sin utilizar en una sección. Por ejemplo, podríamos encontrarnos con que al final de una sección hay una gran cantidad de bytes con el opcode 90 o 00, lo cual implica que es un espacio que no contiene instrucciones necesarias para el programa y entonces podríamos aprovecharlo para inyectar el código que deseemos en ese lugar.

Mayormente esto no ocurrirá, por lo tanto, tendremos que hacernos el espacio manualmente expandiendo o creando una nueva sección.

EXPANDIR UNA SECCIÓN
La primera pregunta que surge al momento de expandir una sección es: ¿Cuál de todas? La mejor respuesta es: la última. Si expandimos cualquier sección que no sea la última, nos encontraremos con varios pasos más que tendremos que hacer, tal como actualizar todas las RVA que apuntan al comienzo de cada una de las secciones, etc. Por lo tanto, lo mejor es que alarguemos la última sección.

Para ello abrimos el LordPE, presionamos en “PE Editor” y elegimos el ejecutable que vamos a modificar.


Allí, hacemos click en “Sections” para ver la información de todas las secciones dentro del ejecutable.


En la ventana que allí vemos, hacemos click secundario en la última sección y elegimos la opción “Edit section header…” del menú desplegable.

Al hacerlo, se nos abrirá la siguiente ventana:


Desde allí podremos modificar todo lo que necesitamos para alargar la sección. El primer paso es hacer que la misma sea “writeable” y “readable” (escritura y lectura) y además su contenido se ejecute como código.

Para ello editaremos los Flags: hacemos click en el botón “…” y marcamos los casilleros indicados en la siguiente imagen:


Presionamos OK para guardar y nos quedamos en la ventana de “Edit Section Header”. Allí alargaremos esa sección, sumando tanto a RawSize como a VirtualSize los bytes que necesitemos. En mi caso, sumaré 100h a ambos campos, quedando de la siguiente manera:

ANTES:


DESPUÉS:



Guardamos presionando OK y Save en la ventana principal de PE Editor.

Ahora abriremos el ejecutable modificado con un editor hexadecimal, y nos dirigiremos a la última parte de la sección que modificamos. Para ello debemos sumarle al RawOffset, la longitud (RawSize) original de la sección. Si nos fijamos, esa información se encuentra dentro de la que estuvimos editando previamente.


En mi caso, ROffset es A4E00h y el RSize original era de 6000h. Entonces, el final de la sección se encuentra en el offset A4E00h + 6000h, o sea en el AAE00h.

Podemos utilizar el buscador del editor hexadecimal para posicionarnos en ese offset.



Como podemos observar en la imagen, al final de la sección se encontraba un espacio con algunos bytes en 00h, esto finaliza precisamente en el offset AAE00h.

Nuestro último paso será añadir antes de ese offset, los 100h que hemos sumado a esta sección.


Los bytes en rojo son los que hemos añadido, ahora podemos notar que la sección finaliza en el offset AAF00h en lugar de AAE00h y esto es correcto, ya que ahora tenemos 100h más.

Guardamos y ejecutamos el .exe para asegurarnos que no rompimos nada :)


Perfect! El binario que elegí editar fue el cliente de Putty de 32bits.

En la próxima entrega añadiremos código útil en este hueco que nos hemos hecho manualmente y modificaremos el Entry Point del .exe para que sea lo primero que se ejecute al iniciar el programa :)

Allí nos leemos! Saludos!


Author: Sheila A. Berta
Tw: @UnaPibaGeek.
Web: www.semecayounexploit.com.