Seth: Ataques MITM a conexiones RDP y mitigación

Seth es una herramienta desarrollada en python y bash que nos permite realizar un ataque MITM man in the middle en conexiones RDP aprovechándose una configuración insegura como es el NO habilitar la autenticación a nivel de red NLA para conexiones de escritorio remoto.

Como requerimiento previo para usar Seth es necesario tener instalado arpspoof por lo que será necesario instalar el paquete dsniff.

apt install dsniff -y

Clonar el reporsitorio de Seth. 

git clone https://github.com/SySS-Research/Seth.git

Escenario en un entorno de dominio Active Directory

• Atacante: 1.0.0.38 (Kali)
• Víctima: 10.0.0.50 (Win10)
• Host remoto: 10.0.0.76 (WServer 2019)

Seth se ejecutará en la máquina atacante 10.0.0.38 y se mantendrá a la escucha esperando que se establezca una conexión, la máquina víctima 10.0.0.50 (el usuario que se conectará a la máquina remota 10.0.0.76) le aparecerá el prompt de autenticación de credenciales, el certificado autofirmado no confiable del equipo remoto (que acabará aceptando) y finalmente se establecerá la conexión RDP. 

Seth interceptará el certificado y se podrá en medio de la comunicación insegura y sin cifrar capturando los eventos de teclado y en consecuencia las credenciales de acceso a la máquina remota.

Desde la máquina Kali 10.0.0.38 descargamos y previamente ejecutamos el script de seth.sh.

./seth.sh <INTERFACE> <ATTACKER IP> <VICTIM IP> <GATEWAY IP|HOST IP> [<COMMAND>]

Veremos que captura las pulsaciones de teclado DOMINIO\USUARIO:PASSWORD incluso después de que se establezca la conexión RDP.

Figura 1: Seth - MitM en conexiones RDP.

Haciendo uso del cliente rdesktop nos autenticamos con las credenciales capturadas y vemos como se establece una conexión RDP hacia la máquina remota.

rdesktop -g1024x768 <REMOTE IP> -u <USER> -p <PASSWORD> -d <DOMAIN>

Figura 2: rdesktop - Conexión RDP a la máquina remota víctima.

Mitigar ataques MITM en conexiones RDP

NLA (Network Level Authentication) requiere que el usuario que se conecta desde un cliente RDP se autentique antes de que se establezca una sesión con el servidor RDP. Utiliza el proveedor de soporte de seguridad, CredSSP, que está disponible a través de SSPI (Security Support Provider Interface). 

En sistemas Windows esta opción está habilitada por defecto para mantener una comunicación segura y evitar este tipo de ataques.

Figura 3: Habilitar NLA (Autenticación a nivel de red) en conexiones remotas RDP.

Para habilitar y aplicar este cambio en un entorno de dominio a través de políticas de grupo GPO.

Configuración del equipo > Plantillas administrativas > Componentes de Windows > Servicios de Escritorio remoto > Host de sesión de Escritorio Remoto > Seguridad > Requerir la autenticación del usuario para las conexiones remotas mediante Autenticación a nivel de red

Figura 4: Habilitar NLA a través de política de grupo GPO.

Conclusiones

Debido al constante y acelerado cambio tecnológico es una gestión complicada la migración de servicios y sistemas en las empresas. Sería más que necesario implementar medidas de control en el bastionado y configuraciones seguras para cualquier máquina que forme parte de una infraestructura corporativa, independientemente del entorno en el que se esté ejecutando (DES, PRE o PRO).

A día de hoy es muy común encontrarse con este tipo de configuraciones o bien por desconocimiento o bien por mantener una retrocompatibilidad en sistemas legacy ya existentes (anteriores a Windows XP SP3 y Windows Server 2008) que se resisten a ser actualizados por las compañías debido a las complejidades de migración que supone para los servicios que están ejecutando. Por lo que este tipo de técnicas siguen siendo efectivas y deben considerarse como un riesgo alto de seguridad.

Publicación relacionada de interés.

• Hardening en servicios de Escritorio remoto RDP

Saludos!

Como protegerse de ataques ARP Spoofing

Siguiendo el tema de las entradas en las que comentara los ataques MITM en la tabla ARP.

1. Ataques MITM: ARP Poisoning y DNS Spoof con Ettercap - Parte 1 de 2
2. Ataques MITM: ARP Poisoning y DNS Spoof con ARPSpoof - Parte 2 de 2

