Hola Visitante

Autor Tema: Descubrimiento Automático de Proxy Web. WPAD  (Leído 3938 veces)

ronal

  • Newbie
  • *
  • Mensajes: 21
    • Ver Perfil
Descubrimiento Automático de Proxy Web. WPAD
« en: Noviembre 27, 2008, 11:15:34 pm »

WPAD. WeB Proxy Auto-Discovery

Digamos que esto es una frivolidad para este fin de semana.... :P

¿quién no ha visto esto alguna vez?



Pues bueno, antecedentes.... El viernes pasado por la tarde en clase me metí en ese “fregao” con mis alumnos... y funcionó pero “a medias” y eso no.... las cosas enteritas y prometí que funcionaría del todo, así que elaboré este manual (para ellos y cómo no... para el foro también)

WPAD es un PROTOCOLO, joer... otro más... muchas aplicaciones (entre ellas Internet Explorer) son compatibles con ello, también Firefox y otros navegadores, pero lo que llama la atención del navegador de Microsoft es que “ya viene de serie” la activación del mismo... y el servicio WinHTTP también...

¿Para qué sirve?

Pues como su nombre indica para que se detecte la presencia de un Proxy Web Automáticamente y se use el mismo a la hora de navegar por la red.

Esto que a primera vista puede ser irrelevante, curioso o simplemente desconocido por muchos, tiene como todo en la vida, sus ventajas e inconvenientes.

La ventaja es para los administradores de una red, no tienen por qué “instruir a mano” los navegadores de los puestos de trabajo uno por uno e ir configurando el Proxy web en cada puesto.

Gracias a este servicio, se puede imponer un Proxy (eso ya a elección de cada uno) en toda una red, es mas, se puede configurar de un modo mas “granular” e incluso decidir qué ip’s salen por el Proxy, cuales no, si para acceder a una determinada dirección se debe usar el Proxy, o si por el contrario no conviene o no se quiere sencillamente.

Ya sabemos lo que es un Proxy, no? Pues bueno, para los despistados y dejando a parte los tipos de proxys, etc. Digamos que es una máquina por la que pasarán todas (o parte) de las conexiones de una red a otra.

Usar un Proxy siempre tiene alguna ventaja añadida, se pueden filtrar contenidos, por ejemplo impedir que los usuarios naveguen a páginas “dudosas”, o imagina un colegio con niños en la sala de informática, pues el Proxy puede impedir que acudan a determinadas páginas que por su contenido no son adecuadas para ellos.

También en determinadas ocasiones y dependiendo del Proxy, se puede acelerar esto de la navegación por la red, puesto que los usuarios en lugar de ir directamente al sitio en cuestión, lo entrega el Proxy, eso es un Proxy caché... en fin, las bondades de los proxys son muchas y ciertamente son interesantes su uso.

Ahora bien, este servicio que viene de serie en Windows, el hecho de que el navegador ya considere que puede “auto-detectarlo” de forma automática sin más, tiene una desventaja...

¿qué pasaría si en una red se añade un “falso” Proxy?

¿qué ocurriría si ese Proxy es “aprendido” por el navegador como lo hace Internet Explorer?

¿Qué pasaría si ese Proxy es “propiedad” de un supuesto atacante?


Ya lo veis claro, verdad? Pues sí!!!! Todo el tráfico web pasaría por ese Proxy (o todo el que el “atacante” desee) y podría capturar todo eso que ya sabemos, contraseñas, claves, cookies, etc...

Todavía podemos ir más allá... un peligro mas grave... las redes inalámbricas... si ese “atacante” consiguió unirse a una red inalámbrica (no hablo ya de una red protegida, pongamos un punto de acceso libre, un hotspot público) y pone en marcha todo el artilugio que nos ocupa en este caso, resultará que aquellas personas que dispongan en su navegador esa opción habilitada, pasarán por el Proxy y por tanto por la máquina del atacante...

Como ya dije, no es sólo propio de Internet Explorer, otros navegadores también lo permiten, Fierefox en la pantalla que sigue...



La diferencia es que no viene de serie activado....

