El ataque del hombre en medio escenificado

Las cenas de empresa de Informatica64 suelen tener momentos únicos que tienen algo de valor incalculable. De hecho, una vez pasada la cena, se habla del MVP de la cena de ese año. Ese MVP es el protagonista del hecho más destacable.

Entre las acciones que han quedado para la historia y la leyenda negro está el momento en que uno se llevó para el camino los restos de embutido y una botella de vino tinto de la cena que solicitó al camarero le envolviera amablemente. En otro año uno decidió que un esturión que estaba disecado en la pared tenía frío y se quitó los calcetines para taparle, colocándoselos en plan preservativo. Y así... año tras año algo sucedía.... pero este año el momento perdurará en mi retina por siempre.

Ataque de Spoofing

El año pasado ya fue digno de épica y el hecho había superado las ediciones antereriores. Hace un año faltó una persona y entre tres se encargaron de ir convenciendo a los distintos camareros de que sí había venido con lo que el camarero fue sirviendo la comida en el sitio que dejaron para él. Cuando el camarero venía le convencían de que había ido al baño, de que ahora venía, etc... con lo que al final se zamparon una cena extra entre tres personas. A la semana siguiente enviaron una foto para mostrar que él estuvo allí. El montaje estaba hecho con el Paint...como mucho.

Pero este años...Este año iban con la misma idea en mente, aunque sabían que estaban bajo vigilancia, así que sus oportunidades de realizar este “ataque de spoofing” eran pocas. Parecía que no se iban a salir con la suya pero...

Ataque de Man in The Middle

... quiso el destino que uno de los comensales de la cena decidiera pedir su entrecot más hecho y se lo entregara al camarero. A la vuelta, fue otro el camarero que trajo encapsulado la carnaca a la mesa de todos los comensales. Sin embargo, la carnaca venía sin cifrar y uno de los tres elementos que el año pasado realizó el ataque de spoofing, tenía activo el sniffer.

Cuando el camarero preguntó “¿de quién es ete entrecot?” él vio la oportunidad del ataque. El camarero había lanzado un mensaje de difusión que venía sin cifrar y por lo que se podía observar el filete venía sin firmar.

Ni corto ni perezoso el atacante apartó su plato con los hogs del corderaco que se había metido entre barriga y espalda para contestar: “Es mío”.

La víctima, el pobre camarero, decidió aceptar esa respuesta como cierta ya que la red estaba considerada un entorno de confianza. El atacante se había encontrado con un entorno vulnerable en el que se había enviado un filete sin cifrar por una red de difusión, en la que no se utilizaba ningún sistema de autenticación y había conseguido introducirse entre el emisor del filetaco y el receptor para interceptar el mensaje.

Una vez conseguido el entrecot el atacante tuvo que levantar el firewall porque empezó a recibir ataques de denegación de servio lanzados contra su brazo en forma de tenedor que llevaba desde otro de los usurpadores del año pasado. Este ataque le hizo perder medio token de filete en el reparto.

Análisis Forense

Sin embargo, el atacante fue detectado, ya que el emisor, al saltar el timeout, reenvió su entrecot-request al camarero. Éste contesto que había recibido un ACK del nodo situado seis sillas más allá y una rápida revisión del plato de logs demostró que allí se había producido una intrusión y que el en otra hora filete se había evaporado.

Mitigación del ataque

El ataque ya se había producido así que lo único que se podía realizar es disparar el plan de contingencia. El camarero tuvo que volver a crear un nuevo paquete y reenviar el entrecot-response otra vez para atender al cliente. El atacante, una vez detectado, fue desconectado del switch.

Conclusiones

La culpa ha sido de la arquitectura. El número de errores ha sido alto:

1.- El atacante se encontró el mensaje porque se envió por una red de difusión cuando debería haberse enviado directamente a la boca del emisor y no intentar buscar al propietario del entrecot-request mediante un mensaje de broadcast.

2.- El mensaje de entrecot-response iba sin cifrar y fue fácil de decodificar por cualquiera que tuviera un sniffer activo.

3.- La conexión venía sin firmar con lo que le fue fácil al atacante generar un validador estático que engañara a las víctimas.

Para resolver el problema el camarero debería haber apuntado quién le envió el mensaje entrecot-request y haber contestado con un mensaje directo de entrecot-request que no usara broadcast.

En segundo lugar el mensaje debería haber venido cifrado, es decir, oculto bajo una tapa opaca de metal que no permitiera a ningún osado atacante con el sniffer activo detectar el mensaje.

Por último, el camarero debería haber comprobado la identidad del receptor del entrecot.

Este ataque, con IPSec o SSL, no hubiera pasado...

Saludos Malignos!

PD; ¿Pasa esto sólo en i64 o es común en todas las cenas?