Yuzi download

En varios artículos hemos hablado de cómo hacer ataques de Network Packet Manipulation a entornos de bases de datos. Hablamos de cómo ownear MySQL colocándonos en medio de la comunicación del cliente y el servidor. En otro artículo comentamos cómo hackear Wordpress con la misma técnica. Al final todo se basa en que el tráfico entre las aplicaciones web y el motor de base de datos puede ir sin cifrar, así es por defecto en la instalación de los motores de base de datos y es labor de los administradores configurar las protecciones y el cifrado.

Figura 1: Fortificación de comunicación entre WordPress y MySQL

En el artículo de hoy nos pondremos del lado del Blue Team y hablaremos de cómo fortificar tu Wordpress cifrando las comunicaciones entre éste y el  motor de MySQL.

Punto 0. Mi Wordpress por defecto

Partimos del siguiente esquema:

- Máquina A con dirección IP 192.168.56.103 tiene instalada un Wordpress.
- Máquina B con dirección IP 192.168.56.106 tiene instalado y configurado MySQL por defecto.

Si analizamos las peticiones se puede ver como accediendo al WordPress, entre la máquina 192.168.56.103 y 192.168.56.106 se realizan una serie de consultas a la base de datos. Estos paquetes son susceptibles de ser manipulados.

Figura 2: Trafico de WordPress a MySQL sin cifrar

Punto 1. Fortificando la conexión a MySQL con SSL

En este punto lo que vamos a hacer es preparar los tres componentes necesarios para que MySQL acepte conexiones bajo SSL. En primer lugar hay que consultar si la compilación de MySQL que se está utilizando permite utilizar SSL, si no fuera así habría que instalar una versión más nueva o compilarla con soporte a SSL.

Para verificar esto accedemos a MySQL con un cliente y ejecutamos la siguiente consulta “show variables like ‘%ssl%’;”. Si las variables have_openssl y have_ssl tienen como valor DISABLED significa que está soportado pero no activo. Si por el contrario encontramos el valor NO, significa que la compilación de MySQL no soporta SSL. Si aparece el valor YES, significa que está correctamente configurado y el servidor permite conexión bajo este mecanismo. Además, hay que ver las rutas de las variables ssl_ca, ssl_cert y ssl_key que indican la ruta de la CA, del certificado del servidor y de la clave de éste.

Figura 3: variables de MySQL para configurar SSL

En este punto vamos a utilizar OpenSSL para generar la CA, el certificado y la clave. Para ello ejecutamos las siguientes instrucciones:

- openssl genrsa 2048 > ca-key.pem
- openssl req –sha1 –new –x509 –nodes –days 3600 –key ca-key.pem > ca-cert.pem

Con esto tenemos creado el certificado y la clave privada de la CA. Nos pedirán que rellenemos varios datos como país, ciudad, dominio, e-mail, etcétera.

- openssl req –sha1 –newkey rsa:2048 -days 730 -nodes -keyout server-key.pem > server-req.pem

Con esto generamos la clave privada para el servidor. A continuación, exportamos la clave privada del servidor a tipo RSA con la ejecución del siguiente comando:

- openssl rsa -in server-key.pem -out server-key.pem

Por último, generamos un certificado de servidor utilizado el certificado de la CA.

- openssl x509 -sha1 -req -in server-req.pem -days 730 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > server-cert.pem

Los ficheros cacert.pem, server-cert.pem y server-key.pem deben estar en la ruta /etc/mysql. Aunque esto puede ser configurado en el fichero de configuración de MySQL /etc/mysql/my.cnf. Editando dicho fichero y buscando a partir del campo “[mysqld]” debemos descomentar la parte de SSL y asegurarnos de que las variables tienen la configuración adecuada, tal y como puede verse en la siguiente imagen.

Figura 4: Configuración del fichero my.cnf

Ahora, reiniciamos el servicio de MySQL. Una vez el motor arranque y lea la configuración del fichero sabrá de dónde leer la información del certificado, la CA y la clave privada. Ahora, podremos conectarnos con un cliente MySQL a través de SSL. Como ejemplo rápido utilizamos el propio MySQL. La instrucción es la siguiente:

-  mysql –u [user] –p –ssl-ca=[ruta cacert]. 

