Escalar privilegios en Windows 7,8,10, Server 2008, Server 2012 mediante Hot Potato
Hot Potato de @breenmachine son varias técnicas para escalar privilegios en Windows. Básicamente podríamos decir que primero redirecciona todo el tráfico HTTP a local para capturar las peticiones de los servicios de la máquina, luego las responde mediante solicitudes de peticiones de autenticación NTLM que reenvía a un servidor SMB local, que finalmente crea un servicio que ejecuta un comando (un cmd.exe por ejemplo) con los privilegios correspondientes.
Así dicho de golpe parece un embrollo, así que vamos a ver paso a paso cómo hacerlo...
En una red local cualquier aplicación puede utilizar Web Proxy Auto Discovery Protocol (en adelante WPAD) para encontrar proxies para poder salir a Internet. Esa información con sus reglas y demás está en un archivo Javascript wpad.dat que está en un servidor WPAP accesible mediante la URL:http://wpad/wpad.dat. Esto lo implementó Netscape en 1996 y la verdad es que después de tantos años no ha cambiado demasiado.
En el primer paso del ataque debemos hacer que nuestra máquina no envíe las peticiones HTTP a un proxy real si no a nuestro propio equipo, y eso pasa por falsificar la URL para que apunte a localhost.
Un equipo Windows por defecto no tendrá entrada 'wpad' en el fichero host así que el siguiente paso será la consulta al servidor DNS. Normalmente no suele haber ningún registro A 'wpad' pero por si acaso se utiliza una técnica llamada 'agotamiento de puertos UDP' que consiste en usar todos los puertos UDP disponibles (esto en localhost se consigue bastante rápido) para que, a la hora de intentar realizar una consulta DNS, falle porque no hay puertos UDP origen disponibles.
A continuación la tercera vía será la consulta Netbios que tendremos que falsificar para que 'wpad' nos devuelva 127.0.0.1. En principio y sin privilegios no podremos esnifar el tráfico para hacer un MiTM, así que lo que haremos será inundar el host con respuestas NBNS (ya que es un protocolo UDP). Una complicación es que el paquete NBNS tiene un campo de 2 bytes, el IDTX, que no podemos ver y que debe coincidir en la solicitud y la respuesta. Sin embargo podemos iterar sobre todos los 65536 valores posibles al hacerlo rápidamente.
Lo curioso que además afectará a todos los usuarios de la máquina, incluyendo administradores y cuentas del sistema.
Como en los dos pasos anteriores hemos trabajado para redireccionar todo el tráfico HTTP a través de un servidor local que controlamos, podemos hacer cosas como redirigirlos a algún sitio que solicite la autenticación NTLM.
Con el exploit de Potato, todas las peticiones HTTP se redirigen a una redirección 302 a"http://localhost/GETHASHESxxxxx", donde xxxxx es un identificador único. Las solicitudes de "http://localhost/GETHASHESxxxxx" responden con una petición 401 para autenticación NTLM.
A continuación, las credenciales NTLM son retransmitidas a un listener SMB local que crea un nuevo servicio de sistema que ejecuta un comando definido por el usuario.
Cuando la solicitud HTTP en cuestión se origina desde una cuenta de privilegios elevados, por ejemplo, cuando se trata de una solicitud del servicio de Windows Update, este comando se ejecutará con el privilegio "NT AUTHORITY\ SYSTEM"... bingo!
También es un poco extraño a veces, debido a las peculiaridades en la forma en que Windows maneja la configuración del proxy y el archivo WPAD. A menudo, cuando el exploit no funciona, es necesario dejarlo correr y esperar. Cuando Windows ya tiene una entrada de caché para WPAD o está permitiendo el acceso directo a Internet, porque no se encontró WPAD, podría tomar 30-60 minutos para que se actualice el archivo WPAD. Es necesario dejar el exploit se ejecute y tratar de probar de nuevo más tarde, una vez transcurrido este tiempo.
Las técnicas que se enumeran aquí se ordenan de menor a mayor complejidad. Las técnicas del final de la lista deberían funcionar en todas las versiones anteriores. Se incluyen vídeos y capturas de pantalla para cada uno.
Windows 7 - ver https://youtu.be/Nd6f5P3LSNM
Windows 7 puede explotarse de forma fiable a través del mecanismo de actualización de Windows Defender.
Potato.exe tiene código para desencadenar automáticamente éste. Basta con ejecutar lo siguiente:
Si la red tiene una entrada DNS para "WPAD" puedes intentar "-disable_exhaust false". Esto debería hacer que la búsqueda de DNS falle e intente la resolución por NBNS. Esto parece funcionar bastante bien en Windows 7.
Windows Server 2008 - Ver https://youtu.be/z_IGPWgL5SY
Como Windows Server no viene con Defender, necesitamos un método alternativo. En su lugar vamos a comprobar simplemente las actualizaciones de Windows. La otra advertencia es que en algunos dominios el servidor 2K8 pregunta por WPAD.DOMAIN.TLD en lugar de sólo WPAD. El siguiente es un ejemplo de uso:
Si en la red hay una entrada DNS para "WPAD", de igual forma que antes puedes intentar usar "-disable_exhaust false". Sin embargo, el agotamiento DNS hace que TODAS las búsquedas fallen y el proceso de actualización de Windows podría tener que hacer algunas búsquedas de DNS antes de llegar a WPAD... por lo que tendría que hacerse en el momento oportuno para que funcione en este caso.
Windows 8/10/Server 2012 - Ver https://youtu.be/Kan58VeYpb8
En las últimas versiones de Windows, parece que la actualización de Windows ya no "respeta" la configuración de proxy fijada en "Opciones de Internet" ni detecta WPAD. En su lugar, las configuración del proxy para Windows Update se controla con "netsh winhttp proxy…"
Aunque también contamos con una característica nueva de Windows, el "actualizador automático de certificados no confiables". Los detalles se pueden encontrar en https://support.microsoft.com/en-us/kb/2677070 y https://technet.microsoft.com/en-us/library/dn265983.aspx
Desde el artículo de TechNet "Windows Server 2012 R2, Windows Server 2012, de Windows 8.1 y Windows 8 incluyen un mecanismo de actualización automática que descarga las listas de confianza de certificados (CTL) diariamente".
Parece que esta parte de Windows todavía utiliza WPAD, incluso cuando la configuración del proxy se controle mediante winhttp.
En este caso el uso de Potato es el siguiente:
Si la red tiene una entrada DNS para "WPAD", consulta la documentación en Server 2008. El agotamiento de puerto podría ser complicado.
Utilizando la misma técnica de fuerza bruta TxID, técnicamente podríamos realizar ataques de suplantación NBNS fuera de nuestra red local. De hecho, en teoría, siempre y cuando haya una conexión lo suficientemente rápida como para soportarlo, debemos ser capaces de realizar ataques de suplantación NBNS contra cualquier hosts de Windows con el que podemos hablar a través del puerto UDP 137.
En realidad, aunque funciona en la práctica en la red local, todavía se tiene que probar más y verificarlo a través de Internet.
Estan lanzando una versión modificada de la herramienta "Responder.py" que lleva a cabo este ataque. El siguiente video muestra el ataque a una red distribuida de la siguiente manera:
Página de GitHub de Potato: https://github.com/foxglovesec/Potato
Además existe SmashedPotato, el cual permite saltear el bloqueo de AppLocker.
Fuente: SeguInfo
Así dicho de golpe parece un embrollo, así que vamos a ver paso a paso cómo hacerlo...
En una red local cualquier aplicación puede utilizar Web Proxy Auto Discovery Protocol (en adelante WPAD) para encontrar proxies para poder salir a Internet. Esa información con sus reglas y demás está en un archivo Javascript wpad.dat que está en un servidor WPAP accesible mediante la URL:http://wpad/wpad.dat. Esto lo implementó Netscape en 1996 y la verdad es que después de tantos años no ha cambiado demasiado.
En el primer paso del ataque debemos hacer que nuestra máquina no envíe las peticiones HTTP a un proxy real si no a nuestro propio equipo, y eso pasa por falsificar la URL para que apunte a localhost.
1. Falsificador local Netbios
Los clientes pueden recibir la ubicación de wpad.dat mediante DHCP (opción 252) o resolviendo el nombre del servidor WPAD y haciendo un HTTP GET a la URL. Como sabéis el orden normal de resolución de nombres es el fichero host, luego la resolución DNS y finalmente un broadcast UDP mediante NetBIOS Name Service (NBNS).Un equipo Windows por defecto no tendrá entrada 'wpad' en el fichero host así que el siguiente paso será la consulta al servidor DNS. Normalmente no suele haber ningún registro A 'wpad' pero por si acaso se utiliza una técnica llamada 'agotamiento de puertos UDP' que consiste en usar todos los puertos UDP disponibles (esto en localhost se consigue bastante rápido) para que, a la hora de intentar realizar una consulta DNS, falle porque no hay puertos UDP origen disponibles.
A continuación la tercera vía será la consulta Netbios que tendremos que falsificar para que 'wpad' nos devuelva 127.0.0.1. En principio y sin privilegios no podremos esnifar el tráfico para hacer un MiTM, así que lo que haremos será inundar el host con respuestas NBNS (ya que es un protocolo UDP). Una complicación es que el paquete NBNS tiene un campo de 2 bytes, el IDTX, que no podemos ver y que debe coincidir en la solicitud y la respuesta. Sin embargo podemos iterar sobre todos los 65536 valores posibles al hacerlo rápidamente.
2. Servidor WPAD falso
Una vez que hemos conseguido que 'wpad' resuelva 127.0.0.1, debemos levantar un servidor HTTP en local que cuando reciba una petición a "http://wpad/wpad.dat" responda algo como:FindProxyForURL(url,host){
if (dnsDomainIs(host, "localhost")) return "DIRECT";
return "PROXY 127.0.0.1:80";}Lo curioso que además afectará a todos los usuarios de la máquina, incluyendo administradores y cuentas del sistema.
3. HTTP -> SMB NTLM Relay
Anteriormente el protocolo NTLM era vulnerable a ataques MiTM. Por ejemplo un atacante capturaba los intentos de autenticación mediante el protocolo SMB y los podía reenviar contra la propia máquina de la víctima o a otro servidor para obtener acceso mediante psexec o similar. No obstante, Microsoft ya parcheó ésto desactivando la posibilidad de usar la misma autenticación NTLM con un challenge ya en uso, algo que sin embargo sigue funcionando desde otros protocolos como HTTP (HTTP->SMB) como ya vimos recientemente en el blog.Como en los dos pasos anteriores hemos trabajado para redireccionar todo el tráfico HTTP a través de un servidor local que controlamos, podemos hacer cosas como redirigirlos a algún sitio que solicite la autenticación NTLM.
Con el exploit de Potato, todas las peticiones HTTP se redirigen a una redirección 302 a"http://localhost/GETHASHESxxxxx", donde xxxxx es un identificador único. Las solicitudes de "http://localhost/GETHASHESxxxxx" responden con una petición 401 para autenticación NTLM.
A continuación, las credenciales NTLM son retransmitidas a un listener SMB local que crea un nuevo servicio de sistema que ejecuta un comando definido por el usuario.
Cuando la solicitud HTTP en cuestión se origina desde una cuenta de privilegios elevados, por ejemplo, cuando se trata de una solicitud del servicio de Windows Update, este comando se ejecutará con el privilegio "NT AUTHORITY\ SYSTEM"... bingo!
Usando el exploit
Su uso depende del sistema operativo.También es un poco extraño a veces, debido a las peculiaridades en la forma en que Windows maneja la configuración del proxy y el archivo WPAD. A menudo, cuando el exploit no funciona, es necesario dejarlo correr y esperar. Cuando Windows ya tiene una entrada de caché para WPAD o está permitiendo el acceso directo a Internet, porque no se encontró WPAD, podría tomar 30-60 minutos para que se actualice el archivo WPAD. Es necesario dejar el exploit se ejecute y tratar de probar de nuevo más tarde, una vez transcurrido este tiempo.
Las técnicas que se enumeran aquí se ordenan de menor a mayor complejidad. Las técnicas del final de la lista deberían funcionar en todas las versiones anteriores. Se incluyen vídeos y capturas de pantalla para cada uno.
Windows 7 - ver https://youtu.be/Nd6f5P3LSNM
Windows 7 puede explotarse de forma fiable a través del mecanismo de actualización de Windows Defender.
Potato.exe tiene código para desencadenar automáticamente éste. Basta con ejecutar lo siguiente:
Potato.exe -ip -cmd [cmd to run] -disable_exhaust trueSi la red tiene una entrada DNS para "WPAD" puedes intentar "-disable_exhaust false". Esto debería hacer que la búsqueda de DNS falle e intente la resolución por NBNS. Esto parece funcionar bastante bien en Windows 7.
Windows Server 2008 - Ver https://youtu.be/z_IGPWgL5SY
Como Windows Server no viene con Defender, necesitamos un método alternativo. En su lugar vamos a comprobar simplemente las actualizaciones de Windows. La otra advertencia es que en algunos dominios el servidor 2K8 pregunta por WPAD.DOMAIN.TLD en lugar de sólo WPAD. El siguiente es un ejemplo de uso:
Potato.exe -ip -cmd [cmd to run] -disable_exhaust true -disable_defender true -spoof_host WPAD.EMC.LOCALSi en la red hay una entrada DNS para "WPAD", de igual forma que antes puedes intentar usar "-disable_exhaust false". Sin embargo, el agotamiento DNS hace que TODAS las búsquedas fallen y el proceso de actualización de Windows podría tener que hacer algunas búsquedas de DNS antes de llegar a WPAD... por lo que tendría que hacerse en el momento oportuno para que funcione en este caso.
Windows 8/10/Server 2012 - Ver https://youtu.be/Kan58VeYpb8
En las últimas versiones de Windows, parece que la actualización de Windows ya no "respeta" la configuración de proxy fijada en "Opciones de Internet" ni detecta WPAD. En su lugar, las configuración del proxy para Windows Update se controla con "netsh winhttp proxy…"
Aunque también contamos con una característica nueva de Windows, el "actualizador automático de certificados no confiables". Los detalles se pueden encontrar en https://support.microsoft.com/en-us/kb/2677070 y https://technet.microsoft.com/en-us/library/dn265983.aspx
Desde el artículo de TechNet "Windows Server 2012 R2, Windows Server 2012, de Windows 8.1 y Windows 8 incluyen un mecanismo de actualización automática que descarga las listas de confianza de certificados (CTL) diariamente".
Parece que esta parte de Windows todavía utiliza WPAD, incluso cuando la configuración del proxy se controle mediante winhttp.
En este caso el uso de Potato es el siguiente:
Potato.exe -ip -cmd [cmd to run] -disable_exhaust true -disable_defender trueSi la red tiene una entrada DNS para "WPAD", consulta la documentación en Server 2008. El agotamiento de puerto podría ser complicado.
TODO: Firma SMB?
No está claro si este ataque va a funcionar cuando SMB signing esté habilitado. El exploit actual no lo hace, pero puede ser debido a la falta de soporte en la librería CIFS usada. La razón para sospechar que puede funcionar es que todo está sucediendo en 127.0.0.1. Si las firmas se basan en host, ¿podrían coincidir?Un nuevo ataque de red
Pensemos de nuevo en el ataque de suplantación NBNS.Utilizando la misma técnica de fuerza bruta TxID, técnicamente podríamos realizar ataques de suplantación NBNS fuera de nuestra red local. De hecho, en teoría, siempre y cuando haya una conexión lo suficientemente rápida como para soportarlo, debemos ser capaces de realizar ataques de suplantación NBNS contra cualquier hosts de Windows con el que podemos hablar a través del puerto UDP 137.
En realidad, aunque funciona en la práctica en la red local, todavía se tiene que probar más y verificarlo a través de Internet.
Estan lanzando una versión modificada de la herramienta "Responder.py" que lleva a cabo este ataque. El siguiente video muestra el ataque a una red distribuida de la siguiente manera:
- firewall pfSense
- 10.0.0.0/24 -> LAN corporativa
- 10.0.1.0/ 24 -> Servidor de red
- Desde la red de la empresa, vamos a atacar a una máquina en la red de servidores.
Página de GitHub de Potato: https://github.com/foxglovesec/Potato
Además existe SmashedPotato, el cual permite saltear el bloqueo de AppLocker.
Fuente: SeguInfo
Comentarios
Publicar un comentario
siempre es bueno, leer tus comentarios