Defensa contra un Man in the Middle (MiTM)

Pero tío qué has fumado... de qué estás hablando??

Métele a Materazzi encima, verás que bien lo defiende

(Pongo esto porque se ha equivocado de hilo ¿eh?)

Yo hace mucho tiempo que no toco estas cosas pero creo que el SSL lo que hacía era cifrar los datos con algún algoritmo simétrico tipo RSA. Hay que tener en cuenta que con RSA y una clave de 1024 bits , con los ordenadores actuales se tardaría miles de años en descifrar el mensaje en cuestión. Realmente no evitas que un intruso recoja la información, pero no tendrá manera humana de descifrarla. Aunque creo recordar que había maneras de evitar también que un desconocido violase el tema de la confidencialidad, el no repudio y la autenticidad, con cosas como el hash por el ejemplo, que no es más que la firma digital.

Es un procedimiento sencillo aunque quizás algo confuso. Como se suele hacer en estos casos supongamos que hay una persona (Bob) que quiere comunicarse con otra (Alice) de de manera segura y una tercera (Eve) que controla completamente el canal de comunicación y quiere espiarles. Alice tiene una clave privada asimétrica que la identifica, y Bob tiene la clave pública de Alice (y como es pública, Eve también la tiene)

1) Antes de nada, Bob genera aleatoriamente una clave simétrica que es la que se utilizará para cifrar todas las comunicaciones posteriores con Alice.
2) Bob cifra la clave simétrica con la clave pública de Alice, con lo cual sólo ésta puede descifrarla.
3) Bob envía la información. Eve la captura, pero como no tiene la clave privada de Alice no puede descifrarla y no tiene ni idea de lo que contiene.
4) Alice recibe la información. La descifra con su clave privada y obtiene la clave de cifrado simétrica que Bob ha generado.
5) Alice inicia la comunicación con Bob cifrando el mensaje con la clave simétrica.
6) Eve también captura este envío, pero como tampoco tiene la clave simétrica para descifrarlo se come los mocos
7) Bob recibe el mensaje y lo descifra con la clave simétrica.
8) Se repiten los pasos 5-7 en ambas direcciones. Eve puede tener el control total sobre el canal de comunicación, pero sin la clave privada de Alice no puede conocer la clave simétrica de cifrado, y sin ésta no puede extraer ninguna información útil.

Ahora sustituye "Bob" por "cliente", "Alice" por "servidor" y "Eve" por "man-in-the-middle" y ya tienes (a grandes rasgos) como funcionan los protocolos del tipo SSL y cómo evitan que se puedan espiar las comunicaciones seguras.

Creo que tu duda más que el método en sí del ataque man in the middle es el entender cómo se puede solucionar un problema que afecta a un nivel inferior de la torre de protocolos OSI, por medio de un nivel superior.

Piensa por ejemplo en el protocolo IP, nivel de red (nivel 3). No es orientado a conexión, no asegura la entrega ordenada de paquetes, y no tiene control de errores. Básicamente, es una puta mierda de protocolo Sería una tortura por ejemplo navegar por internet "a pelo" sobre el protocolo IP.

Sin embargo, si al protocolo IP le montas encima el protocolo TCP de nivel de transporte (nivel 4), que es orientado a conexión, tiene control de errores y asegura la entrega ordenada, solucionas todas las carencias que tiene IP. Ya que el protocolo que va por encima, se encarga de llevar un "control" sobre los paquetes IP que se van enviando y recibiendo, los mete en un circuito virtual, y les va haciendo un control de errores.

Con el man in the middle es similar, actúa a nivel de enlace como has dicho, pero si le pones un protocolo de nivel superior (en este caso SSL) que te asegure la privacidad y autenticación, por mucho que haya un man in the middle no podrá hacer nada aunque reciba todos los mensajes, porque tu clave privada es necesaria para descifrar los mensajes, y el man in the middle no la tiene.

como se pueden detectaR? yo he dejado mi red abierta unos dias y lo he probado y es super facil hacerlo... y salen paginas web visitadas, conversaciones del msn etc etc... yo uso ettercap para el ataque y wireshark para analizar el trafico en el mac ejeje salu2!!!!

pablos93 escribió:como se pueden detectaR? yo he dejado mi red abierta unos dias y lo he probado y es super facil hacerlo... y salen paginas web visitadas, conversaciones del msn etc etc... yo uso ettercap para el ataque y wireshark para analizar el trafico en el mac ejeje salu2!!!!

Ainssss, me estáis recordando al funesto examen de redes2 de este junio mamones!!!

Muy interesante el hilo

Creo que te lo han contestado ya perfectamente.

Aunque sea de un nivel superior, los datagramas en el nivel OSI se van encapsulando uno dentro de otro de mayor capa a menor. Hasta que llegan al nivel físico que es el que manda 0 y 1 por la red.

Entonces aunque consigas hacer un Man In the middleen nivel 2 Enlace, lo único k podrias ver son las cabecerás Ethernet (o PPP que no creo que sea el caso) y las cabeceras ip puesto que todo lo demás quedaría cifrado con SSL..

Puedes probar en tu red local encriptar algo con SSL, o conectarte a un servidor web mediante SSL y con el Wireshark tratar de ver los paquetes. Verás que salvo las cabecerás, lo demás va todo cifrado, con lo cual podrías capturar los paquetes, pero nunca descifrarlos.

Salu2

Gracias a alsaan y a Det. Pero sigo teniendo una duda:

Segun leo en la wikipedia, la clave simetrica comun se negocia mediante Diffie. Diffie es vulnerable a MiTM, por definicion, de modo que si M negocia una clave simetrica con A (llamemosla x) y otra simetrica con B (llamemosla z), A piensa que se esta comunicando con B (de hecho, se comunica con B) pero lo esta haciendo a traves de M, porque los extremos no estan autentificados (¿se dice autenticado o autentificado?)


De hecho, segun tengo entendido, la unica forma de protegerse ante un MiTM es mediante un Secure Port (o similares) en los routers, por eso me parece tan raro que se afirme que con SSL se evita el ataque, y tampoco entiendo para que empresas como Cisco han implementado el Secure Port si con SSL ya se evita el ataque.

Al hilo de lo que dice Det, que conocia, sigo sin entender que a la hora de cifrar un paquete se detecte el MITM. Si M esta en medio desde la negociacion de claves, puedes engañar a ambas partes. ¡¡Gracias de verdad!!

El único problema del Man In The Middle es que esté en una vía estrecha de 1 solo carril y sentido. Si fuera de 2 carriles, aún puedes pasar sin atropellarlo, o golpeándolo ligeramente con los retrovisores.

Para el proceso de intercambio de claves simétricas se utiliza algún algoritmo de tipo asimétrico para asegurar este intercambio de datos. Además SSL se introduce como una especie de capa adicional (por decirlo de alguna manera) entre la capa de aplicación y la de transporte, estableciendo comunicaciones seguras a nivel de socket (identifica máquina y puerto). SSL realiza un cifrado de alto nivel de los datos que se intercambian (se cifran hasta las cabeceras HTTP).

Secure Port no sabía lo que era pero por lo que he leído se ve que básicamente es asignar un puerto a la MAC de un dispositivo de forma estática. Eso supongo yo que será por algunos inconvenientes que se dan al utilizar SSL, a saber:

Autenticidad: SSL requiere para su funcionamiento la identificación del servidor Web ante el cliente y la realiza adecuadamente, pero normalmente no se produce una identificación en sentido contrario. Es decir, no es obligada en la mayoría de los casos la presencia del certificado del usuario que se está conectando al servidor.

Confidencialidad: SSL proporciona una buena seguridad de que los datos no van a ser capturados por extraños de forma útil en el proceso de transferencia de los mismos, pero no proporciona ninguna seguridad después de finalizar la conexión.

Integridad: ocurre algo parecido a lo anterior. En el corto proceso que dura el envío de datos sí podemos estar seguros de que éstos no van a ser modificados, puesto que SSL lo impide. Pero una vez que finaliza la conexión segura no podemos estar tranquilos.

No Repudio: en este aspecto SSL falla al máximo, ya que no hay por defecto establecido ningún método para dejar constancia de cuándo se ha realizado una operación, cuál ha sido y quiénes han intervenido en ella. SSL no proporciona formas de emitir recibos válidos que identifiquen una transacción.

Para finalizar, comentar que no existe el mecanismo de defensa perfecto en cuestiones telemáticas, sino que más bien se emplean las que mejor se ajustan a cada caso concreto, combinándose entre sí para proporcionar toda la seguridad posible, pero que nunca será del 100%.

Cancerber escribió:Segun leo en la wikipedia, la clave simetrica comun se negocia mediante Diffie. Diffie es vulnerable a MiTM, por definicion, de modo que si M negocia una clave simetrica con A (llamemosla x) y otra simetrica con B (llamemosla z), A piensa que se esta comunicando con B (de hecho, se comunica con B) pero lo esta haciendo a traves de M, porque los extremos no estan autentificados (¿se dice autenticado o autentificado?)