Para comprobar que la conexión se ha realizado a través de SSL podemos consultar la variable Ssl_Cipher.

Figura 5: Configuración de la conexión

Si abrimos ahora WireShark y aplicamos el filtro de MySQL para ver el tráfico observaremos que ya no vemos nada. Sin embargo, si utilizamos un filtro “tcp.dstport == 3306” veremos que hay conexión con dicho puerto de la máquina 192.168.56.106.

Figura 6: Tráfico cifrado entre WordPress y MySQL

Las consultas están siendo cifradas, y por eso WireShark no reconoce contenido de los datos que se envían al motor de MySQL.

Punto 2. Configurar Wordpress para que cifre con SSL la conexión con MySQL

Ahora, hay que indicar en el fichero wp-config.php de WordPress que éste debe entender los flags de MySQL para SSL. Para ello, añadimos al fichero la instrucción “define(‘MYSQL_CLIENT_FLAGS’, MYSQL_CLIENT_SSL);”, tal y como se puede ver en la imagen siguiente.

Figura 7: Configuración de WordPress

Ahora accedemos al sitio web de nuestro WordPress y las consultas a MySQL irán por un canal cifrado, tal y como puede verse en la imagen. En este momento los ataques de NPM (Network Packet Manipulation) ya no es válido, ya que no podemos detectar y manipular las cadenas de MySQL. Si probamos con WireShark veremos que solo accedemos a la conexión al MySQL, pero nada de las consultas, si que veríamos la conexión al puerto 3306, pero todo cifrado.

Figura 8:Conexión a MySQL desde WordPress

De esta forma estamos fortificando el intercambio de información entre el WordPress y la base de datos MySQL. También se puede forzar a que usuarios concretos sólo puedan hacer conexiones bajo SSL, lo cual es interesante para fortificar.

Más artículos sobre seguridad y fortificación en WordPress:

- Hackear WordPress con ataques de Network Packet Manipulation
- Fortificar WordPress frente ataques de fuerza bruta
- WordPress: Ten cuidado con el cacheo de borradores
- WPHardening: Automatizar la fortifación de WordPress
- Listar los plugins de WordPress
- Configurar Latch en WordPress

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”

Email Sherlock es un servicio que nos permite realizar búsquedas de cuentas y perfiles asociadas a una dirección de correo electrónico con el fin de descubrir en qué redes y, si es posible, quién se encuentra detrás de ella. En un primer vistazo podemos entender que Email Sherlock nos permite obtener información de dónde una cuenta de correo se encuentra dada de alta, además de otros detalles relativos al alias de correo, como datos del dominio del e-mail o sitios en los que el usuario está en uso.

Figura 1: Email Sherlock - Doxing y ataques APT de Spear Phishing o de Spear Apps

El objetivo es sencillo, en una investigación se trata de hacer un doxing y estrechar el cerco y, sabiendo que tiene una cuenta de un determinado servicio, un potencial atacante podría realizar desde ataques de Spear Phishing adaptados a una red social de la que se sabe que forma parte, o un miembro de los cuerpos de seguridad en plena investigación policial solicitar datos de esa cuenta. Este tipo de utilidades son muy útiles para las investigaciones OSINT, tal y como se cuenta en la charla dedicada a este tema por nuestro compañero Diego Samuel Espitia, CSA de Eleven Paths en Colombia.


Figura 2: Eleven Paths Talks [11] - Técnicas OSINT
Es un servicio que se puede consumir vía página web, pero además también puedes encontrar la aplicación en formato móvil en Google Play Store y en AppStore para iPhone. Gracias a esta herramienta podremos obtener información personal de quién se encuentra detrás de una cuenta de correo electrónico, podremos conocer su nombre completo, su localización, profesión, hobbies y muchas cosas más - dependiendo de los servicios -.

Figura 3: Email Sherlock para Android

En principio puede no ser sencillo conocer dicha información, pero al saber en qué redes sociales está dado de alta, se podría verificar si el perfil está abierto y conocer información de él. Por supuesto, también te puede ser útil para saber en qué redes has dejado tus rastros y debes eliminarlo... si lo deseas.

¿Cómo funciona el proceso de Email Sherlock?

