#NotPetya: Recuperación de datos de un disco cifrado con Salsa20

NotPetya Ransomware
NotPetya Ransomware

Ha habido muchos de estos ataques, pero los que marcaron nuestros titulares son #WannaCry y #NotPetya (también conocido como Petya, Petya.A, ExPetr, y otros nombres). Sin dudas el Ransomware como ataque es una tendencia alarmante de 2017.

Con las lecciones de la epidemia anterior atendidas, especialistas de todo el mundo reaccionaron rápidamente al nuevo desafío y, en cuestión de horas después de que las primeras computadoras se infectaron, comenzaron a analizar los discos cifrados.

El pasado 27 de junio, las primeras descripciones de cómo #NotPetya se propagaba e infectaba computadoras apareció. Mejor aún, se encontró una vacuna para prevenir las infecciones por #NotPetya.

Alternativa a #NotPetya

Si #NotPetya no puede obtener privilegios de administrador al ejecutarlo, realiza el cifrado AES de los archivos de usuario únicamente y el sistema operativo continúa funcionando.

Desafortunadamente, la recuperación de los archivos de usuario en ese caso requiere conocer la clave RSA privada (que supuestamente está disponible para su compra en el Darknet para 100 bitcoins).

El siguiente método para recuperar datos funciona sólo si #NotPetya tenía privilegios de administrador y utilizó el algoritmo Salsa20 para cifrar todo el disco duro.

Los creadores de #NotPetya cometieron un error en su implementación del algoritmo Salsa20

Debido a este error, la mitad de los bytes de clave de cifrado no se utilizaron de ninguna manera.

Esta reducción en la longitud de clave de 256 a 128 bits, por desgracia, todavía no deja ninguna esperanza de descifrar datos en un tiempo razonable.

Sin embargo, ciertas peculiaridades de cómo se aplicó el algoritmo Salsa20 permiten recuperar datos, sin ninguna clave necesaria.

Cómo funciona Salsa20

Salsa20 es un cifrado de flujo síncrono en el que el cifrado, genera un flujo de claves dependiente de la clave y los bytes de este flujo de claves se agregan a los bytes de texto sin formato, mediante la operación XOR.

Para el descifrado, el procedimiento debe ser repetido.

Para que el flujo de claves sea calculado para cualquier desplazamiento en la secuencia, el generador de claves s20_expand32 () genera una matriz de flujo de claves de 64 bytes en la que se mezcla lo siguiente:

  • 256 bits (32 bytes) de la clave de cifrado
  • 8 bytes del abusador (número usado una vez) en una secuencia aleatoria
  • 16 bytes de la constante sigma (“expanda 32 bytes k” o “-1nvalid s3ct-id”)
  • 64 bits (8 bytes) del número de bloque en la secuencia

La siguiente figura, muestra cómo se organizan los datos:

64 bytes de la matriz pasan a través de la función de mezcla; Los 64 bytes resultantes se utilizan como un fragmento keystream.

Debe tenerse en cuenta que los fragmentos generados de keystream siempre están alineados con un múltiplo de frontera de 64 bytes.

Por ejemplo, para cifrar 7 bytes empezando en el desplazamiento 100, debemos encontrar el número de bloque que tiene el primer byte (100/64 == 1), calcular un flujo de claves para este bloque y usar 7 bytes desde el desplazamiento (100% 64 == 36). Si no hay suficientes bytes en el bloque, se genera un flujo de claves para el siguiente bloque, y así sucesivamente.

Mientras se cifra una sola secuencia (un disco es considerado por #NotPetya como un solo flujo), ni la clave ni el abuso cambian. Por lo tanto, para cada disco cifrado, la única variable que afecta al flujo de claves es el número de bloque.

Más de Salsa20

Según lo diseñado por los creadores de Salsa20, 264 bloques de 64 bytes cada uno permiten generar un keystream con un período de 270 ~ 1021 bytes.

Este es un período bastante largo para casi cualquier aplicación práctica, y los discos duros de esta capacidad no aparecerán en ningún momento pronto.

Sin embargo, implementar todo esto fue un poco más difícil.

El período actual del keystream en #NotPetya

Mire el prototipo de la función s20_crypt32 ();

Los sectores de disco se cifran llamando a esta función

Enum s20_status_t s20_crypt32 (uint8_t * key,

Uint8_t nonce [estática 8],

Uint32_t si,

Uint8_t * buf,

Uint32_t buflen)

Un desplazamiento de bytes en el flujo se pasa a través del argumento si (probablemente Stream Index).

Y a juzgar por el tipo de argumento, está claro que sólo contiene 32 bits, en lugar de 64 bits.

Este valor va al flujo de claves después de haber sido dividido por 64, por lo que queda un máximo de 26 bits.

// Establece los segundos de 4 bytes de n en el número de bloque

S20_rev_littleendian (n + 8, si / 64);

 

Análisis del problema de #NotPetya

Destacados en gris son los bytes que no afectan a la generación de claves debido a un error en la implementación de la función s20_rev_littleendian ().

Por lo tanto, de 26 bits del número de bloque, sólo 16 bits (bytes en el desplazamiento 0x20-0x21) afectan el flujo de claves.

Consecuentemente, el período máximo de claves es 216 = 65.536 bloques de 64 bytes cada uno o 4 megabytes.

El volumen de datos cifrados en un disco duro es muchas veces mayor que 4 megabytes, por lo que muchos datos diferentes se cifran utilizando los mismos fragmentos de claves. Este hecho permite implementar un ataque trivial basado en un texto claro conocido.

Otro error

Los errores de los desarrolladores no terminan aquí.

Cuando se llama a la función s20_crypt32 (), ¡pasan … el número del sector de 512 bytes en lugar del valor de desplazamiento en bytes!

Los sectores suelen estar cifrados por pares (1.024 bytes por acceso), lo que significa que el flujo de claves usado para cifrar dos pares de sectores vecinos es el mismo en 1.022 bytes (desplazado por 2 bytes).

Heurística para ataque de texto plano conocido

Las versiones modernas de Windows utilizan el sistema de archivos NTFS, que emplea un número entero de estructuras diferentes; La mayoría de sus campos son bastante predecibles.

Es más, los discos contienen un gran número de archivos cuyo contenido es también bastante predecible (en su totalidad o en parte).

Primeros 512 bytes del keystream

Para validar la clave de cifrado, #NotPetya cifra el sector 0x21, que contiene valores predefinidos (todos los bytes 0x07). Esto nos da 512 bytes del keystream.

Recuperando el keystream por MFT

#NotPetya no cifra los primeros 16 registros MFT (32 sectores), sino que cifra todos los demás.

Cada registro de archivo comienza con la secuencia “FILE” usualmente seguida por bytes 30 00 03 00 (UpdateSequenceArrayOffset = 0x30, UpdateSequenceArrayLength = 3).

Teóricamente, estos 4 bytes pueden tener otros valores, pero son casi siempre los mismos para todos los registros de archivos dentro de la misma partición lógica NTFS.

Así, a partir de un registro de archivo (ocupando dos sectores), se pueden recuperar 8 bytes del flujo de claves, y cada registro vecino proporciona dos bytes más (y la posibilidad de verificar los seis bytes obtenidos previamente).

Los registros finales están casi enteramente compuestos de ceros, que pueden proporcionar hasta 1.024 bytes adicionales del keystream.

Una vez que se recuperan los fragmentos de keystream utilizados para cifrar el MFT, se puede recuperar toda la estructura del sistema de archivos.

Recuperar el keystream por archivos conocidos

#NotPetya también cifra los primeros dos sectores de cada archivo más de 1.024 bytes. El tamaño del clúster por lo general excede dos sectores (puede ser 8 sectores, por ejemplo).

En ese caso, después de encontrar el encabezado cifrado de cualquier archivo y saltar 1.024 bytes, podemos recuperar fácilmente los próximos 3 kilobytes en texto claro.

Si tenemos un archivo en el que exactamente los mismos 3 kilobytes están en el desplazamiento de 1.024 bytes de la cabecera, el encabezado del archivo muy probablemente también será el mismo.

Así que podemos recuperar hasta 1.024 bytes adicionales del keystream.

Una instalación limpia de Windows XP contiene 8.315 archivos en la carpeta Windows. En Windows 8.1 instalado en un equipo utilizado activamente, este número supera los 200.000.

Lo más probable es que muchos de ellos coincidan con los archivos en un disco cifrado.

Gracias a esto, la indexación de archivos DLL y EXE de las instalaciones de Windows disponibles (preferiblemente de la misma versión y con actualizaciones similares instaladas) puede ser suficiente para recuperar el flujo de claves por completo.

Una vez recuperados los fragmentos de la clave, también puede proceder a la recuperación de archivos únicos.

Perspectivas y trampas

La recuperación manual de un disco cifrado es una tarea tediosa: el proceso puede tardar horas y requiere una gran cantidad de espacio libre en disco.

Pocos usuarios tienen un disco vacío de repuesto tan grande como el que está cifrado, y el intento de experimentos en un disco original infectado es una tarea sin sentido.

Así que aquellos que desean una herramienta de recuperación fácil y sin complicaciones aún no tienen suerte.

En el lado positivo, podemos esperar que los proveedores de servicios profesionales sean capaces de recuperar más datos de lo que ha sido el caso hasta la fecha.

Las empresas que se especializan en la recuperación de datos es probable que vienen con el software necesario, gracias a su experiencia.

Dicho esto, todavía hay algunos inconvenientes en el camino de la recuperación

El algoritmo para seleccionar los sectores a cifrar (y que por lo tanto necesitan ser descifrados) también contiene errores (por ejemplo, al analizar estructuras NTFS), y esto puede tener un efecto en el resultado.

Recuperar datos de un disco duro utilizando el método descrito requiere la aplicación de ciertas heurísticas.

La completitud de la recuperación de datos depende de muchos factores (tamaño del disco, espacio libre y fragmentación) y puede llegar al 100% para los discos grandes que contienen muchos archivos estándar (SO y componentes de aplicación idénticos en muchas máquinas y que tienen valores conocidos).

Como se indica al principio de este artículo, este método desafortunadamente no se puede utilizar para descifrar archivos que se cifraron con el algoritmo AES, que es utilizado por #NotPetya cuando no puede obtener privilegios de administrador.

 

Por Dmitry Sklyarov, Head of Reverse Engineering, Positive Technologies

Sígueme en Twitter

Sé el primero en comentar

Dejar una contestacion