SMBleed (CVE-2020-1206): nueva vulnerabilidad en SMB 3.1.1 (y que puede combinarse con SMBGhost para RCE)

Seguro que ya sabéis que hace poco se publicó código que permite la ejecución remota de código o RCE usando SMBGhost (CVE-2020-0796), una vulnerabilidad en el mecanismo de compresión de SMBv3.1.1 PERO que fue parcheada hace tres meses por Microsoft. Hasta ahí todo bien... parche publicado rápidamente por el fabricante y posterior aparición de exploits: desde el que permitía un crash del sistema, pasando por elevación de privilegios hasta este último RCE que comento, algo que no impedirá sin embargo que muchos incautos infecten sus máquinas des-actualizadas con malware ya más "weaponizable".

No obstante, durante la investigación para explotar SMBGhost la gente de ZecOps descubrió otra vulnerabilidad en la funcionalidad de descompresión que permite leer memoria del kernel no inicializada y, lo que es peor, combinada con la ya parcheada SMBGhost permitiría de nuevo ejecución remota de comandos: señores y señoras, con ustedes SMBleed (CVE-2020-1206).

Lectura remota de la memoria del kernel

Si recordáis, SMBGhost se aprovechaba de la falta de comprobaciones contra integer overflows en Srv2DecompressData, la función que recibe el mensaje comprimido que envía el cliente, asigna la cantidad de memoria requerida en el campo OriginalCompressedSegmentSize y descomprime los datos. Concretamente si asignábamos un valor muy grande a OriginalCompressedSegmentSize podíamos desbordarlo y escribir fuera de los límites (o "out of bounds" que en español queda raro). Microsoft lo solucionó pero todavía se dejó un error grave: si seteamos un valor pequeño (x + 0x100) a OriginalCompressedSegmentSize los datos no inicializados del kernel serán tratados como parte del mensaje, básicamente porque en la función FinalCompressedSize se actualiza para mantener el valor de CompressedBufferSize, que es el tamaño del búffer.


La PoC de ZecOps requiere credenciales y un recurso compartido con permisos de escritura, pero el bug aplica a cada mensaje, por lo que puede ser explotado sin autenticación. También hay que tener en cuenta que la memoria filtrada proviene de asignaciones anteriores en el pool NonPagedPoolNx, y, dado que controlamos el tamaño de la asignación o allocation, podríamos controlar los datos que se están filtrando, hasta cierto punto claro.

https://github.com/ZecOps/CVE-2020-1206-POC


Versiones vulnerables 

Windows 10 Version 2004

UpdateSMBGhostSMBleed
KB4557957Not VulnerableNot Vulnerable
Before KB4557957Not VulnerableVulnerable

Windows 10 Version 1909

UpdateSMBGhostSMBleed
KB4560960Not VulnerableNot Vulnerable
KB4551762Not VulnerableVulnerable
Before KB4551762VulnerableVulnerable

Windows 10 Version 1903

UpdateNull Dereference BugSMBGhostSMBleed
KB4560960FixedNot VulnerableNot Vulnerable
KB4551762FixedNot VulnerableVulnerable
KB4512941FixedVulnerableVulnerable
None of the aboveNot FixedVulnerablePotentially vulnerable*

Encadenando SMBleed con SMBGhost para RCE no autenticado

Explotar SMBleed sin autenticación es menos sencillo, pero también posible. Además pudieron usarlo junto con SMBGhost para lograr RCE (Ejecución remota de código) y comentan que pronto publicarán todos los detalles técnicos. De momento, podemos disfrutar sólo de la PoC para el RCE de SMBGhost:

https://github.com/ZecOps/CVE-2020-0796-RCE-POC


Contramedidas

Se puede corregir SMBleed y SMBGhost haciendo una o varias de las siguientes cosas:

- La actualización de Windows resolverá los problemas por completo (recomendado)
- Bloquear el puerto 445 detendrá los movimientos laterales usando estas vulnerabilidades
- Forzar el aislamiento del host
- Deshabilitar la compresión SMB 3.1.1 (no es una solución recomendada)

Fuentes:

- SMBleedingGhost Writeup: Chaining SMBleed (CVE-2020-1206) with SMBGhost
- CVE-2020-1206 | Windows SMBv3 Client/Server Information Disclosure Vulnerability
- SMBleed: A New Critical Vulnerability Affects Windows SMB Protocol

0 comentarios :

Publicar un comentario