Durante siglos, la criptografía ha evocado imágenes de protección, privacidad y seguridad. Hasta que, en 1996, dos investigadores de la Universidad de Columbia en EEUU, Adam Young y Moti Yung, concibieron el primer criptovirus de la Historia:

«En este trabajo presentamos la idea de la Criptovirología, demostrando que la criptografía también puede ser utilizada ofensivamente. Por ofensivo queremos decir que puede ser utilizada para montar ataques basados en la extorsión que causan pérdida de acceso a la información, pérdida de confidencialidad y fuga de información.»

En su artículo seminal, Young y Yung sentaron las bases teóricas de lo que sería el ransomware que hoy todos aborrecemos: la intersección entre la criptografía y el malware.

En su momento, el trabajo de Young y Yung no recibió atención por considerarse poco realista:

• Su propuesta requería el uso de criptografía asimétrica. Ni todo el hardware de la época poseía la capacidad computacional para trabajar con RSA, ni las restricciones de exportación de criptografía permitían el uso de longitudes de clave suficientemente robustas.
• No se vislumbraba medio impune de cobrar el rescate.

Por supuesto, con el aumento de la capacidad de cómputo y con el auge de las criptomonedas, el escenario cambió. A partir de mediados del 2000, el ransomware criptográfico experimentó un crecimiento sin precedentes. Su efecto ha sido, y sigue siendo, devastador.

Cuando la criptografía se vuelve canalla

A grandes rasgos, el proceso de ataque de los criptovirus bosquejado por Young y Yung atraviesa tres fases:

1. Infectar a la víctima.
2. Cifrar todos los archivos de ciertas extensiones a los que tenga acceso.
3. Pedir el rescate.

Para ser invulnerable, el ransomware criptográfico necesita dos elementos:

• Criptografía robusta: algoritmos de cifrado simétricos y asimétricos a prueba de balas.
• Claves fuertes: suficientemente largas y totalmente aleatorias.

El resto del artículo examina las fases que sigue un ransomware criptográfico bien diseñado para cifrar todos los archivos a los que tenga acceso:

1. Generar de manera totalmente aleatoria claves secretas de algoritmos simétricos robustos para cifrar los archivos.
2. Cifrar con estas claves los archivos de la víctima.
3. Cifrar dichas claves con claves públicas de algoritmos asimétricos.

1) No random, no ransom

Para cifrar un archivo se requiere una clave de cifrado aleatoria. Si te parece trivial, ponte en el lugar del creador del malware: una vez desplegado en un dispositivo infectado, cuyas especificaciones técnicas desconoces por completo, ¿cómo obtiene tu programa esa clave para cifrar con ella los archivos de la víctima? Tienes varias opciones:

• Codificarla directamente en el malware: hmm, mala idea. El análisis de código binario mediante reversing del ejecutable dará con las claves. Por ejemplo, DMA Locker v1 incluía la clave de cifrado en el propio código, lo que permitía su fácil recuperación.
• Solicitarla a un servidor C&C: es una solución aceptable, aunque plantea sus propios inconvenientes: la víctima debe estar conectada a Internet; el acceso a ese servidor no puede estar bloqueado por un cortafuegos; el tráfico debe cifrarse, lo que añade nuevas complejidades; el sitio se aloja en la red Tor; suelen necesitar Algoritmos de Generación de Dominio para evitar el cierre de servidores por las autoridades; etc. Por ejemplo, CryptoWall utilizaba este enfoque, con grandes réditos.
• Cada copia genera su propia clave de cifrado: para ser robustas, las claves criptográficas necesitan generarse de forma verdaderamente aleatoria. En caso contrario, podrían adivinarse o regenerarse. La cuestión es: ¿dónde encuentras en el dispositivo infectado la entropía necesaria para crear claves robustas? Y no, no se te ocurra recurrir a la típica función rand() de los lenguajes de programación, porque fallará miserablemente, como DMA Locker v2. La forma más segura es utilizar funciones robustas y bien testadas llamadas Generadores de Números Pseudo-Aleatorios Criptográficamente Seguros (Cryptographically Secure Pseudo Random Number Generator, CSPRNG). En los sistemas operativos de la familia Windows, las funciones CSPRNG están disponibles a través de APIs dedicadas, como CryptGenRandom(), vía la Cryptographic API (CAPI), ahora obsoleta; la posterior RtlGenRandom(), llamada también SystemFunction036; o, la más reciente, BCryptGenRandom(), proporcionada por la Cryptography API: Next Generation (CNG). Por supuesto, existen soluciones análogas en otras familias de sistemas operativos, aunque con otros nombres.

Así pues, la mejor opción será que el malware invoque al ejecutarse a una función CSPRNG para generar la clave aleatoria. De hecho, este paso resulta tan crucial para el éxito del ataque, que algunas propuestas anti-ransomware, como USHALLNOTPASS, Redemption, PayBreak o DRBG, proponen controlar el acceso a estas funciones mediante hooks o instalar en ellas puertas traseras para coartar así la capacidad del ransomware de generar claves robustas.

Algunos ransomware crean una misma clave para cifrar todos los archivos de la víctima, mientras que otros, más paranoicos, crean una clave diferente para cada extensión de archivo o incluso para cada archivo individual a cifrar. En todos los casos, quedan por resolver otros dos retos:

1. ¿Cómo se cifran los archivos con esa(s) clave(s)?
2. ¿Cómo se protege(n) esa(s) clave(s)?

2) Cifra, cifra, cifra sin parar