El éxito de esta técnica de ataque radica en que dentro de una misma red local es posible la suplantación de la dirección MAC de la puerta de enlace, por la dirección MAC del atacante en la tabla ARP del equipo atacado. De modo que todo el tráfico que se genere desde en el equipo atacado será interceptado por el equipo atacante y este a su vez lo redireccionará a la dirección de la puerta de enlace legítima de la red local, de esta manera el equipo atacado no será consciente de que su tráfico de red se esté monitoreando, al menos que este consulta su tabla ARP (arp -a).

En la siguiente captura se puede ver una consulta a la tabla ARP de un equipo atacado, consultada antes y después de ser atacado. Vemos como la dirección MAC del Gateway es suplantada por la dirección MAC del atacante (en este caso correspondiente a la dirección IP 192.168.100.20).

Figura 1: Suplantación de MAC en la tabla ARP (ARP Spoofing)

Una opción que podemos aplicar para prevenir la suplantación de la dirección MAC de nuestro Gateway, es incluir dicha dirección MAC en la tabla ARP del sistema local de forma estática. Con esto conseguiremos que el equipo ya tenga definida una ruta estática de dirección IP correspondiente con su dirección MAC, por lo que será imposible el uso de técnicas ARP Spoofing para intentar suplantarla.

En sistemas Windows añadir una o varias rutas estáticas en la tabla ARP es posible con la utilidad de comandos ARP.

arp -s [IP_GATEWAY] [MAC_GATEWAY]

Figura 2: Añadir ruta estática en la tabla ARP en sistemas Windows.

Otra forma de hacerlo es mediante la utilidad de comandos Netsh en su modo interactivo.

netsh
netsh>interface
netsh>ipv4
netsh>add neighbors "[NOMBRE_INTERFACE]" "[IP_GATEWAY]" "[MAC_GATEWAY]"

Figura 3: Añadir una ruta estática en la tabla ARP en sistemas Windows con Netsh.

En el caso de sistemas Linux el argumento y la expresión del comando es la misma que en el caso de Windows.

Vemos como las rutas estáticas en la tabla ARP se marca como "PERM" (permanent).

arp -s [IP_GATEWAY] [MAC_GATEWAY]

Figura 4: Añadir una ruta estática en la tabla ARP en sistemas Linux.

Cualquiera de estas líneas de comandos de la tabla ARP se podría automatizar en un script de inicio del sistema. Ejecutar scripts o aplicaciones al inicio del sistema.

En el caso de Windows se puede crear un fichero por lotes .bat con la instrucción. Y añadir este script en el inicio de sesión o sistema.

@echo off
arp -s [IP_GATEWAY] [MAC_GATEWAY]
exit

En el caso de Linux crearíamos un script .sh en bash. Darle permisos de ejecución a este script y añadiendo el path de ubicación en una línea al final del fichero /etc/rc.local por ejemplo.

#!/bin/sh -e
# Añadir ruta estática gateway en la tabla ARP
arp -s [IP_GATEWAY] [MAC_GATEWAY]
exit 0

Saludos!

Ataques MITM: ARP Poisoning y DNS Spoof con ARPSpoof - Parte 2 de 2

• Ataques MITM: ARP Poisoning y DNS Spoof con Ettercap - Parte 1 de 2
• Ataques MITM: ARP Poisoning y DNS Spoof con ARPSpoof - Parte 2 de 2

Esta vez comentaré prácticamente lo mismo pero realizando el ataque desde una terminal de forma manual, sin una GUI. Desde una distribución Kali Linux usando arpspoof y el plugin DNS_Spoof de Ettercap también desde la terminal.

El equipo atacante (KaliLinux) tendrá que "hacer de router" por lo que se tendrá que habilitar ip_forward para enrutar todo el tráfico que llegue a el. De modo que deje salir a la puerta de enlace original todo el tráfica de la víctima. Si esto no se hiciese la vícitma se daría cuenta de algo extraño sucede ya que se quedaría sin conexión a Internet.

Para este ejemplo el equipo atacante tendrá la dirección 192.168.100.20.

echo 1 >> /proc/sys/net_ipv4/ip_forward

Figura 1: Habilitar ip_forward para el enrutamiento de tráfico.

Usando Nmap lanzamos un escaneo de reconocimiento a toda la red local disponible en este caso una clase C CIDR /24.

Para este ejemplo la víctima será la 192.168.100.10.

nmap -sP [DIRECCIÓN_RED/CIDR]

Figura 2: Escaneando toda la red local con Nmap.

Envenenamos la tabla ARP del equipo atacado y le hacemos creer qu ela dirección MAC verdadera del equipo atacante (192.168.100.20) es la misma que la de su puerta de enlace (router: 192.168.100.1). Inicio del ataque, especificamos la interfaz de salida con -i y con -t el target (víctima) seguido del equipo (router) en el que suplantaremos la dirección MAC para la víctima.