Ya puestos en antecedentes y sabiendo al menos de que va el asunto, el objetivo final de este pequeño documento es capturar lo que nos de la gana de una ip o de una red entera que usa este protocolo.

Vamos a necesitar varias cosas:

Como poco un Proxy “propio”, un esnifer y un servidor web.

Si usamos Linux, como es el caso, también SAMBA

Si usamos Windows, nada...

Y dependiendo del “entorno” de la red vulnerable, un servidor DHCP, un servidor DNS y si ya existe eso en la red, tendremos que tirarlos abajo con alguna herramienta específica.. un martillo y un mazo es algo exagerado, jajaja... pero ya veremos,

Se van a plantear dos escenarios, uno en el que los clientes reciben una IP asignada por un servidor (DHCP) y otro en el que la IP de los clientes de red es estática.

En ambos casos suponemos que no existe DNS corporativo o si existe, no está bien configurado (como es el caso del muuuchoooos por cien de los casos) aún así, y como deferencia a mis alumnos, no explicaré ahora el método con DNS, todavía no llegamos a ese protocolo y no voy a adelantarles nada, otra vez será... una ampliación posterior.

Antes de ponernos al tajo, es IMPRESCINDIBLE, conocer cómo es posible que el navegador conozca la dirección de un Proxy automáticamente.

Según el RFC correspondiente http://www.wrec.org/Drafts/draft-cooper-webi-wpad-00.txt esto se consigue vía DHCP y/o DNS (luego veremos que lo de Windows no tiene perdón de Dios y que no hace falta nada de eso)

Centrémonos en DHCP, cuando un cliente se “engancha” a una red y solicita una Ip, intercambian una serie de mensajes con el servidor... DHCP Discover – DHCP Offer – DHCP ACK son los habituales... pero también existen otros, como DHCP Inform que contiene alguna otra información relevante, en nuestro caso el famoso (a partir de hoy) WPAD.

Ese servidor DHCP contiene en su configuración la información típica y necesaria para entregar a los clientes:

Ese servidor DHCP contiene en su configuración la información típica y necesaria para entregar a los clientes:

      dirección IP
      Máscara de Subred
      Puerta de Enlace
      Servidores DNS
      Tiempo de alquiler de la IP prestada
      .....
      .....

Si ese servidor DHCP se configura, además de con todo eso, para informar al/los clientes de que existe un “Proxy para su detección automática” también se lo dirá a los clientes que soliciten esa IP.

Realmente, lo que les entrega es una dirección URL que incluye la configuración del Proxy, el puerto de conexión y las reglas de quien puede usar el Proxy, quien no, etc...

Por esto mismo necesitaremos un servidor WEB, puesto que lo primero que hará el navegador del cliente es “conectarse” a esa URL para cargar el archivo de configuración.

Hay que hacer notar que el servidor Web y el Proxy no tienen por qué ser la misma máquina, ni tan siquiera estar en la misma red, no es el caso de este ejemplo... como es un “chico malo” monta en su portátil tanto el Web Server como el Proxy, y el esnifer y toda la pesca.. pero en un entorno “seguro” no debería ser así.

Usaremos un dhcpd en Linux y Apache para solventar este asunto desde la máquina del atacante... seguro que ya estás pensando

¿Y si ya existe un DHCP “verdadero”?

Pues si lo dejamos al azar, efectivamente puede ser una lotería... igual unos se conectan mediante nuestro “rogue DHCP” y otros no... por eso, si este es el caso, antes inundaremos la red con falsas peticiones DHCP (incluso se registrarán falsas máuiqnas ante el verdadero Server) y le mantendremos entretenido...

Os recuerdo que no hay forma posible de “elegir” un servidor DHCP por parte del cliente, sencillamente el primero que responde es el que se lleva “el gato al agua”, por tanto, si la “bueno” lo mantenemos entretenido, no asignará Ip’s y lo hará el nuestro.

Ya dije antes que esto puede ser MUY grave en redes inalámbricas, porque si antes de la inundación DHCP enviamos paquetes de desautenticación a los clientes legítimamente conectados, se irán de la red y cuando vuelvan, será nuestro DHCP_Malo el que se las asigne.

Me evito comentar “paso a paso” el tema del Server DHCP, nos bastará con saber dos cosas para el caso de Linux y el que nos ocupa:

[list=]El archivo de configuración del Server está situado en /etc/dhcpd.conf

El archivo de “alquileres” de Ips, vamos las que se asignan a los clientes esta en: /var/state/dhcp/dhcpd.leases
Si queremos informar de un “posible” Proxy para ser “auto-descubierto” tenemos que añadir (al menos) dos líneas en el archivo de configuiración dhcpd.conf, estas son:

Código: [Seleccionar]
option wpad-url code 252 = text; # en la configuración global

option wpad-url = \"http://dirección_del_proxy/archivo.pac\" # en la configuración de la/las subredes que asigna.


Quedaría así, ,mas o menos:

Código: [Seleccionar]
ddns-update-style none;
option domain-name \"Malo_DHCP\";
option domain-name-servers 195.235.113.3, 195.235.96.90;
default-lease-time 600;
max-lease-time 7200;
authoritative;
option wpad-url code 252 = text;
subnet 192.168.4.0 netmask 255.255.255.0 {
   range 192.168.4.50 192.168.4.80;
   option routers 192.168.4.254;
   option broadcast-address 192.168.4.255
default-lease-time 600;
max-lease-time 7200;
option netbios-node-type 2;
option wpad-url = \"http://192.168.4.66/proxy.pac \";
}


Esto asigna ip’s de la 192.168.4.50 a la 192.168.4.80, con máscara de subred 255.255.255.0, puerta de enlace 192.168.4.254, dns 195.235.113.3 y 195.235.96.90 con un tiempo de alquiler de 600 segundos por defecto y 7200 segundos máximo.

IMPORTANTE LA ÚLTIMA línea, es la dirección IP del servidor web y archivo que se cargará (proxy.pac) y MAS IMPORTANTE TODAVÍA, que después del último carácter y las comillas exista un espacio y/u otro carácter, por ejemplo esto:

Código: [Seleccionar]
option wpad-url = \"http://192.168.4.66/proxy.pac\\\\n\";

El motivo es porque algunos navegadores fallan si no es así... cosas de la vida...

Recuerda que esa ip ha de ser la del servidor web, no la del Proxy, que en este ejmplo será la misma tanto para uno como para el otro, pero que no tiene por qué ser de ese modo.

Ahora tenemos que plasmar qué diántres contiene el archivo proxy.pac.

Pues es un código javascript, que en su versión más resumida e ínfima puede ser el que se muestra:

Código: [Seleccionar]
function FindProxyForUrl (url, host) {
   return \"PROXY 192.168.4.66:8888\";
}


Ese pequeño código informará al navegador del cliente que la dirección IP del Proxy es 192.168.4.66 y que está escuchando por el puerto 8888.

Siento ser tan repetitivo... esa IP es la misma que la del web Server, pero no tiene por qué serlo, podría ser otra máquina.

Al final del texto os pondré otras “posibilidades” del archivo .pac, como ya aventuré anteriormente, se puede decidir si unas ips usaran el Proxy o no, si unas direcciones web de Internet o de intranet se accedien mediante le Proxy o no, los puertos... etc....

También hay que reseñar otra cosa... ese archivo lo llevaremos al directorio donde el webserver guarda las páginas web, vamos al document root, si es un apache pues por ejemplo en /usr/local/apache/htdocs

Y mas cosas, hay que “enseñar” a apache o al webserver que se use para que interprete correctamente las extensiones .pac y el autodiscovery... Eso lo conseguimos añadiendo una línea del tipo AddType y/o en la configuración del Virtual Host, este es un ejemplo:

En la sección Addtype de Apache en el archivo httpd.conf añadimos:

Código: [Seleccionar]
AddType application/x-ns-proxy-autoconfig .pac

Y en VirtualHost del mismo archivo httpd.conf, añadimos:

Código: [Seleccionar]

         ServerName 192.168.4.66
         ServerAlias 192.168.4.66
         AddType application/x-ns-proxy-autoconfig .pac


Bueno, el ultimo AddType nos lo podemos ahorrar.. pero ya que está puesto...

Y otra cosa mas... bueno, eso lo digo después...

