Volvemos a la carga con una nueva entrada de la serie #MundoHacker, donde tratamos en varios tutoriales las medidas para atacar y/o defenderse en el mundo digital.
A grandes rasgos, un ataque Man in the Middle o MITM sucede cuando el atacante hace de puente entre la conversación de dos o más terminales, desviando el canal de emisión a uno propio, lo que en la práctica le permite obtener cualquier información que esté circulando.
¿Qué es un Man in the Middle o MITM?
Hablar de MITM sin hablar del protocolo de resolución de direcciones, y más concretamente del ARP Poisoning, no tiene sentido, así que empezaremos por ello.
El protocolo de resolución de direcciones o ARP es el método que tiene una máquina de comunicarse con otras. Para ello, y siempre y cuando hablemos de un dispositivo conectado a una red, dicho terminal preguntará siempre que así lo necesite dónde se encuentra la dirección IP del terminal con el que quiere comunicarse mediante un ARP request a la dirección de difusión de la red. Esa máquina, u otra (según la arquitectura, todos o algunos de los terminales conectados en una red están escuchando) responde con la dirección pedida, y ésta queda registrada en una memoria caché de la primera máquina.
Un ARP Poisoning es uno de los métodos más comunes de ataques a redes, y que permite llevar a cabo un MITM. Lo que se busca es que el caché de la máquina o máquinas que queremos registrar tengan como dirección MAC la del atacante, y mantengan la dirección IP real de una de las máquinas de la red. Con esto, todo el tráfico que circule por esa red en dirección a esa IP (o no) pasará antes por el terminal atacante, y podrá ser leído, modificado o borrado.
Los ataques Man in the middle o MITM no solo se usan entre terminales conectados en la misma red, sino que también podría usarse para comunicaciones en varias redes mediante routers.
Existen variantes a este tipo de ataques, como el que nos podemos encontrar cuando un atacante cambia la información de conexión de alguno de nuestros navegadores, redirigiendo la navegación por internet según le complazca.
Cómo podemos defendernos de un Man in the Middle
Existen varios métodos para defenderse de un Man in the middle o MITM, aunque por lo general, el mayor problema es enterarte. Para ello, existen algunas posibles efectos que hay que tener en cuenta, aunque ninguno es 100% efectivo, y habrá que recurrir a software o a un análisis ARP para saberlo a ciencia cierta.
- Una de las primeras señas que nos podemos encontrar es que alguno de los terminales conectados a la red LAN atacada puede mostrar un mensaje como el que acompaña estas palabras. Si alguna vez habéis administrado una red, sabréis que lamentablemente esta situación se acaba sucediendo más de lo esperable, y por lo general es debido al fallo humano, pero si hablamos de una red (como por ejemplo la de una empresa) que lleva tiempo funcionando sin problemas (se supone una buena arquitectura detrás), podría servir de aviso.
- En este caso, lo primero que deberíamos hacer es realizar una consulta RARP (protocolo de resolución de direcciones inverso), que nos devolverá para la dirección MAC pedida, qué direcciones IP hay. En una red normal no debería haber clonación de MAC, por lo que en caso de que hubiera dos o más IPs en la misma MAC podría tratrarse de un ataque. El administrador de red es el que tiene la última palabra en este sentido (hay situaciones donde la clonación de MAC es necesaria para la arquitectura de red buscada).
- Existen programas que escuchan en las redes, y envían un mail al administrador cuando una entrada ARP cambia. Quizás en este caso el más conocido sea ARPWatch, para sistemas Unix.
Pero si lo que queremos es una defensa a posibles ataques MITM, existen dos métodos:
- Tablas ARP estáticas: Los MITM existen gracias al ARP Poisoning, y éste gracias a que el caché ARP se actualiza dinámicamente. Para evitar esto, bastaría con que las tablas caché de ARP sea estática. Pero como todo en esta vida, no es la panacea, ya que si el caché es estático, cualquier cambio en la dirección de uno de los terminales tendrá que ser actualizada a mano en todos los demás, por lo que este método, aunque infalible, solo se usa en redes pequeñas, fácilmente operables por un único administrador.
- DHCP snooping: El protocolo de configuración dinámica de host hace exactamente eso, ofrecer dinámicamente una configuración a cada terminal. Por tanto, el caché ARP carece de sentido, al ser el propio terminal de red el que al recibir un paquete DISCOVERY con la petición, devuelve otro OFFER con una configuración IP que no se esté usando en ese momento, quedando toda la información almacenada (anterior MAC, tiempo, paquetes enviados,…). En esencia, este tipo de arquitectura es más segura y cómoda (ya que se actualiza sola), por el simple hecho de que un nuevo terminal es fácilmente reconocible en el historial, pero tiene asociado otro ataque como puede ser el de la clonación de DHCP, esto es, montarse un DHCP falso conectado en red que conteste a las peticiones DISCOVERY. El que primero conteste (el falso o el verdadero) será el que administre la configuración de los terminales. Afortunadamente, dos DHCP activos cantean mucho, y bastaría activar Wireshark (u otro software de registro semejante) para ver qué IPs devuelven OFFER.
________
Puedes ver más artículos de esta serie en #MundoHacker, donde tratamos en varios tutoriales las medidas para atacar y/o defenderse en el mundo digital.
Y si el contenido que realizo te sirve para estar actualizado en tu día a día, piensa si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.
Os dejo un artículo super interesante sobre esta nueva amenaza TI. Ha sido publicado el en el Blog de Kaspersky Lab . Habla justo de un ataque man-in-the-middle. Un saludo
Muchas gracias por el enlace Natalia ¡Se agradece!
Relacionado con este tema… conozco el caso de una empresa que instala en los ordenadores un certificado propio (da error de local issuer certificate al tirar contra github, npm, etc…) para hacer un man in the middle, romper el cifrado SSL de los usuarios/trabajadores y según ellos “mejorar el filtrado y la seguridad”. Esto me lleva a pensar que, si miro mi correo o entro en mi banco desde mi ordenador del trabajo (cosa que, hasta donde yo sé, es legal), ellos vean los tokens de autenticación al estar usando ese certificado propio para romper el cifrado SSL entre mi banco y yo.
El caso es, ¿es legal que una empresa haga ésto?
Depende del país donde operen. Yo no soy abogado, pero me da que eso en España es ilegal ya que son datos personales y la GDPR es de ámbito europeo.
Otra cosa es que haya por ahí alguna otra excusa para saltárselo (en plan que en horario de trabajo y desde los dispositivos de la compañía la empresa tiene por razones de seguridad derecho a saber qué ocurre).
Supongo que al final lo que prima es el derecho del usuario, pero por si acaso consúltalo mejor con un abogado especializado en temas digitales.