ettercap es un conjunto de herramientas con capacidad de disección para múltiples protocolos que facilita la ejecución de ataques Man-in-the-middle en redes locales.
Una de las múltiples funcionalidades que tiene ettercap es la posibilidad de realizar envenenamiento ARP de una puerta de enlace que esté siendo usada por otros equipos de la red local, lo que nos permite la captura de tráfico de terceros. Este método es válido para poder valorar las condiciones de seguridad de los protocolos empleados en una LAN, si bien, como cualquier otra herramienta de seguridad, en malas manos puede ser empleada para la obtención maliciosa de información sensible sin nuestro conocimiento y/o consentimiento.
Con el objeto de ilustrar la importancia del uso de protocolos cifrados, vamos a ver la implicación del uso de distintos protocolos ante un evento de envenenamiento ARP. Para ello dispondremos de una red local simulada con dos máquinas virtuales corriendo en el mismo segmento. La primera es una estación Debian, que ejecutará ettercap, y la segunda es una máquina Windows XP, que actuará como víctima. El montaje es válido para tantas máquinas virtuales en el segmento como se deseen, siempre que la RAM lo permita 🙂
Lo primero que haremos será lanzar ettercap especificando la puerta de enlace y el rango de máquinas a atacar. En este caso particularizamos para una sóla IP, nuestra máquina víctima, si bien es posible lanzar la escucha para todas las máquinas del segmento (lo cual entraña riesgos de saturación de las comunicaciones, lo que no hace recomendable esta opción). Si es preciso añadir varias máquinas víctima, se aconseja el uso de rangos menores.
Una vez lanzado ettercap, verificamos mediante los menus interactivos el estado de las víctimas (la puerta de enlace y la máquina en la red local)
Tal y como hemos comentado, ettercap tiene capacidad de disección para múltiples protocolos. Veamos qué ocurre si lanzamos desde la máquina víctima una petición FTP. En la consola y en tiempo real veremos la interceptación de las credenciales:
Si inspeccionamos el tráfico entre la máquina víctima y el FTP destino, observaremos con más detalle el tráfico capturado:
¿Por qué podemos ver las credenciales? Esto se debe a que FTP es un protocolo en el que el intercambio de información entre máquina origen y destino no está cifrado, con lo que si envenenamos la puerta de enlace, que es la que la máquina víctima utiliza para canalizar su tráfico hacia la máquina destino, capturaremos las credenciales en claro.
Veamos que pasa en un intento de login HTTP. Este ejemplo es real, y corresponde a Pixmania, que no utiliza HTTPS para autenticar a sus clientes (desde aquí les animo a que lo hagan cuanto antes)
Como el tráfico no es cifrado, volvemos a capturar las credenciales. ¿Qué pasará en un entorno cifrado, por ejemplo, Gmail, donde toda la comunicación es HTTPS?
Como cabía esperar, al ser HTTPS cifrado, lo único que capturaremos al envenenar la puerta de enlace es tráfico cifrado del que no podremos deducir credenciales.
Espero que este último ejemplo, así como los anteriores, nos sirvan a todos para comprender el peligro de los ataques Man-in-the-middle y de la poca conveniencia de emplear protocolos sin cifrado. A la vista está el porqué.