En la captura podemos ver como las direcciones MAC de la tabla ARP del equipo víctima (Windows) cambiaron después del ataque. La MAC del router es la misma que la del atacante.

Dejaremos esta terminal minimaza y siempre funcionando.

arpspoof -i [INTERFAZ_RED] -t [IP_VÍCTIMA] [IP_ROUTER]

Figura 3: arpspoof - Antes y después del ataque.

Empezamos a capturar tráfico en Wireshark desde el equipo atacante. Como ejemplo ingresaré en una web con mi nombre de usuario y contraseña. Este sitio no utiliza HTTPS, por lo que toda la información que veamos o ingresemos en un formulario no irá cifrada y será visible en texto claro.

Figura 4: Ingresando credenciales en un formulario de un sitio que no utiliza HTTPS.

Una vez interceptado HTTP el tráfico en Wireshark, podemos ver la solicitud POST de login. Examinado este paquete vemos el nombre de usuario y la contraseña en texto introducidos por la víctima.

Figura 5: Captura de credenciales introducidas por la víctima en el sitio web.

Iremos un paso más allá incorporando el plugin dns_spoof de Ettercap. Como se trata de redirigir las peticiones a direcciones DNS que solicite la víctima, crearemos una website (que puede ser una réplíca visualmente de un sitio web conocido: facebook.com, gmail.com, etc.). 

Para ello crearemos un servidor HTTP con Apache. Creamos un documento HTML, en este ejemplo no replicaré ningún sitio ya que llevaría más trabajo y como prueba de concepto me basearé en la representación y entendimiento de la técnica más que en su elavoración.

Figura 6: Creación de un posible sitio web malintencionado.

Redirigimos las peticiones DNS a las direcciones IP que queramos en este caso al servidor Apache que estará sirviendo en la máquina del atacante.

Como ejemplo podemos redirigir las peticiones que vayan hacia google.es hacia una dirección IP correspondiente a otro sitio web que se verá más adelante, facebook.com y a este blog se redirigirán al servidor Apache del atacante.

Editamos el fichero del plugin "dns_spoof" de Ettercap.

/etc/ettercap/etter.dns

Figura 7: Editando fichero etter.dns para redirección de peticiones DNS de la víctima.

Una vez creado el documento principal y redirigido las peticiones DNS a la dirección IP de nuestro servidor, arrancamos el servicio del servidor Apache (ya instalado por defecto en Kali).

service apache2 start

Figura 8: Iniciar el servicio del servidor Apache

Lanzamos el plugin dns_spoof a través de ettercap haciendo uso de la terminal. Estando la terminal de arpspoof funcionando. Abrimos una nueva terminal para ejecutar lo siguiente.

ettercap -T -q -i [INTERFAZ_RED] -M arp:remote -P dns_spoof //[IP_ROUTER]// //[IP_VÍCTIMA]//

Figura 9: Ejecución del plugin dns_spoof de Ettercap en la terminal.

Si observamos las siguientes capturas de pantalla, vemos como el cliente intenta acceder a facebook.com y este lo redirige a nuestro servidor Apache.

Es curioso que siendo sitios webs bien conocidos y que de forma automática redirigen estas solicitudes a conexiones HTTPS y no HTTP. Pero en ciertas ocasiones y también dependiendo de como tengamos de limpio los navegadores webs tanto en IE como Firefox en ambos casos redirigieron estas solicitudes a donde se esperaba.

En la mayoría de ocasiones esto no fue posible mostrarlo tal cual aparecen en las capturas, ya que como ya dije al final del post de la parte 1 existen técnicas (HSTS y HPKP) que evitan que esto pase así como tampoco sería efectivo con SSLStrip el cual veremos en una futura entrada de este blog.

De manera que en la gran mayoría de ocasiones (no en todas) tuve que forzar la petición por "HTTP://facebook.com" en la barra de direcciones del navegador. Estos sitios web están configurados para redireccionar de forma automática sus solicitudes HTTP a HTTPS. Aunque se acceda por algún enlace o se escriba solamente "facebook.com" estas webs siempre intentarán redirigir a su sitio seguro y comprobar su certificado.

En el caso de este blog al no disponer de HTTPS y menos de un certificado de confianza, vemos que no existe ningún problema en redirigir tráfico HTTP.

En el último caso la redirección de google.es hacía la dirección IP establecida vemos que ha funcionado. Lo cual no siempre fue así de las pruebas realizas, por la misma razón que comenté anteriormente, la redirección HTTP a HTTPS.

 Figura 10: Redirección de facebook.com hacia el servidor Apache del atacante.

