CVE-2021-40444 totalmente armado

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

Antecedentes

Aunque ya hay muchos PoC por Internet, decidí probar suerte en armar esta vulnerabilidad, ya que lo que encontré disponible carecía de información valiosa que valga la pena compartir, considerando también que Microsoft ya publicó un parche para esta vulnerabilidad.

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

• Blog de Ret2Pwn
• Tuit de j00sean

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 y 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. Entonces, 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 hizo que incluso buenos PoC, como el de lockedbyte, fallaran al intentar funcionar correctamente.

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 publicar los detalles.

Archivo HTML

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

Archivo CAB

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

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

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

• TypeCompress: Si el CAB está comprimido, el truco de abrirlo dentro de un archivo 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 '../', tendríamos que 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é tiene que establecerse en 2 En efecto, podemos dejarlo en 1
• cbFile: Curiosamente, si la extracción del CAB finaliza 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 de 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 usando el valor _IMAGE_DOS_HEADER.e_magic como firma, evitando potencialmente que se incrusten archivos PE 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. Depende del lector curioso desarrollarlo más.

NOTA2: El parche de Microsoft bloquea esquemas de 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 mediante el esquema de URI .cpl. Para explotarlo, un atacante necesita generar un DLL especialmente diseñado. 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. Si bien esto 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 se puede utilizar 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 bien conocida mediante 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 descarga y ejecución SIN un archivo CAB.

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

Ataque de archivo sin CAB mediante 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 diseñado, 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:

1. Se descarga un archivo RAR especialmente diseñado (probablemente en la carpeta Descargas)
2. El DOCX se extrae y se abre
3. La relación almacenada en document.xml.rels apunta a un html malicioso
4. Se lanza la vista previa de IE para abrir el enlace HTML
5. El JScript dentro del HTML contiene un script/iframe que apunta al archivo RAR, con el prefijo del esquema de URI ".wsf:"
6. Como el RAR fue diseñado para ser simultáneamente un RAR válido y un script WSF válido, el script se ejecuta

Qué exploits PoC implementa la herramienta