CVE-2021-40444 totalmente armamentizado

Generador de docx malicioso para explotar CVE-2021-40444 (Ejecución remota de código en Microsoft Office Word), funciona con archivos DLL arbitrarios.

Actualización 31/05/2022 - CVE-2022-30190 - Follina

Ahora el generador puede crear el documento necesario para explotar también el ataque "Follina" (aprovechando ms-msdt).

Antecedentes

Aunque ya hay muchos PoC por internet, decidí intentar armamentizar esta vulnerabilidad, ya que lo que encontré disponible carecía de información valiosa que valga la pena compartir, considerando además que Microsoft ya publicó un parche para esta vulnerabilidad.

Hasta ahora, los únicos recursos valiosos que he visto para crear un generador totalmente funcional son:

• Blog de Ret2Pwn
• Tuit de j00sean
• Tuit de wdormann

Los recursos anteriores describen muchos de los requisitos necesarios para crear una cadena completa. Para evitar repetir demasiada información innecesaria, solo resumiré los detalles relevantes.

Cadena de explotación

1. Se abre el Docx
2. La relación almacenada en document.xml.rels apunta a un html malicioso
3. Se lanza la vista previa de IE para abrir el enlace HTML
4. El JScript dentro del HTML contiene un objeto que apunta a un archivo CAB, y un iframe que apunta a un archivo INF, con el prefijo de la directiva ".cpl:"
5. Se abre el archivo cab, el archivo INF se almacena en el directorio %TEMP%\Low
6. Debido a una vulnerabilidad de path traversal (ZipSlip) en el CAB, es posible almacenar el INF en %TEMP%
7. Luego, el archivo INF se abre con la directiva ".cpl:", lo que provoca la carga lateral del archivo INF mediante rundll32 (si se trata de una DLL)

Requisitos pasados por alto

Hay bastantes requisitos pasados por alto para que este exploit funcione, lo que provocó que incluso buenos PoC, como el de lockedbyte, fallaran.

Quizás nadie los "publicó" explícitamente para evitar que la vulnerabilidad se explotara más. Pero ahora está parcheada, así que no debería causar muchos problemas revelar los detalles.

Archivo HTML

Según este tuit de Will Dormann, el HTML debe tener al menos 4096 bytes para activar la "Vista previa" en MS Word.

Archivo CAB

El archivo CAB debe ser parcheado a nivel de bytes para evitar errores de extracción y lograr el ZipSlip:

• filename.inf debe convertirse en ../filename.inf
• filename.inf debe tener exactamente <12-char>.inf No es del todo cierto, lo importante es modificar coffCabStart
• CFFOLDER.typeCompress debe ser 0 (sin comprimir)
• CFFOLDER.coffCabStart debe incrementarse en 3 (debido al '../'' añadido)
• CFFOLDER.cCfData debe ser 2
• CFFILE.cbFile debe ser mayor que todo CFHEADER.cbCabinet
• CFDATA.csum debe recalcularse (o ponerse a cero) [OPCIONAL]

Las razones de estas restricciones son muchas, y no dediqué suficiente tiempo a comprenderlas todas en profundidad, pero veamos las más importantes:

• TypeCompress: Si el CAB está comprimido, el truco de abrirlo dentro de un archivo de objeto para provocar la escritura del INF fallará Falso, logré el mismo resultado con una muestra comprimida con MSZIP
• CoffCabStart: CoffCabStart da la posición absoluta de la primera estructura CFDATA, como añadimos un '../', necesitaríamos incrementarlo en 3 para apuntar al archivo (esto es más una suposición)
• cCfData: Como solo hay 1 archivo, deberíamos tener solo 1 CFDATA, no estoy muy seguro de por qué debe establecerse en 2 En efecto, podemos dejarlo en 1
• cbFile: Curiosamente, si la extracción del CAB concluye sin ningún error, WORD marcará el archivo INF para su eliminación, arruinando el exploit. La única forma de evitarlo es hacer que WORD crea que la extracción falló. Si el valor de cbFile se define como mayor que el propio archivo del gabinete, el extractor alcanzará un EOF antes de leer todos los bytes definidos en cbFile, generando un error de extracción.
• [OPCIONAL] Parece que MS Word no comprueba este valor. De todos modos, para tener un CAB correcto, el valor csum debería recalcularse. Afortunadamente, como señaló j00sean y según la documentación de MS, este valor puede ser 0

NOTA1: Defender ahora detecta si el archivo CAB contiene un PE utilizando el valor _IMAGE_DOS_HEADER.e_magic como firma, lo que potencialmente evita que los archivos PE se incrusten en el CAB. ¿Se puede omitir esta firma? No estoy seguro, pero como se observó antes, esta es una vulnerabilidad parcheada, así que no planeo invertir mucho más tiempo en esto. Le toca al lector curioso desarrollar esto más a fondo.

NOTA2: El parche de Microsoft bloquea esquemas URI arbitrarios, aparentemente usando un enfoque de lista negra (esto es solo una suposición)

Ataque DLL

La cadena de ataque principal asociada con CVE-2021-40444 es el ataque DLL cargado a través del esquema de URI .cpl. Para explotarlo, un atacante necesita generar una DLL especialmente manipulada. Si quieres probarlo, prueba mi script evildll-gen.

JScript, VBScript, Javaw, MSIexec, ...

Como señaló Max Maluin, es posible interactuar con varios tipos de archivo abusando de IE y del URI basado en la extensión de archivo asociada. Aunque esta puede ser una buena forma de explotar IE, tiene limitaciones.

De hecho, cabe señalar que el método utilizado en el exploit para descargar archivos se basa en actualizaciones de controles ActiveX, y no puede usarse para descargar archivos arbitrarios.

Según la documentación de Microsoft, la etiqueta codebase solo puede apuntar a unos pocos tipos de archivo: OCX, INF y CAB.

Incluso si podemos descargar directamente un archivo OCX o INF, todavía no podemos estar seguros de descargar el archivo en la ubicación correcta dentro del sistema. Con el exploit del cab, es posible mover el archivo .inf a una ruta conocida usando el path traversal, pero en cualquier otro caso el archivo se almacenará en un directorio aleatorio, lo que hace prácticamente imposible referenciarlo.

Hasta la fecha, no he encontrado una forma de encadenar la descarga y la ejecución SIN un archivo CAB.

Nota: Hablando solo de IE, el HTML smuggling podría ser un escenario posible para explotar la vulnerabilidad.

Ataque de archivo sin CAB usando archivo RAR híbrido

Esta técnica fue revelada por primera vez por Eduardo Braun en Twitter y explicada más a fondo en este documento.

Ten en cuenta que con esta técnica, la cadena de ataque es un poco diferente. Este ataque requiere que el usuario descargue un archivo RAR especialmente manipulado, obtenido encadenando un script WSF válido y un archivo RAR válido. Una vez abierto, el RAR contendrá un DOCX con una referencia a un HTML, que a su vez intentará cargar el archivo RAR como un script WSF.

Para resumir: