Abusando de WPAD para implantar ficheros PAC maliciosos (colisión de nombres gTLD)

Normalmente en las empresas los usuarios utilizan un servidor proxy para navegar por Internet, mejorando así el rendimiento (caché), la monitorización y la seguridad. Para no tener que configurar manualmente los navegadores se suelen utilizar los llamados ficheros PAC (proxy auto-config) donde se define el proxy apropiado para acceder a cada URL, y para saber la ubicación de estos ficheros se utiliza WPAD (Web Proxy Autodiscovery Protocol) mediante descubrimiento por DHCP o DNS.

Recientemente un estudio de la Universidad de Michigan ha revelado la existencia de una vulnerabilidad en WPAD que podría ser aprovechada por un atacante para interceptar estas peticiones de descubrimiento y retornar un fichero PAC que haga que un usuario utilice un proxy malicioso.

Veamos un poco en qué consiste. Por ejemplo, si en el navegador de un equipo está marcada la opción de 'Detectar la configuración automáticamente' (como se muestra en la imagen de arriba) el sistema se basará en el hostname para buscar el fichero .pac en este orden:

Hostname: 
computer.team.division.company.example

Búsqueda de fichero .pac:
wpad.team.division.company.example/wpad.dat
wpad.division.company.example/wpad.dat
wpad.company.example/wpad.dat
 
Si el dominio .company.example no es resuelto por los DNS internos la petición se reenviará automáticamente a los DNS públicos.

El problema es que WPAD está activado por defecto en todos los sistemas operativos Microsoft Windows y en el navegador Internet Explorer, por lo que si en una empresa no está implementado su uso se estarán enviando de forma incontrolada peticiones a Internet. 

De hecho, los investigadores confirman en su whitepaper: "en dos de los 13 root servers, se observan todos los días aproximadamente 20 millones de este tipo de consultas que contienen fugas al espacio de nombres DNS público. Este ha sido un problema conocido desde hace años, pero ... no ha sido explotable con anterioridad".

Y dicen no "explotable con anterioridad" porque en 2012 la ICANN abrió la puerta a la contratación de dominios de nivel superior genéricos pasando de 22 a los 1300 que se prevé que habrá en los próximos años. Es decir, podéis imaginar que si los atacantes son capaces de comprar el nombre de dominio .company.example podrían poner un sitio web en wpad.company.example y publicar su propio archivo PAC que indique a los navegadores usar el servidor proxy del atacante...

Para evitarlo, el US-CERT recomienda:

- Considerar desactivar la detección/configuración automática de proxy en los navegadores y sistemas operativos cuando se trata de dispositivos que no serán utilizados en redes internas.
- Considerar el uso de un nombre de dominio completo (FQDN) de un DNS global como el root de la empresa y espacio de nombres interno.
- Configurar los servidores DNS internos para responder autoritariamente a las consultas internas de TLD.
- Configurar los firewalls y servidores proxy para registrar y bloquear las solicitudes de salida para archivos Wpad.dat.
- Identificar el tráfico WPAD esperado y vigilar el espacio de nombres público o considerar registrar dominios de forma defensiva para evitar futuros conflictos de nombres.
- Presentar un informe a la ICANN si se está sufriendo un daño grave demostrable como consecuencia de la colisión de nombres.

Fuentes:
- When domain names attack: the WPAD name collision vulnerability
- WPAD name collision bug opens door for MitM attackers
- White paper: enterprise remediation for wpad name collision vulnerability