Anteriormente analizamos por qué el ransomware criptográfico usa cifrado para perjudicar a sus víctimas impidiendo el acceso a sus archivos, pero este objetivo no siempre se cumple de la forma en que los cibercriminales lo esperan. Hoy veremos los errores cometidos al aplicar cifrado en el ransomware, que en algunos casos permitieron la creación de herramientas de descifrado para recuperar los archivos.

En particular, explicaremos cómo cuatro familias de ransomware criptográfico utilizaron el cifrado en diferentes etapas de su evolución: hablamos de CryptoDefense (2014), TorrentLocker (2014), TeslaCrypt (2015), que tuvo un éxito abrumador, y Petya (2016).

#1 CryptoDefense

Cuando apareció CryptoDefense, era sorprendentemente similar a CryptoLocker (una de las primeras familias de ransomware criptográfico en tener gran repercusión). Tenía grandes defectos de implementación en la comunicación con su servidor de C&C, así como en el proceso de cifrado de archivos.

El protocolo de C&C de CryptoDefense se basa en peticiones HTTP POST enviadas desde el malware en el host infectado. Para proteger la comunicación, CryptoDefense usa la ofuscación en la URL HTTP POST como forma de ocultar la clave empleada para cifrar el cuerpo del mensaje. El mensaje POST lleva el mensaje del protocolo de C&C cifrado con RC4 usando la clave oculta de la URL POST.

Imagen 3: Descifrado del protocolo de C&C de CryptoDefense. Créditos: Yonathan Klijnsma

Una vez interceptada la comunicación con el C&C, se puede descifrar fácilmente. La solicitud contiene toda la información necesaria para recuperar la clave de cifrado y revelar el protocolo de C&C de CryptoDefense subyacente, lo que permite la creación de firmas de red para impedir que su payload cifrador de archivos tenga éxito.

En cuanto al cifrado de archivos, el error es sorprendentemente similar. Para poder entender mejor esta falla de CryptoDefense, recordemos antes el funcionamiento básico de CryptoLocker:

1. CryptoLocker (cliente) infecta el sistema de la víctima y le envía a su servidor de C&C el ID de campaña y un ID de sistema, que es único.
2. El servidor de C&C responde con OK para confirmar el cliente.
3. El cliente envía una nueva solicitud con el ID de campaña y el ID de sistema único.
4. El servidor de C&C proporciona la nota con el pedido de rescate y la clave pública de un par de claves RSA-2048 generadas exclusivamente para esa combinación de ID de campaña/ID de sistema. La clave privada nunca deja el servidor de C&C.
5. El cliente confirma que ha recibido correctamente la nota de rescate y la clave pública del servidor de C&C, y que el proceso de cifrado se ha completado.

Para corregir una falla detectada en CryptoLocker, mediante la cual el cifrado recién se lleva a cabo una vez que el malware se comunica con el servidor de C&C, CryptoDefense decidió generar las claves de cifrado de archivos directamente en el host infectado, es decir, se salta los pasos 3 y 4.

No obstante, los autores de CryptoDefense pasaron por alto un pequeño detalle: olvidaron eliminar la clave de cifrado, generada en el host infectado y utilizada para cifrar los archivos. Por lo tanto, el descifrado se puede lograr fácilmente si se encuentra la clave privada RSA en el sistema de la víctima y se transmiten estos datos a la API de Windows para descifrar los archivos afectados.

Así es como CryptoDefense cometió dos veces el mismo error básico: usar el cifrado pero revelar la clave.

#2 TorrentLocker

Las versiones iniciales y defectuosas de TorrentLocker escogieron un algoritmo muy seguro para cifrar los archivos de la víctima: AES en modo CTR. Sin embargo, la manera en que se utilizó el algoritmo dio lugar a una debilidad notable en el esquema general.

AES es un esquema de cifrado por bloques, lo que significa que es capaz de cifrar bloques de un tamaño fijo (16 bytes). No obstante, los mensajes pueden tener otras longitudes y aquí es donde entran en juego los modos de operación.

AES en modo CTR toma un valor inicial como parámetro, conocido como el vector de inicialización, y lo utiliza para estirar la clave (que puede tener 128, 192 o 256 bits) hasta la longitud del texto sin formato (contenido no cifrado), convirtiéndose en lo que se conoce como una cadena de claves o keystream. A continuación, la cadena de claves codifica el mensaje con XOR, imitando el concepto de un cifrador de flujo.

El ataque de las primeras versiones de TorrentLocker era bastante simple: generaba una cadena de claves de 2MB en el sistema infectado y procedía a cifrar el primer segmento de 2MB de cada archivo aplicando el cifrado XOR al segmento con la cadena de claves. En los casos en los que los archivos eran más pequeños que 2MB, quedaban cifrados en forma completa con este método.

Sin embargo, este uso del cifrado AES en modo CTR era exactamente análogo a la reutilización del vector de inicialización y la clave en los cifradores de flujo, un error de novato en el mundo criptográfico. De esta forma, si logramos obtener un solo archivo cifrado y su contenido no cifrado original, es muy fácil recuperar la cadena de claves y descifrar todos los demás archivos. Las versiones posteriores de TorrentLocker corrigieron el error reemplazando el modo de operación CTR por CBC, que analizaremos posteriormente en la sección sobre TeslaCrypt.

Imagen 4: Esquema del modo de operación CTR

#3 Petya

Petya tomó un enfoque diferente al de los demás tipos de ransomware criptográfico: en lugar de cifrar archivos individualmente, se enfocaba en el sistema de archivos. Su objetivo es la partición Master Boot Record (MBR) de la víctima, responsable de cargar el sistema operativo inmediatamente tras el arranque del sistema.

El sistema de cifrado elegido por los desarrolladores de Petya era Salsa20, que pertenece a la cartera de productos de eSTREAM. Esta cartera es el resultado de un proyecto para promover el diseño de nuevos cifradores de flujo para reemplazar a los más viejos, como RC4; la adopción de Salsa20 por Petya señala la evolución del ransomware criptográfico a nuevos algoritmos de cifrado más robustos.

Cuando se ejecuta Petya, se inicia un ataque en dos etapas para cifrar el sector MBR que está muy bien diseñado. Empieza modificando el sector MBR y mostrando la pantalla azul de la muerte (BSoD, del inglés) para que el usuario reinicie el sistema. A continuación, muestra un comando Checkdisk falso mientras cifra el sector. Finalmente reinicia el sistema una vez más y muestra una pantalla parpadeante con una calavera y el pedido de rescate.

Imagen 5: Pantalla mostrada por Petya al presionar una tecla, con la calavera y el pedido de rescate

A pesar del miedo que suele provocar la imagen de la calavera y el pedido de rescate de Petya, es posible reparar el daño causado gracias a varias fallas de uso del cifrado. Su error más crítico, que permite descifrar el sector MBR una vez que el ataque se realizó con éxito, proviene de la forma en que deriva su clave de cifrado.

Para entender esta falla, debemos trabajar de atrás hacia delante. Empezamos investigando cómo la clave de recuperación, proporcionada a las víctimas después de pagar el rescate, se utiliza en el proceso de descifrado. Luego, aprovechamos un error de implementación para descifrar el sector MBR sin necesidad de conocer la clave completa.

El conjunto de caracteres para ingresar la clave de recuperación se limita a 54 símbolos y su longitud es de 16 caracteres. Una vez ingresada en la pantalla del pedido de rescate, se lleva a cabo su verificación para comprobar si es correcta.

Durante el proceso de verificación, la clave introducida se expande a una clave de 32 bytes codificada con un algoritmo personalizado y se compara con un búfer de verificación en la secuencia. Si la clave codificada coincide con el búfer de verificación, se introduce en el sistema de cifrado Salsa20 (estrictamente hablando, Salsa10) y se recuperan los sectores cifrados.

