Y desde el Router... Qué? Parte III

[Vic_Thor]

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:



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:



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:



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



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!!!!



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



Fácil, no??

Saludos.

Saludos.
Excelente gracias.
Justo estaba armando un ataque de este estilo.

jeje la que hay liada por aqui.

Un saludo!

Saludos.
Configuré apache como proxy de la forma que lo indicas en el video(equipo A), ahora me puse como proxy al equipo A;
el resultado es que cualquier peticion que haga a cualquier dominio me lo redirige hacia el que especifiqué en:

  Código:

ProxyPass / dominio
y
ProxyPassReverse / dominio

Bien, supongase que le hago creer a la victima que http://www.D1.com y http://www.D2.com corresponden a la ip del atacante, cual debe ser
la sintaxis que debo poner en el httpd.conf de apache para que cada dominio lo redireccione al correcto?.(actualmente ambos los redirecciona a http://www.D1.com).
Gracias de antemano.

P.D: La pregunta viene de: ¿ Como hace el atacante para obtener los datos no solo de wadalbertia sino de otros dominios adicionales?.

[Vic_Thor]

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

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

  Código:

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

  Código:

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

y así los que gustes...

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

  Código:

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

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

pues entre otras cosas necesitarás algo así:

  Código:

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

  Código:

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

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

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

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

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

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

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

"Dr. Wadalberto Informa:

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

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

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

Accede y escribenos!!!

Saludos!"

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

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

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

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

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

Hola:

Ahora mismo acabo de terminar de reelerme los tres textos... Como siempre, en tu línea!

Si no me equivoco, en este texto lo que hacemos es cambiar la dirección IP de los servidores DNS del Router de la víctima por un servidor "controlado" por nosotros con el fin de controlar la resolución de nombres de dominio...

Con esto conseguiremos hacer, por ejemplo un DNS spoofing, falsificar resoluciones de dominio. Siendo más concretos... Cuando la víctima introduzca en su navegador http://www.wadalbertia.org, en vez de resolver el dominio hacia la dirección IP: 67.225.138.XXX (verdadera) sea resulta a otra dirección IP controlada por el atacante, y en donde pueda correr un servidor web que falsifique la identidad del portal de wadalbertia con el objetivo por ejemplo de capturar contraseñas...

Es importante dejar claro que el servidor DNS tan solo resuelve dominios en direcciones IP no participa en la conexión entre cliente y servidor. Es decir, cuando se establece la conexión entre víctima y servidor web los servidores DNS ya no son utilizados.

En tu ejemplo, si no me equivoco, realizas un DNS spoofing, para resolver engañosamente una resolución hacia un hosts controlado por ti, en este caso la resolucion de dominio de http://www.wadalbertia.org, para que dicho hosts pueda sniffar la conexión, en este caso utilizas un servidor proxy para recibir y reenviar datos a Internet y a la ethernet víctima, luego utilizas un sniffer para capturar dicho tráfico...

Resumidamente... ¿Me equivoco?

A mi se me ocurre otra forma...

Una vez que tenemos realizado el túnel, casi casi podemos decir que el "chollo" que tenemos montado es como si se tratase de una red ethernet normal, como si los hosts estuvieran físicamente conectados al mismo segmento de red... Vale no! Los protocolos y otras historias funcionarán de diferente manera... pero para lo que yo quiero explicar creo que vale el concepto...

Para poder robar y capturar información sensible podríamos atacar por otro lado... jugar con las tablas de enrrutamiento... Me explico:

Explicaré el concepto resumidamente, sin profundizar en ello para evitar extenderme demasiado.

Podemos hacer que todas las conexiones que salgan a Internet desde la red victima pasen por un hosts controlado por el atacante, ese hosts actuaria como puerta de enlace, aunque se encuentre en otra red. En este hosts estaría corriendo un sniffer para capturar todo tipo de tráfico y un proxy para reenviar el tráfico a internet y a la red ethernet víctima, actuaría como un "router de internet" con un sniffer...

El inconveniente que tiene esto es si manipulamos la puerta de enlace del Router por donde salen las conexiones a Internet de la red víctima podemos realizar un bucle infinito que provocará que no exista conexión a internet en la red víctima a menos que las conexiones a internet salgan por la red atacante... No se si podría haber otra solución...

Podemos atacar a través del servidor DHCP, indicándole que asigne a los hosts de la red vícitma como puerta de enlace nuestro Router que a su vez redirigirá las conexiones al hosts controlado con un sniffer + un proxy, de esta forma las conexiones a internet saldrán por el Router de la víctima...

No se si me he explicado claramente... y si no existen otros inconvenientes... pero creo que también sería factible... ¿me equivoco?

Un saludo.

[Vic_Thor]

....
....

Si no me equivoco, en este texto lo que hacemos es cambiar la dirección IP de los servidores DNS del Router de la víctima por un servidor "controlado" por nosotros con el fin de controlar la resolución de nombres de dominio...

Correcto!

Con esto conseguiremos hacer, por ejemplo un DNS spoofing, falsificar resoluciones de dominio. Siendo más concretos... Cuando la víctima introduzca en su navegador http://www.wadalbertia.org, en vez de resolver el dominio hacia la dirección IP: 67.225.138.XXX (verdadera) sea resulta a otra dirección IP controlada por el atacante, y en donde pueda correr un servidor web que falsifique la identidad del portal de wadalbertia con el objetivo por ejemplo de capturar contraseñas...

Vamos bien...

Es importante dejar claro que el servidor DNS tan solo resuelve dominios en direcciones IP no participa en la conexión entre cliente y servidor. Es decir, cuando se establece la conexión entre víctima y servidor web los servidores DNS ya no son utilizados.

Seguimos bien... + una aclaración...

En el "ejemplo" tanto el dns como "todo lo demás" está en el mismo equipo del atacante, pero no tiene por qué ser así!!!

La ventaja es que el DNS "malo" puede ser otra máquina (incluso otra máquina con ip pública diferente al de la máquina que captura los datos)

En tu ejemplo, si no me equivoco, realizas un DNS spoofing, para resolver engañosamente una resolución hacia un hosts controlado por ti, en este caso la resolucion de dominio de http://www.wadalbertia.org, para que dicho hosts pueda sniffar la conexión, en este caso utilizas un servidor proxy para recibir y reenviar datos a Internet y a la ethernet víctima, luego utilizas un sniffer para capturar dicho tráfico...

Resumidamente... ¿Me equivoco?

No te equivocas... recuerda lo que dije antes... el servidor dns sólo necesita resolver una u otra ip... no tienen por qué coindicidr la ip pública del dns con la ip pública del atacante (cuando toque la parte IV se verá el ejemplo "práctico")

A mi se me ocurre otra forma...

Una vez que tenemos realizado el túnel, casi casi podemos decir que el "chollo" que tenemos montado es como si se tratase de una red ethernet normal, como si los hosts estuvieran físicamente conectados al mismo segmento de red... Vale no! Los protocolos y otras historias funcionarán de diferente manera... pero para lo que yo quiero explicar creo que vale el concepto...

mmmm, en éste ejemplo (el de la parte III, NO HAY TÚNEL!!!) lo que cuentas, en el mejor de los casos, podríamos aplicarlo a la parte I ó parte II y en esos escenarios no necesitamos un dns puesto que ya el tráfico lo redirigimos a nuestro antojo.

Para poder robar y capturar información sensible podríamos atacar por otro lado... jugar con las tablas de enrrutamiento... Me explico:

Explicaré el concepto resumidamente, sin profundizar en ello para evitar extenderme demasiado.

Podemos hacer que todas las conexiones que salgan a Internet desde la red victima pasen por un hosts controlado por el atacante, ese hosts actuaria como puerta de enlace, aunque se encuentre en otra red. En este hosts estaría corriendo un sniffer para capturar todo tipo de tráfico y un proxy para reenviar el tráfico a internet y a la red ethernet víctima, actuaría como un "router de internet" con un sniffer...

El inconveniente que tiene esto es si manipulamos la puerta de enlace del Router por donde salen las conexiones a Internet de la red víctima podemos realizar un bucle infinito que provocará que no exista conexión a internet en la red víctima a menos que las conexiones a internet salgan por la red atacante... No se si podría haber otra solución...

La teroría está "casi" pero no es viable.

No se puede porque si manipulas la tabla de rutas, que es lo que se hace en definitiva en las partes anteriores, debe existir contacto físico entre las interfaces... es decir, si creas una nueva entrada diciendo que "para ir a cualquier sitio el próximo salto es la ip del atacante" no funcionará, puesto que la ip pública del atacante y la ip pública de la víctima no están directamente conectadas!!!!

Y por su puesto, las ip's locales o internas de ambas redes tampoco lo están.

Por ello el túnel... si no hay túnel, no hay contacto físico y por ende los paquetes no saldrán a ninguna parte.

Y repito... en este caso en la parte III, no hay túnel, sólo el desvío por el DNS.

Podemos atacar a través del servidor DHCP, indicándole que asigne a los hosts de la red vícitma como puerta de enlace nuestro Router que a su vez redirigirá las conexiones al hosts controlado con un sniffer + un proxy, de esta forma las conexiones a internet saldrán por el Router de la víctima...

No se puede por lo que dije antes... no puedes poner como puerta de enlace una máquina que no tienes físicamente conectada a la red.

Hola:

¡Gracias por la aclaración, Vic_Thor!

Solo una cosa más, si tenemos montada un VPN, tampoco sería factible lo que propongo?

Un saludo.

[Vic_Thor]

Si, con una VPN podría ser... en definitiva es un túnel, al estilo de GRE del ejemplo.

Podrías "envenenarlos" pero no cambiar las puertas de enlace puesto qu si es así la víctima perdería la conexión. Hay un caso "especial" , lo dejo como pregunta para que deis vuestras opiniones.... (jejeje, me salió la vena de profe): "que pasaría si ambas redes, víctima y atacante comparten el mismo direccionamiento IP? O sea, supongamos que tanto la red local víctima como la red local atacante utilizan 192.168.0.0/24 con puerta de enlace 192.169.0.1... que pasaría????"

Si, con una VPN podría ser... en definitiva es un túnel, al estilo de GRE del ejemplo.

Podrías "envenenarlos" pero no cambiar las puertas de enlace puesto qu si es así la víctima perdería la conexión. Hay un caso "especial" , lo dejo como pregunta para que deis vuestras opiniones.... (jejeje, me salió la vena de profe): "que pasaría si ambas redes, víctima y atacante comparten el mismo direccionamiento IP? O sea, supongamos que tanto la red local víctima como la red local atacante utilizan 192.168.0.0/24 con puerta de enlace 192.169.0.1... que pasaría????"

Con linux yo lo hacía con ebtables en el gateway remoto conectado por vpn y así conseguía que los paquetes a determinada IP saliese por su "adsl" y lo que me interesaba lo sacaba por la VPN hasta nuestro cpd donde se filtraba dicho tráfico, todo de forma transparente.

Lo de la vpn con la misma subnet en cada extremo se resuelve con un 1-1 NAT y un proxy arp.

un saludo

Hola:

Al final me he liado yo solo...

Yo me refería al ejemplo con una VPN/Tunel.

Podrías "envenenarlos" pero no cambiar las puertas de enlace puesto qu si es así la víctima perdería la conexión

Esto es a lo que me refería yo en mi anterior post... podríamos provocar un bucle infinito, a menos que: salgamos a Internet por la red del Atacante.

O que ataquemos al servidor DHCP del Router Victima para que asigne como puerta de enlace una dirección controlada por nosotros, el inconveniente que tiene esto es: Solo es posible si los hosts de la red utilizan el servidor DHCP, si las direcciones IP son introducidas "a mano" no es posible, a menos que hagamos un ARP Spoof, pero como se trata de subredes diferentes ya se complica el asunto...

Un saludo.

Saludos.
Para realizar esta practica en linux utilice un servidor dns(bind9) y un servidor proxy(squid), pero no he logrado completar la practica debido
a un error que me manda el squid.
Les cuento lo que hago para ver si me pueden ayudar a resolver el problema.

1. Configuro en el servidor DNS(que corre en 10.10.7.87) que http://www.wadalbertia.org corresponde a 10.10.7.87.
2. Subo el servicio Squid /2.7.STABLE3 en el puerto 80
3. Cuando la victima pide http://www.wadalbertia.org, el DNS le devuelve 10.10.7.87. Ahora la victima asume que esta IP es wadalbertia,
inicia el saludo de 3 vias y hace GET HTTP/1.1 (Obviamente en el campo Host del http manda http://www.wadalbertia.org).
4. Cuando la victima hace el GET al squid obtiene un mensaje como el siguiente:

  Código:

ERROR
The requested URL could not be retrieved

While trying to process the request:

GET / HTTP/1.1
Host: www.wadalbertia.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; es-ES; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: ***



The following error was encountered:

    * Invalid Request

Some aspect of the HTTP Request is invalid. Possible problems:

    * Missing or unknown request method
    * Missing URL
    * Missing HTTP Identifier (HTTP/1.0)
    * Request is too large
    * Content-Length missing for POST or PUT requests
    * Illegal character in hostname; underscores are not allowed

Your cache administrator is webmaster.
Generated Mon, 09 Aug 2010 21:54:39 GMT by backtrack (squid/2.7.STABLE3)

Es decir, El squid no redirecciona la peticion HTTP.
Por otro lado, si configuro en la victima que utilice Squid como servidor proxy, y luego pido http://www.wadalbertia.org, me lo retorna sin ningun problema.

En resumen, si configuro squid de forma manual en la victima, este redirecciona todo el trafico (como debe ser), si obligo a la victima a usar Squid como proxy(mediante el cambio de DNS, etc etc) me sale el error que les pongo arriba.
Alguien sabe como solucionar el problema?, que estoy haciendo mal?

P.D: Utilice squid porque no pude encontrar la configuracion del apache que trae el backtrack, si alguien sabe como
configurar el apache que viene en backtrack, su descripcion me seria de ayuda.

Gracias de antemano.

Hola

Creo que lo que necesitas es poner a squid en modo transparente, con iptables lo puedes hacer sin problemas.

un saludo

[Vic_Thor]

Puesdes hacerlo con squid como te han dicho.

En Backtrack tienes apache y su configuración dentro de /etc/apache2 y siguientes... tan solo tienes que pasar los modulos necesarios que están en /etc/apache2/mods-available a /etc/apache2/mods-enabled y luego la configuración "particular" la puedes hacer en /etc/apache2/httpd.conf, los virtualhost en /etc/apache2/sites-enabled/000-default o como quieras llamarlo.

Saludos.
Bien!!!, lo he lograo.
La solucion fue poner squid como proxy transparente, aunque no fue precisamente con iptables, ya que yo lo tenia corriendo en el puerto 80.
Sin embargo lo cambie de puerto al 3128 y le indique al iptables que las request al puerto 80 las reenviara al 3128. Hasta aqui el problema persistia.
Luego cambie en el /etc/squid/squid.conf la linea:

http_port 3128

por esta otra

http_port Myip:3128 transparent.

Y funcionó.
Sin embargo, ahora esta el problema de que el squid no redirecciona las peticiones https. Alguien sabe como solucionarlo?
Me imagino que de eso se trata la parte IV de esta serie (o no vic_thor?), si queries podeis adelantarme como se configura el apache para redireccionar https(o el squid).

Vamos vic_thor con la parte IV, fuerza con ese excelente material.