lunes, diciembre 15, 2008

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?

10 comentarios:

Darth Kiwi dijo...

Impresionante el ataque, pero ante un buen chuleton pocas medidas de seguridad valen.
Y despues de la carne se uso software etilico libre (tambien llamado botellon) o codigo propietario algo mas carillo (copazos a 12€)??

CentOS manic Monday dijo...

cagondios que frikis que sois jajajajaja

Es lo que pasa por no usar IP Tunnels para paquetes de semejante importancia, para otra ya verás como el emisor del entrecot-request le pide hasta el certificado SSL al camarero ajajjaaj

Mi cena de empresa el Miércoles, creo que voy a acabar yo solo con la reserva federal de Lambrusco, reza por mi..

saludos!

Wi®

CentOS dijo...

offtopic.... whoooops,ni el wordpad se libra...

http://www.kb.cert.org/vuls/id/926676

Anónimo dijo...

Jajaja que bueno.

Me ha impresionado las pocas medidas de seguridad que toman algunos camareros, aunque claro con semejantes ataques ... muy bueno.

Desconciencia dijo...

impresionante , simplemente impresionante, nunca se me ocurriria un simil tan bueno para las cenas de navidad , mira que mi profesor de redes se empeña en decirme que no todo se puede asemejar a la vida real , pero dia tras dia queda demostrado que si.
enhora buena por tu blog

un fiel seguidor en la sombra!

hiltion dijo...

Jejeje, de esta manera a cualquiera se le puede explicar un ataque de spoofing para que lo entienda.

Y menuda jeta, el tipo!

Tendréis que ir perfeccionando los ataquescena-navideños para la del año que viene.

Aquí estaré por estas fechas en un año, esperando una nueva entrega :P

Ah, y felices fiestas

Trancek dijo...

k jeta tienen algunos xDD, seguro que alguna vez lo habras hecho tu "sin querer" ejej

Juan Irigoyen dijo...

Joder, yo creo que tenéis un virus en toda regla, el antivirus "vino tinto 1.0" que estáis utilizando no funciona muy bien, este debe estar alojado en la Fat, yo probaría con un "Vega Sicilia v.95"...

En cualquier caso, como os veo poco preparados te puedo dejar mis datos, estaría encantado en echaros una mano con todos estos problemas de seguridad.

Mikelats dijo...

A ver si se hace una quedada general como el año pasado que menuda envidia dan esas comidas y/o cenas llenas de frikismo.

@Juan Irigoyen,
¡Coño!,
No serás de la Sociedad Abendaño ¿no?
Si no lo eres, tienes un doble navarro con el mismo nombre, apellido e informático de profesión.

¡Feliz Navidad a tod@s!

Ariel M. Liguori dijo...

JAJAJa, pasa en todos lados! Que buana analogía xD !!

Saludos

Eleven Paths Blog

Seguridad Apple

Entradas populares