Aunque se ejecuta el método de expansión en la clave, lo que duplica su tamaño, esto no añade ninguna entropía  adicional a la clave porque el algoritmo de expansión es determinista. Por lo tanto, la seguridad queda delimitada por 54¹⁶ claves diferentes posibles, lo cual equivale a un nivel de protección de 92 bits (es decir, log₂(54¹⁶) = 92.07) y más, por ejemplo, la capacidad de 80 bits estimada de la NSA para descifrar claves por fuerza bruta.

Sin embargo, además de la entropía limitada, los desarrolladores de Petya cometieron un error de implementación en el núcleo de Salsa20, que crea una matriz de 16 palabras con las constantes, los valores de seguridad de un solo uso o nonces, y la clave obtenida de una tabla maestra, que se utilizarán durante el proceso de cifrado.

Los desarrolladores de Petya modificaron una implementación existente de Salsa20 para hacerla compatible con la arquitectura de 16 bits, pero no tuvieron en cuenta una parte esencial. La razón de querer modificar la implementación de Salsa20 puede atribuirse al modo de ejecución final. Petya está diseñado para operar como un cargador de arranque, que se ejecuta en 16 bits en modo real en todos los procesadores x86.

Para crear la matriz, se crean dos copias de la tabla maestra en formato little-endian. Los desarrolladores de Petya cambiaron las variables uint32_t por uint16_t (Imagen 6) para poder usarse en arquitecturas cuyo tamaño de palabra es de 16 bits. Sin embargo, se olvidaron de adaptar el nuevo tamaño de palabra en el bucle de la tabla maestra del núcleo de Salsa20, de manera que se leen 2 bytes y el intervalo para la siguiente lectura se incrementa en 4 bytes.

Imagen 6: Error de desarrollo en Petya al modificar Salsa20 para su uso en arquitecturas de 16 bits

Por esta razón, solo se termina aplicando la mitad de la clave en la derivación de claves en Salsa20. Esto reduce el nivel de seguridad de cifrado general de Petya de 92 bits a una seguridad de solo 46 bits (es decir, log₂(54⁸) = 46.04), que se puede descifrar en pocos segundos utilizando fuerza bruta incluso en equipos estándar.

#4 TeslaCrypt

No es casualidad que TeslaCrypt haya sido una de las familias más exitosas de ransomware criptográfico hasta el momento. La implementación cuidadosa del cifrado y la elección de los algoritmos indica que los desarrolladores de TeslaCrypt son expertos en cifrado.

TeslaCrypt utiliza AES-256 para cifrar los archivos; sin embargo, a diferencia de la versión defectuosa de TorrentLocker, utiliza CBC como modo de operación.

En el modo CBC, cada bloque de texto cifrado (fragmento de tamaño fijo del mensaje cifrado) se inserta como vector de inicialización en el cifrado del siguiente bloque, y todos los bloques son cifrados usando la misma clave. Por lo tanto, no hay ninguna cadena de claves ni analogías con cifradores de flujo, lo que hace que el procedimiento utilizado para descifrar las versiones de TorrentLocker defectuosas aquí sea inaplicable.

Imagen 7: Esquema del modo de operación CBC

La clave AES se cifra utilizando un algoritmo similar a EC-ElGamal y se envía de vuelta al servidor de C&C. La elección del cifrado de curva elíptica en vez de RSA es muy conveniente para evadir la detección, ya que genera textos cifrados más cortos y requiere menos tiempo para ejecutarse.

No obstante, los desarrolladores de la versión de TeslaCrypt v2.2.0 (también denominada TeslaCrypt v8) cometieron un error menos trivial. Como lo informó BleepingComputer y luego analizó Talos, la clave de recuperación (RK) destinada a proteger la clave de cifrado utilizada para cifrar los archivos durante el ataque se genera multiplicando la clave secreta compartida (C2K), establecida con el servidor de C&C, por la clave privada utilizada para cifrar los archivos (FK).

RK = C2K * FK