Figura 11: Redirección de es.es.facebook.com hacia el servidor Apache del atacante.

Figura 12: Redirección de zonasystem.com al servidor Apache del atacante.

Figura 13: Redirección de google.es hacía la dirección IP establecida en etter.dns.

Con nslookup vemos la comprobación de redirecciones DNS en el equipo atacado. En este caso facebook.com redirige al servidor Apache del equipo atacante.

Figura 14: Comprobando las redirecciones DNS en el equipo atacado.

En próximas entradas comentaré para que como sirve y como usar SSLStrip. Las desventajas que actualmente existen y que posibilidades de redirigir tráfico HTTPS hacia HTTP.

Saludos!

Ataques MITM: ARP Poisoning y DNS Spoof con Ettercap - Parte 1 de 2

• Ataques MITM: ARP Poisoning y DNS Spoof con Ettercap - Parte 1 de 2
• Ataques MITM: ARP Poisoning y DNS Spoof con ARPSpoof - Parte 2 de 2

Existen múltiples utilidades para realizar técnicas de ataques Man In The Middle (MITM). Es un tema que está más que documentado en Internet. En una anterior entrada ya comentara en que consisten y como realizar estos ataques desde Cain & Abel en entornos Windows.

Con el fin de tener esto como un apunte personal más, comentaré como realizar un "ARP Poisoning" y incorporar el plugin "DNS_Spoof" con Ettercap, una utilidad gráfica que podemos descargar e instalar en cualquier entorno Linux. Por defecto también está disponible está disponible en Kali Linux.

Ettercap es muy sencillo de utilizar, por lo que no me extenderé explicando los detalles. Solamente con las capturas de pantalla se pueden seguir los pasos perfectamente y entender sus funciones.

Establecemos las librerías pcap. Sniff > Set pcap filter...

Figura 1: Set pcap filter Ettercap

Asignamos una interfaz de red para el sniffing. Sniff > Unified sniffing...

Figura 2: Asignar interfaz de red para la captura de paquetes.

Indicamos la interfaz de red, en este caso eth0.

Figura 3: Indicar interfaz de red

Escanemos los hosts disponibles de la red local. Scan for hosts... Una realizado el escaneo listamos los hosts disponibles. Hosts list.

Figura 4: Escaneo de hosts disponibles de la red local.

En este escenario vemos dos hosts disponibles, el equipo que nos interesa atacar es el que corresponde a la dirección IP 192.168.100.10. Lo seleccionamos y realizamos el ARP Poisoning hacia este equipo. Mitm > ARP poisoning...

Figura 5: Selección de la víctima para ARP poisoning.

Nos interesa capturar las conexiones del equipo remoto por lo que seleccionamos Sniff remote connections.

Figura 6: Sniff para conexiones remotas.

En esta punto ya estaremos envenenado la tabla ARP de la víctima. Pero añadiremos el plugin "dns_spoof" que integra Ettercap. Esto nos servirá para suplantar peticiones DNS y así redirigir estas peticiones a la dirección IP que tengamos establecida en el fichero "/etc/ettercap/etter.dns".

Administramos los plugins disponibles en Ettercap. Plugins > Manage the plugins...

Figura 8: Administrar plugins en Ettercap.

Se abrirá una nueva pestaña en la que buscaremos y seleccionaremos el plugin dns_spoof.

Figura 9: Selección del plugin dns_spoof.

Por último solo restará modificar el fichero local /etc/ettercap/etter.dns (en Kali Linux) para redirigir las peticiones de nombres de dominio del equipo víctima hacia las direcciones IP que establezcamos. En este caso las redirigí al propio equipo local (atacante) que tiene la IP 192.168.100.20. En este equipo tengo un servidor Apache el cual podría almacenar una réplica de la website que estamos redirigiendo, de este modo podríamos "engañar" a la víctima haciendo creer que está haciendo a facebook.com cuando realmente está accediendo en mi web idéntica de facebook.com alojada en mi servidor Apache.

Figura 10: Fichero etter.dns. Redirigiendo websites.

Tiempo atrás se podía realizar con éxito este ataque. Hoy en día gracias a las mejoras de seguridad existen mecanismos que dificultan los DNS Spoof como son HPKP y HSTS.

Estos pueden interceptar las comunicaciones, cookies y otros parámetros. Obligando el uso de protocolos seguros como HTTPS, redirigiendo los sitios webs a su lugar legítimo.

