Un sniffer es un programa que intercepta datos transmitidos a través de la red.
En principio, los sniffers son difíciles de detectar; su naturaleza hace que envíen el mínimo número de paquetes de datos.
1. Métodos de Detección
No siempre es posible detectar un sniffer; es algo difícil debido a su naturaleza. Sin embargo, detectar una máquina que está espiando es más fácil.
De alguna manera, podemos diferenciar los diferentes métodos que existen en dos grupos dependiendo de si son:
- Detección local
- Detección remota
1.1 Detección Local
Es un método determinante, pero un proceso largo. Debemos estudiar cada máquina, cada sistema operativo…
Buscaremos evidencias como interfaces en modo promiscuo, procesos sospechosos.
En un sistema como Linux, podríamos usar route o netstat para ver el uso de una interfaz.
bockvan@tango:~$ netstat -re
Tabla de enrutamiento IP del kernel
Destino Puerta de enlace Máscara de red Banderas Métrica Ref Uso Interfaz
172.16.0.0 * 255.255.255.0 U 0 0 0 eth0
default 172.16.0.1 0.0.0.0 UG 0 0 0 eth0En caso de que el uso de una interfaz sea más que sospechoso, utilizaremos ifconfig para ver si está en modo promiscuo.
bockvan@tango:~$ /sbin/ifconfig eth0
eth0 Enlace encap:Ethernet Dirección HW 00:05:1C:13:CE:F0
Dirección inet:172.16.0.3 Difusión:172.16.0.255 Máscara:255.255.255.0
ACTIVO DIFUSIÓN FUNCIONANDO PROMISC MULTICAST MTU:1500 Métrica:1
Paquetes RX:11583 errores:0 perdidos:0 sobrepasados:0 marco:0
Paquetes TX:11306 errores:0 perdidos:0 sobrepasados:0 portadora:0
colisiones:0 longitud de cola de transmisión:100
Bytes RX:3799031 (3.6 MiB) Bytes TX:10693650 (10.1 MiB)
Interrupción:11 Dirección base:0xc000Como puedes ver, hay una interfaz en modo promiscuo. Para desactivar este modo, usaremos: ifconfig <interface> -promisc
También podemos revisar los registros para ver si alguna interfaz fue puesta en modo promiscuo:
root@tango:/home/bockvan# tail /var/log/messages
Feb 12 18:40:08 tango kernel: dispositivo eth0 entró en modo promiscuo
Feb 12 18:41:47 tango kernel: dispositivo eth0 salió del modo promiscuo
Feb 12 18:42:01 tango kernel: eth0: Modo promiscuo habilitado.
Feb 12 18:42:01 tango kernel: dispositivo eth0 entró en modo promiscuo
Feb 12 18:42:02 tango kernel: eth0: Modo promiscuo habilitado.
Feb 12 18:42:02 tango kernel: dispositivo eth0 salió del modo promiscuo
Feb 12 18:44:37 tango kernel: eth0: Modo promiscuo habilitado.
Feb 12 18:44:37 tango kernel: dispositivo eth0 entró en modo promiscuo
Feb 12 18:47:28 tango kernel: eth0: Modo promiscuo habilitado.
Feb 12 18:47:28 tango kernel: dispositivo eth0 salió del modo promiscuoEn cualquier caso, si el atacante que instaló el sniffer tiene gran control sobre la máquina, podría ocultar toda esta evidencia, eliminar registros, etc.
Un buen ejemplo de esto es RhideS, que es un LKM programado por Ripe que oculta el modo promiscuo en las interfaces de red. Puedes encontrar este módulo y muchas más cosas en el sitio web de 7a69 [1].
1.2 Detección Remota
Principalmente hay dos pruebas para detectar un sniffer en nuestra red.
1.2.1 Método Pasivo
Escucha todos los paquetes que circulan en la red buscando actividad sospechosa. Por ejemplo, el envío de solicitudes ARP.
1.2.2 Método Activo
Envía paquetes modificados esperando la respuesta que una máquina con una interfaz en modo promiscuo nos daría. En este tipo de prueba, entran en juego las características de los sniffers en sí mismos, así como las de los sistemas en los que se encuentran. Esto último implica estudiar la pila TCP/IP del sistema operativo y encontrar características que nos permitan determinar la existencia de un sniffer.
Algunas de las pruebas más conocidas son:
- Pruebas ICMP
- Pruebas ARP
- Pruebas DNS
- Pruebas de LATENCIA
2. Técnicas de Detección
Por ejemplo, el sistema operativo GNU/Linux, al estar en modo promiscuo, responderá a los paquetes TCP/IP enviados a su DIRECCIÓN IP incluso si la DIRECCIÓN MAC en ese paquete es incorrecta, cuando normalmente los paquetes que contienen una DIRECCIÓN MAC incorrecta no son respondidos porque la interfaz de red los ignora (son descartados). Por esta razón, si enviamos paquetes TCP/IP con información incorrecta de DIRECCIÓN MAC a toda una subred, las máquinas en modo promiscuo nos responderán (responderán con RESET -RST-).
2.1 Técnicas
Dependiendo del sistema operativo que se esté utilizando, necesitaremos enviar paquetes modificados de una manera u otra, ya que la pila TCP/IP de cada sistema, a pesar de seguir un estándar, no está definida para solicitudes no estandarizadas.
2.1.1 PING
Una falla en la implementación de la pila TCP/IP en algunos núcleos GNU/Linux puede ser explotada para descubrir sniffers en el sistema. El núcleo verifica cada paquete para comprobar si la IP pertenece a la máquina en cuestión; si es así, este paquete va a la pila TCP/IP para ser procesado. Lo que no se verifica es que la dirección (ethernet) de la tarjeta de red contenida en el paquete coincida con la DIRECCIÓN MAC de la interfaz de la tarjeta de red. La razón por la que esto no se verifica es porque la tarjeta de red permite que pasen paquetes entrantes que no coinciden con su dirección de red. Si enviamos una “solicitud de eco” ICMP con una DIRECCIÓN IP correcta y una DIRECCIÓN MAC falsa, si el objetivo de nuestra prueba responde, significa que probablemente está espiando la red y tiene la interfaz en modo promiscuo.
En algunos núcleos FreeBSD ocurre algo similar, solo que en lugar de usar una DIRECCIÓN IP correcta debemos usar una dirección de broadcast correcta.
En los sistemas Microsoft Windows, podemos realizar esta prueba utilizando una DIRECCIÓN IP correcta y como dirección ethernet ff:00:00:00:00:00, que no es una dirección de difusión pero debido a la pobre implementación de la pila TCP/IP en estos sistemas, al hacer este tipo de solicitudes obtendremos una respuesta. Al realizar esta prueba, se sabe que ciertos dispositivos de red curiosamente también responden sin que necesariamente signifique que su interfaz (o interfaces) estén en modo promiscuo.
Los sniffers actuales vienen equipados con un filtro de DIRECCIÓN MAC, por lo que no responden con ECHO REPLY.
2.1.2 ARP
Hay varias formas de verificar remotamente la existencia de una interfaz en modo promiscuo. El método más simple sería enviar una solicitud ARP a una dirección que no sea de difusión. Si la máquina responde, debe estar en modo promiscuo.
Un método más elaborado podría aprovechar la caché ARP. Cada ARP tiene información completa tanto del origen como del destino. Si se envía un solo ARP a una dirección de difusión, incluyendo mi propia dirección de tal manera que en los minutos siguientes otros equipos recordarán esta información. Luego, si enviamos un ARP pero no a difusión y luego hacemos ping a difusión, cualquiera que responda sin ARPing solo podría haber obtenido la dirección MAC mediante sniffing.
Una variación de este método (usado por nepped, desarrollado por savage de apostols) utiliza una falla en arp.c en sistemas del núcleo Linux, es la función arp_rcv(). Esta función es responsable de determinar cuándo enviar respuestas ARP. Cuando llegan solicitudes insuficientes y dañadas, los sistemas Linux responderán con solicitudes ARP independientemente de la MAC de destino. En general, solo se procesan los marcos con la MAC de la máquina, por lo que no es un problema. En modo promiscuo, como sabemos, todos los marcos se procesan sin verificar la dirección MAC de destino y no hay forma de diferenciar si el paquete realmente estaba destinado para la máquina que está escuchando.
2.1.3 DNS
Muchos sniffers ofrecen la posibilidad de mostrar la resolución de nombres de las máquinas que están espiando, para que se presente más información al usuario.
Los capturadores de solicitudes DNS capturan tráfico de red en bruto, y es necesario traducir direcciones IP a nombres de máquinas. Es común que los capturadores hagan solicitudes DNS para traducir las IPs de los paquetes capturados. Un ejemplo de esto es AntiSniff, que envía paquetes falsos con IPs falsas (tanto de origen como de destino) y escucha (captura) solicitudes DNS buscando una resolución para las IPs falsas que creó. Las máquinas que hacen solicitudes de resolución para las IPs que ponemos en los paquetes de prueba tendrán un capturador y estarán escuchando nuestro tráfico de red.
Una solución que los nuevos capturadores de última generación están implementando es resolver nombres con cierto retraso que depende de los datos que recibimos y decodificamos, de modo que si no logramos capturar datos, no hay necesidad de resolver la IP. Gracias a esto, los capturadores no saturan la red con solicitudes de resolución DNS.
2.1.4 Pruebas de Latencia
Consiste en comparar el tiempo de reacción de una máquina antes y después de saturar el tráfico de la red con información irrelevante. De esta manera, el equipo con un sniffer instalado analizará todo el tráfico inútil para luego procesarlo y tardará más en responder que cuando no hay saturación en la red.
Hay casos donde esta técnica puede fallar:
Debido a la carga de la red, puede haber falsas alarmas; esto se debe a que el medio no puede soportar tanta cantidad y algunos paquetes llegan con cierto retraso. Para solucionarlo, solo necesitamos cargar un poco menos la red.
Los sniffers suelen ejecutarse en modo usuario, mientras que el envío de paquetes ICMP debe ejecutarse en modo kernel, siendo independiente de la carga de la máquina para cada proceso, por lo que los posibles sniffers no serán detectados ya que el sistema intentará responder de la misma manera que si no hubiera sniffer.
3. Engañando AntiSniff
Este antisniffer es capaz de trabajar con la mayoría de los sniffers, pero sigue patrones muy específicos, por lo que basta con modificar algo para detectarlo. Hay técnicas que permiten el sniffing sin que AntiSniff pueda evitarlo. Pero ciertamente es molesto tener que escribir un sniffer para cada antisniffer cuando los sniffers en el mercado son realmente buenos. Si Mohammed no quiere reescribir el programa, se hace un módulo de kernel… ¿qué va a hacer este módulo? Bueno, simple, modificar un poco la pila TCP/IP de nuestro sistema, para que todas las herramientas comunes que AntiSniff es capaz de detectar sean filtradas. La técnica de sniffing ya está muy trabajada, las utilidades de red son muy buenas, lo único que tendríamos que hacer sería crear módulos para los antisniffers.
Algunos consejos finales para desarrollar un sniffer:
- No hacer solicitudes DNS (ni siquiera con retraso).
- Dejar de hacer sniffing cuando hay demasiada actividad en la red.