martes, 27 de diciembre de 2011

¿Piensas que tus conversaciones de Skype son privadas?

En una charla con un nivel bastante divultativo, Stefan Burschka contaba un estudio realizado conjuntamente con su estudiante Benoît Dupasquier sobre la posibilidad de identificar el contenido de una convesación de VoIP cifrada por Skype.
Resulta que a pesar de que las conversaciones sobre VoIP de Skype están cifradas, tiene una relativa debilidad: que tiene una tasa de paquetes constante con el tiempo. Esto permite establecer correlaciones entre la longitud del paquete y el contenido de voz al que corresponde.
Mediante un algoritmo denominado "Dynamic Time Warping" se puede además conseguir que la correlación se mantenga independiente de la velocidad a la que habla cada persona En concreto, se puede ver en esta figura sacada de su paper la baja correlación que tienen dos frases diferentes y abajo cómo se detecta una alta correlación con la misma frase.

Además, mediante un filtro de Kalman se puede conseguir que la detección sea independiente del hablante.

Eso sí, por ahora la detección tiene una tasa de éxito del entorno del 66%, y sobre un conjunto de frases predefiinidas...
O sea, que una agencia gubernamental (y Stefan trabaja para una empresa de defensa suiza...) con suficiente capacidad de CPU y un corpus de voces sobre Skype puede probablemente tener una idea de lo que hablas. Claro que a veces a mí también me gustaría saber qué es lo que dice la persona con la que estoy hablando por Skype, y eso que yo sólo tengo que usar mis oídos, especialmente cuando uso el WiFi del congreso, que debe de dejar pasar dos de cada tres paquetes o así.
El ataque es relativamente fácil de mitigar... basta con rellenar los paquetes con unos cuantos bytes aleatorios (los ceros no valen, como hemos visto en otras charlas), lo que destruiría esas correlaciones.

Suplantación de identidad en GSM

Karsten Nohl, conocido de otros años junto con Luca Melette, ha vuelto a impactar en las inseguridades de la red GSM, comenzando su presentación por una demostración de suplantación de identidad en GSM, habilitada por la debilidad de la cifra A5/1 actualmente utilizada por muchos operadores para cifrar las comunciaciones digitales de los teléfonos de segunda generación.
En esa demostración, ha sido capaz de demostrar la capacidad de establecer una llamada de origen falso (aunque no ha demostrado que la llamada luego pueda enviar voz) y un SMS originado falsamente suplantando un teléfono inocente que pasaba por ahí.
El problema está en que hay basantes medidas de mitigación que se pueden aplicar, pero muchos de los operadores aún no las están aplicando:
  • Randomizar el relleno de los paquetes GSM (que son de longitud constante y hoy se rellenan con ceros o contenidos constantes -- 0x2B).
  • Autenticar cada llamada (en lugar de una vez de vez en cuando, lo que permite reutilizar una clave capturada en una llamada anterior en una llamada siguiente.
  • Y lo que sería la mejor solución, pero la más complicada: Utilizar cifrado A5/3, que es más seguro que el actual A5/1 (que ya está abierto y las herramientas de descifrado libremente disponibles desde el año pasado).
La charla terminaba con una llamada a la accción, por un lado creado un registro de las capacidades de seguridad de los diferentes operadores a lo largo del mundo, y por otro lado para aquellos que sospechen que podrían estar siendo intervenidos, una herramienta, el "Catcher Catcher" que permite detectar los intentos de intervenir una llamada con los ataques de suplantación, localización e interceptación conocidos.

Los tiempos heroicos: el Atari 2600


Empieza (para mí) el congreso con un recuerdo de hacks de otro tiempo: la consola Atari 2600.

La descripción de hardware y la manera de programar nos lleva a las épocas de los “verdaderos programadores” que hacían programas con 128 bytes de RAM y 4k de ROM. Y cuando se les agotaba, se inventaron los bancos de RAM o ROM que se iban cambiando a base de escribir en un registro. Supongo que de aquí a la memoria virtual no había más que un paso… :-)
Pero en realidad eso es lo más sencillo, cuando Sven Olli ha pasado a contar cómo se dibujaba la pantalla es cuando se empieza a percibir la verdadera habilidad de los programadores:  la señal de TV no se obtiene de un banco de RAM para toda la imagen (demasiado cara en aquel momento, Sven ha citado que 1k de RAM valía lo que 1G hoy), sino que se genera a partir de la descripción de dos medias líneas, a base de un patrón de fondo y cinco “sprites”: dos jugadores, dos misiles y una pelota (lo indispensable para programar un juego de pong y un juego de combate de tanques).
Para dibujar la pantalla, hay que ir cambiando lo que hay en cada línea a medida que el haz va dibujando la imagen la pantalla… ¡contando los ciclos de cada instrucción! (bueno, también hay instrucciones que te ayudan a sincronizarte con el borde izquierdo de la pantalla o con un temporizador). Y por si fuera poco, si se quiere que la mitad izquierda sea diferente de la derecha o su imagen especular, hay que cambiar el contenido de la línea sobre la marcha...
La verdad es que con estos requisitos, parece mentira que se hayan podido desarrollar versiones de Donkey Kong o El Imperio Contraataca, o el detalle que podemos ver esta foto de la presentación.

Y para saber más, es cuestión de descargarse el emulador Stella y unas cuantas ROMs clásicas y ¡a jugar!

Preparándose para sobrevivir tras las líneas enemigas...

Bueno, otro año más vamos a recoger los Frutos del Caos. Este año la misión será más difícil que otros, porque es necesario recolectar tras las líneas enemigas...



Pero aún así, parece que no va a haber que luchar contra elementos, frío ni nieve: el pronóstico es que no va a haber nieve y poco frío (para lo que es Berlín).

sábado, 29 de enero de 2011

Depurar conexiones HTTPS

Tienes una aplicación Internet que no funciona y los mensajes de error no ayudan... ¿qué se puede hacer?

Pues se arranca Wireshark, y se puede ver las conexiones de la aplicación, si las peticiones funcionan, si hay respuestas incorrectas. No siempre ayuda, pero la mitad de las veces te permite arreglarlo.

¿Pero qué pasa si la comunicación es HTTPS? Bueno, está cifrada por lo que el analizador no nos va ayudar demasiado... pero he aquí que hay otras posibildades. Han hecho falta tres o cuatro búsquedas de Google, pero al final es posible.

La cuestión está en conseguir un proxy especializado en intercepción de conexiones HTTPS. Parece ser que no es muy difícil. Hoy estaba usando Mac OSX, por lo que es levemente más difícil, pero Burp Proxy me ha funcionado a la primera. Hay bastantes alternativas, por lo que he visto, pero ¿para qué mirar más?

¿Cómo funciona? Se arranca la aplicación, se cambian las opciones del navegador para que utilice proxy para HTTPS, usando la dirección del programa, 127.0.0.1:8080, y en la pestaña de proxy aparecen todas nuestras peticiones, seguramente descifradas para la depuración que se quiera hacer.

Para que funcione cómodamente, la propia aplicación genera un certificado falso para cada página web, basado en una autoridad local generada localmente. No hay más que confiar en esa autoridad para siempre... y ya está toda nuestra seguridad perdida irremediablemente y sin esfuerzo adicional. Por lo que no hay que olvidarse de borrar el certificado una vez se haya acabado...

La aplicación tiene múltiples otras opciones que puede aplicar por conexión, interviniendo las peticiones, las respuestas... pero ¿quién querría usar eso para depurar?