Tras abrir la página en nuestro navegador observaremos un campo donde introducir la dirección de e-mail objeto de nuestra búsqueda, a continuación pulsaremos sobre “GO” y comenzara la recopilación de información, este proceso tardara un poco y al acabar nos mostrará en pantalla los resultados de nuestro análisis. Entre otras cosas podremos verificar que la cuenta introducida es válida, el nombre completo de su propietario y si se han encontrado otras cuentas asociadas a este usuario en diversas redes sociales.

Figura 4: También permite buscar información en bases de datos del gobierno

Normalmente estos ataques se hacen aprovechándose de los leaks de información que se dan en estos servicios en las procesos de login, de registro de una cuenta nueva o de se me ha olvidado la contraseña. Por ejemplo, en Facebook, si la cuenta existe es posible acceder a información del usuario aún no teniendo la contraseña con un proceso de login incorrecto - igual que se hace con el número de teléfono -. Otras redes sociales dan un mensaje distinto en el proceso de recuperación de contraseña cuando la dirección de correo electrónico existe a cuando no, etcétera. Teniendo todos ellos catalogados, te sale el servicio de Email Sherlock.

Figura 5: Información asociada a la cuenta de e-mail en Gravatar

Gracias a la información sobre las redes sociales en las que el usuario tiene una cuenta, un atacante podría iniciar un ataque de Spear Phishing suplantando la dirección de un sitio donde tenga cuenta. Si ademas es una información que él no ha publicado en ningún otro sitio, el efecto puede ser mayor y hacerlo más propenso a caer.

Figura 6: Información asociada a la cuenta de e-mail en Vimeo

Estos ataques son muy comunes y en muchas ocasiones pueden ser muy peligrosos y si por medio de estos e-mails se consigue inyectar una Spear App, bastaría para conseguir dar un paso de gigante. Es decir, si descubrimos que un usuario tiene una cuenta en Vimeo o Gravatar, tal vez sea útil enviar un correo con un Spear App para robar el token OAuth de esa cuenta de Outlook mediante una oferta irrechazable de una nueva app premium de Gravatar o Vimeo para su correo electrónico.

Figura 7: Resultados de búsqueda con UserSherlock

La página también nos muestra con más detalle si el usuario tiene perfiles en algunas de las plataformas más conocidas de la red revisando los nombres de los usuarios enlazando otro servicio útil de OSINT llamado UserSherlock. En ese caso no se puede garantizar que sean los usuarios asociados a esa dirección de correo electrónico, pero es información útil que quizá merece la pena revisar una a una.

Autor: Sergio Sancho Azcoitia

HSTS (HTTP Strict Transport Security) es un mecanismo de seguridad que se fuerza desde el servidor web a los navegadores y que permite asegurar que las conexiones que se realizan desde el navegador al sitio web se realizarán siempre a través de un canal seguro con TLS/SSL. En otras palabras, si cuando un usuario quiere acceder a un sitio web cómo puede ser Gmail o Facebook, éste no introduce en la barra de direcciones URL el protocolo con HTTPs, por ejemplo “https://gmail.com” o “https://facebook.com”, sino que introduce simplemente gmail.com o facebook.com, entonces el navegador automáticamente fuerza la conexión HTTPs.

Figura 1: Ataques a HSTS: SSLStrip 2 & Delorean

Si no se hiciera ese forzado, durante esa primera conexión un atacante en medio podría hacer una manipulación de todo el tráfico entre el navegador y el atacante para que la conexión en ese tramo fuera sin cifrar, y el cifrado se hiciera entre la máquina del atacante y el servidor original que usa HTTPs. De esto se aprovechaba en el pasado el ataque SSL Strip diseñado por el famoso hacker Moxie Marlinspike, y nuestra querida Evil FOCA lo implementa de igual forma pero en los ataques de Bridging HTTP(IPv6)-HTTPs(IPv4).

Figura 2: Concepto de SSLStrip de un dominio con Evil FOCA

Sin embargo, a día de hoy la mayoría de los sitios de gran uso, como pueden ser Paypal, Gmail, Facebook, Twitter, Outlook, etcétera, utilizan la cabecera HSTS para que los navegadores que lo soportan, que a día de hoy son todos, sepan que cuando el usuario introduzca el dominio en la barra de direcciones sin especificar el protocolo, se debe acceder siempre a través de TLS/SSL. De este modo, nunca se realizará una petición HTTP a un dominio que use HSTS y evitará que un atacante en medio puedo hacer un esquema de SSLStrip. Puedes leer más sobre esto en la serie de artículos de nuestro compañero Sergio de los Santos dedicada a Certificate Pinning.

El problema de la primera petición

Por otro lado, quedaba por resolver la primera petición cuando se instala un navegador, es decir, si nosotros instalamos Mozilla Firefox o Google Chrome, la primera vez que hiciéramos una petición a gmail.com, esta petición iría por HTTP hasta ser redirigido al servidor por HTTPs con un redirect y recibir la cabecera HSTS para establecer la política de seguridad. Para resolver este "mínimo" problema, se habilitó una lista precargada de dominios, dónde al instalar un navegador, éste ya tiene una lista precargada de dominios a los que debe conectarse por HTTPs.

La cabecera que un servidor con HSTS habilitado nos devuelve tiene 3 partes: el valor de max-age que es el tiempo en segundos de vida del HSTS en nuestro navegador para dicho dominio - y que vimos que se podía utilizar como una supercookie para vigilar al usuario. Si un dominio X nos devuelve en su cabecera Strict-Tansport-Security un valor de max-age de 1.000.000 de segundos, esto quiere decir que durante el próximo millón de segundos, siempre que hagamos una petición al dominio X, nuestro navegador lo hará bajo HTTPs, aunque no lo indiquemos explícitamente. Otra parte es include subdomains, es decir si el servidor nos devuelve este campo querrá decir a partir del dominio hacia abajo se hará efectivo el HSTS. Por último, podemos recibir el valor preload.

¿Cómo podemos saber si un sitio devuelve HSTS?

Para ver las opciones de HSTS puedes usar las herramientas del developer de Google Chrome o muchos plugins de Firefox, pero para esta pequeña prueba utilizaremos la herramienta curl, con la que podemos realizar peticiones web y obtener las respuestas del servidor. En el primer ejemplo hacemos la consulta sobre Paypal:

Figura 3: Información HSTS de paypal.com

El servidor de Paypal nos devuelve la cabecera Strict-Transport-Security con el valor del max-age. Probando con Outlook encontramos una curiosidad. Tal y como se puede ver en la imagen el dominio que tiene HSTS es www.hotmail.com y no www.outlook.com. Realmente da igual, ya que se hacen varias redirecciones al acceder a Outlook, pero dominios como Outlook.com o login.live.com no devuelven la cabecera.

Figura 4: Configuración de hotmail.com

Estas configuraciones abren posibilidades a un atacante y ventanas de vulnerabilidad a estos dominios en las redes, tal y como vamos a ver a continuación.

PoC: Usando MITMf para lanzar SSLStrip 2

El investigador Leonardo Nve publicó hace algún tiempo la herramienta SSLStrip 2 o SSLStrip+, la cuál es una evolución de SSLStrip. Hoy en día la herramienta desarrollada por Leonardo fue añadida a un framework denominado MITMf. Este framework es muy completo ya que proporciona gran cantidad de plugins, todos ellos relacionados con ataques de red. En este ejemplo que vamos a ver el ataque se lanzará sobre una máquina Windows 7 en la que se acaba de instalar el navegador Firefox 44.0.2. Desde la línea de comandos lanzamos el script mitmf.py con los plugins de arp, dns, hsts e indicando a quién se debe envenenar, en este caso a un router y la máquina Windows.

Figura 5: Lanzando el ataque con MITMf

Si comprobaramos la caché ARP de la máquina Windows veríamos que el envenenamiento de caché ha funcionado. Ahora toca comprobar qué dominios vienen precargados en el navegador. Por ejemplo, introduciendo sitios como Gmail, Facebook o Twitter, el navegador directamente se ha conectado por HTTPs, por lo que el SSLStrip 2 no nos funciona. En el caso de Outlook vemos cómo empezamos a ver qué la herramienta MITMf comienza a trabajar y podemos ver el mensaje: “zapped a strict-transport-security header”, es decir, estamos en medio, hubo una primera petición por HTTP y SSLStrip 2 se está encargando de eliminar los headers HSTS para evitar problemas futuros.

Figura 6: MITMf intercepta las peticiones Outlook.com y subsiguientes

Una vez vemos que está funcionando el ataque, si introducimos un usuario y contraseña en el login de Outlook lo podemos visualizar en la máquina con Kali Linux, tal y como se puede ver en la imagen superior. Lo curioso de esto, es que en un navegador recién instalado Gmail, Facebook o Twitter, vienen con HSTS precargado, pero en el caso de Outlook no.

Poc: Viajemos hacia el futuro

El investigador José Selvi demostró como mediante un ataque al tiempo de los equipos podríamos hacer caducar las entradas HSTS en el navegador, por lo que se tendría que hacer de nuevo una petición por HTTP. Selvi llamó a esto ataque Delorean. Es cierto que conseguir cambiar el tiempo de una máquina remota no es sencillo, aunque depende un poco del caso. José Selvi enseñó en una de sus charlas como en el caso de Ubuntu o Fedora se podía aprovechar el acceso de este sistema operativo a la red para interceptar la petición NTP que se genera. El protocolo NTP permite sincronizar los tiempos de una máquina. Entonces, con un ataque ARP Spoofing básico, SSL Strip2 y Delorean podemos:

- Colocarnos en medio de la comunicación.
- Interceptar las peticiones NTP y modificarlas, por ejemplo diciendo al sistema que se encuentra en 2 o 3 años adelante.
- Visualizar las claves.

Aparte de mantener la aplicación MITMf con la configuración anterior, habrá que lanzar la herramienta Delorean e incluir una regla en iptables. La regla en iptables es la siguiente:

iptables –t nat –A PREROUTING –i [interfaz de red] –p udp –s [red origen] ! –d [red destino] –dport 123 –j REDIRECT –to-port 123.

La máquina víctima es un Ubuntu, el cual podría ser echado de una red WiFi mediante un ataque de desautenticación para así forzar la petición de sincronización temporal vía NTP. Otro ataque posible sería el de colocar una WiFi abierta y esperar a que un sistema Ubuntu se conectara. En ese instante, el sistema realizará una petición NTP que puede ser interceptada por nosotros y modificada con Delorean.

Figura 7: Camibando la hora a un Ubuntu para caducar HSTS

Como se puede ver en la siguiente imagen correspondiente al sistema Ubuntu, el tiempo ha cambiado. Nos hemos ido al futuro, concretamente al año 2019, al mes de Enero. Hemos viajo al futuro.

Figura 8: Fecha del sistema cambiada

Ahora, si desde Ubuntu accediéramos al navegador y navegásemos a dominios como Gmail o Facebook seríamos vulnerables y con SSLStrip 2 nos podrían robar las credenciales. En el caso de Twitter no, porque deberíamos viajar en el tiempo 20 años, ya que el max-age que la empresa del pájaro azul impone son más de 20 años. En la siguiente imagen se puede ver como se accede a Gmail y no se está haciendo a través de HTTPs. Esto es debido a que las entradas HSTS caducaron en la caché del navegador y se realizó la petición por HTTP. Como mucha gente puede pensar, en un entorno real, esto haría saltar alarmas, ya que modificar 2 o 3 años la fecha de un equipo puede provocar que los certificados caduquen y salten alarmas en la máquina, pero las passwords de Gmail vuelan también.

Figura 9: Autenticando en Google sin HTTPs

HSTS es una medida a día de hoy bastante segura, y aunque existen técnicas para bypassearla, no es algo sencillo. Es cierto que hay muchos sitios, incluidos bancos, que no utilizan HSTS a día de hoy, pero cada vez van siendo más los que se decantan por la sencillez de HSTS y por el potencial que tiene.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”

En alguna ocasión os he hablado de MITMf, un framework que implementa diversos ataques basados en interceptar una comunicación y colocarse en medio de ésta. Últimamente están saliendo herramientas que nos ayudan a automatizar y simplificar las pruebas de auditoria de red. Hoy hablaré sobre Bettercap, una evolución de la famosa navaja suiza de red Ettercap que ayuda a implementar los Ataques en redes de datos IPv4& IPv6. Vamos a verlo.

