martes, 20 de enero de 2009

Protocolos de Enrutamiento. Atacando a RIP (Parte3)

Aunque esto lo vamos a descubrir en un momentito, está bien que sepamos las Ip’s de los routers que interconectan nuestra empresa...

Veamos:

RS: Es el router que conecta recursos con Internet, tiene 2 interfaces:

· LAN: 192.168.43.254
· WAN: xxx.xxx.xxx.xxx (es la pública, claro)

RC: Es el router de la sede central que conecta recursos con la sede central y con las oficinas:

· Interface1: 192.168.4.111, conecta Central con Recursos
· Interface2: 172.28.0.111, Conecta Central con Oficina 1 y Oficina2

RO1: Es el Router de Oficina 1 que conecta con central

· Interface1: 172.28.0.112 que conecta Oficina 1 y central
· Interface2: 192.168.200.111 que conecta la red de Oficina1, vamos, que será la puerta de enlace para la gente de ficina1

RO2: Es el router que conecta Oficina 2 con la Central

· Interface 1: 172.28.0.113 que conecta Oficina 2 y Central
· Interface 2: 10.0.0.111 que conecta que conecta la red de Oficina2, vamos, que será la puerta de enlace para la gente de Oficina2

ATACANTE: Máquina Linux situada en central

· Interface1: 172.28.0.66 y puerta de enlace 172.28.0.111

Otro gráfico... uno mas para verlo mas claro:

El ataque consistirá en hacer pasar el tráfico de las oficinas por la máquina del atacante mediante el envío de actualizaciones RIP a los routers de la topología, para ello la máquina 172.28.0.66 (el atacante) falseará su IP y enviará dichas actualizaciones a los routers R01 y R02 haciéndose pasar por RC, los paquetes a enviar les indicarán a los routers involucrados que para llegar a Internet o a la red de recursos corporativos, la mejor manera de llegar es a través de él mismo... luego re-enrutará el tráfico hacia el verdadero destino de los paquetes y las respuestas de vuelta las enviará de nuevo a los legítimos orígenes.

La ip objetivo del ataque será la 10.0.0.55 que está situada en la red de la oficina2, este equipo se conecta habitualmente a una web importantísima para su trabajo diario...

http://www.wadalbertia.org/phpBB2/index.php

Para lograr el objetivo, el atacante necesita saber:

· Ip origen: nuestra víctima la ip 10.0.0.55
· IP destino: la de estos foros... 67.225.138.174

Realmente necesitamos la red destino... que bien puede ser 67.225.138.0/24, pero en este ejemplo usaremos sólo la IP.

También necesitaremos saber o estar seguros de que la métrica hacia esa red desde el origen es mayor a 1, puesto que si fuese uno el router de la oficina 2 podría hacer tres cosas:

a) Balancear la carga, el 50% de los paquetes irían por la interface del router y la otra mitad por la de la máquina del atacante
b) Usar únicamente la interface del router de oficina 2
c) Usar únicamente la máquina del atacante.

Esto lo podremos averiguar con un simple trazado de rutas hacia la víctima y otro trazado hacia wadalbertia, sumamos los saltos y será la métrica que aplicará el router de la oficina2.

Hombre, esto ya lo sabíamos de antes, tenemos unos dibujitos maravillosos, pero claro... no siempre sería así, verdad?

Bien, para verlo mas claro, hagamos como si estuviésemos en la máquina 10.0.0.55 y lanzamos un esnifer para RIP... se llama ass (no... no es culo como su significado indica) es Autonomous System Sniffer, ciertamente no sólo sirve para RIP, pero aquí lo usaremos para ello.


Podemos apreciar que para llegar a la red 172.28.0.0 (que se supone que es donde está el atacante) necesita de un salto, mientras que para ir a otras redes precisa de 2 ó 3 saltos... por tanto, si le decimos que para ir a wadalbertia se necesita sólo un salto y es por 172.28.0.66 (ip del atacante) se lo tragará....

Ahora veámoslo desde el punto de vista del atacante...

Primero hacemos un traceroute a la ip 10.0.0.55 (víctima), luego otro traceroute hacia wadalbertia (red destino que queremos ponernos en medio)

Nota: La salida del traceroute a wadalbertia la paré antes de que terminase,

Si te fijas, desde el atacante se pasan por los routers 172.28.0.111 y 172.28.0.113 para llegar a la red 10.0.0.0, recuerda también que el router 172.28.0.113 es el que nos conecta a la red víctima...

Y para llegar a wadalbertia, se pasan por los routers 172.28.0.111 y 192.168.4.254 (y mas... pero como ya te dije lo paré antes de que terminase puesto que el resto de saltos no nos interesan)

Por tanto, necesitará al menos dos saltos, por tanto, si conseguimos “enseñar” al router 172.28.0.113 que para ir a wadalbertia en lugar de dos saltos necesita uno sólo, la cosa está finiquitada.