De manera informativa y educativa en posteriores entradas comentaré una de las técnicas que podemos utilizar para intentar bypasear este tipo de mecanismos de seguridad.

Saludos!

Ataques MITM: ARP Spoofing/Poisoning sobre IPv4 - Parte 2 de 2

• Ataques MITM: ARP Spoofing/Poisoning sobre IPv4 - Parte 1 de 2
• Ataques MITM: ARP Spoofing/Poisoning sobre IPv4 - Parte 2 de 2

¿Cómo prevenir o evitar ataques MITM - ARP Spoofing/Poisoning?

Una de las maneras para prevenir el ARP Spoofing de manera manual, es el uso de tablas de caché ARP de forma estáticas, de forma que no existe caché dinámica, cada entrada de la tabla mapea una dirección MAC con su correspondiente dirección IP.

Para añadir rutas estáticas ARP a la tabla caché se pueden realizar de diferentes formas, dependiendo el OS que utilicemos. Abrimos una consola con privilegios administrativos.

Windows o Linux:

arp -s [IP Address] [MAC Address]

arp -s 192.168.1.1 00:11:22:33:44:55

Windows (usando netsh):

netsh > interface > ipv4 > add neighbords "[NombreDeLaConexiónDeRed]" [IP Address] [MAC Address]

netsh > interface netsh interface> ipv4

netsh interface ipv4> add neighbords "Conexión de área local" 192.168.1.1 00:11:22:33:44:55

El inconveniente de añadir rutas estáticas a la caché de la tabla ARP es que al reiniciar el PC las direcciones estáticas se eliminan. Para mantener esta tabla podríamos generar un script .vbs o .bat (el cual le daríamos privilegios administrativos) y que este se ejecute en el inicio del sistema, ya bien podemos incluirlo en la carpeta "Inicio" o hacer uso del editor de directivas de grupo local.

gpedit.msc > Configuración de Windows > Scripts (inicio o apagado) > Inicio > Agregar... > buscamos la ruta del fichero .vbs o .bat. Esto lo añade por defecto en la ruta: C:\Windows\System32\GroupPolicy\Machine\Scripts\Startup

Dejo referencia a un artículo con más detalle: http://www.zonasystem.com/2017/08/como-protegerse-de-ataques-arp-spoofing.html

¿Cómo detectar ataques MITM - ARP Spoofing/Poisoning?

Si empezamos a notar alguna anomalía mientras navegamos.

• Que un página que debería llevar un protocolo HTTPS está como HTTP.
• Que aún siendo HTTPS se nos caiga la conexión con el servidor de dicha página o nos deniege el acceso ya que detecta que la entidad certificadora CA que emite el certificado para la conexión no es el original o un entidad emisora legítima.
• Que una dirección DNS que sabemos a donde nos lleva y como es la página web de esta, se nos muestra una página web similar o nos encamina a otra página web distinta.

En cualquiera de los casos anteriores sería entonces donde podría consultar la tabla ARP con el comando arp -a y comprobar la existencia de direcciones MAC clonadas correspondientes a distintas direcciones IP.

Como prueba sobre dos Windows 7 Ultimate x64 instalados en máquinas virtuales. Aunque como ya dijera en la primera entrega el OS no influye para este tipo de ataques ya que se tratan a nivel de red local en la Capa 2 (enlace de datos o acceso) del modelo OSI.

Para que se pueda ver de una manera más clara hice uso del sniffer de red Wireshark. Que hace uso de WinPcap que son librerías necesarias para capturar el tráfico de transmisión de datos en una red, y que trabaja a nivel de núcleo.

En las capturas de pantalla que muestro a continuación se ocultan parte de lo que forman las direcciones, esto lo hago por seguridad. Pero un detalle que quiero aclarar es que en una dirección MAC lo normal sería ocultar los últimos tres bloques hexadecimales ya que estos identifican la dirección con relación a los tres primeros que identifican el proveedor o fabricante del adaptador de red. 

En este caso yo oculte los 4 primeros bloques hexadecimales manteniendo visibles los 2 últimos, la razón es por que al estar trabajando en máquinas virtuales las direcciones que identifican al fabricante eran las mismas y entonces no se podría ver la diferencia. Igualmente oculto el cuarto bloque de la dirección MAC completa que correspondería el primero que identifica dicha dirección MAC.

El escenario para este ejemplo sería.

Atacante:

• IP Address: 10.0.0.15
• MAC Address: xx:xx:xx:xx:09:27
• Gateway: 10.0.0.1 (MAC xx:xx:xx:xx:66:00)

Víctima:

• IP Address: 10.0.0.14
• MAC Address: xx:xx:xx:xx:A6:38
• Gateway: 10.0.0.1 (MAC xx:xx:xx:xx:66:00)

Usando Wireshark

La víctima es la que detectará el ARP Spoofing del atacante, capturando tráfico y así ver modificaciones de falseos/clonados/suplantaciones de direcciones MAC en las tramas ARP Request y ARP Reply.

Figura 1: Detectando trama MAC duplicada filtrando por el protocolo ARP en Wireshark.

Vemos como un host anuncia su dirección MAC sin que nadie se lo pida. Después un host solicita la dirección MAC y hay dos respuestas con la misma dirección IP pero diferente dirección MAC.

Finalmente, Wireshark detecta el ARP Spoofing, que lo describe como: "duplicate use of 10.0.0.1 detected" "Detectado el duplicado del uso de la 10.0.0.1" es decir, la puerta de enlace o gateway.

Pero sería muy tedioso, tener que abrir y poner a capturar tráfico de tramas ARP cada vez que encendemos nuestro PC y nos ponemos a navegar por internet, y que por encima al final del día paremos la captura y analicemos la .pcap para detectar si fuimos víctimas de un ataque Man In The Middle.

Por lo que para esto ya existen muchas y diversas aplicaciones, tanto para OS Windows como para OS Linux y compatibles con sus distribuciones, que de manera automática y transparente para el usuario, sin necesidad de que este realice ninguna acción, estas detectan si están ocurriendo modificaciones de la caché de la tabla ARP y que monitorean el tráfico de tramas ARP Request y ARP Reply.

Usando DecaffeinatID (Windows)

Para Windows podremos encontrar DecaffeinatID, es una pequeña aplicación desarrollada por IronGeek.com y que después de instalarla se carga en la taskbar de Windows ejecutándose de manera background y automatizada. Nos avisa de cambios producidos a tiempo real en la caché de la tabla ARP del PC.

Nos dice que la dirección IP de la gateway a cambiado mostrándonos la dirección MAC original por la falseada.

Figura 2: Detectando suplantación de direcciónes MAC con DecaffeinatID.

Usando ArpWatch (Linux)

Para Linux podremos encontrar ArpWatch, que usa libpcap (es igual que Winpcap, pero de código abierto y que son las librerías que son usadas por sistemas Linux) y monitorea los cambios de direcciones IP y direcciones MAC. Estos avisos podemos modificarlos para que nos alerte a nuestra dirección de correo, y lógicamente ver mensajes de logs.

Después de descargar el .gz e instalarlo. Escribimos los siguientes comandos y parámetros para su uso.

sudo arpwatch -i eth0

Este comando ejecuta Arpwatch, así cuando detecte un cambio de direcciones IP-MAC nos mostrará un mensaje de log en el directorio /var/log/syslog.

Saludos!

Ataques MITM: ARP Spoofing/Poisoning sobre IPv4 - Parte 1 de 2

• Ataques MITM: ARP Spoofing/Poisoning sobre IPv4 - Parte 1 de 2
• Ataques MITM: ARP Spoofing/Poisoning sobre IPv4 - Parte 2 de 2

En que consiste un ataque MITM ARP "Man in the middle"?

Los tipos de ataque "Man in the middle" (MITM) o también conocidos como "Hombre en el medio", consisten en realizar una técnica de ataque pasivo, denominada: ARP Spoofing, ARP Poisoning o ARP Poison Routing (APR), y se lleva a cabo en redes LAN (Local Area Network) y WLAN (Wireless Local Area Network).

 

Estando conectados en la misma red, este ataque nos permite capturar todo el tráfico dirigido de uno o varios hosts de la red a la puerta de enlace configurada (Gateway) y viceversa.

Consiste en "engañar" o más bien envenenar la caché de la tabla ARP de la víctima (lo que se conoce como: ARP Cache Poison - APR).

 

De modo que la dirección MAC Address (Media Access Control Address) de la puerta de enlace de la víctima no sea la verdadera, si no que sea la dirección MAC del atacante. Así cuando la víctima realice consultas hacía internet que serán requests para su gateway antes pasaran por el host del atacante, este lo dejará pasar al router el router devolverá la respuesta al atacante de nuevo y este a la víctima. De esta manera que la víctima no se dará de cuenta de lo que está pasando.

Para que quede más claro:

Figura 1: Esquema de ataque MITM.

Un detalle a tener en cuenta es que si en vez de envenenar la caché de la tabla ARP de la víctima con la MAC del atacante se envenenara con otra MAC falsa (por ejemplo: 00:11:22:33:44:55) a la victima le provocaremos una de denegación de servicio DOS (Denial Of Service).