Figura 1: Bettercap, una katana para realizar ataques de red

Bettercap está escrito en código Ruby y se aprovecha de la flexibilidad y potencial de dicho lenguaje. En la propia página de Bettercap se preguntan, ¿Por qué otra herramienta de MiTM? y los propios desarrolladores explican este hecho porque Bettercap es completo, actualizado, modular, portable y fácil de extender por cualquier usuario. Si alguien argumenta que Bettercap es un Ettercap le contestan lo siguiente:

Figura 2: Explicación de por qué utilizar Bettercap

La instalación de Bettercap es realmente sencilla. Tiene dependencias, pero ejecutando gem install bettercap el proceso se lleva a cabo completamente. En caso de necesitar alguna librería se puede utilizar apt-get para completar el proceso. Una vez instalado, dispondremos de un binario, el cual podremos ejecutar.

Figura 3: Instalacion de Bettercap en un Kali Linux 2.0

Una vez instalado, lo mejor es comprobar todas las opciones que la herramienta proporciona. A continuación se pueden ver las opciones por módulos:

• Spoofing.
• Discovery.
• Sniffer.
• TCP-Proxy.
• HTTP-Proxy.
• HTTPS-Proxy.
• SSLStrip.
• HTTP-Server.
• DNS-Server.

Cada módulo dispone de diversas opciones parametrizables, lo cual hace que la herramienta sea flexible y muy potente. Como primer ejemplo, vamos a ver cómo realizar un sniffing básico, almacenando lo que pasa por la interfaz de red en un fichero PCAP. Además, vamos a aplicar un filtro al sniffer mediante el uso del parámetro –P.

Figura 4: Protocolos que pueden analizarse con Bettercap

Los protocolos “filtrables” se pueden consultar en la documentación del sitio web de Bettercap. A continuación se muestran los protocolos que serán tratados por la herramienta:

PoC: Sniffando con Bettercap y aplicando filtros

En esta prueba de concepto se configura Bettercap como sniffer. Se debe indicar al framework que no se quiere realizar spoofing mediante el parámetro –no-spoofing, tal y como se puede ver en la imagen. Si analizamos el tráfico que genera Bettercap, el módulo de Discovery está habilitado por defecto, por lo que veremos cómo se está realizando un ARP Scan de forma constante. Es decir, enviando ARP Request a todas las direcciones IP de la red. En la imagen se puede ver como la herramienta nos indica rápidamente las máquinas con las que tenemos conectividad, esto es debido al módulo de Discovery.

Con el parámetro –L indicamos a Bettercap que “parsée” los paquetes que llegan al equipo, e implícitamente habilita el modo sniffer, el cual se activa con el parámetro –X. Por otro lado, el parámetro –sniffer-output hace que todo lo que llega a la interfaz se almacene en el fichero, en este caso better.pcap.

Figura 5: Bettercap en modo sniffer

En la propia pantalla se puede visualizar las peticiones que se han realizado, aunque todo queda almacenado en el fichero PCAP. El código de colores ayuda a visualizar la información de manera sencilla y útil.

PoC: ARP Spoofing by default

En esta prueba de concepto configuraremos a Bettercap con el módulo de ARP Spoofing y aplicaremos un filtro para poder visualizar el tráfico que sea solo HTTP o al puerto 80 TCP. El escenario propuesto para esta prueba de concepto es el siguiente:

• Una máquina Windows será la víctima.
• Un router con el que la máquina Windows se comunica para enviar peticiones y tráfico hacia a Internet.
• Una máquina con Kali Linux con Bettercap instalado.

Desde Bettercap ejecutamos la instrucción bettercap –sniffer-filter “tcp port 80”. Esto por defecto activa los módulos de Spoofing, Discovery y Sniffer. Hay que recordar que para no habilitar el módulo de Spoofing habría que indicarlo con el parámetro –no-spoofing. El filtro nos permite filtrar la información no deseada y centrarnos en lo deseado, en este caso, tráfico HTTP. Si quisiéramos realizar un ARP Spoofing contra dos máquinas concretas, podríamos utilizar con el parámetro –T la dirección IP a suplantar, por ejemplo –T 192.168.1.35 y con –G 192.168.1.1 indicamos la dirección IP del router.

