Hot Potato. Más que una elevación en Windows, un compendio de fallos bien aprovechados

martes, 19 de enero de 2016

Hace unos días se ha hecho pública una elevación de privilegios previamente desconocida y con prueba de concepto pública en todos los Windows. Esta es un poco especial, porque consigue elevar privilegios gracias a un compendio de fallos de diseño de Windows bien gestionados, además de "abrir la puerta" un nuevo tipo de ataque. Veamos los detalles y cómo intentar combatirlo.

Tres ataques en uno

Ocurre cada cierto tiempo. Se publica una prueba de concepto para elevar privilegios sin parche alguno. Un verdadero dolor de cabeza para un administrador de una red si quiere mantenerla bajo control. Sin ser muy estrictos, se nos viene a la cabeza que a final de 2014 ocurrió varias veces  seguidas en Windows y una más en agosto de 2015. En el kernel de Linux, de las últimas ocurrió en marzo de 2015. Pero esta es especial, porque en realidad se trata de una combinación de fallos basados en otros históricos conocidos y uno más moderno de los mencionados de 2014.

Esta última frase (de https://code.google.com/p/google-security-research/issues/detail?id=222) parece que les dio la idea...

NTLM es un protocolo de autenticación inventado por Microsoft que tiene dos versiones. La primera está obsoleta, y sufre del problema de la reflexión o "pass the hash", que ha traído a Microsoft de cabeza desde que se descubrió hace años. Se trata de que alguien intente autenticarse con un equipo del atacante por NTLM, se tome esa información, y se haga pasar por la víctima aunque no se sepa la contraseña. Antes incluso se podía aprovechar para pasarle los hashes a la propia máquina, pero quedó mitigado con el parche MS08-068. Ya no se podían utilizar autenticaciones (desafíos) que estuvieran siendo usadas en ese momento. Esto fue un pequeño golpe para los atacantes, pero el parche nunca evitó los ataques entre protocolos. O sea, que una autenticación viniese de WebDAV a SMB (como hicieron en Google) o de HTTP a SMB, como se ha hecho ahora.

Esquema de funcionamiento de Hot Potato


Lo interesante de la patata caliente es el uso combinado de fallos que probablemente no sean nunca corregidos o que va a costar que arreglen por estar muy intrincados en Windows o mantenerse por compatibilidad hacia atrás. Se usan tres tipos de ataques. Veamos.

Falsificar NBNS

Cuando un nombre o dominio no responde por DNS o resolución directa del archivo host, se pregunta al resto de sistemas en la red, través del protocolo NBNS, quién conoce la IP de quien se busca. El ataque hace que se responda siempre a todos los procesos del propio equipo que es él mismo (127.0.0.1) ante cualquier pregunta. Pero no le harán caso si no responde con el mismo ID con el que se le preguntó, así que se responde a todo el mundo, con todos los ID generados por fuerza bruta (solo son 65536 valores). Como va por UDP, es rápido y efectivo. ¿Qué pasa si no se nos pregunta por NBNS porque ya lo soluciona por DNS? En el equipo, se copan todos los puertos UDP. Con ellos se responde a los DNS y si no hay libres, DNS no funcionará... así que se usará NBNS como intento desesperado.

Aunque no tenga nada que ver con este ataque concreto, el creador deja la puerta abierta a un ataque NBNS sobre internet (siempre que la víctima tenga el UDP 137 abierto, claro).

Un WPAD falso

Por otro lado, tenemos otro ataque ya conocido. Windows intenta que le digan automáticamente, qué proxy debe usar. O sea, espera que haya un sistema con nombre "wpad" que resuelva, se conecte, y le dé la configuración (un archivo .dat). Lo hacen incluso servicios esenciales de Windows.

Con esa opción marcada, el equipo buscará siempre un WPAD
 
Ahora, usando el ataque NBNS ya descrito, se le dice al equipo que el wpad está en 127.0.0.1. Y se le devuelve .DAT (se le configura el proxy) también con 127.0.0.1. ¿Qué se consigue? Que se convierta la máquina objetivo en su propio proxy local, y por tanto,observar su tráfico. Y además, a todos los usuarios del equipo les aparecerá que el proxy es 127.0.0.1.

El ataque, abriendo proxies locales para todos los procesos

Llevando la autenticación NTLM de HTTP a SMB

Esta es la parte que supone una novedad (aunque se tomara la idea de Google). El parche mencionado, MS08-068, corrigió un ataque típico, pero no la raíz del problema. Nadie detuvo el ataque NTLM entre protocolos. Si se capturan credenciales NTLM a través de HTTP y se reenvían a un proceso SMB de la máquina, podremos enviar mensajes que serán ejecutados como SYSTEM porque parecen autenticados. Y aquí está la elevación.

El ataque en acción, metiendo a un usuario raso en el grupo de administradores

Ahora solo falta esperar que una petición HTTP generada desde un servicio con altos privilegios intente autenticarse por NTLM a algún sitio. Como tenemos un proxy HTTP en el equipo, capturamos las credenciales y se lanzan e inyectamos un comando. Todo se envía al servicio de escucha SMB interno. Ya está, el comando se lanzará con máximos privilegios. ¿Qué servicios generan peticiones HTTP autenticadas con NTLM privilegiados? Windows Update, Windows defender… El ataque aquí varía de versión a versión, pero es bastante fiable.

¿Se podrá corregir? ¿Cómo? ¿Qué tiene que hacer ahora Microsoft?

Normalmente, un fallo de elevación de privilegios ocurre en algún punto del sistema por una mala programación (desbordamiento de memoria, pobre configuración…). Arreglando esa parte, se cierra la puerta. Pero este problema es especial, porque arreglarlo implica solucionar tres problemas conocidos desde años y que nunca se erradicaron, además de que la experiencia nos dice que Microsoft es lento con las elevaciones.

Lo más probable es que Microsoft se vea obligado a corregir de alguna manera esa posibilidad de usar hashes NTLM (con desafíos en uso) que van de protocolo a protocolo. Corrigió el problema "canónico" de pass the hash evitando esto de servidor SMB al propio servidor SMB, pero ahora le toca a otros protocolos. Un dato: El parche se emitió en 2008 y el problema se conocía desde 2000. Había formas de mitigarlo, pero el ataque existió 8 años. ¿Tardará ahora tanto? Otro dato: Las  elevaciones de privilegios mencionadas al principio del artículo y sacadas a la luz por Google, fueron comunicadas en público porque Microsoft no las corrigió en el plazo de 90 días de cortesía que se les concede. En cualquier caso, parece que si cierra alguna de estas puertas, habrá otras formas de abrirlas combinando otros métodos en un futuro próximo.

¿Qué tiene que hacer el administrador?

No puede quedarse esperando el parche. Como cualquier fallo puede (y debe) atacar el problema desde varios frentes. Aquí ofrecemos algunas pistas. Aviso: hay mucho por hacer, y si no se tenían los deberes hechos, puede ser problemático:
  • Para el ataque NBNS: Identificar paquetes mal formados o "floods" de este tipo en la red. Existen programas específicos, y además los IDS deberían detectarlos. Disponer de registros DNS para todos los nombres y evitar la resolución NetBIOS. En especial para WPAD o WPAD.dominio.
  • Contra el ataque WPAD, evitar que Windows busque este archivo. Detener el servicio "Servicio de detección automática de proxy web WinHTTP" en los equipos y evitar que Internet Explorer lo busque. Por si acaso, un truco puede ser incrustar WPAD en el archivo hosts, y ponerlo a cualquier valor.
  • Forzar el uso de NTLMv2
  • Contra la autenticación NTLM. Forzar el uso de Kerberos y NTLMv2 (si se disponen de equipos medianamente modernos) y aplicar esta mejora publicada por Microsoft hace tiempo. También, firmar toda comunicación SMB.
 
Opciones de seguridad relacionadas con la firma de comunicaciones SMB
Pero son parámetros muy sensibles si se tienen equipos viejos en la red. Se pueden romper cosas.
 
Y en general, usar el cortafuegos saliente para evitar que cualquier programa no conocido acceda a la red. Evitar la ejecución de programas desconocidos por usuarios.... lo de siempre.
Por último, destacar que es curioso como esta prueba de concepto no está siendo detectada por los antivirus inmediatamente. Aunque no sirva para nada, suelen detectar rápidamente estos binarios para evitar las primeras embestidas de atacantes que intenten lanzar tal cual el binario.
Sergio de los Santos
ssantos@11paths.com

2 comentarios:

  1. Gracias por la explicación, muy buen articulo.
    No se si seria una opcion para mitigar el problema, utilizar la opción 252 del DHCP para establecer el archivo WPAD, según el articulo https://technet.microsoft.com/en-us/library/cc995261.aspx debería intentar localizar el archivo primero por la entrada DHCP antes que por DNS. Saludos

    ResponderEliminar
  2. Hola. Sí, toda opción de que el servidor de WPAD se localice antes y quede establecida, es una forma de mitigarlo.

    ResponderEliminar