Las ataques de ARP Spoofing, también llamados envenenamiento ARP, se basan en introducir información falsa en las tablas de ARP de uno (o ambos) de los de los extremos de una comunicación con el fin de que este utilice inadvertidamente al atacante como intermediario a la hora de trasnmitir y recibir información. Esto permite al atacante no sólo espiar la información intercambiada por el atacado, sino también modificarla a su antojo.
Para combatir con eficacia este tipo de amenazas, un ingeniero de seguridad debe ser consciente de las técnicas de prevención, detección y reacción que puede emplear contra ellas.
La principal técnica de prevención es un buen diseño de la red. Muchos ingenieros no se dan cuenta, pero poner PCs de usuario en redes de paso supone un verdadero riesgo ya que si alguno decidiese utilizar herramientas de ARP Spoofing podría interceptar no sólo el tráfico destinado y originado hacia/desde su segmento sino todo aquel que lo utilice como red de tránsito. Un diseño correcto puede limitar a un único segmento de red el daño que un atacante puede realizar mediante ARP Spoofing. La manera de evitar esto es mantener las redes intermedias de tránsito vacías de PCs de usuarios, concentrando a estos en segmentos localizados en las "hojas" de nuestra red.
A la izquierda de la figura anterior (no se por qué pero Blogger la saca muy borrosa, si quiere ver el original, mucho más definido, pulse sobre la imagen) se puede ver una red mal diseñada al permitir que la red de paso (B) contenga PCs de usuario. Cualquiera de estos PCs de usuario puede lanzar un ataque de ARP Spoofing para desviar el tráfico cursado entre el router interior y el exterior con el resultado de que podría espiar todo el tráfico saliente de la red A.
A la derecha de la figura anterior se encuentra un diseño correcto. En él, la red B se ha vaciado de PCs de usuario. Los PCs que antes estaban en B han pasado a una red "hoja", C. Gracias a este diseño, un atacante de la red C sólo podría escuchar el tráfico de su red pero no de la B.
Este buen diseño sobre el papel debe desplegarse en la práctica de manera correcta. Si a pesar de haber vaciado de PCs las redes de tránsito, un intruso puede pinchar un portátil a una de estas redes seremos igual de vulnerables que antes. Para evitarlo hay que tomar medidas preventivas en los niveles de la capa OSI 2 y 1 (enlace y físico):
- En la capa 2 hay que segmentar los conmutadores que dan servicio a las distintas redes en VLANs separadas asignando a cada VLAN única y exclusivamente los puertos dedicados a cada uno de los equipos residentes en ellas. Muchos administradores dejan puertos libres en cada VLAN por si un día se necesita pinchar urgentemente un equipo a ellas sin tener que esperar a que el administrador lo configure en el conmutador; esa comodidad tiene su contrapartida negativa y es que se deja abierta una puerta a nuestra red, puerta que puede aprovechar un atacante para pinchar su equipo a nuestra red si consigue acceso físico al conmutador (cosa no demasiado difícil en algunas organizaciones). Además, los puertos en uso de las redes de tránsito deben protegerse de alguna manera para evitar que máquinas no autorizadas se conecten a ellas. Lo ideal sería desplegar una solución del tipo NAC o 801.1X, pero la mayor parte de las redes actuales carece por ahora de la infraestructura necesaria para algo tan complejo. Al menos, lo que sí se puede hacer es limitar el uso de esos puertos concretos del conmutador a las MACs concretas de los equipos legítimos. No es una solución definitiva porque es muy fácil falsificar la MAC de un equipo, pero al menos servirá para retrasar al atacante y, con suerte, generará algún log de error en el equipo que servirá para alertar a los administradores si estos cuentan con una infraestructura de correlación de logs adecuada (del tipo Cisco Mars, Bitácora, logICA, etc). Por último, habrá que configurar los conmutadores correctamente para evitar que se utilicen contra ellos algunas de las VLAN Hopping existentes para acceder a una VLAN desde un puerto perteneciente a otra diferente.
- En la capa 1 las medidas de seguridad son evidentes y se corresponden, al fin y al cabo, con las medidas de seguridad habitualmente recomendadas para las instalaciones de comunicaciones y tratamiento de datos. Básicamente se trata de impedir que una persona no autorizada pueda interactuar físicamente con alguno de nuestros conmutadores, por ejemplo pinchando su portátil a una VLAN no autorizada, apagando el conmutador para forzar una redirección del tráfico, o accediendo al puerto de consola del conmutador para reconfigurarlo. Para ello, el equipamiento de comunicaciones debe situarse en armarios cerrados con llave y preferiblemente vigilados con un circuito cerrado de cámaras, en salas de acceso restringido y con un soporte eléctrico y climático controlado y a prueba de fallos.
Para seguir el resto de las explicaciones le recomiendo que descargue y experimente con la maqueta de Netkit que he utilizado para escribir este artículo, es similar a la que se usó de ejemplo en los artículos "Creación de laboratorios virtuales con Netkit" I y II (lea estos artículos si no sabe como utlizar una maqueta realizada con Netkit) pero le he añadido una red de gestión, de manera que tenga una puerta trasera para acceder a los equipos por SSH sin mezclarse con el tráfico de la red de pruebas.
En el escenario de ejemplo, Alice quiere navegar por internet a través de un conmutador y un enrutador que le sirve de puerta de enlace; y PC-Sniffer quiere espiar el tráfico que Alice intercambia con Internet.
Teniendo en cuenta lo anterior y a partir de ahora, el esquema de la red de pruebas que vamos a utilizar en este artículo es el siguiente:
En lo que se refiere a las técnicas de detección, la vigilancia de los paquetes intercambiados en la red y de las tablas de ARP de los equipos clave serán nuestras principales armas.
Vigilando el tráfico de red se pueden detectar anomalías que nos alerten del trascurso de un ataque de ARP Spoofing. Examinando con Wireshark capturas del tráfico cursado a través del Switch de la maqueta podemos ver las siguientes anomalías:
- En la captura del ataque con Ettercap podemos ver (paquetes 1 a 4) como el PC Sniffer (192.168.0.3) pregunta a la red por la MAC del Router (192.168.0.1) y por la de Alice (192.168.0.2). En los paquetes 5 y 6 ya aparecen las primeras señales de alerta; aparentemente el Router y Alice se lanzan pings entre sí, pero si examinamos la MAC de origen de ambos ping podemos ver que ¡en realidad se trata la MAC del PC-Sniffer!. Inmediatamente después, y sin esperar respuesta a los ping, el PC Sniffer manda actualizaciones de ARP para "envenenar" las tablas de Alice y el Router (paquetes 7 y 9). El resultado es que las respuestas a los pings le llegan al PC-Sniffer, lo que le permite saber que su ataque ha tenido éxito. En los paquetes 15 y 16 se puede ver como las respuestas a los pings se reenvían a sus legítimos destinarios, tal y como se hará con el resto del tráfico una vez que el PC-Sniffer lo haya visualizado. A partir de ahí (paquetes 19 a 26) se puede ver como el PC-Sniffer insiste machaconamente en enviar paquetes de actualización ARP para mantener las tablas de Alice y del Router "correctamente envenenadas". Si todo lo anterior ya debería inquietarnos, es cuando Alice comienza a navegar cuando vemos que algo va definitivamente mal. Porque a partir del paquete 43 vemos que todo el tráfico parece duplicado. Esto se debe a que el tráfico tiene que atravesar el Switch una vez, de camino al PC-Sniffer, y otra, de camino a su destinatario, en vez de atravesar el Switch una única vez (que sería lo lógico). De hecho, al mismo Wireshark le parece rara la situación y a partir del paquete 48 comienza a colorear de negro los paquetes repetidos para alertar de que algo no va nada bien.
- Por su parte, en la captura del ataque realizado con Arppoison (incluido en la carpeta /root/scripts del PC-Sniffer de la maqueta), se pueden observar comportamientos anómalos. Arpoison es una herramienta programada con fines didácticos, así que su funcionamiento es algo más primitivo que el de Ettercap. Para empezar no hace un ping previo para comprobar que el envenenamiento se ha realizado con éxito y luego produce las mismas anomalías en los paquetes intercambiados e incluso alguna más. Y es que, cuando se usa Arpoison, se puede ver como en las capturas realizadas en el Switch aparece paquetes de ICMP Redirect (el primero aparece en el paquete 12), tan raros en las redes modernas que el Wireshark lo colorea de negro para señalarlo como anomalía. Esto se debe a que Arpoison utiliza Scapy para manejar paquetes y este a su vez Libpcap para realizar las escuchas. el problema es que Libpcap saca copias de los paquetes recibidos y se las entrega a las aplicaciones de usuario, pero no impide que los paquetes originales sigan siendo procesados por el kernel del PC. El kernel del PC-Sniffer no sabe nada de las aviesas intenciones de su dueño por lo que reacciona automáticamente cuando recibe un paquete que no está dirigido a su dirección IP enviando un paquete de ICMP Redirect alertando al remitente de que esos paquetes no le corresponden. Esta anomalía es tan evidente que cualquier IDS/IPS, por malo que fuese, lo habría detectado; para evitarla el dueño del PC-Sniffer podría haber activado su cortafuegos local para bloquear con él todos los paquetes ICMP salientes (si su cortafuegos le permite afinar bastaría con bloquear los paquetes ICMP Redirect salientes).
A nivel local, las inconsistencias en las tablas de ARP son síntomas muy serios de un posible ataque. Generalmente, es muy difícil que un PC y el enrutador que hace de puerta de enlace de la red tengan la misma MAC por lo que cuando esto ocurra deberían encenderse nuestras alarmas. Otra anomalía que debería ponernos en alerta es el cambio de la MAC conocida de equipos clave de la red, como por ejemplo los enrutadores que hacen de puerta de enlace.
En estado normal, la tabla de ARP de Alice tiene el siguiente aspecto:
PC-Alice:~# arp -i eth0 -a ? (192.168.0.1) at EA:0E:85:D7:58:04 [ether] on eth0
Si el atacante (PC-Sniffer) iniciase un ataque con Ettercap:
PC-Sniffer:~# ettercap -M arp:remote -T /192.168.0.1/ /192.168.0.2/ ettercap NG-0.7.3 copyright 2001-2004 ALoR & NaGA Listening on eth0... (Ethernet) eth0 -> CA:88:E3:51:83:57 192.168.0.3 255.255.255.0 SSL dissection needs a valid 'redir_command_on' script in the etter.conf file Privileges dropped to UID 65534 GID 65534... 28 plugins 39 protocol dissectors 53 ports monitored 7587 mac vendor fingerprint 1698 tcp OS fingerprint 2183 known services Scanning for merged targets (2 hosts)... * |==================================================>| 100.00 % 2 hosts added to the hosts list... ARP poisoning victims: GROUP 1 : 192.168.0.1 EA:0E:85:D7:58:04 GROUP 2 : 192.168.0.2 BA:4E:E3:B8:96:91 Starting Unified sniffing... Text only Interface activated... Hit 'h' for inline help Sat Mar 14 10:59:44 2009 TCP 192.168.10.1:49581 --> 192.168.0.2:22 | AP ...`..........I.S.4S..o^...D./~.....u.i....K...gaK5J
El resultado sobre la tabla de ARP de Alice sería el siguiente:
PC-Alice:~# arp -i eth0 -a ? (192.168.0.1) at CA:88:E3:51:83:57 [ether] on eth0 ? (192.168.0.3) at CA:88:E3:51:83:57 [ether] on eth0
Como se puede ver, desde el punto de vista de Alice, no sólo ha cambiado la MAC del enrutador (192.168.0.1) sino que además ahora parece coincidir con la MAC de un PC (192.168.0.3), lo que es señal inequívoca de que se está produciendo un ataque de ARP Spoofing que intenta desviar el tráfico de Alice destinado al enrutador hacia un PC intruso. Cuando este PC finaliza Ettercap, este se encarga de restablecer las tablas de ARP a su estado correcto. Lo que deja a Alice de la siguiente manera:
PC-Alice:~# arp -i eth0 -a ? (192.168.0.1) at EA:0E:85:D7:58:04 [ether] on eth0 ? (192.168.0.3) at CA:88:E3:51:83:57 [ether] on eth0
Como se puede ver, el ataque deja huellas tanto durante su transcurso como durante un corto tiempo tras él (hasta la expiración de la entrada en la tabla de ARP). Esto se debe a que el intruso debe interactuar con sus víctimas, antes de iniciar el ataque, para recopilar las MACs de dichos equipos con el fin de reparar las tablas de ARP tras él. Se puede estudiar la estructura interna de un programa similar a Ettercap en el mencionado artículo sobre escuchas en redes conmutadas. En ese programa, el Arpoison mencionado antes, la función que deja la huella "incriminatoria" en las tablas de ARP es la función gatherData(), ejecutada antes del ataque mismo. Como esta función debe preguntar a Alice y al Router por sus MAC mediante una llamada de ARP (representada en el código fuente del artículo por la llamada a la función scapy.getmacbyip() dentro de gatherData()), es el momento en el que el atacante PC-Sniffer "toca" directamente a sus víctimas dejando las huellas mencionadas. Se podría plantear la pregunta de si el atacante podría renunciar a ejecutar esta función para minimizar su huella, pero lo cierto es que no, porque si no averigua las MACs originales de los equipos a espiar no podrá lanzar el ataque ni reconstruir las tablas de ARP tras él.
Visto lo anterior, es evidente que son necesarias herramientas automatizadas que nos permitan defender las tablas de ARP de los equipos críticos que queramos salvaguardar de este tipo de ataques.
Una de las herramientas clásicas a este respecto es Arpwatch. Esta herramienta monitoriza la tabla de ARP y alerta por correo electrónico al administrador cuando se produce el cambio de una correspondencia IP-MAC. Lo ideal es instalar dicha herramienta en todas las estaciones de trabajo Linux de la red. En redes con direccionamiento estático, si se tiene la certeza de que no se ha producido el recambio de la tarjeta de red de ningún ordenador, la llegada de un correo de Arpwatch suele ser alerta inequívoca de que se está produciendo un ataque de ARP Spoofing. En redes con direccionamiento dinámico (DHCP), los pares IP-MAC cambian con cierta frecuencia, por lo que puede ser complicado monitorizar todos los cambios, aunque lo que sí se puede vigilar es el registro IP-MAC de la puerta de enlace por defecto de cada red, la cual debería permanecer inalterable en las tablas de ARP de todas las estaciones de trabajo.
Otra opción, algo más compleja pero con más posibilidades es ArpON. A diferencia de Arpwatch, ArpON no se limita a alertar al administrador sino que reacciona para bloquear el ataque. ArpON tiene dos modos de funcionamiento, estático y dinámico. En modo estático (SARPI), ArpON toma nota al arrancar de las entradas de la tabla de ARP, guardando esta información en una caché alternativa. A partir de ahí, ArpON sólo permite que se tramiten las peticiones y respuestas ARP de pares IP-MAC que no entren en contradicción con la información previa de su caché. El modo dinámico (DARPI) es similar, pero permite que la caché de ArpON vaya incorporando nuevos pares IP-MAC desconocidos en el momento de su arranque.
En redes con DHCP se puede optar también por activar un sistema de DHCP Snooping. Aparte de evitar que aparezcan servidores DHCP "furtivos", este sistema mantiene un registro de las MACs asociadas a las IPs concedidas y los puertos de los conmutadores donde se encuentran estas MACs. Con esta información, el sistema monitoriza los intercambios de ARP que se producen en sus puertos y si detecta un paquete ARP cuyo origen a nivel IP no se corresponde con la MAC registrada lo bloquea para impedir el envenenamiento. Esta opción se encuentra ampliamente disponible, por ejemplo en los equipos de Cisco donde recibe el nombre de Dynamic ARP Inspection.
