rosayxy/recreate-cve-2023-21768recreando el exploit para cve-2023-21768.
Causa: Al comparar AFD.sys de 202209 y 202307, en la función AfdNotifyRemoveIOCompletion, tanto la versión de Windows de 202209 como la de 202307 tienen un paso que usa la función ProbeForWrite para verificar si una región de memoria está en modo usuario, pero la dirección del buffer verificada difiere en 0x8 bytes. Antes del parche de esta vulnerabilidad, no existía dicha verificación, por lo que se puede suponer que la dirección de verificación del buffer en la versión de 202209 podría ser incorrecta y posiblemente ineficaz. Además, el buffer verificado está relacionado con una asignación intermedia: **(_DWORD **)(a3 + 24) = v20; donde el buffer que debería verificarse es a3+24, y el valor de v20 está relacionado con v8 = IoRemoveIoCompletion(v25, Pool2, v4, (unsigned int)v6, &v20, a1, v13, 0), donde al menos Pool2, v4, v13 parecen estar determinados por una estructura desconocida pasada desde modo usuario, por lo que se sospecha que el valor de también está relacionado con esa estructura pasada desde modo usuario (tras leer un writeup, parece que es el valor de retorno de que llama a ).
v20IoRemoveIoCompletionKeRemoveQueueExSi a3+24 almacena una dirección del modo kernel, podría generar una primitiva de escritura arbitraria en el kernel (kernel arbitrary write), y luego explotarse mediante IORING (método de explotación: https://windows-internals.com/one-i-o-ring-to-rule-them-all-a-full-read-write-exploit-primitive-on-windows-11/).
Entorno de reproducción: Código fuente compilado con Visual Studio 2022 + Windows 11 202209 (ejecutándose en Hyper-V). Opción de compilación: x64 Release. Debido a la ausencia de vcruntime140.dll en HyperV, se usó enlace estático.
Cadena de funciones dentro de AFD.sys: AfdFastIOdeviceControl -> AfdNotifySock -> AfdNotifyRemoveIOCompletion, que asigna un campo de una estructura desconocida a una dirección determinada por modo usuario, creando así una primitiva de escritura arbitraria en kernel (arbitrary kernel Write-Where) que luego es aprovechada por IORing.
Implementación del exploit: A través de la función ArbitraryKernelWrite0x1 se realiza la escritura arbitraria. La parte principal de esta función en el exploit reutiliza una herramienta del maestro x86matthew para eludir Winsock e interactuar directamente con AFD.sys (originalmente la herramienta servía para crear sockets TCP directamente) (https://www.x86matthew.com/view_post?id=ntsockets).
Lo que permite la escritura en direcciones arbitrarias es la estructura AFD_NOTIFYSOCK_DATA, es decir, la estructura desconocida mencionada anteriormente. Sus diversos componentes están principalmente diseñados para sortear las distintas comprobaciones en la cadena de llamadas a funciones.
El primer parámetro, el handle, se crea mediante la función NT no documentada NtCreateIoCompletion (https://securityintelligence.com/x-force/patch-tuesday-exploit-wednesday-pwning-windows-ancillary-function-driver-winsock/).
Actualización sobre la experiencia de depuración: Parece que, al depurar código que se ve muy similar, a menudo se queda atascado en lugares extraños.
Por ejemplo, al principio, al llamar a _NtCreateFile, el primer parámetro era hSocket, y en la función original __imp_ObReferenceObjectByHandle siempre devolvía un número negativo. Después de observarlo, se definió otro handle para usarlo como parámetro de _NtCreateFile y _NtDeviceIoControlFile (estas dos funciones parecen interactuar principalmente con afd.sys, se puede consultar el artículo de x86matthew).
Además, al principio no se llamaba a NtSetIOCompletion, por lo que IORemoveIOCompletion no superaba la comprobación... así que se consultó el enfoque de https://securityintelligence.com/x-force/patch-tuesday-exploit-wednesday-pwning-windows-ancillary-function-driver-winsock/.
Luego, en el grupo de sombra, se pidió ayuda porque no se podían cargar las tablas de símbolos. Se descubrió que la causa era que el ordenador que ejecutaba Windbg no tenía el proxy activado, por lo que no podía conectarse a las tablas de símbolos en línea.
Finalmente, se usó Windbg para depurar el programa en Hyper-V, sin necesidad de hacerlo tan complicado como en Microsoft Learn. Basta con ejecutar en la línea de comandos de Hyper-V: bcdedit /debug on; bcdedit /dbgsettings net hostip:(dirección IPv4 del conmutador predeterminado de Ethernet en el host) port:50001 key:1.2.3.4.
En el archivo zip se incluye el proyecto completo de Visual Studio para la reproducción.
Por último, un agradecimiento especial a la hermana Tingting y al colega Mimi que ayudaron a solucionar problemas con Windbg.