El protocolo Diffie-Hellman como bien dices no protege contra un MitM, sólo sirve para evitar el eavesdropping (espionaje pasivo).
Si existe la posibilidad de un ataque de este tipo se deben utilizar otros métodos de intercambio de claves, como puedan ser los certificados digitales, que autentifican* al menos a una de las partes.


*Según la RAE ambas formas son igualmente válidas. A mí me suena mejor "autentificar"

powerline escribió:Autenticidad: SSL requiere para su funcionamiento la identificación del servidor Web ante el cliente y la realiza adecuadamente, pero normalmente no se produce una identificación en sentido contrario. Es decir, no es obligada en la mayoría de los casos la presencia del certificado del usuario que se está conectando al servidor.

Una vez establecida una conexión segura el servidor puede usar perfectamente un sistema de autentificación básico basado en nombres de usuario y contraseñas. No lo veo un problema.

powerline escribió:Confidencialidad: SSL proporciona una buena seguridad de que los datos no van a ser capturados por extraños de forma útil en el proceso de transferencia de los mismos, pero no proporciona ninguna seguridad después de finalizar la conexión.

Integridad: ocurre algo parecido a lo anterior. En el corto proceso que dura el envío de datos sí podemos estar seguros de que éstos no van a ser modificados, puesto que SSL lo impide. Pero una vez que finaliza la conexión segura no podemos estar tranquilos.

Una solución hardware tendría también estos problemas, y de hecho no creo que un protocolo de transporte de datos deba preocuparse de estas cosas.


Lo del Secure Port parece que sirve para restringir los dispositivos que se pueden conectar a un router/switch según su dirección MAC, pero no tiene nada que ver con las comunicaciones seguras.

Ya lo voy pillando. En cualquier caso, SSL protege "en principio" de un MitM, pero se me ocurre algo como crear un certificado falso de forma que Alice acepte la conexion con Mallory pensando que lo hace con Bob. Es Mallory quien se comunica con Bob mediante un canal seguro y Mallory retransmite la informacion a Alice en su otro codigo.

Todo esto suponiendo, evidentemente, que hablamos de negociacion de clave simetrica mediante RSA. Es mas seguro que con Diffie, claro, pero engañar a un usuario con un certificado creo que es bastante sencillo...

Que por cierto, yo si que veo Secure Port como la solucion al MitM. Si solo puedes tener una mac determinada por cada puerto del router, al entrar MAC2 por el puerto esperado para MAC1, o entrar MAC1 por un puerto no esperado, la conexion se rechaza. Es algo asi como autentificar a nivel de enlace (aunque evidentemente se pueden cambiar las direcciones fisicas).

Hombre, normalmente los certificados digitales vienen firmados con la clave privada de alguna entidad certificadora de confianza (como VeriSign), por lo que es difícil que Mallory pueda falsearlos. Puedes intentar engañar al usuario colándole un certificado sin firmar, pero eso ya depende de cómo sea el usuario y de la aplicación que esté usando. Por ejemplo, los navegadores actuales te avisan claramente y te advierten del peligro cuando te encuentras con un certificado no válido.



Secure Port parece que está orientado a evitar el ARP Poisoning en la red local, más que a garantizar comunicaciones seguras. El "man-in-the-middle" no tiene por que estar en tu misma red local, perfectamente puede encontrarse entre el router y el punto de destino, desde donde puede interceptar y manipular fácilmente cualquier transmisión no cifrada. Además, es dificil gestionarlo cuando tienes muchos equipos en la red (o con ordenadores portátiles) y tampoco sirve para redes inalámbricas.
Está bien tenerlo, es una capa de seguridad más, pero si no se acompaña de otras medidas (como el uso de protocolos cifrados) no sirve de mucho para garantizar la confidencialidad de las comunicaciones...

Perfecto, ya lo entiendo del todo. De todas maneras, es lo que queria decir, igual a ti no te la cuelo, pero a la mayoria de la gente le sale la ventanita de certificado digital y acepta para ver la web, porque no lo entiende. Pero esto ya no es un fallo de SSL sino de idiotez humana, claro

Y si, Secure Port es para evitar el poisoning en Red Local. Claro que no habia pensado en la posibilidad del MITM fuera de la red local, y es la opcion mas logica. Todo esto viene a que el otro dia aprendi que se puede controlar el trafico de una red cableada con switches, algo que me parecia imposible (y en principio asi deberia ser), y fijate todo lo que he aprendido...

De verdad que muchisimas gracias, alsaan. Seguire preguntando