La clave de recuperación se almacena en el sistema infectado y permite la recuperación de la clave privada si se conoce la clave compartida. Sin embargo, los desarrolladores de TeslaCrypt v2.2.0 asumieron erróneamente que podían aprovechar ellos mismos el complicado problema de RSA: la factorización.

Décadas más tarde, los investigadores aún no han sido capaces de descubrir un algoritmo eficiente para calcular los factores primos de un número dado (tan grandes como los que se usan en RSA). Sin embargo, esto no significa que la factorización no pueda tener éxito.

La clave de recuperación simplemente no era lo suficientemente larga para eludir el ataque de factorización. Por lo tanto, la fuerza bruta resultó ser la mejor manera de encontrar la clave de cifrado de archivos y, finalmente, descifrar los archivos para restaurarlos a su forma original.

¿Se puede usar el cifrado contra el ransomware criptográfico?

Muchos han preguntado si es cierto que el ransomware criptográfico no cifra los archivos cifrados. La respuesta es "sí y no".

Evidentemente, es posible cifrar cualquier dato ya cifrado. De hecho, es la idea principal del enrutamiento cebolla (onion routing), diseñado para preservar la privacidad y transmitir datos a través de un circuito de nodos de enrutamiento. El circuito se compone de tres nodos, de modo que cuando el usuario quiere acceder a un sitio web, la solicitud se cifra con el nodo número tres (nodo de salida), se vuelve a cifrar (el contenido ya cifrado) con el nodo número dos y se cifra una vez más utilizando el nodo número uno (nodo de entrada).

A medida que la solicitud pasa a través de cada nodo, se descifra utilizando la clave del nodo actual, de manera tal que solo el nodo de salida tendrá la solicitud original, ya que los cifrados anteriores se quitaron durante el proceso de enrutamiento cebolla. El nodo de salida hace la solicitud en nombre del usuario y envía la respuesta usando un proceso de cifrado similar al que se aplicó originalmente a la solicitud.

Para obtener la mayor eficiencia y precisión, el ransomware criptográfico suele decidir si va a cifrar un archivo determinado en función de su extensión de nombre de archivo; por ejemplo, la lista de los tipos de archivos cifrados por TorrentLocker en el año 2014 está disponible aquí. Si la extensión coincide con las incluidas en la lista predefinida de extensiones, se cifrará; de lo contrario, quedará sin cifrar.

Por otro lado, las herramientas de cifrado a menudo anexan alguna nueva extensión predeterminada al nombre del archivo durante su cifrado. Es un hecho interesante que todavía no hayamos visto ninguna herramienta de cifrado que se enfoque en el ransomware criptográfico.

Como consecuencia, si el sistema resulta infectado por algún tipo de ransomware criptográfico que no esté diseñado para cifrar la herramienta utilizada en ese sistema en particular, los archivos cifrados por ella simplemente no serán cifrados por el malware. Teniendo esto en cuenta, una característica útil para agregar a las herramientas de cifrado es la aleatorización de extensiones, lo que podría ser tan simple como permitirle al usuario que defina un esquema durante la instalación.

La aleatorización de extensiones no genera ninguna sobrecarga en el rendimiento del sistema ni requiere grandes cambios de diseño en las herramientas de cifrado, y hasta cierto punto podría ser eficaz contra el ransomware criptográfico.

Para atacar los archivos cifrados, los desarrolladores de ransomware criptográfico tendrían que seleccionarlos y encontrarlos en el momento de ejecución o descartar la idea de seleccionar archivos según su extensión, modificando sus ataques para evitar el cifrado de archivos críticos de aplicaciones o del sistema operativo que pudiera dañar el sistema y hacer que el ataque falle antes de lograr sus objetivos.

Esta es la razón por la que el uso de herramientas legítimas de cifrado de archivos como protección podría casualmente disminuir el impacto del ransomware criptográfico. Sin embargo, la mitigación del ransomware criptográfico no debería depender totalmente de las herramientas de cifrado: la creación de backups y otras medidas proactivas son aún más importantes.