Diferencias entre Modo Promiscuo (Promiscuous Mode) y Modo Monitor (Monitor Mode)

Ya que este ataque es utilizado en redes cableadas que se encaminan mediante dispositivos switch, el tráfico no se transmite por un medio abierto (como pueden ser las transmisiones inalámbricas), por lo que para capturar este tipo de tráfico en uno o varios hosts es necesario realizar este tipo de técnicas como los ARP Spoofing.

Con la tarjeta en modo promiscuo (Promiscuous Mode - termino utilizado para redes cableadas) ya que modo monitor (Monitor Mode) sería el término apropiado para redes inalámbricas y poder capturar todo los IVs (Initialization Vectors). Estos modos tanto promiscuo como monitor se refieren a lo mismo (pero cada uno aplicándolo en su término adecuado, dependiendo el área en el que se esté utilizando o tratando) y en lo que consisten es poder capturar TODOS los paquetes que circulan por la red, aunque no vayan dirigidos al host que solicito la petición.

¿Cómo se modifica la trama Ethernet para realizar un ARP Cache Poison?

Toda trama MAC se compone en su header (o cabezera) de una dirección MAC origen y una dirección MAC destino (al final de la cabezera también muestra el tipo de Ethernet), el payload (o cuerpo) compuesto por datos y el trailer (o cola) que muestra un CRC (Cyclic Redundancy Check, comprobación de errores) o cheksum (Suma de verificación) o FCS (Frame Check Sequence), este verifíca si la trama a llegado correctamente a su destino o no.

La forma más habitual de crear un ARP Spoofing es creando una "condición de carrera" (Race Condition) que consiste en la distribución de respuestas ARP no solicitadas (por las víctimas), las cuales son almacenadas en la cache ARP de las víctimas o clientes.

¿Por qué es posible este ataque MITM-Man in the middle?

Tanto los paquetes “ARP request” como los “ARP reply” no proporcionan ninguna validación de identificación en la transacción. Por este motivo este ataque se hace transparente al usuario ya que la trama no se verifica en ninguno de los sentidos con alguna marca identificativa (ID) de integridad.

Un caso práctico y secillo de realizar el ataque con Windows.

El escenario para esta práctica es el siguiente:

Gateway:

IP: 10.0.0.1

MAC: xx:xx:xx:xx:66:00

Víctima:

IP: 10.0.0.4

MAC: xx:xx:xx:xx:96:0E - GW: 10.0.0.1

O.S.: Windows XP Professional SP3 (x86)

Atacante:

IP: 10.0.0.3

MAC: xx:xx:xx:xx:1F:71

GW: 10.0.0.1

O.S.: Windows 7 Ultimate SP1 (x64)

En esta técnica no influye el tipo de sistema operativo ni la arquitectura que se utilice ya que esto es a nivel de comunicación de redes. 

[1] - Antes de realizar el ataque consultaremos como está el escenario de los equipos de la red. Primero vamos consultar la dirección MAC del atacante con el comando en Windows ipconfig /all o simplemente getmac y veremos que la MAC del atacante es: xx:xx:xx:xx:1F:71, si realizamos un ping a la dirección IP de la víctima (10.0.0.4) y después consultamos la caché de la tabla ARP del atacante, con el comando arp -a así obtendremos la MAC de la víctima (xx:xx:xx:xx:96:0E) y la MAC del gateway o puerta de enlace (en este caso un dispositivo Router: xx:xx:xx:xx:66:00) como se puede ver en la siguiente screenshot.

Figura 2: Consultando tabla ARP del equipo atacante comprobando las direcciones MAC reales.

[2] - Ahora consultamos como están las cosas por la parte de la víctima, tanto su IP address como su MAC Address, y la caché de la tabla ARP.

Figura 3: Comprobando dirección IP y dirección MAC de la víctima.

Figura 4: Consultando la tabla ARP de la víctima con las direcciones MAC originales.

Podemos ver como en la caché de la tabla ARP de la Víctima figura la dirección IP del atacante con su correspondiente MAC y lo mismo pasa con los datos de la gateway.

Ahora empezaremos el ataque, para ello utilizaremos una tool para Windows: Cain & Abel.

Una vez instalemos y ejecutemos Cain en el PC del atacante (deshabilitar antes el antimalware que tengamos ejecutándose en el PC), veremos que con esta herramienta podremos hacer casi de todo tipo de ataques. Pero me centraré especialmente en el ataque mencionado APR (ARP Poison Routing).