El ransomware recurre a la criptografía simétrica para cifrar los archivos de la víctima. Algunos ejemplos de ransomware, como Nemucod, 7ev3n, XORist o Bart, recurrieron a algoritmos de cifrado basados en hacer XOR entre el archivo y diversas variantes de claves, desde las que se rompían trivialmente hasta las que suponían un bonito ejercicio para una asignatura de Criptografía 101.

Así que mejor no reinventar la rueda, sino recurrir a algoritmos de cifrado bien estudiados y de seguridad demostrada, como el AES. Estos algoritmos se caracterizan por:

• Ser muy rápidos, pudiendo alcanzar velocidades de hasta 1 GB/s, dependiendo de la implementación en software y del procesador del dispositivo.
• Requerir claves cortas, por ejemplo, de 128 ó 256 bits.

Pero una cosa es proponerse utilizar un algoritmo robusto de cifrado y otra muy distinta es utilizarlo bien.

En primer lugar, con el fin de ser muy compactos y evitar la compilación con bibliotecas criptográficas, muchos autores de ransomware programan ellos mismos los algoritmos criptográficos. Cualquiera que haya tratado de codificar AES o RC5 habrá comprobado que se trata de una pesadilla. Por ejemplo, los autores de Petya, al codificar ellos mismos el algoritmo de cifrado en flujo Salsa20, cometieron varios errores sutiles, pero decisivos, a la hora de programar los buffers y variables de 16, 32 y 64 bits. Debido a estos errores, las claves generadas de 512 bits de longitud poseían en realidad 256 bits efectivos.

En segundo lugar, como su propio nombre indica, los algoritmos de cifrado en bloque operan cifrando bloques de uno en uno. Como consecuencia, bloques en claro idénticos darán como resultado bloques cifrados idénticos. ¿Qué tiene eso de malo? Echa un vistazo a la legendaria foto del pingüino de Linux cifrada encadenando los bloques sin más:

Esta debilidad exige que los bloques se encadenen de forma que bloques idénticos se cifren de manera diferente. Si el malware no usa un modo de encadenamiento apropiado, existe la posibilidad de recuperar parte de los archivos cifrados. Muchas muestras de ransomware, como DMA Locker, han venido utilizando el modo ECB de encadenamiento de bloques.

Otro fallo tremendo ha sido la utilización de algoritmos de cifrado en flujo reutilizando la misma clave para todos los archivos. Por ejemplo, TorrentLocker o DirCrypt cometieron este fallo de principiante. En la práctica, teniendo acceso a un único archivo sin cifrar y su correspondiente archivo cifrado de más de 2 MB, se podía recuperar la clave usada mediante un ataque trivial de texto claro conocido y, con ella, descifrar todos los demás archivos cifrados.

Y no basta con cifrar a conciencia. Además, los archivos de la víctima deben destruirse, ya que, en caso contrario, sería posible su recuperación mediante herramientas de disco, como con ciertas versiones de Gpcode.ak. Normalmente, el malware sobrescribe los archivos en claro con su versión cifrada o bien los borra de manera irreversible. Por ejemplo, cosa curiosa, LeChiffre sólo cifraba los primeros y los últimos 8.192 bytes de cada archivo.

¡Y aún hay más! El ransomware no sólo necesita destruir por completo los archivos cifrados, sino también sobrescribir la memoria para borrar todo rastro de las claves usadas. En el caso de WannaCry, por ejemplo, los analistas pudieron recuperar los números primos p y q utilizados para generar las claves públicas. Con Bad Rabbit, las claves quedaban en memoria y se podían leer siempre que no se reiniciara la máquina. CryptoDefense también dejaba rastro de las claves de cifrado usadas.

La conclusión es clara: la criptografía es más compleja y traicionera de lo que parece.

3) Mi clave, dónde estará mi clave

Ya solo queda un pequeño detalle: ¿cómo proteger la clave usada para cifrar los archivos?

Si está en el código, será recuperada mediante reversing. Si se destruye sin más, luego no será posible descifrar los archivos y nadie pagaría el rescate. Si se envía desde el servidor C&C podría ser interceptada. Tal y como sugirieron Young y Yung, nada como cifrarla a su vez mediante un algoritmo de cifrado asimétrico, como RSA o ECC.

Normalmente, se despliega la copia de malware junto con su propia clave pública o bien ésta se solicita al servidor C&C, como en el caso de DMA Locker v4. Además, si la clave es de longitud suficiente, no existe ningún peligro en escribirla en el código a la vista de los analistas. En cambio, si es corta, como ocurrió con TeslaCrypt, el valor de la clave pública podría factorizarse y obtenerse la clave privada para descifrar con ella las claves de cifrado de los archivos.

Eso sí, la pareja de claves pública y privada debe ser única para cada copia del malware. En caso contrario, si se usa la misma pareja durante toda una campaña, pagado el rescate una sola vez por una víctima y obtenida entonces la clave privada, se podrán descifrar las claves de cifrado de archivos de todas las demás víctimas, como ocurrió con DMA Locker v3.

El futuro del Ransomware

Por mucha cripto que usen, no hay que perder de vista el hecho de que el ransomware no es más que un virus. Antes de cifrar nada, necesita infectar a la víctima. Los malos están haciendo sus deberes: las sucesivas versiones de ransomware usan la criptografía de manera cada vez más sofisticada. Bien implementada, la criptografía de un ransomware es inatacable. Con el tiempo no habrá manera de crear “descifradores”. Sólo quedará la prevención.