Bien, ya tenemos todo... antes de intentar nada, vamos a ver si funcionan las cosas como deben ser:

Probando el servidor DCHP en LINUX

Verificamos que el archivo /etc/dhcpd.conf está en su sitio y con el contenido correcto:



Creamos el archivo de “alquileres”



Y ahora vamos a probar si un cliente cualquiera (en este caso un Windows 2003) obtiene la IP automática:



OK

Probando Servidor Web

Verificamos como antes la ubicación de los archivos, las rutas y el contenido de la url proxy.pac



También hacemos lo mismo con el archivo de configuración de apache y la sección VirtualHost, el Addtype y eso que ya se dijo...



Iniciamos el servidor web y verificamos que los procesos dhcpd y httpd están corriendo:



Comprobamos que tenemos acceso al web Server:



Ponemos en marcha “nuestro Proxy” usaré 3proxy pero sirve cualquier otro... por supuesto a la espera de conexiones por el puerto 8888



Desde el Windows, navegamos un rato... a google, a wadalbertia... y nuestro Proxy “lo capta” como era de esperar....



Todo perfecto, no iba a ser menos

Y si resulta que ya existiese un dhcp en la red?

Pues con las ips que ya entregó poco podemos hacer... pero para “los nuevos” podemos entretenerle, inundarle de peticiones.... usaremos un flooder que se llama dhcpx, lo deamos un ratito, con un minuto sera suficiente:



Y si vemos la tabla de ese “verdadero” DHCP, curioso.... registros falsos por todas partes:



Si esto lo trasladamos a una red inalámbrica, es mucho mas simple... porque si tras inundar al Server dhcp desautenticamos a los usuarios conectados, ya sabes... aireplay-ng y el ataque –0 0....., cuando se vuelven a conectar, obtendrán la IP de nuestro “maldito” dhcp y su tráfico por nuestra máquina

Ahora vamos al segundo caso... aquel en el que el/los equipos de esa red tienen IP estática, por ejemplo...

      ip fija 192.168.4.222
      mascara 255.255.255.0
      puerta de enlace 192.168.4.254
      DNS públicos, 195.235.113.3 195.235.96.90



Si lo dejamos “tal cual” no funcionará lo del Proxy, porque ese equipo “no sabe” que existe un Proxy automático de configuración... nadie se lo ha dicho, antes fue dhcp, pero al ponerle una ip “a mano”, nada de nada, se lo tendría que decir.... un DNS.

En estos casos se debe utilizar el servicio DNS, pero ni podemos, ni esa máquina lo hará puesto que los DNS son públicos...

En un entorno “normal” sería el mismo DNS quien ha de guardar la dirección del servidor web y la del Proxy... y aquí es donde caen muchos.... nadie se acuerda de esto ni de quitar lo del auto descubrimiento del Proxy en los navegadores....

Y entonces? Que? Ponemos un DNS?

Hombre es una opción, pero... si ya tienen el DNS “a mano” no podemos hacerlo.... no usarían el nuestro sino el que figura en las casillitas de arriba...

Pero en fin, Windows es como es... UTILIZA NETBIOS!!!!

NetBios es otro protocolo, propietario de los Windows, un engendro que idearon hace años Microsoft e IBM, el caso es que como el DNS no les resolverá el nombre o la IP del Proxy, lo buscarán por NetBIOS, válgame DIOS que penita....

Lo primero que tenemos que hacer es cambiarnos el nombre en la máquina Linux... por cual??? Jajaja, ni mas ni menos que por wpad



Una vez hecho esto, lanzamos de nuevo el Proxy como antes:



(observa que ya o se llama vic_thor la máquina, sino wpad)

Y cómo usamos NetBios con Linux?

Pues con SAMBA

Para configurar SAMBA al efecto, necesitamos saber cual es el grupo de trabajo de la red... eso es fácil, los Windows y NetBios son muy parlanchines, continuamente está anunciandose...

Con un esnifer cualquiera lo podremos conseguir puesto que gran parte del tráfico NetBios es broadcast (para todos), en el ejemplo vemos claramente que el grupo de trabajo se llama CASA:



*Nota: En esta pantalla aparece la IP 192.168.4.111 en lugar de la 192.168.4.222, no \"me pienses mal\" no hay truco... es simplemente que me equivoqué de máquina en la captura...

Así que ahora, desde un frontend para samba o desde el mismo archivo de configuración (smb.conf) “tuneamos” samba como ha de estar:



También hay que cambiar otras opciones, elegirnos como master browser y los puertos netbios....



Y los puertos....



Ya lo tenemos....

Desde la shell ejecutamos nmbd para lanzarnos a la red Windows diciendo que somos wpad y estamos “listos para participar”

Vamos a ver si “nos ven”, desde el equipo Windows hacemos un ping a wpad



Ea!!! Somos nosotros :P

Si nuestro “amigo” el de la ip estática tiene verificada la casilla de detectar Proxy automáticamente... pasará lo mismo de antes...



Ahora va a google, luego a debian, a yahoo... vamos, lo de antes pero mediante netbios.

Esto se debe a que también “por defecto” se activa NETBIOS en los Windows...



Para impedir todo esto, ya sabes... Desactivar lo del Proxy automático en los navegadores, levantar un DNS privado que registre apropiadamente a sus clientes INCLUYENDO la máquina wpad y wpad. (ojito con el punto al final) también hay que registrar el servidor web y eso... y por supuesto deshabilitar netbios sobre tcp/ip, aunque eso, a pesar de lo que parece no es tan sencillo... pero algo es algo...

Por último, sería conveniente que el archivo proxy.pac del webserver se llame también wpad.dat, vamos que lo copies con ese nombre en el mismo directorio httdocs, realmente buscarán ese archivo por NetBios y si el servidor web no es la misma máquina del Proxy y no es un Windows daría problemas... así que mejor, los dos... un proxy.pac y otro wpad.dat, el mismo perro con dos collares

Y ya para terminar te dejo un ejemplo “mas granular” del archivo de configuración .pac o .dat, no hace falta mucha mas información que la que se muestra:

Código: [Seleccionar]

// Ejemplo Básico. TODO  pasa por el proxy 192.168.4.100:8888

// function FindProxyForURL(url, host)
{
//       return \"PROXY 192.168.4.100:8888\";
// }


//Ejemplo mas detallado

function FindProxyForURL(url, host) {


// indicar una línea por cada url a la que se accede sin el proxy...
     // Acceso a URL's que no precisen de proxy:
     if (shExpMatch(url,\"*.foo.com/*\"))       {return \"DIRECT\";}
     if (shExpMatch(url, \"*.foo.com:*/*\"))    {return \"DIRECT\";}
     if (shExpMatch(url, \"*.microsoft.com:*/*\"))   {return \"DIRECT\";}

// Si existen varios proxys, se pueden indicar por IP o por nombre DNS

     // Acceso con proxy a ip's determinadas de la red
     // puerto del proxy 8888 del proxy fastproxy.foo.com:

     if (isInNet(host, \"192.168.4.33\",  \"255.255.255.0\"))    {
        return \"PROXY fastproxy.foo.com:8888\";
     // tambien podría ser return \"PROXY 192.168.4.100:8888 si esa
     //fuese la ip de fastproxy.foo.com:8888
     }
     
     // Para el resto de condiciones que no se cumplen se indica el
    // nombre del proxy o la dirección IP del mismo

     return \"PROXY 192.168.4.100:8888; DIRECT\";
     // también podria ser return \"PROXY miproxy.foo.com:8888\" igual
    //que antes...

  }


Si lo piensas... hasta pueden existir varios proxys... y si investigas por tu cuenta, averiguarás que también hay mas opciones de descubrimiento, hasta para ftp....

Suerte.

Este Articulo a sido creado por Vic_thor y publicado en:
http://www.wadalbertia.org/phpBB2/viewtopic.php?t=4339

.

Berni69

  • Administrator
  • *****
  • Mensajes: 25
    • Ver Perfil
Re: Descubrimiento Automático de Proxy Web. WPAD
« Respuesta #1 en: Julio 12, 2009, 12:00:37 pm »
ostiaa no lo habia leido, y eso que llevaba muichisimo tiempo publicado en el foro
es una manual bastante bueno, gracias pro la aportacion ronal