Si corremos el esniffer desde “nuestra” posición, nos haremos una idea mas clara de la topología... casi, casi como en los gráficos (casi)

Una cosa antes de ponerte la captura de pantalla, hay que dejar un minuto mas o menos el esniffer corriendo, QUE NO SABES POR QUÉ???? Coña, lo de las actualizaciones de RIP, los 30 segundos de rigor y todo eso... que para ello lo expliqué antes

Bien, saldrán unos numeritos, unos y doses, eso son paquetes RIPv1 y RIPv2 respectivamente... veámoslo:

Como observarás en la pantalla anterior, claramente descubrimos como es el enrutamiento, los routers, los vecinos, las Ip’s, las métricas... vamos, todo....

Bueno, pues ahora hay que preparar el ataque... inyectaremos un paquete con destino a 172.28.0.113 (router de la red 10.0.0.0) haciéndonos pasar por 172.28.0.111 (siguiente salto de la red 10.0.0.0), diciéndole que para ir a Wadalbertia (67.225.138.174) se va “mejor” (métrica 1) por 172.28.0.66 (máquina del atacante)

Y TODO el tráfico de 10.0.0.55 con destino a Wadalbertia pasará por nuestra máquina

PERO ANTES!!! Antes, si queremos que la red víctima reciba respuestas, tendremos que poner nuestra IP como origen de los paquetes y no la de la víctima!!! Vamos que si no hacemos NAT el tráfico de salida pasará por nosotros pero el de vuelta no...

Y cómo hacemos NAT en Linux???? Pues claro, hombre claro... IPTABLES!!!

Por tanto, ANTES de inyectar nada:

· Habilitamos el reenvío:

echo 1 > /proc/sys/net/ipv4/ip_forward

· Hacemos nat en origen:

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.55 -j SNAT --to-source 172.28.0.66

Y ZAS!!! TODO el tráfico entre la IP 10.0.0.55 y Wadalbertia pasará por nuestra máquina (cuando inyectemos el paquete) y seremos capaces de capturar también el tráfico de vuelta y entregárselo a la red de la víctima

Ahora, si... un generador de paquetes, podemos usar el que queramos, nemesis es buan opción, pero hay uno también especializado en RIP, se llama srip

Lo que haremos es:

srip -2 -n 255.255.255.0 -g 172.28.0.111 172.28.0.66 172.28.0.113 67.225.138.174 1

Que es:

–2 (RIP versión 2)

-n 255.255.255.0 máscara de subred

-g 172.28.0.111 IP del router o gateway que enviará el paquete ip-spoofing)

172.28.0.66 máquina del siguiente salto

172.28.0.113 Router al que se le enviará el paquete

67.225.138.174 Red ó IP que se llega vía 172.28.0.66

1 Métrica (numero de saltos)

Y se actualizará la tabla de rutas del router 172.28.0.113 con esa entrada... la aceptará porque viene de 172.28.0.111, aunque valide el origen del paquete, llegará....

Veamos que pasa ANTES de inyectar el paquete, supongamos que la máquina 10.0.0.55 hace un trace route a wadalbertia (salida cortada)

Y ahora DESPUES de inyectar el paquete:

Como ves hay un salto “extra” la máquina 172.28.0.66 que somos nosotros

Si ponemos un esnifer y la máquina Linux para capturar contraseñas y eso, pues.... está claro, no?

Por cierto... ahora nuestros en nuestros foros la contraseña ya no viaja en texto plano,


El usuario, si se ve en texto plano... “pepillo

Y el password en md5 que era... “eldelospalotes

En fin, espero que haya sido de interés, he de decir que este fin de semana nos entretuvimos un poco en clase con este asunto, venga que lo sé... que más de un alumno mio anda por aquí... a que sí? Jajaa, menudo tema... entre esto, lo del secuestro de sesiones y STP, vaya fin de semana que nos pasamos.

Saludos, a mis alumnos también

PD:

ass (pertenece a la suite de IRPAS) lo podéis encontrar en:

http://www.phenoelit-us.org/irpas/download.html

srip (fuente en C, hay que compilarlo) en:

http://packetstormsecurity.org/groups/horizon/srip.c

Ayy!!! que se me olvidan "las soluciones"...

* Autenticar RIP mediante CHAP

* Silenciar las interfaces del router por las que no se deben enviar actualizaciones, p.e. las ethernet (interfaces pasivas y/o ACLS)

* Filtros y listas de acceso al puerto 520 de UDP y/o a las direcciones de multicast

* validar el origen de los paquetes

* Usar rutas estáticas (cuando se pueda)

* Utilizar protocolos "mas fuertes" como OSPF (que también es vulnerable a este tipo de ataques, pero algo mas complejo)

* Vigilar... un simple traceroute delatará el asunto.

Protocolos de Enrutamiento. Atacando a RIP (Parte1)
Protocolos de Enrutamiento. Atacando a RIP (Parte2)

Autor: Vic_Thor
Publicado en: www.wadalbertia.org

No hay comentarios: