En este mi primer artículo hablaré sobre la posibilidad que tiene un intruso para realizar un ataque de Denegación de Servicio (DoS) mediante la creación de paquetes HSRP falsos, si no tomamos ciertas precauciones. Por si acaso:
Renuncia, Disclaimer:
“Toda la información aquí presente ha sido elaborada con fines puramente educativos, para colaborar en el conocimiento de la seguridad en redes de datos. El autor NO se hace responsable del mal uso que pueda darse a la misma o de las consecuencias que puedan derivarse en la puesta en práctica de estas técnicas.”
Para ello elaboraremos un laboratorio virtualizado mediante la aplicación GNS3, integrando varias máquinas virtuales con VMWare Workstation, que represente un escenario real. Para saber cómo hacerlo os recomiendo la siguiente lectura que encontraréis aquí.
Tomaremos la siguiente topología:
En este caso los switches de capa 3 “CORE01” y “CORE02” son los encargados de realizar el enrutamiento entre las vlan 10, 11 y 200 para lo que se han definido 3 interfaces virtuales, una por cada VLAN y cuyas IP´s figuran a los lados de los mismos. Los switches “EDIF01”, “EDIF02” y “SERVERS” son de acceso, es decir donde se conectan los equipos finales, entre ellos el del supuesto atacante. Los enlaces entre CORE01 y CORE02 y EDIF01, EDIF02 y SERVERS son enlaces troncales (Trunk) con encapsulación 802.1q. HSRP está configurado en cada Interfaz Virtual en CORE01 y CORE02 tal y como sigue:
|
CORE01 |
CORE02 |
| interface Vlan10ip address 10.10.10.2 255.255.255.0
standby 10 ip 10.10.10.1 standby 10 priority 200 standby 10 preempt ! interface Vlan11 ip address 10.10.11.2 255.255.255.0 standby 11 ip 10.10.11.1 standby 11 priority 200 standby 11 preempt ! interface Vlan200 ip address 10.10.200.2 255.255.255.0 standby 200 ip 10.10.200.1 standby 200 priority 200 standby 200 preempt |
interface Vlan10ip address 10.10.10.3 255.255.255.0
standby 10 ip 10.10.10.1 standby 10 priority 150 standby 10 preempt ! interface Vlan11 ip address 10.10.11.3 255.255.255.0 standby 11 ip 10.10.11.1 standby 11 priority 150 standby 11 preempt ! interface Vlan200 ip address 10.10.200.3 255.255.255.0 standby 200 ip 10.10.200.1 standby 200 priority 150 standby 200 preempt |
En este caso todas las interfaces de “CORE01” recibirán el tráfico de los equipos de las VLAN 10, 11 y 200 ya que poseen una prioridad superior que las de “CORE02”. Para el articulo tomaremos como referencia la vlan 11.
El primer paso será extraer información de la red en la que nos encontramos, en concreto el tráfico HSRP. Esto no será difícil ya que es tráfico Multicast. Poniéndonos en el papel del atacante, como primer paso, conectaremos nuestro PC a la red y ejecutaremos Wireshark recoger algo de información que circule por ahí:
De aquí podemos extraer toda la información necesaria para generar nuestro propio paquete, como por ejemplo:
1.- HSRP está configurado por defecto ya que la MAC de origen es la que el propio protocolo genera de forma predeterminada. No sólo por los primeros 6 octetos “00:00:0c:07:ac” sino porque el último octeto “0b” corresponde con el grupo configurado, el 11. 11 en decimal equivale a 0b en hexadecimal.
2.- La prioridad sí se ha cambiado ya que por defecto es 100 y en este caso es 200.
3.- La autenticación entre iguales es la generada por defecto.
4.- la IP virtual es la 10.10.11.1, es decir la puerta de enlace predeterminada de los hosts.
5.- Podemos intuir que nuestro segmento tendrá una máscara de subred /24. Y también que si el grupo de HSRP es el 11, la IP´s que figuran son la 10.10.11.X ¿porqué no pensar que estamos en la VLAN 11? Hay que tener en cuenta que las redes también hay que administrarlas y cuanto más intuitivos sean los valores más fácil será la gestión. Como todo, esto tiene sus inconvenientes…
Para simular el ataque contaremos con un PC con BackTrack 5 instalado. Entre las innumerables herramientas que tiene esta estupenda distribución emplearemos “yersinia“. Yersinia es una aplicación que permite la creación de ataques para varios protocolos, entre ellos HSRP. Lo que haremos será generar un paquete “a medida” con unos valores que nosotros queramos y lo mandaremos reiteradamente. Y ¿qué valores serán estos? bueno, básicamente los mismos salvo que cambiaremos la prioridad y la IP de origen. La prioridad para que CORE01 deje de ser el router “Active”; y la IP de origen, que pondremos la del un host que nosotros queramos. ¿Con esto que conseguimos? Bueno, veamos primero qué es lo que pasa en el funcionamiento normal de la red. Cuando un equipo de la red 10.10.11.0 /24 se quiera comunicar con otro de otra red, sea internet u otra local, deberá conocer la MAC de su puerta de enlace realizando un ARP “request”. Esta consulta,un broadcast de capa 2 (MAC de destino ff:ff:ff:ff:ff:ff) será recibida por todos los equipos de la red, entre ellos el switch “CORE01”. Dado que, “CORE01” es el switch “Active” de HSRP ya que tiene una prioridad mayor será éste quien responda a los ARP “request” que le lleguen preguntando por la MAC de la IP 10.10.11.1, la puerta de enlace predeterminada. En ese momento, “CORE01” mandará un ARP “reply” al equipo solicitante diciendo que su MAC (la 00:00:0c:07:ac:0b) corresponde a la IP 10.10.11.1. Así pues, cuando a un equipo le llegue este ARP “reply” lo almacenará en su caché ARP y ya tendrá toda la información necesaria para construir la trama y a partir de ahí la comunicación con otras redes.
Como decía, lo que vamos a hacer con ese paquete “a medida” es decir a todos los routers HSRP que existe “otro” con una IP 10.10.11.101 y una prioridad mayor del router “Active” actual (el CORE01). Cuando le llegue ese paquete a CORE01, verá que la prioridad es de 201, mayor a la que él tiene, 200. En ese momento comenzará una negociación que finalizará con “CORE01″pasando un estado de “Standby” y delegando al supuesto router con IP 10.10.11.101, la respuesta de los ARP “request” que se produzcan en la red sobre la IP 10.10.11.1. Obviamente no existe un router, ya que hemos spoofeado la IP 10.10.11.101 que en realidad es de un PC de trabajo normal y corriente. Por tanto si no hay quién responda o proporcione la MAC de la puerta de enlace, ¿cómo podrán los host de la red componer una trama de forma correcta? Efectivamente no podrán, les falta la MAC de destino, con lo que no pueden crear correctamente una trama, por lo que no se producirá la comunicación.
El paquete lo generaremos con el siguiente comando:
root@atacante:~# yersinia hsrp -dest 01:00:5e:00:00:02 -dport 1985 -group 11 -hello 3 -hold 10 -interface eth1 -ipdest 2.0.0.224 -ipsource 101.10.11.10 -ipvirtual 1.11.10.10 -opcode 0 -password cisco -priority c9 -reserved 0 -source 00:00:0c:07:ac:0b -sport 1985 -state 10 -version 0 -attack 0
Como podréis ver todas las variables corresponden con los distintos campos que hemos visto en la captura original. Sin embargo convendría matizar alguno:
1.- Las IP´s tanto de origen, destino y virtual están escritas al revés. Esto es así ya que, no sé por qué razón, la herramienta los cambia. Alguna razón habrá.
2.- La IP de origen ya no es la 10.10.11.2 (la verdadera) sino la 10.10.11.101 (la del equipo victima).
3.- La prioridad es c9 (0xc9) que equivale a 201 en decimal, mayor que 200.
4.- Por último -attack 0, hace referencia al ataque 0, consistente en el envío de un paquete “en crudo” de HSRP. Nosotros lo que haremos será ejecutar varias veces el comando (Tecla↑ + Enter), y de esta manera estaremos mandando varios paquetes. Claro está esto lo podremos automatizar, pero como este post es meramente informativo, nuestra intención no es desestabilizar la red sino mostrar la manera de cómo nos la pueden liar…, no vamos a ir más allá.
Ahora vamos a ver cómo funciona todo. Imaginemos que en el switch “EDIF02” tenemos 4 equipos, uno, el “LEGITIMO” con Backtrack (IP 10.10.11.103); dos, el equipo “VICTIMA_XP” con Windows XP (IP 10.10.11.101); tres, “ATACANTE” con Backtrack también (IP 10.10.11.104); y cuatro, un equipo legitimo también “Windows_7” (IP 10.10.11.106). Luego nos haremos con la consola del switch “CORE01” para ver los log que salen por pantalla.
Partiendo de cero:
El “usuario legitimo” hace ping al servidor DNS de Google:
Y también desde Windows 7:
El switch no tiene ningún mensaje de log, todo O.K.
Y el atacante listo para empezar a mandar varios paquetes HSRP modificados especialmente para la ocasión:
Pues nada, a mandar paquetes se ha dicho!!!!!
Al recibirlos el switch “CORE01” pasa de “Active” a “Speak”, esto es comienza a “negociar” cuál será el teórico switch que ocupará el estado “Active”, ya que está recibiendo paquetes con una prioridad mayor a la que tiene él y por tanto termina pasando a estado “Standby”.
Y esto mismo en una captura quedaría:
Por otro lado vemos que el usuario legítimo ha dejado de tener conectividad con el DNS de Google:
Si analizamos las capturas tendremos que tanto el host “Windows_7” y el “usuario-legitimo” están tratando de obtener la MAC de la IP 10.10.11.1, es decir su puerta de enlace y por supuesto no la obtienen, no hay respuesta de 10.10.11.1:
Y por supuesto cuando dejamos de mandar los paquetes HSRP malintencionados todo vuelve a la normalidad,
El “CORE01” vuelve a ser el “Active”:
Comienzan a aparecer los ARP reply:
Y se recupera la comunicación:
Y hasta aquí la primera entrega. Espero que os hay parecido interesante y hayáis podido ver como no necesariamente los ataques pueden ir dirigidos a un servidor para dejar sin servicio a un número determinado de usuarios. A veces el objetivo puede ser otro. Los efectos, en cualquier caso, podrán variar. No tiene el mismo impacto para la actividad económica de una empresa dejar inoperativo a una planta de un edificio de oficinas, que hacerlo a una red industrial de una fábrica a la que están conectados autómatas, PC´s, robots, etc. No quiero ni saber cómo serían las caras de los administradores cuando los sistemas de monitorización se pongan en rojo porque se ha perdido la conectividad o si ésta va y viene de vez en cuando. Tened en cuenta que los equipos que sufren este ataque, no son los switches de acceso sino los de distribución o core. Es decir, que un número de usuarios determinado se quede sin conexión no tiene porqué ser necesariamente por que ha fallado el switch al que están conectados, sino que problema puede estar en un equipo más centralizado, y tal vez custodiado. Ahora bien, ¿se puede evitar? Eso lo dejamos para otro momento…
Seguiremos informando….