DoS remoto en Windows Vista
El último bombazo: provocar una Blue Screen of Death (BSOD) en Windows Vista, Windows 7 RC o Windows 2008 Server (<R2)
La noticia original (con su exploit en python): Windows Vista/7: SMB2.0 NEGOTIATE PROTOCOL REQUEST Remote B.S.O.D. (con fecha de 7 de septiembre).
Esta mañana la he probado en un portátil con Windows Vista:
- He activado la compartición de archivos: en Panel de control hay una opción que dice algo así como Opciones de red y de compartir recursos, y ahí dentro hay varias opciones para elegir qué se comparte. Esto es necesario para activar la pila Samba del kernel de Windows.
- Si hubiera un firewall que cubriera el puerto 445 habría que desactivarlo. No era el caso.
- Utilizando el exploit de Laurent Gaffié y sabiendo la IP del portátil lo tiré abajo sin más que cortar el exploit, pegarlo en un fichero y ejecutarlo contra el portátil.
El funcionamiento
El exploit simplemente se conecta al puerto 445 de la víctima, envía un mensaje de sesión SMB y se desconecta.
En tal mensaje de sesión, en su cabecera, hay un atributo que se llama Process ID High, de 16 bits. Normalmente suele ser 0, pero lo que descubrió Laurent es que si en vez de ser 0 era 0×26 (lo que viene siendo un &), conseguía obtener un bonito fallo de página (error PAGE_FAULT_IN_NONPAGED_AREA).
Es decir, que manipulando ese atributo provocaba que algún puntero en algún lado apuntara hacia alguna zona de memoria que no pertenecía a nadie. Para más inri, el código del SMB2.0 está en el kernel, por lo que este fallo de página se lanzaba en modo kernel, con el consecuente reinicio de la máquina.
Hasta aquí lo que tenemos en un ataque remoto de denegación de servicio.
Lo que posteriormente ha descubierto Rubén Santamarta, de 48bits, es que se puede (con ciertas limitaciones) manipular la dirección a la que salta el kernel según el valor de ese atributo de la cabecera, pudiendo dar lugar a una inyección de código.
Tal y como explica en su artículo:
.text:000156B7 mov eax, _ValidateRoutines[eax*4]; FALLO – out-of-bounds dereference.
.text:000156BE test eax, eax
.text:000156C0 jnz short loc_156C9
.text:000156C2 mov eax, 0C0000002h
.text:000156C7 jmp short loc_156CC
.text:000156C9 ; —————————————————————————
.text:000156C9
.text:000156C9 loc_156C9: ; CODE XREF: Smb2ValidateProviderCallback(x)+4F3j
.text:000156C9 push ebx
.text:000156CA call eax ; Smb2ValidateNegotiate(x) ;
Inicialmente partimos de que ESI apunta a una parte de la cabecera SMB del paquete recibido. ESI+0x0C es un puntero al atributo Process ID High de tal cabecera, por lo que
Nos deja en EAX, los 16 bits de más peso a 0 (siempre) y los 16 de menor peso con el contenido de tal atributo copiado literalmente (ver movzx). Por ejemplo, si el Process ID High fuera 10, EAX tendría el valor 0x0000000A,
La siguiente instrucción
va a la tabla (de punteros a función) _ValidateRoutines, y según el valor de EAX, escoge una entrada u otra (cada una ocupa 4 bytes).
Siguiendo con el ejemplo, esto cogería la undécima entrada de la tabla (en la dirección _ValidateRoutines + 0×28) y la copiaría en EAX, con lo que tendríamos en EAX la dirección de memoria de la función a ejecutar.
A continuación se comprueba si tal puntero no es nulo. De ser nulo, en EAX se guarda el valor 0x0C0000002 y se sigue con la ejecución en otra parte.
jnz short loc_156C9
mov eax, 0C0000002h
jmp short loc_156CC
Por el contrario, si efectivamente no es nulo, se guarda EBX en la pila y se salta a tal función:
push ebx
call eax
Conclusión: según pongamos un valor N en el atributo Process ID High, podemos conseguir que el kernel salte a la posición de memoria indicada en la entrada (N+1)-ésima de la tabla _ValidateRoutines.
¿Y si la tabla tiene menos entradas que N+1? Pues la dirección de memoria la tomará de lo que venga después de esa tabla. Si pudiésemos controlar el contenido de esos datos que están después, se podría hacer que el kernel saltara a una posición a voluntad. Y por eso es que Rubén habla de cierta posibilidad de ejecución de código remoto.