Figura 6: Ataque de ARP Spoofing con Bettercap

El ataque de suplantación se puede realizar a través de ARP Spoofing o con ICMP Redirect. Con el parámetro –spoofer se puede indicar ARP, ICMP o NONE. Por defecto, si no se indica se lanzará ARP Spoofing. Además, si no se indican direcciones IP a las que spoofear, el ataque se llevará a cabo contra toda la red de ámbito local y todos los equipos que se encuentren disponibles en la red.

PoC: SSL Strip 2 con Bettercap

En esta prueba de concepto vamos a configurar un SSLStrip+ o SSLStrip2 de Leonardo Nve, el cual viene implementado con Bettercap y se puede utilizar de forma muy sencilla, como ya se vio con MITMf en el artículo de “Ataques man in the middle a HSTS: SSLStrip 2 & Delorean”. Bettercap es compatible con el SSLStrip de Moxie Marlinspike, por lo que también se puede utilizar. Configuramos el módulo de Proxy para reenviar todo el tráfico dirigido al puerto 80 a Bettercap, le indicamos el target con el parámetro –T y con el parámetro –P le indicamos que “parsée” las peticiones POST.

Figura 7: Ejecución de bettercap en modo proxy

El parámetro –proxy-module permite inyectar código HTML, CSS o Javascript. Esto es interesante si se quiere modificar el contenido de un recurso, e intentar ejecutar código del lado del navegador tal y como se hacía con el trabajo de "Owning bad guys {and mafia} using Javascript botnets". Un posible objetivo podría ser la inyección de código HTML con intención de lograr un Phishing en la página o conseguir que el navegador realizara peticiones a un recurso externo el cual devolviera un exploit.

En la documentación de Bettercap viene un ejemplo de lo que se verá cuando el Bypass de HSTS funcione. Sabemos que el bypass de HSTS es parcial y que depende de una serie de condiciones, pero si las cumplimos, la eliminación de la cabecera HSTS por parte de Bettercap es fundamental para que nos funcione el ataque. Recordando las condiciones nos encontramos con:

• El navegador Firefox o Chrome no debe tener cacheado el dominio en su caché HSTS, es decir, el Max-Age no debe estar insertado en el navegador. En caso de que esté cacheado durante N segundos, lo que se indique en Max-Age, las peticiones a ese dominio no se realizarán nunca por HTTP, y serán siempre por HTTPS. 

• En el caso de tener cacheado dicho dominio o esté en una lista precargada, podríamos realizar un ataque de tipo Delorean, creado por José Selvi. Con este ataque se busca provocar la caducidad de dichas entradas en la caché del navegador. Este ataque se logra interceptando peticiones NTP de las máquinas y llevándolas hacia el futuro.

Figura 8: Ataque de HSTS bypass cambiando el dominio de la víctima

En la imagen se puede ver cómo Bettercap muestra “Found stripped HTTPS link”. El módulo de SSLStrip está funcionando y podemos ver cómo todo pasa por nuestro Proxy, el cual hemos arrancado con el parámetro –proxy. Es fundamental el cambio de las “www” a las “wwww”. Estamos apoyándonos en un servidor DNS que está devolviendo la dirección IP del mismo Facebook en este caso.

Figura 9: Ataque ejecutado con éxito saltándose el sistema HSTS

Si analizamos las peticiones POST nos encontramos con información jugosa. Por ejemplo, SSLStrip+ nos ha funcionado y vemos como el usuario introdujo su dirección de e-mail y su contraseña “dadada”. Las peticiones pueden verse en texto plano, cuando en un uso normal estarían protegidas bajo HTTPS, pero de esta forma tenemos acceso al contenido.

Figura 10: Captura de credenciales en texto plano

Conclusión final

Bettercap es una herramienta llena de posibilidades con la que podemos realizar gran parte de los ataques de red modernos y que permite ser ampliada de forma sencilla gracias al lenguaje sobre el que está programada. Sin duda, Bettercap es una de las herramientas que debemos llevar en la mochila en una auditoria interna y/o de red.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”