[3] - Nos dirigimos a la pestaña "Sniffer" y dentro de esta en el apartado "Hosts", activamos el icono de la tarjeta de red (configurada previamente para "modo promiscuo" y así poder capturar tráfico que obtendremos aunque los paquetes request y reply no vayan dirigidos al ordenador del atacante) (1), activamos el icono que se muestra con una imagen "+" (en azul) para definir el rango a escanear, en este caso voy a tiro fijo definiendo un rango de clase C (mascara de red de una longitud de 24 bits) comprendido de los hosts 10.0.0.1 hasta 10.0.0.20, pulsamos en OK (3).

Vemos que la IP y MAC de la gateway y el atacante coinciden con los datos anteriores consultados.

Figura 5: Escaneando un rango de red con Cain.

[4] - Dentro de la pestaña "Sniffer", nos dirigimos en al apartado APR (1), y seleccionamos APR en el panel izquierdo (2), para que se nos habilite la opción de poder añadir los host para realizar APR pinchamos en la la zona vacía o "blanca" del panel superior-derecho y pulsamos en el icono con una imagen "+" (en azul) (3), Se nos abrirá una ventana (4) en la que diremos que todo e tráfico de 10.0.0.4 (víctima) (5) que vaya dirigido a la 10.0.0.1 (gateway) (6) pase antes por la máquina en la que se ejecuta Cain, que es la máquina del atacante 10.0.0.3 y finalmente pulsamos OK (7).

Figura 6: Enrutando el tráfico del equipo de la víctima hacía la dirección MAC del equipo atacante con Cain.

[5] - Para finalizar el ataque, simplemente pulsamos en el botón con la imagen de icono amarillo y veremos como la víctima (10.0.0.4) está siendo poisoning (evenenada) por un tráfico ARP reply no proveniente del gateway con la MAC de este (xx:xx:xx:xx:6600), si no con la MAC del atacante (xx:xx:xx:xx:1F:71), suplantando así esta dirección en la caché de la tabla ARP de la víctima.

Figura 7: Iniciando el evenenamiento ARP de suplantación MAC con Cain.

[6] - Si ahora, con la APR ya en ejecución y la caché de la tabla ARP de la víctima ya envenenada realizamos una consulta arp -a podremos ver en el PC de la víctima que la dirección IP de la gateway (10.0.0.1) y la dirección IP del atacante (10.0.0.3) se mapea o redirige a una única misma dirección MAC, que es la del atacante (xx:xx:xx:xx:1F:71).

 

Figura 8: Consultando la tabla ARP de la víctima una vez suplantada.

Una vez realizado el ataque Man in the middle utilizaremos un sniffer de paquetes de red como puede ser Wireshark.

[7] - Con Wireshark a la escucha de la transmisión de paquetes de la red, y filtrando solo tráfico HTTP con consultas a métodos POST (de envio) en su URL. Para así caputar inicios de sesión y obtener en texto plano (Plain Text) el nombre de usuario y contraseña de páginas NO cifradas HTTP. En este ejemplo muestro un user y password del login de la página web oficial de "es.Wikipedia.org" como ejemplo.

http.request.method == "POST". 

Podemos ver que el user es "AdrianLois" y la password es "zonasystem123".

Figura 9: Filtrando tráfico con Wireshark desde el equipo atacante para interceptar las credenciales.

[8] - Filtrando el tráfico capturado por el protocolo MSNMS (MSN Messenger Service) podremos ver la dirección de correo de la víctima como también la dirección email del usuario que establece la conexión con la víctima.

• La dirección de email de la víctima es la dirección destino 10.0.0.4, que se muestra como "xxxx...5[at]hotmail[dot]com".
• La dirección de email del usuario/a con la que establece comunicación la víctima es la dirección destino que figura como 64.4.44.26 y que vemos como "xxxx...a[at]hotmail[dot]com".

Figura 10: Filtrando por el protocolo MSNMS para capturar la dirección e-mail de la víctima.

[9] - Las conversaciones que se establecen mediante el protocolo MSNMS utilizado para las conversaciones a tiempo real por medio de mensajería instantánea (IM - Instant Menssaging) con MSN Messenger. Estas conversaciones pueden ser capturadas en texto claro, ya que este protocolo NO cifra las comunicaciones.

Así podemos observar como la dirección IP de la víctima (10.0.0.4) envió un mensaje instantáneo con el escrito "ola q tal".

 

Figura 11: Interceptando conversación de MSN messenger.

En la segunda entrega de esta entrada, explicaré un poco: usos no adecuados o con malos fines, usos legítimos y como prevenirse de técnicas y tools de este tipo de ataques Man in the middle y la suplantación de direcciones MAC.

Saludos!