Hola,
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é.
Un saludo,
Creo que lo de gmail, se podría saltar si configuras ettercap para que soporte SSL, ¿no?
Un saludo.
El problema creo recordar, derivaba en que la víctima recibía un mensaje advirtiéndole de que el certificado de seguridad no era fiable, pero podías saltartelo igualmente también usando SSLstrip: http://www.thoughtcrime.org/software/sslstrip/
Gracias por escribir este articulo, Sergio. Ójala sirva para que la gente comience a darse cuenta de por qué los protocolos no cifrados son cada día un problema mayor, sobre todo en entornos que son cada día más móviles (gente conectándose a la red desde cafés y lugares públicos, redes compartidas, redes inalámbricas sin cifrado, etc.).
Sin lugar a duda, movimientos como soportar HTTP/S en servicios como correo Web (Gmail, Hotmail, Yahoo! Mail), lectores de noticias e incluso buscadores (Google) son un ejemplo a seguir.
@roote: SSL no se puede saltar fácilmente, a no ser que el ataque man-in-the-middle se implemente de tal forma que el cliente de HTTP/S reciba un certificado por parte del atacante que coincida con la URL (mail.google.com) y esté cifrado por una autoridad de certificación conocida (o bien el usuario ignore el aviso del navegador acerca del certificado). Si se consigue esto, el atacante puede obtener acceso a todo el tráfico HTTP/S, cifrado con el certificado y la cable privada del atacante.
Definitivamente es posible, pero no con ettercap. Y es posible porque muchos usuarios no consideran los avisos de los navegadores acerca de certificados caducados o inválidos como algo realmente serio.
@felipe: Juraría que con ettercap si es posible. Descomentando la línea:
redir_command_on = «iptables -t nat -A PREROUTING -i %iface -p tcp –dport %port -j REDIRECT –to-port %rport»
Del fichero /etc/etter.conf. El problema venía en que el navegador alertaba al usuario, y ahí entraba en juego SSLStrip para hacer creer a este que se encontraba en un sitio web cifrado con SSL cuando en realidad los datos los está transmitiendo en abierto.
Haz la prueba, estoy seguro de que debería de funcionar, pero si me equivoco mis disculpas. Por otro lado, un buen post Sergio, hay un grave problema de concienciación respecto a esto como comenta felipe.
roote,
Desconocía la opción que comentas. Si vuelvo a instalar las máquinas virtuales haré la prueba gustosamente (si sabes de algún sitio donde haya hecho la demo, dinos dónde!)
En lo que estamos todos de acuerdo es que el trasfondo de este problema no es técnico, sino de concienciación de los usuarios. Esto es una carrera larga, poco a poco se han ido migrando servicios que tradicionalmente iban en HTTP a NTTPS, aunque todavía quedan muchos por migrar.
Lo mismo podríamos aplicar a FTP, que sigue teniendo tirón y popularidad en infinidad de entornos. Afortunadamente Telnet, salvo contadas excepciones, pasó a mejor visa con SSH.
No obstante a mí me asusta que el hecho de que el número de personas que se incorporan todos los días a estas nuevas tecnologías sea creciente y que simultáneamente muchos se tiren a la piscina sin saber las mínimas nociones. Es por esto que es de agradecer que los proveedores de servicios mayoritarios como Google, Windows Live Mail, Facebook, Twitter o cualquier otro implementen soluciones de seguridad (aunque sean tan simples como migrar a HTTPS) que den cobertura a la masa que se va incorporando (aunque ellos no se den cuenta).
Un saludo,
Una demo donde se muestra es: http://www.youtube.com/watch?v=ESGV9zlo0Zo
El problema que comentaba @felipe sobre el aviso del navegador a la víctima con el certificado podría evitarse utilizando SSLStrip.
Pero una cosa está claram y es lo que comentas en el post, hay un grave problema de concienciación, y si los usuarios no se preocupan por adquirir unas mínimas nociones, tendrán que ser los proveedores de servicio los que proporcionen ese mínimo, aunque el usuario nunca llegue a darse cuenta.
Un saludo
Buen post!
Lamentablemente mucha culpa de estos tipos de ataques viene por mala configuración por parte de los administradores de red (hablo en local).
Cosas como el Dinamic ARP Inspection, el DHCP Snooping o tantas otras de los Switches Cisco (por poner el ejemplo que mejor conozco)previenen estos posibles problemas/brechas, obviamente no todo el mundo puede permitirse una infraestructura en Cisco, pero siempre hay alternativas y no sé si por desidia o falta de conocimiento no se aplican en el 80-90% de los casos..
El resto si, desidia de muchos «webmasters CCC», y eso tiene peor arreglo ;)
Saludos!
Wi®
Hola Sergio, entiendo que la prueba comentada no daría los mismos resultados si los host estuvieran en una red switcheada. ¿Es así?
Saludos.
Pez,
Creo que no he entendido tu pregunta. Ettercap funciona únicamente en redes lan switcheadas. La idea del envenanamiento mostrado es atacar el punto común a dos máquinas en una red LAN, en este caso la puerta de enlace, y eso sólo se puede dar si la red es switcheada.
¿Responde esto a tu pregunta?
Un saludo,