miércoles, 30 de diciembre de 2009

26C3: Here be Dragons

Para cerrar el congreso, un par de expresiones artísticas que decoraban el entorno



Un dragón que decoraba la sala de fumadores, también conocida como chill-out (¿o era al revés?)

Cuando uno llegaba al BCC, le recibía este heredero del blinkenlights



Heredero, porque las animaciones de color se podían cargar desde el teléfono móvil, como se hacía con el blinkenlights grande, aunque claro, en tamaño es mucho menos espectacular.

Y en el bar, estaba este juego de lásers dibujando sin manchar las paredes

Cacharreos varios

Además de varios cacharros que ya estaban en años anteriores, como los cuadrópteros,



este año había dos cacharros nuevos que me llamaban la atención:
  • el primero, este tipo de segway que es capaz de mantenerse a sí mismo en equilibrio sobre dos ruedas (los humanos lo hacemos todo el trato sobre dos pies... :-).


Se puede ver en acción en su medio natural aquí:


  • La segunda versión de virtuosismo robótico está en esta caja, que se sostiene a sí misma en equilibrio sobre una esquina, a base de mover el peso que está en diagonal.

Para cuando no hay tiempo de comer bien: nueces de Brasil

La verdad es que este año, la masificación ha puesto mucha presión por conseguir un sitio para ver las conferencias. De hecho, yo hasta he considerado la posibilidad de alimentarme de Nueces de Brasil (que en Brasil se llaman castañas del Pará, pero que en realidad se cultivan en Bolivia).


Esto es una de las mayores bombas calóricas que he visto: esa bolsa completa tiene 1340 kcalorías, con una bolsa casi no es necesario tomar nada el resto del día.
Pero claro, la mejor manera de evitar estos agobios es quedarse en casa y ver las charlas en diferido...

Virtualización para ejecución controlada de binarios maliciosos

En mi última charla, se ha descrito la plataforma secuBT (la charla del AS/400 ha sido cancelada :-( ), orientada a la traducción de binarios para poder ejecutar código malicioso en un entorno seguro.

La plataforma utiliza traducción dinámica de código, en la que se van traduciendo los bloques de instrucciones a medida que es necesario ejecutarlas y las mete en una cache, de acuerdo al siguiente diagrama, de modo que los bloques de código sólo se traducen cuando van a ser ejecutados

Respecto a la protección, se obtiene por dos circunstancias:
  • Por un lado, todo el código traducido tiene privilegios menores que los de la librería del sistema
  • Por otro lado, todas las llamadas al sistema son chequeadas y traducidas dentro del entorno virtualizado
Para que funcione a una velocidad razonable, el programa introduce optimizaciones en la eficiencia de traducción y en la de ejecución.

Respecto a la eficiencia de traducción, tras evaluar la posibilidad de tener una traducción a código intermedio que luego se optimiza, se decidieron por la estrategia más sencilla de tener una tabla de traducción para el código, que es simple y rápida.

Respecto a la eficiencia en la ejecución, el programa introduce optimizaciones en múltiples sentidos, como ejemplo se han contado algunas de las posibles implementaciones de las llamadas indirectas (ya que todas las instrucciones que afectan al flujo de control se tratan de manera especial), para intentar disminuir su peso (la traducción estándar requiere sustituir esa única llamada por treinta instrucciones):
  • La implementación estática se traducen por una llamada con cache, de modo que se compara el destino con el anterior de esta misma llamada y si coincide no se ejecutan el resto de las comprobaciones, y su eficiencia depende de la tasa de aciertos.
  • En las llamadas dinámicas, se utiliza una tabla de hash para las direcciones "permitidas", y si se encuentra en esa tabla, tampoco se hacen todas las comprobaciones
El hecho de utilizar la traducción dinámica se traduce en la posibilidad de endurecer la seguridad con la que se ejecuta el programa:
  • Forzar la protección frente a ejecución en zonas de datos, como el heap o stack. Aunque los procesadores de Intel tienen esta funcionalidad, no todos los SO la tienen habilitada.
  • Comprobar todas las cabeceras ELF.
  • Proteger todas las estructuras de datos internas, utilizando mprotect para proteger todas las escrituras a memoria a las estructuras del entorno, salvo cuando se está ejecutando código de la propia máquina virtual.
  • Interceptar todas las llamadas al sistema, tanto para permitirla, denegarla, devolver un valor artificial o traducirla a una llamada a código de usuario que haga lo que queramos. Por ejemplo, para hacer creer al código que tiene privilegios de root (de lo cual se incluía una demo).
Todas estas medidas ofrecen protrección frente a los tres tipos más clásicos de problemas: la ejecución de código en el stack / heap que ha llegado ahí mediante un heap overflow, el retorno a libc y o la restritura de la dirección de retorno, de los cuales se ha incluido una demo en la charla.

Por último se ha presentado un estudio de las prestaciones del programa, y en media, la traducción introduce una ineficiencia de un 7%, que sólo sube a un 9% cuando se activan todas las medidas de protección de memoria y de filtrado de llamadas del sistema.

La librería se puede encontrar aquí.

Y la nieve llegó a Berlín

Por primera vez en varios años, la nieve vuelve a caer sobre Berlín


y en el CCC (en Berlín cae siempre, pero a veces no coincide)



Lo cual me recuerda a una de las transparencias de la presentación de ayer de Fnord:


martes, 29 de diciembre de 2009

PKIs: DNSSEC vs. X.509

Como el año pasado, una de las charlas estelares era la de Dan Kaminsky, tanto que muchos nos quedamos a todo el noticiario de Fnord en alemán (para practicar) para no perder nuestro sitio (este año he notado mucha más escasez de sitio en las charlas que en el CCC pasado, y las entradas también se han agotado el primer día -- posiblemente incluso a primera hora).

La esencia de la charla era que podíamos eliminar los passwords y los actuales certificados que usamos para seguridad (en SSL, IPSec y en algunos casos hasta en SSH), y sustituirlos por una aplicación global de DNSSEC como repositorio de autenticación y certificación.

Respecto al tema de los passwords, citaba una estadística de Verizon en la que el 60% de los problemas de seguridad estaban relacionados con ellos.

Para eliminar los problemas, citaba dos aproximaciones:
  • Forzar el uso de claves más seguras, imponiendo controles estrictos de seguridad
  • Aceptar que una limitación fundamental es que hay que almacenarlos en la memoria humana, cuya capacidad es bastante limitada en media, y sustituirlos por claves de alta seguridad criptográfica, que se pueden almacenar en tarjetas de memoria protegidas por claves más sencillas.
Tras estudiarlo Dan ha llegado a la conclusión de que lo que nos ha fallado en el intento de coseguir este último objetivo es X.509, el estándar actual de certificados que se usa en SSL, IPSec, en casi todo lo que lleve seguridad (p.e. aplicaciones firmadas) menos en SSH.

Para explicar los certificados, ha recurrido a una analogía más sencilla, que son los pasaportes: podemos aceptar el contenido de un pasaporte como cierto porque nos fiamos del esfuerzo que emplea el gobierno que emite el pasaporte en evitar las falsificaciones. Un certificado es igual, sólo que en vez de papel es electrónico, las firmas se aplican cifrando con una clave privada un extracto ("hash") del contenido y es una compañía llamada Autoridad de Certificación (CA) la que da la fiabilidad de ese documento.

Los problemas que Dan ha presentado con los certificados X.509 son:
  • Más de la mitad de los certificados que se utilizan en servidores SSL en el mundo no sirven para nada, porque están firmados por los autores del contenido (como si Dan se pusiese a hacer pasaportes...)
  • Una buena parte de las CA basan la fiabilidad de los certificados que emiten en usar el DNS y el Whois (que también consultan por correo electrónico que se basa en el DNS). Por tanto, la seguridad de esos certificados es tan buena o mala como el sistema de DNS (que ya sabemos de charlas anteriores que no es fiable).
  • Y las CA que utilizan procedimientos más estrictos (verificando documentos de papel y registros oficiales) se ven penalizadas porque sus procedimientos son más complejos para hacer lo mismo y al final todos los navegadores aceptan todos los certificados, por lo que su producto es idéntico.
Comparando DNSSEC con X.509, el primero tiene ventajas respecto a:
  • La capacidad de excluir a los participantes que no ofrecen servicios fiables, ya que DNS tiene raíz única, un único registro de datos para cada dominio de segundo nivel, pero a la vez competencia en los proveedores de servicios que manejan el proceso de incluir datos en el registro. Esto permite que el registro de datos puede excluir registradores que no tengan la calidad suficiente. Frente a eso, nadie controla la raíz de los certificados X.509, y la única posibilidad de determinar qué certificadores son fiables es crear una entidad de certificación privada con los criterios deseados, lo cual es costoso y lento (aunque, por ejemplo, el ejército americano ha sido capaz de hacerlo).
  • La capacidad de delegar, que es intrínseca en DNS, pero que en X.509 está muy mal implementada, a pesar de que X.509 es increíblemente complejo precisamente para permitir la delegación. La opción de delegación para firmar subdominios no está implementada correctamente en casi ningún lado, y la única opción práctica para delegar hoy en día es crear autoridades de certificación delegadas, que pueden firmar cualquier certificado.
Y para entretener un poco más a la audiencia, todo ésto se veía salpicado de diferentes vulnerabilidades de seguridad detectadas en X.509, como:
  • El uso de caracteres nulos de terminación dentro de los nombres certificados para que aparezcan como pertenecientes a otro sitio
  • El uso de múltiples nombres dentro de un certificado, que crea ambigüedades respecto a lo que se ha certificado, y que permite que mientras la CA firma una cosa, el navegador piensa que ha firmado otra
  • Y por último, una prediccion de un problema que aparecerá tarde o temprano, relacionado con un certificado raíz de Verisign que no expira hasta 2028, y que está firmado con una función de hash insegura, MD2 (antecesor de MD4 y MD5, los más usados hoy en día y también vulnerables). Un ataque a MD2 que permita crear un contenido con el mismo hash, permitiría hacer pasar cualquier cosa como firmada por Verisign. ¿Por qué no nos ha pasado todavía? Porque la complejidad de ese ataque a MD2 ha disminuido ya hasta ser de un orden de magnitud de 2^73 y la capacidad actual de ataque todavía es de sólo 2^63. ¿Cuánto tiempo nos quedará?
  • Ambigüedades en la codificación de los OIDs de ASN.1 que podrían permitir ataques de overflow de modo que las firmas parecen ser de un CN mientras que en realidad se han obtenido firmando otro atributo.

Ataques a terminales con una red GSM emulada

Otra charla más sobre ataques de GSM, complementaria de la más famosa donde se desvelaba el ataque a la cifra A5/1, fue la de Harald Welte sobre el uso de Open BSC para emular una red GSM y a base de enviar mensajes incorrectos desde la red, comprobar la robustez de los terminales a mensajes malformados. Harald fue el que el año pasado comentó acerca de sus primeros pasos con Open BSC para crear una red GSM de prueba basada en una BTS comprada en eBay.

En la charla, además de una introducción a GSM parecida a la del año pasado, se contó una actualización del estado de Open BSC, que ya está operativa, y además de la BTS de Siemens de la que habló el año pasado también soporta una picocelda de ip.access: nanoGSM, a la que se conecta por el interfaz A-bis sobre IP (mucho más fácil de usar).

En este momento soporta señalización, voz y mensajes cortos, y de hecho durante toda la conferencia se mostraba el log del programa y se podía ver cómo los usuarios enviaban los mensajes cortos. De hecho, puede ser un buen sustituto de los teléfonos DECT que se usaban hasta ahora para la comunicación dentro del CCC congress. Desafortunadamente no conseguí registrar el mío a tiempo ... :-( Para el futuro, se trabajará en la implementación de GPRS/EDGE, MMS y UMTS, con lo que se podrá comprobar la seguridad de los protocolos más relevantes de las redes móviles hoy en día.

Este es uno de los puntos que Harald mencionaba sobre los posibles ataques a los teléfonos: que tienen tantos protocolos y opciones que apenas se usan que casi seguro que están llenos de problemas de seguridad, porque es un código que se usa poco. Además también mencionó que muchos teléfonos utilizan el último TMSI (el número local que sustituye al número universal IMSI cuando el usuario se conecta a la red, para evitar la localización de alguien a base de escuchas pasivas) recibido cuando hacen roaming en una nueva red y que casi todos los teléfonos se mueren al recibir mensajes incorrectos, por lo que es muy probable que estén plagados de agujeros de seguridad.

Respecto a los ataques a los terminales, en la charla se contaban los métodos empleados: poner un proxy en el interfaz A-bis sobre IP (el que usa la nanocelda), con un par de puertos UDP para recibir los mensajes inyectados, que se generan a base de implementar los protocolos de GSM en scapy, y como los datos por ese interfaz sólo se envían cuando hay una llamada establecida, Open BSC utiliza una opción propia denominada "llamada silenciosa" que establece una conexión con un terminal móvil pero sin realmente efectuar una llamada, y por ahí se envían los paquetes inyectados y borrosos. Aunque se citaba que se está probando desde agosto con 860 teléfonos, no se hizo ninguna demostración de ninguna vulnerabilidad específica encontrada... (igual es que a pesar de todo no hay muchas).

Mitigación de DDoS y botnets

En charla de mitigación de ataques de denegación de servicio y botnets, Rodent, de Las Vegas, que aloja irc.2600.net y Beave, fundador del Deathrow OpenVMS server, nos hablan de su experiencia mitigando los efectos de estos ataques, basados en su propia experiencia, ya que según ellos, siempre que pongas algo en Internet, te encontrarás con este tipo de ataques, y más en el caso de lo que se pone en Internet sea una BBS, un foro o un servidor dejuegos.

Resumiendo mucho la charla, las estrategias de mitigación empiezan por tener las herramientas adecuadas para hacer el trabajo que se tenga entre manos antes del ataque, y en general en Internet eso implica casi lo mismo si se trata de una BBS casera o de un ISP grande:
  • Tener las herramientas adecuadas para dar el servicio, lo cual incluye tener servidores, firewalls y conexiones adecuadas para el servicio que se quiere dar (es decir, un modem ADSL de 30€ probablemente no sirva para el trabajo, incluso si tiene OpenWRT.
  • Tener la gente adecuada para el servicio, incorporarlos gradualmente de modo que se les pueda llegar a conocer, que sean fiables, y que sean el número adecuado (ni muchos ni pocos).
  • Hay que monitorizar, tener herramientas que vigile, graben y avisen cuando hay problemas de modo automatizado.
  • Tener el soporte adecuado de los proveedores: el operador, los fabricantes de los equipos. Y ponerles a prueba, preguntarles qué van a hacer en caso de problemas y qué tiempos de resolución se pueden esperar. Y pensar en la recuperación de desastres.
Una vez ha comenzado el ataque, ellos proponen tres estrategias diferenciadas:

Aguantar el ataque

Esto en general implica mitigar el ataque en lo posible, monitorizarlo para saber cuándo se acaba y en general poner las medidas de defensa adecuadas para que el servicio siga funcionando. En este punto hay que tener en cuanta algunos matices:
  • Al igual que en muchos casos, conviene no ofrecer tratos a los atacantes. En su experiencia esto nunca funciona, ya que los atacantes no son capaces de respetar los pactos, ni siquiera entre sí.
  • Adaptar la respuesta defensiva al ataque, sin usar todas las posibilidades de defensa al principio. De este modo, se entra en una escalada de conflicto que cansa también al atacante y le hace pensar que atacar es mas difícil de lo que pensaba.
  • Hay que tener en cuenta que a veces puede ser interesante tener piezas sacrificables ("low hanging fruit"). Un servidor fácil de tirar pero que no es crítico para el servicio puede permitir al atacante sentirse vencedor sin afectar al servicio, siempre que el crea que no es así.
Reportar lo monitorizado

Esto implica que se tienen o activan los sistemas de monitorización y registro (de acuerdo con la política de privacidad que se tenga, o que hay que tener publicada), como tcpdump (pero hay que tener cuidado en la máquina en la que se hace que tenga cpu y disco duro suficiente).
Aunque reportarlo significa ponerlo en conocimiento del gobierno, agencia gubernamental o cuerpo de policía correspondiente, en general también se puede reportar también a la comunidad apropiada o los investigadores de seguridad que trabajen en ese campo (puso como ejemplo a shadowservers.org e infragard.org).

Ser proctivo

En este caso se refiere a atacar a los atacantes. Esto quizá es más fácil de decir si eres parte de 2600.net que por parte de otros, y mucho más asequible si los atacantes son simplemente aficionados o "script kiddies". Se comentan varias técnicas clásicas a utilizar:
  • Ingeniería social: casi todos los aficionados caerán ante su deseo de presumir del ataque conseguido.
  • Conocer sus métodos, y usarlos en su contra. Esto en general puede llegar a implicar aplicar ingeniería inversa a su botcode
  • Difundir los eventos, de modo que otros sepan lo que pasa (esto en general era el objetivo de la charla)
Todo ello con mucha precaución, sobre todo respecto a tu identidad si hay la posibilidad de que alguno de ellos sean profesionales. Tor es una herramienta muy adecuada para esto, ya que tiene un nivel razonablemente alto de anonimato. A este respecto, para distinguir unos de otros ha mostrado el criterio de que usualmente los kiddies usan irc, mientras los profesionales utilizan páginas web y P2P para controlar sus botnets.

Charlas relámpago (3)

Bueno, es el número 3 pero eso no significa que haya asistido a las dos anteriores. Estas charlas son como un congreso dentro del congreso, unas son anuncios, otros proyectos en la fase inicial, pero en general siguen la famosa frase de la película "Forrest Gump": la vida es como una caja de bombones, no sabes qué es lo que hay dentro.
  • Servando Barreiro: ha mostrado sensores plug & play que son detectados como joysticks por los ordenadores, y que vende en minitronics.net
  • Pollock+Casbon: Where does my money go?, una página que permite ver el presupuesto mediante un sistema de visualización visualmente atractivo (aunque el prototipo todavía es un poco lento en un netbook).
  • Pareja: ha presentado un dispositivo Open RFID Tag, que permite hacer todo tipo de ataques a dispositivos lectores RFID, no sólo los más comunes de 13,5 MHz, sino también los de baja frecuencia 125 KHz. El dispositivo pequeño y pasivo (funciona con la alimentación del lector). Y se lo puede hacer uno mismo, ya que toda la información está disponible en la web con GPL.
  • schleuder: (en español: columpio) es un gestor de listas de correo encriptada on OpenPGP. Puede mejorar la privacidad y oscuridad de los que envían el correo. Es independiente del MTA (exim, sendmail, etc.). Identifica a los usuarios por la clave PGP, no por la dirección de correo, y por tanto permite pseudonimicidad. Se puede administrar por correo y opcionalmente por web.
  • Chemeris: ha presentado ClockTamer, una fuente de reloj de alta fiabilidad, que pueden ser usados en OpenBTS y airprobe (mejor que USRP que sólo tiene un reloj fijo de 64MHz). Tiene un montón de opciones, y aunque actualmente tiene una precisión de 0.28 ppm aislado, puede conseguir 50 ppb sincronizado al GPS, y podría bajar a 1 ppb cuando den con el algoritmo adecuado.
  • Sylwester: una implementación de Chiptunes en un microcontrolador supersimple (el DAC es un puente resistivo y se alimenta de 5V) pero que produce música.
  • Deubeuliou: una distribución de debian pensada para ser ejecutada en teléfonos móviles basada en gnome llamada hackable:1, que supongo que querrá competir con Android y el iPhone... y se podrá ejecutar en un teléfono OpenMoko.
  • Richard: WAFP, Web Application Finger Printer, una aplicación que descarga todos los ficheros estáticos de una aplicación web, los compara con una base de datos y determina cuál es la aplciación que hay detrás de una página web concreta.
  • Steil: presentó un traductor de binarios llamado libcpu, que cuando esté completo permitirá ejecutar binarios de otros ordenadores en una máquina Linux genérica (por ahora funciona para M68k y 6502)
  • Ge0rG: libhomebrew, una bilbioteca para facilitar el portado de aplicaciones a consolas de juegos "hackeadas".
  • Ge0rG: YAXIM - OSS Jabber on Android , un cliente de jabber para usar en Android, para cuando se quiera huir del software de Google para usar mensajería instantánea...
  • hackable-devices, una página para ser capaz de encontrar ese hardware libre que haga falta para cualquier necesidad. Toda la organización está basada en software libre.
  • Boltz: el Atari Coldfire Project, que tiene como objetivo crear un ordenador compatible con Atari, con ya 18 meses de existencia y ya tienen un primer prototipo que funciona ¡a pilas! (curioso que cuelgan del dominio atari.org).
  • Fundación nlnet: busca proyectos abiertos que financiar sobre internet y redes, tanto grandes como pequeños, asistencia a eventos, bajo el principio de "hackers para hackers". Y además proporcionan el dinero rápidamente, en 5-6 semanas. ¡Dinero gratis! La verdad, debe de haber pocos proyectos que merezcan la pena.
  • Assaf Nativ: sobre maneras de hacer trampas en juegos flash, para conseguir puntuaciones altas y luego venderlas, por ejemplo. Ha contado hasta 5 maneras: abriendo la aplicación con un depurador y buscando tu puntuación para cambiarla, hay que tener en cuenta que a veces está multiplicada por ocho. O con un programa llamado r4zcheater, que utiliza el API de Adobe para depuración. Quitando la aleatorización del juego buscando llamadas al generador de números aleatorios. Ralentizando el juego. Decompilando el fichero SWF, con programas como el Sothink. Utilizar OCR y bots para que jueguen por ti.
A partir de aquí son en alemán
  • La Hochschule Bremen se presenta como una universidad para educar hackers, mediante su programa educativo NETS-X, que intenta presentar los desafíos normales de un profesional de la seguridad informática.
  • Korrupt: Smoker Synchronisation que ha presentado un protocolo para sincronizar las pausas de fumar de todos los trabajadores, mediante Skype y varias primitivas de comunicación (SYN, ACK y ACK+n) y flags (+/-c cigarrillos, -t tabaco, etc.).
  • Thorsten Bremer: Una presentación sobre posibilidades de mejor protección de nuestros datos personales, más allá de lo poco que ofrece la ley (alemana). No me he enterado demasiado de qué quieren hacer.
  • Sobre el grupo www.terminal21.de, que quiere construir (literalmente, con ladrillos y demás) un hackerspace en una ciudad que llama Sala (Halle), cerca de Leipzig.
  • La sesión ha concluido con una presentación de Florian sobre los Geeks famosos en la historia, que según él han sido: Arquímedes, Herón de Alejandría, Al-Chwarizmi, Leonardo da Vinci, Tesla y Alexander Fleming.

Jugando con las ciudades

En esta charla, Eleanor Saitta ha intentado comunicar cuáles son los problemas de las ciudades actuales y posibles intervenciones sobre ellas para mejorarlas.
La verdad es que para ser la primera charla del día, la he encontrado un poco dura, sobre todo la parte teórica de crítica del capitalismo que invade nuestras ciudades (y que tiene pinta de ser la fuente de todos sus males. Todo esto aderezado de nueva terminología como imaginarios y "affordances" (no conozco que tenga traducción).
Sin embargo, a la hora de la sugerencia de intervenciones, me han parecido todas bastante interesantes y/o divertidsas, muchas de ellas ya conocidas (aquí hay muchas referencias en español), y alguna otra que no conocía (y la verdad, no habría estado mal que la presentación tuviese alguna foto...).

Intervenciones físicas:
  • WiFi público semi-legal
  • CCTV para los ciudadanos: se trata de que sean los propios ciudadanos los que controlen las cámaras de vigilancia y las utilicen para protegerse de la policía... basado en que países como Estados Unidos la policía no debe de ser de fiar, supongo.
  • Carriles de bici "hágaselo uno mismo": Se trata de coger la pintura adecuada, informarse de cómo se pinta esto de manera profesional, con ropa de trabajo, etc. Parece ser que debe de haber sido hecho en alguna parte.
  • Mobiliario urbano: añadir mesas o sillas, o una hamaca a la ciudad. O darle la vuelta a un banco, para hacerlo más útil...
  • Jardines guerrilleros: Se trata de hacer crecer vegetales en solares vacíos. O cubrir los edificios de cemento cubierto de hiedra.
Eventos:
  • En el transporte público, está la anécdota del grupo de teatro que colgó columpios en el Metro de San Francisco y animó a que los pasajeros lo usaran. Y las tardes de té, aunque esas no las ha explicado en demasiado detalle.
  • Juegos públicos en la ciudad: Aquí también había ejemplos de San Francisco, como por ejemplo: Journey to the end of the night (del cual hay una versión este fin de año en Berlín), o SFZero.
  • Parking day: crear un parque en una plaza de aparcamiento durante un día.
  • Espacios de arte temporal, aprovechar la crisis para pedir gratis, sitios que no tienen todavía un inquilino para hacer exposiciones de arte alternativo (que no tendrían sitio en una galería convencional).
  • Café inflable: Crear un tercer espacio (ese sitio que no es ni casa ni el trabajo) pero rápidamente y de bajo coste a base de usar estructuras inflables.

lunes, 28 de diciembre de 2009

Ataques a SS7

El día ha terminado con una charla acerca de ataques posibles a la red SS7 y su transporte sobre IP, SIGTRAN.
Tras una introducción a SS7, su arquitectura (centrado en el uso en las redes móviles, ya casi nadie habla de las redes fijas...), los sistemas de intercepción legal y toda una serie de debilidades que ya se han reportado este año sobre la red GSM, la charla se ha enfocado en el núcleo de red, donde se usa SS7 para el establecimiento de las llamadas telefónicas y el envío de mensajes cortos.
Ahí se han presentado nuevas maneras de comprobar la seguridad con la aparición del transporte del SS7 sobre IP (SIGTRAN), que permite el transporte de SS7 sobre redes IP (aunque en general, SIGTRAN nunca se transporta sobre Internet). El protocolo base que transporta la señalización sobre IP se llama SCTP, un protocolo de transporte con más funcionalidades de fiabilidad y robustez que TCP.
Una de las primeras herramientas para probar este protocolo ha sido desarrollada por el autor, SCTP Scan, y permite hacer lo equivalente a nmap (o portbunny) y detectar servidores SCTP que pueda haber en una red.
Otra herramienta presentada (y también desarrollada por el autor) era ss7calc, una calculadora para las direcciones de los puntos de control SS7, los códigos de punto, que se representan en hasta tres formatos incompatibles y no siempre es fácil saber cuál se usa (aunque en la charla se ha demostrado que sí es fácil conseguir los valores y sus asociaciones -- porque los publica la ITU, facilitando el trabajo de averiguar la estructura global de la red SS7).
Estas herramientas son sólo el principio de todas las que son necesarias, ya que aunque permiten escanear a nivel de SCTP, todavía quedan por probar todos los niveles superiores hasta el de aplicación (movilidad, localización, llamadas, SMS, red inteligente...).
La charla ha ido muy deprisa en la parte más técnica, pero ha llegado a enumerar varios ataques posibles a una infraestructura SS7 que se facilitan si se obtiene el acceso IP a esas redes:
  • IAM attack: enviando muchos paquetes IAM (los que se envían cuando un usuario pide llamar a otro), como éstos reservan un enlace, rápidamente la capacidad de enlaces de las centrales se acaba y se quedan bloqueadas sin poder establecer llamadas (es el equivalente al SYN flood)
  • REL attack: inyectando un mensaje REL (el que se produce cuando el usuario cuelga la llamada) se pueden colgar cualquier llamada en curso.
  • SRI: el mensaje Send Routing Info permite obtener la localización geográfica de un usuario.
  • Roaming: enviando un mensaje de que un usuario está en otro país diferente al averiguado en el paso anterior, se puede hacer que todas sus llamadas se envíen a ese país para ser descartadas silenciosamente.
  • El último vector de ataque, aún casi todo por explorar son las Femto celdas: pequeñas estaciones base que se conectan a un router ADSL para ampliar cobertura en el hogar. Como tales, si no estuviesen suficientemente protegidas, se podrían abusar para enviar cualquiera de los mensajes anteriores. Y según él, resulta que algunos no están demasiado protegidos...
  • Entrelazada con la charla, el conferenciante ha contado la anécdota de cuando estaban probando a hacer ataques a una red e informaron al cliente operador que pensaban que no habían conseguido hacer nada y la red era segura, la compañía les reveló que habían tirado la pasarela de intercepción legal, que no era parte de la prueba pero estaba conectada a la misma red (y a continuación recibieron presiones de muchas partes para revelar la debilidad...), dejando a las fuerzas de la ley sin capacidad de intercepción en un día.
Mis llamadas telefónicas cada vez están menos seguras... Voy a tener que pasarme a Skype.

Direcciones IPv4 okupadas (mientras queden)

La penúltima charla del día trata de la posibilidad de abusos en la asignación de direcciones IP y números de sistema autónomo (AS).
Originalmente, ambos se asignaban liberalmente, pero a medida que Internet se hizo más complicado hubo que introducir burocracia. Actualmente las direcciones se asignan mediante un sistema jerárquico en que los niveles superiores, denominados RIR (entidades sin ánimo de lucro que reparten las direcciones a los ISPs siguiendo principios acordados por todos de agregación, conservación y unicidad -- no estaría bien que dos personas tuviesen los mismos números).
La información que manejan estas entidades están almacenadas en una base de datos replicada denominada whois, cuyos diferentes objetos explicó nibbler.
Hay varios tipos de debilidades en esta base de datos que han sido ilustradas:
  • Protección de objetos con métodos de cifrado débiles (éstos ya están obsoletos y siendo cambiados)
  • Hay objetos realmente antiguos, de antes de que se formalizara la burocracia, en los que la política respecto a la transición no está escrita y está abierta a abusos, como por ejemplo un caso que mostró en el que se hizo con cuatro números AS sin demasiado problema.
  • En otros casos, los objetos no tienen protección de seguridad, y una persona con suficiente determinación puede tomar posesión de ellos (como una empresa denominada AlphaCron que tomó posesión de un bloque de direcciones /16 (65k direcciones) inicialmente asignados a American Express).

Atacando teléfonos con SMS

Hoy en día, hay un montón de teléfonos que han sido atacados y vulnerados por la parte del sistema operativo, el acceso a Internet y todas sus funcionalidades más avanzadas, que al ser más complejas son más difíciles de asegurar. Pero la charla de Collin Mulliner se centra en los ataques mediante la parte telefónica, que suele tener un procesador separado y especializado que sólo se conecta al general por una conexión serie.

Como dice el autor, el principal peligro de problemas en esta parte es que no es fácil poner un firewall para protegerse de SMS malformados, y el ataque no requiere más conocimiento que el del número de teléfono (bueno, y posiblemente el modelo) del destinatario.

En la charla, se comienza por explicar la estructura de los mensajes SMS tal y como vienen del procesador de GSM al procesador principal a través de la conexión serie, que utiliza comandos AT para enviar los mensajes tal y como se han recibido de la red, lo cual habilita la posibilidad de muchos test de "fuzzing", mediante una librería desarrollada por el autor y un colega de una empresa de seguridad.

Pero queda un segundo problema: las pruebas. Hacer correr una herramienta de fuzzing sobre la red real sería prohibitivo, y aparte de lo que se ha contado en el congreso (que todavía está en desarrollo), no es fácil emular una red GSM. Por tanto, la segunda parte de la charla ha versado sobre la manera de enviar los mensajes "fuzzed" sin necesidad de pasar por la red, para identificar aquellos que tienen algún efecto en los teléfonos con tres sistemas operativos: iPhone, Android y Windows Mobile (para luego probar los que tienen efectos negativos en una red de verdad).

La solución empleada ha sido crear un nivel intermedio de software que simula el modem hacia la parte aplicativa del teléfono. Tiene la ventaja adicional de que permite crear un sniffer de SMS sin esfuerzo adicional.

El primer objetivo fue el iPhone, cuyo proceso llamado CommCenter maneja todos los SMS y las llamadas, que se ejecuta con privilegios de root sin "sandbox". El ataque consiste en inyectar una librería modificada en el proceso, que intercepta la llamada a "open" y que redirige el tráfico a un demonio, que además de pasar todo el tráfico hacia y desde el modem, envía los mensajes recibidos por WiFi de un PC, encargado de generar los mensajes.

Para detectar las caídas y los problemas se usan dos técnicas: por un lado se monitoriza la aparición de crashes en el programa CrashReporter y por otro lado se envían mensajes normales mezclados con los demás para ver que todo sigue funcionando correctamente después de cada mensaje mediante consultas a la base de datos de mensajes.

En Android es relativamente sencillo, cambiando de nombre el dispositivo y rearrancando el demonio que escucha a ese dispositivo se puede redirigir la entrada de mensajes a un proceso arbitrario... el poder del software abierto. La monitorización de crashes es sencilla mediante logcat y la monitorización de los mensajes recibidos es igual que en el iPhone porque también usaba sqlite. El primer resultado obtenido, es que el procesado de SMS con Android no es demasiado robusto, y era fácil bloquear el teléfono o el proceso de mensajes.

Para Windows Mobile es mucho más complicado, ya que se requiere escribir un nuevo serial driver que tiene el mismo interfaz que el driver original pero igual que los demás se comunica con el PC por WiFi. La monitorización es también más complicada porque hay que mirar dos procesos y ver que los dos siguen vivos tras el envío de los mensajes potencialmente malformados.

Después de desarrollar los tres entornos de pruebas y poner los teléfonos a prueba, se encontraron muchos mensajes potenciales, pero en muchos casos no funcionan a través de la red. Y hay mucha diferencia entre operadores ya que no todos aceptan todos los mensajes.

En concreto:
  • Para el iPhone, un mensaje que mate el proceso CommCenter, deja al teléfono totalmente incomunicado ya que no sólo bloquea las llamadas y los SMS sino también el WiFi y el Bluetooth. Si el mensaje sólo mata el proceso Springboard, el teléfono se queda 15 segundos fuera de la red. Colin contaba que en Defcon hicieron un ataque a un amigo, al que le mandaron mensajes como para dejarle sin servicio durante 1 hora. Sin embargo, la red se vio tan saturada de mensajes, que aún estaba enviándolos al cabo de 2,5 horas (y por supuesto, el teléfono seguía incomunicado...). Un segundo ataque consiste en enviar 519 mensajes, uno cada segundo, que como son todos parte de un mensaje multiparte, al usuario le aparecen como uno sólo y que al final son capaces de ejecutar código (aunque no tienen todavía escrito ningún exploit).
  • Android: Un mensaje cualquiera enviado al puerto de WAP push mata el proceso com.android.phone, que es el que se comunica con el SIM, el teléfono se queda incomunicado, ya que requiere el PIN del usuario para acceder al SIM. Además, el teléfono falla silenciosamente (y una vez desconectado no recibe mensajes) y por tanto el usuario no se va a dar cuenta de que está incomunicado hasta que mire el teléfono. Esto sólo funciona en las redes europeas, en AT&T no funciona.
  • Windows Mobile: Se atacó el teléfono HTC Touch, y en ese caso si se envía un mensaje sms conteniendo %n, el proceso GUI (TouchFlo) se muere y no puede volver a arrancarse mientras el SMS no se borre de la bandeja de entrada (con las herramientas de SMS incluidas en Windows Mobile). Al ser previsiblemente el problema derivado de una sustitución de cadenas incorrecta, el problema debería ser explotable, aunque al no ser genérico para todos los Windows Mobile su amplitud es limitada. Sin embargo, la explotación de una vulnerabilidad tan simple se puede hacer con herramientas muy sencillas, como por ejemplo, directamente desde una cabina de teléfono (que ya casi todas permiten mandar SMS).
De todos modos, ya hay soluciones para todos los problemas en las últimas versiones de los tres sistemas operativos (bueno, salvo para el de los 519 mensajes).

Cuatro faustos para un Aleluya

Esta presentación está inspirada en un western de bud & spencer, cuyo título en alemán es algo así como "dos perros del cielo en el infierno", aunque el título en España fue más fuerte, muchachos. La idea es que Erdgeist y Felix von Leitner muestran todos los defectos de diseño en múltiples tecnologías informáticas, y no se libra nadie (aunque al estar en alemán, no todos los defectos son obvios):
  • El ejemplo básico de errores de diseño a los que se refieren es la página de Internet Explorer que dice: "ha ocurrido un error", pero no da ninguna ayuda útil para saber cuál
  • La tendencia actual de los firewall de añadir un nivel tras otro, de modo que un firewall moderno, no sólo tiene filtros a nivel de IP y TCP, sino que también sube y añade un firewall a nivel de HTTP, dentro de eso de XML y dentro de eso incluso uno de SQL...
  • Las cabeceras de HTTP, con su complejidad, verbosidad y dificultad de interpretar
  • La librería zlib que tiene un argumento que puede valer entre -8 y -15
  • MIME con la complejidad que le introduce la internacionalización y de los dominios y las cabeceras mediante diferentes tipos de codificación
  • FastCGI y en general las API de acceso a CGI
  • WAP
  • Las infinitas opciones y direcciones y funciones diferentes dentro del API de sockets, como cuatro tipos de sockaddr, así como todas los defectos de diseño del uso de select junto con ellos, hasta establecer una conexión TCP.
  • libc y su extraño manejo de la memoria en las funciones de cadenas.
  • Así como unos cuantos comentarios de reproche a la proliferación de tipos de datos de 16 bits en lenguage C (short, u_short y uint16, etc.) y a la proliferación de extraños y larguísimos nombres de variables y funciones (como CloseThreadpoolCleanupGroupMembers)
  • El API de OpenSSL que funciona todo a base de strings y requiere recorrerse los certificados X.509 a mano
  • El código para permitir extensiones de tipos y los horrores a los que da lugar en las diferentes versiones de la función wait
  • Las decenas de chapuzas que hay que hacer para internacionalizar el código (i18n)
  • Los nombres de NetBIOS y las APIs de SMB
  • X11 merecería mucho más de las dos transparencias que le dedicaron
  • Por terminar que esto está en todas partes, incluyendo las CPUs y las chapuzas derivadas de la existencia de los coprocesadores aritméticos x87 y su juego de instrucciones
Todo ello acompañado de grandes carcajadas del público en respuesta a las ironías en alemán que aún se me escapan en su mayoría...

Programación de microcontroladores AVR

Wesen, el autor de esta charla, utiliza sus microcontroladores fundamentalmente para crear controladores MIDI de código abierto.

Todo ello ha sido desarrollado sobre la plataforma Arduino como plataforma de desarrollo, donde todo el código ha sido cambiado para soportar sus desarrollos, basdos en metodologías ágiles (o incluso yo diría impacientes) y prototipado rápido.

No me extenderé demasiado en el contenido de esta charla, porque se centra mucho en los detalles de conseguir desarrollar software para un sistema embebido como es el Mididuino, optimizando el tamaño del código, la flexibilidad de programación con C++, el entorno de desarrollo con control de código, construcción automática, pruebas unitarias, sincronización musical y pruebas y depuración...

Videosintetizador basado en FPGA: Milkymist

La charla sobre Milkymist ha demostrado cómo se crea un ordenador de propósito específico mediante una FPGA.
El autor ha escogido desarrollárselo él mismo, debido a la ausencia de proyectos realmente abiertos que permitan el procesado y síntesis en tiempo real de video (a pesar de que sí hay otros proyectos de procesadores abiertoos en código fuente, como GRLIB, OpenSparc, OpenGraphics, Project VGA...).
El procesado de vídeo es difícil porque requiere la flexibilidad de una CPU pero la velocidad del hardware dedicado, la velocidad de una SRAM pero la capacidad de una DRAM.
¿Qué soluciones se han tomado?
Para el primero, se han creado 14 "pipelines" de interpolación lineal de triángulos, cuya coordinación está controlada por una CPU de propósito general.
Para el segundo, se ha utilizado una aproximación a base de ráfagas y una cache, de modo que la lectura de memoria se hace de cuatro en cuatro palabras consecutivas, que se almacenan en una cache, y como los algoritmos son rasterizados, tienden a usar pixels contiguos, y sólo hace falta una cache de unos 4KB por cada "pipeline".
Pero lo más interesante ha sido la información de cuáles son las herramientas necesarias para crearse un desarrollo basado en FPGAs uno mismo:
  • El hardware utilizado es relativamente asequible, una tarjeta con FPGA Xilinx ML401, que cuesta unos $500.
  • A eso hay que añadir simuladores gratuitos, para comprobar que el funcionamiento esperado de la CPU sintetizada es el esperado (como Icarus Verilog, GNU Cver y Verilator -- buggy), que son capaces de funcionar hasta en un EeePC.
  • Para la síntesis de las puertas, el software propio de Xilinx es adecuado, aunque sea cerrado.
  • Y por supuesto GNU/Linux como sistema operativo.
Mucha más información en la página del proyecto.

Ir a la luna con científicos a tiempo parcial

En esta charla, un grupo de "científicos a tiempo parcial" (en realidad son 33 personas de varios tipos de profesiones, que incluyen también ingenieros, economistas y tres personas del programa Apolo original -- y aún así vienen al CCC por si pueden conseguir cooperación de más) nos han contado cómo van a enviar una sonda a la Luna (parecida a las Opportunity y Spirit que están en Marte) para ganar el premio X lunar de Google.

Éste es uno de esos premios que se otorga para desafiar a la humanidad para superarse a sí misma, como el premio que se dio por atravesar el atlántico a Charles Lindberg. El premio de 20 M€ establece un objetivo a conseguir antes de llegar al final de 2012, con varios premios adicionales de bonificación (aunque hay algo más de tiempo con menos dinero de premio si se consigue antes del final de 2014): Llegar a la luna, moverse 500m y transmitir video HD hacia la tierra (lo llaman mooncast)

Bonuses:
  • Tomar una foto de un artefacto humano en la Luna (de otras visitas anteriores a la luna)
  • Detectar agua en la Luna (éste ya tiene menos sentido)
  • Moverse en la Luna una distancia de 5 kilómetros
  • Sobrevivir el la luna una noche lunar (que implica pasar 14 días a -160 grados centígrados, después de haber estado en el día lunar a 160).
La cantidad del premio ha tenido un impacto directo en el presupuesto del proyecto: el grupo ha estimado que pueden hacerlo por 15 M€, y se quedarían con 5M€ de margen... Como comparación, el presupuesto de la NASA para llegar a la Luna fue de 91 millardos de euros, la India ha conseguido orbitar la Luna recientemente por 64 M€, LCROSS ha llegado por 53M€, ambos con tecnología corriente. Así que actualmente lo que van a hacer es un desafío a la tecnología actual, pero ya se ha progresado bastante desde los años 60 y 70.

El plan para llegar a la luna tiene las siguientes partes:
  • Lanzar el cohete hasta una órbita terrestre baja (LEO)
  • Lanzar desde ahí a la Luna una nave más pequeña (el "Lander")
  • Hacer un aterrizaje suave
  • Comunicarse con la tierra
  • Y sobrevivir a la noche lunar
¿Cómo lo van a conseguir? Bueno, los puntos cruciales de su estrategia tecnológica son:
  • Sin cohete: van a usar a un proveedor barato de lanzamientos orbitales llamado Space X
  • Tecnología existente (no van a desarrollar nuevas tecnologías para ellos)
  • Bajo presupuesto (hay que ahorrar dinero)
  • Innovación
  • Sin tiempo (tienen que haber llegado a la lluna antes del final de 2012), la presión agudiza el ingenio.
  • No reinventando las vacas (aunque sí la rueda)
Después de establecer la estrategia, han entrado en más detalles sobre las diferentes partes del proyecto:

Cohete

Como decíamos, para el lanzamiento van a usar el cohete Falcon 1e de SpaceX con el que llegarán a una órbita baja, y tienen el objetivo de reducir el coste de lanzamiento por debajo de $10.000/kg. La carga que tienen que llevar por ahora la calculan en 1.010 kg, un 80% de combustible, y de eso, sólo 5kg es el Rover que se va a mover por la Luna.

Lander

Va a pesar unos 300kg, y van a intentar hacerlo despegar otra vez para volver a la tierra con una muestra (y tienen que hacerlo rápidamente, para que el motor no se enfríe). Han conseguido que otros les recuperen la muestra gratis, lo cual aparentemente tiene que ser costoso... supongo porque el aterrizaje será no controlado y con paracaídas.

CPU

Para simplificar componentes, piensan basarlo todo en FPGAs que van a hacer todo el control digital y analógico, certificadas de componentes de alta fiabilidad (lo cual implica que estará todavía un poco fuera de especificación, porque esto significa un rango de temperaturas de -55 a +125, que se queda un poco corto). Las comunicaciones estarán basadas en Ethernet como bus de control. Sí que tienen una implementación especial del almacenamiento en memoria Flash, para sobrevivir a fallos individuales y la radiación acumulada.

Lander

Éste ha sido la estrella de la noche, ya que hasta el CCC se han traído un prototipo, aunque aún no está hecho del material definitivo.



Como decía antes, recuerda mucho a los que se enviaron a Marte.

Para conseguir adaptarse a sus objetivos (llegar a recorrer 5km y sobrevivir a una noche lunar), y al entorno de la luna (con los cambios de temperatura y un suelo hecho de regolito, que es un material muy hostil), sus componentes fundamentales son:
  1. Cuatro ruedas independientes con dos motores: uno de propulsión y otro de dirección. Entre las cuatro suman 1kg
  2. Una torre para la óptica que permita tomar imágenes HD y encima estéreo, otro kg
  3. Un ordenador principal algo más ligero, sólo 0,5 kg
  4. Energía: con paneles solares y una antena de array 1kg
  5. Además de eso hay hasta 0,5 kg adicionales reservados para los socios y el resto es la estructura que lo sujeta todo, hasta llegar a los 5kg del presupuesto
Siendo el CCC, había que entrar a describir la capacidad del ordenador de a bordo, implementado sobre una FPGA Virtex4 fx20, incluyendo una CPU PowerPC 405, un controlador sata, 512 MB de RAM, dos interfaces gigabit ethernet, 5 canales de flash nand y muchas cosas más que no tuve tiempo de anotar.

Otro componente bastante avanzado es el panel solar, ya que integra las antenas de comunicaciones en array, en concreto una de gran ancho de banda para emitir y otra de menor ancho de banda para recibir comandos (al revés que todos nuestros ADSL, como corresponde a un generador de contenidos -- una cosa que no me ha quedado clara es quién se queda con los derechos de TV... que pueden valer más que el premio).

Otra de las intervenciones estelares de la presentación ha sido una llamada en directo a Jack Crenshaw, contribuidor habitual de la columna Programmer's Toolbox en la revista de sistemas empotrados "Embedded Systems Design" que trabajó calculando las órbitas en el antiguo progama de Apolo (empezó en 1959, nada menos), que contó su trayectoria desde el trabajo en la NASA hasta GE y su participación en este proyecto para ir a la Luna.



Una de las cosas que comentó y decía que sorprendía a muchos (incluyéndome) es que el cálculo de las trayectorias es relativamente sencillo, sólo se tarda minutos en hacerlo. Pero claro, es que si no, no se habría podido hacer en los '60, ya que los ordenadores de la época tenían poca memoria y poca CPU.

En este proyecto como no tienen que preocuparse de los humanos dentro de la nave, pueden utilizar trayectorias más directas (que no tienen posibilidad de segundas oportunidades o de abortar) y que tienen mayores fuerzas de gravedad, así como simplificaciones respecto al cálculo de la órbita.

La última parte de la charla ha descrito la estrategia de comunicaciones, que es bastante innovadora.

Para la comunicación con un dispositivo orbital, el principal problema es la atenuación de la señal con la distancia, que sigue una ley cuadrática, lo cual implica que por ejemplo, la potencia necesaria para llegar a la luna, que está 10 veces más lejos que los satélites de televisión, se requiere 100 veces la potencia.

En general, las comunicaciones con dispositivos distantes ya se pueden hacer, ya que no sólo hemos llegado a comunicarnos a los 400 Mm que nos separan de la luna, sino que hemos llegado a los 164 Gm a Marte, y los 16 Tm de la sonda Voyager 1 (con la que aún seguimos en contacto, parece).

Lo que pasa es que su objetivo es no tener que usar las soluciones habituales, que pasan por tener que usar una antena parabólica de decenas de metros y potencias industriales de emisión para conseguir anchos de banda moderados. Adicionalmente, tienen que tratar el tema de la visibilidad desde la tierra, que va a requerir tener varias de esas antenas, de modo que la conexión no se interrumpa al dar vueltas la tierra.

¿La solución?: desplegar múltiples antenas a lo largo de la tierra, todos conectadas a Internet, de modo que cada antena únicamente tenga que recibir y procesar una parte pequeña del espectro, de modo que la combinación posterior de las señales de todas, se consiga la capacidad necesaria, de la misma manera que si se se tuviese una antena de 30m de diámetro. Además, al estar distribuidas por todo el mundo, se soluciona a la vez el problema de la disponibilidad. Para hacer esto a un coste moderado, cada sitio estará dotado con una FPGA (que permite cambiar la frecuencia que se procesa en cada sitio, reprogramarla con los núcleos necesarios para la CPU y ejecutará GNU/Linux) y una antena parabólica, que van a intentar que sea una estándar de 90 cm.

Estado del proyecto OLPC

Es bueno empezar pronto, ya que las charlas están mucho menos masificadas, así que comienzo con la charla sobre el estado del proyecto OLPC, en la que Cristoph, de OLPC Austria y olpcnews.com ha actualizado a la audiencia sobre el estado actual de estos portátiles ultra portables, eficientes y baratos orientados a la educación digital de los niños de primaria alrededor del mundo.



Tras refrescar los principios básicos del projecto (que los niños posean el equipo, en educación primaria (6 a 11 años), 1 ordenador por niño de media en cada país, e incluir conectividad y software abierto en el ordenador) y las especificaciones del ordenador (que incluye bajo consumo y un display visible bajo luz solar), se pasó a comentar el estado actual.

Por un lado, el proyecto no ha llegado a cumplir algunos de sus objetivos originales, que se demostraron excesivamente ambiciosos:
  • El plan original de Nicholas Negroponte era no empezar a fabricar hasta que tuviese comprometida la fabricación de 10 millones de unidades. Al final no pudo ser, pero hoy en dia sí que hay más de 1 millon de XO-1 funcionando en el mundo.
  • El plan original planteaba un coste de $100. Hoy en día el coste es $188, en parte porque el volumen no ha alcanzado las previsiones originales. Sin embargo, se dice que el diseño de este ordenador está detrás de la aparición de los netbook, que hoy en día se pueden encontrar comercialmente por precios por encima de $300.
En el camino, también ha habido algunos malentendidos, como el momento en que Microsoft, en mayo de 2008, anunció que el XO-1 podría ejecutar Windows XP. Aunque al final sólo unos pocos miles lo usan, este anuncio hizo perder al proyecto una gran cantidad de apoyos por parte de la comunidad creadora de software libre.

La siguiente parte de la conferencia nos ha explicado el funcionamiento de Sugar, el interfaz de usuario del ordenador, pero que es más que eso, ya que es toda plataforma de software orientada al aprendizaje, estructurada en actividades en lugar de programas (escribir, navegar) y que incluye la posibilidad de colaboración con los vecinos para aprender y sistemas para "aprender haciendo".

Me ha parecido particularmente interesante la posibilidad de descargárselo para ejecutarlo desde una memoria flash USB. A ver cuándo tengo tiempo de probarlo...

Jugando con las previsiones que se han hecho para la siguiente generación de ordenadores en 2012, me pareció graciosa la descripción que hizo de las capacidades de la décima generación, el XO-10:
  • Producirá electricidad en vez de consumirla
  • Será capaz de imprimir dinero una vez que no ha podido bajar más su precio
  • Consumirá CO2 en lugar de producirlo
  • Podrá curar el cancer
  • Incluirá un dispensador de club matte
Por último, se ha visto la aplicación en dos estados de ejemplo:
  • Uruguay, medianamente desarrollado que se lo puede permitir y ha decidido entregar ese ordenador a todos sus niños, hasta un total de unos 400k OLPCs, a un precio medio de $274 TCO de 4 años.
  • Nepal, en la parte baja de los ranking de desarrollo, y que sólo se ha podido permitir hacer pilotos en 26 colegios llegando a 2.2k equipos (en una población de 28M de habitantes), pero sin embargo ha desarrollado muchas herramientas educativas por encima (como material educativo en nepalí, una biblioteca de 3-400 libros y una herramienta de creación de contenidos en HTML 5).
Por último, como en muchos otras, la charla ha terminado con una llamada a la participación, diciendo que lo que hace falta son profesores, tecnólogos y propagandistas ("twitterers").

domingo, 27 de diciembre de 2009

Claves para atacar el cifrado de la voz en GSM

Si hay algo que ha sido relevante este año en el CCC, han sido los ataques a GSM, y entre ellos la gran noticia ha sido el anuncio de la rotura de su cifrado en la charla de Chris Paget (con tacones de plataforma rojos) y Karsten Nohl.

La charla tenía en realidad dos partes, cada una sobre una de las dos principales debilidades de la red GSM, que es incluso más grande que Internet en términos de tamaño y nodos conectados.

En la primera parte, acerca de los ataques que posibilita el hecho de que el teléfono no autentique a la red y por tanto, se pueda poner una estación base emulada que haga creer a cualquier teléfono que se está conectando a la red de verdad y capturar todo su tráfico. Estos ataques tienen el inconveniente de que al ser activos, si alguien los busca, encontrará al atacante, a pesar de que normalmente, nadie los busca.

En realidad, las herramientas mostradas (el "Universal Software Radio Peripheral", USRP, junto con un software denominado OpenBTS que emula la parte radio de la red) son todavía capaces de ataques bastante rudimentarios, limitados a la captura de los IMSI, un número identificador del teléfono, que no es visible al usuario y que puede ser utilizado para ataques de denegación de servicio (no es posible suplantarle sin tener acceso físico al SIM, y aún así para suplantar a un usuario se requiere poner el SIM en un microscopio electrónico y dejarlo prácticamente inutilizable).

Pero lo que sí muestra es la evidencia de que en ausencia de pruebas de seguridad, los teléfonos existentes hoy en día tienen una gran cantidad de defectos en el software, y una gran vulnerabilidad a ataques:

  • Por ejemplo, aunque lo normal es que los iPhones no se conecten al OpenBTS, en USA se encontraron uno que insistía en conectarse a ellos, a pesar de que emitían como una red de prueba que no existe, emitían en una banda que en USA no se usa y usando la mínima potencia posible.
  • Otros teléfonos en China, una vez se habían conectado a OpenBTS cambiaban el nombre de la red, y luego ya no lo cambiaban al correcto a pesar de rearrancarlos completamente.
  • Otra vez por error respondieron con el mensaje utilizado para desactivar los teléfonos robados en lugar de para rechazar a los teléfonos y que no se conectasen a la red, lo cual daba lugar a múltiples estados con diversos estados de irrecuperabildad según los teléfonos (p.e., el iPhone requería desconectar la batería... una operación que en Apple requiere una visita al servicio técnico o desmontarlo totalmente).
Por último, también ha puesto en evidencia que aunque el capturador de IMSIs es una herramienta muy grosera y fácilmente detectable, ningún teléfono dispone de ningún mecanismo para saber que está conectado a un equipo de acceso impostor, y todos ocultan al usuario si debido a un ataque el teléfono está haciendo la llamda sin usar cifrado y por tanto la privacidad está comprometida.

La segunda parte de la charla ha tratado el tema mucho más peliagudo de los ataques pasivos (escuchando únicamente), en el cual se ha explicado cómo es posible descifrar el código de cifrado AS5/1, el que es utilizado en GSM para proteger la privacidad de las llamadas.

La motivación de Karsten para desarrollar este ataque y hacerlo público, es que el cifrado de GSM ha aparecido roto en muchos artículos de seguridad, pero en ninguno se había llegado hasta las últimas consecuencias, haciendo públicas las herramientas para descifrar el algoritmo..

El protocolo de cifrado AS5/1, tiene una clave relativamente pequeña (64 bits, igual que el DES que ya casi nadie usa), lo que lo hace vulnerable a un ataque de precomputación, en el que se calculan todos los resultados de cifrar un determinado dato con cada una de las claves. Lo que hasta ahora impedía hacer este ataque es que el tamaño de la tabla precomputada es de 1 Petabyte (y por tanto difícil de ocultar) y precomputar la tabla llevaría 100.000 años de una CPU moderna. Lo que Karsten ha hecho es encontrar una manera de precomputar las claves más sencilla y de almacenar la tabla de modo más compacto mediante tablas de cadenas arco iris modificadas.

Para la parte de computarlo más rápido, han utilizado tarjetas gráficas, que son muy eficientes para procesos en paralelo, por el cual son capaces de calcular 400 claves a la vez, además han hecho que cada cálculo procese 4 bits de cada vez, con lo que después de todo, sólo han hecho falta 3 meses de computación en 40 ordenadores con tarjetas gráficas Nvidia para completar el resultado. Aunque usando FPGAs podrían hacerlo más rápido, la escasez de buenos programadores de FPGA les ha hecho renunciar a ello.

Para la parte de comprimir los resultados en tablas de arco iris, Karten ha entrado en más detalle técnico, en el que ha explicado que el mecanismo básico de una tabla de cadenas es tomar un punto de entrada, aplicarle el algoritmo con la clave varias veces hasta llegar a un punto que se almacena en la tabla. Cuando se tiene un dato de entrada, se le aplica el mismo algoritmo (en este caso el algoritmo que desde el estado interno produce el texto cifrado) hasta encontrar un punto que se encuentre en la tabla, una vez encontrada la cadena correcta, se parte desde el principio y el dato anterior al resultado escuchado es el estado interno necesario. Esto se ve mejor en este diagrama, procedente de su presentación.



Sobre este algoritmo básico, han aplicado dos mejoras:
  • Por un lado, para no tener que mirar en el disco duro cada vez (el equipo de descifrado tiene de 16 a 32 memorias flash USB para almacenar los datos con una latencia razonable) cada vez que se ejecuta el algoritmo si se ha llegado al final de la cadena, sólo se almacenan como finales de cadena valores específicos (p.e. con la segunda mitad a cero). De este modo, sólo cuando el resultado de una cadena es un valor específico se mira en disco duro.
  • La segunda mejora es el principio de las tablas "arco iris", que es utilizar un algoritmo levemente diferente (en vez de usar siempre K) en cada paso de la cadena, de modo que la posibilidad de que dos cadenas colisionen produciendo el mismo valor disminuye mucho.
En la solución empleada, ambos se combinan para tener un cambio de algoritmo cada vez que se encuentra cada uno de los 32 valores distinguidos coon los últimos 15 bits a cero. Con esto, ya tienen unas tablas que con 2 TB tienen un 99% de probabilidades de descifrar una llamada si se dispone de todas las claves y un 50% si sólo se consiguen las claves más obvias.

El proyecto está en la fase en la que irá progresando rápidamente, a medida que empiezan a probar van descubriendo más tramas que usar para atacar, y a disminuir el tamaño de las tablas.

La asociación GSM, ha publicado una nota de prensa señalando todo lo que les falta al equipo para poder ejecutar el ataque sobre una llamada que use "frequency hopping": hardware para sintonizar las frecuencias y un software para seguir las diferentes frecuencias. Ellos piensan hacerlo con USRP2 (que es capaz de capturar 25 MHz completos) y con openBTS, aunque todavía no lo tienen listo porque capturar 25 MHz genera demasiados datos y hay que filtrarlo.

Por último, la recomendación para mitigar este ataque, es deshabilitar la cifra A5/1 y pasar a la A5/3 (sólo un operador, SFR, ha hecho algo por ahora), que todavía es demasiado compleja para ser atacada (aunque en una , aunque esto no tapa todos los agujeros porque un ataque activo podría permitir capturar pasivamente una llamada realizada con A5/3, luego activar el capturador de IMSI para obligar al teléfono a negociar con A5/1 y esto permitiría recuperar la clave, ya que el teléfono reutiliza secretos entre llamadas consecutivas y averiguar la clave de la segunda llamda permite conocer la de la primera.

Y todavía hay dos charlas más sobre ataques a GSM...

Que los robots trabajen por nosotros

La charla de Lorenz G Lechner sobre robots autónomos (para alinearse con el tema del año, los llamó "dragones eléctricos"), era interesante como reflexión del futuro. Lorenz, que venía en calidad de participante en el curso post-doctoral llamado Bit Bang, que intenta prognosticar cómo será el futuro en 2025, contaba su visión de cómo acabarían integrándose los robots en la sociedad humana: aumentando las capacidades del hombre.

Según su visión, tarde o temprano, el futuro nos traerá máquinas autónomas, como las que ya tenemos en varios campos como el hogar (el robot roomba), en biónica (el pingüino autónomo de Festo) y en seguridad (predator y demás).

Sin embargo, el futuro apocalíptico de skynet por en cual las máquinas alcanzan una voluntad propia de dominar al hombre le parece muy poco probable. Si suponemos que las máquinas seguirán un cambio evolutivo, la presión evolutiva de a quién sirven tenderá a hacerlas amigables y dóciles (aunque tengan inteligencia independiente), de la misma manera que esa presión evolutiva ha marcado a los animales domésticos (claro, que no mencionaba el caso de los pit bull o los doberman).

Como segunda característica de las máquinas autónomas que aparecerán, plantea:
  • El postulado de Lorenz: "No hay ninguna tarea física que un hombre pueda hacer mejor que un robot"
  • Que conjuntamente con la Ley de Moore y su duplicación de capacidad, nos lleva a la conclusión de que: "Lo que puede ser automatizado, lo será"
Y en este futuro, ¿qué le queda por hacer al hombre?: pues reivindica la cultura previa al calvinismo en el que la actividad contemplativa no era síntoma de pereza y la vida en los monasterios en los que se trabaja, pero no por necesidad de hacerlo... Nos dedicaremos a actividades intelectuales, probablemente como pasatiemo (¿como escribir blogs?).

Creación de darknets

En la primera charla que mi pequeño incidente aéreo me ha permitido asistir, se da un repaso al estado del arte de la creación de darknets, en el sentido de redes privadas virtuales y anónimas que permiten que diferentes grupos se conecten entre sí (la entrada de Wikipedia se refiere a un subconjunto de éstas usadas para compartición de ficheros, lo cual no es el objetivo de esta charla).

El contenido de esta charla ha surgido en varios sitios al mismo tiempo, que han ido desarrollando estas redes virtuales con diferentes procedimientos y diferentes objetivos.

En orden de evolución, se comenzó presentando los modelos de red privada virtual y cifrada qe no han funcionado:
  • OpenVPN requiere un servidor centralizado que es una pieza crítica de la red (si se cae, la red viene abajo, que es lo que sucedió con MRN VPN), y además ese servidor requiere publicidad y la red se hace menos anónima.
  • Tor permite anonimato y cifrado, pero por diseño tiene una latencia extremo a extremo muy elevada y no es apto para ser usado a nivel IP (p.e. para aplicaciones multimedia o de baja latencia en general).
  • Freenet está muy enfocado a la compartición de ficheros de manera anónima y no puede ser usado para otro propósito.
La primera red que ha cumplido los requisitos ha sido la creada por equinox, dn42, que comenzó siendo un entorno de prueba de sus implementaciones de BGP, y acabó siendo una pequeña internet en miniatura, donde cada persona hacía "peering" con sus amigos, y la red era mallada parcialmente. Esta red ya cumple el requisito de ser anónima, cifrada y descentralizada (de hecho el fundador tuvo que quitar su nodo durante seis meses y la red siguió funcionando sin él), pero tiene limitaciones en cuanto a la administración y el control (y tampoco tiene DNS o whois) y en cuanto a latencia, pues no todos los caminos son directos.

La siguiente generación vino con el software tinc, que crea túneles automáticamente y con una configuración muy sencilla, gracias a que mediante un script se actualizan las tablas de los router periódicamente. La gran mejora vino con el porting del script de actualización a c, con lo que ahora el paquete puede ser incluido en un router con OpenWRT como el Linksys WRT54G o la Fonera.

Este es el software que se utiliza en las siguientes darknets:
  • La conexión de todos los hackerspaces mundiales, separados administrativamente (para que el soporte pueda ser dentro del mismo continente) en dos redes: ChaosVPN y Agora Link (no hay enlaces porque por ahora están en beta privada). Los presentadores (y autores del software), pertenencen a estas redes.
  • La creación de una "warzone" global, un escenario donde jugar a CTF de ámbito global y donde todo está permitido, como extensión de las competiciones CTF que se hacen en el defcon.
  • Y se podría usar para muchas más cosas, como transportar VoIP para CCC (la organización, no la conferencia), compartición de recursos de altas prestaciones (HPC), difusión de conferencias como éstas, cloud computing...
El equipo también comentó los desarrollos futuros que quieren añadir al software:
  • Mejor autenticación
  • Añadirlo a la distribución estándar de OpenWRT
  • Añadirle extensiones para poder tener diferentes darknets en un mismo router, a base de usar puertos ethernet diferentes.
Por último, el grupo anunció un workshop con el software, y la oferta de que todos los interesados se unan a sus redes.

sábado, 26 de diciembre de 2009

Las dificultades para volar a Berlín

A veces la ingeniería social más elemental es la que es más efectiva... No estoy orgulloso de ello, pero las circunstancias lo requerían.
Tras varias horas de retraso, nuestro piloto el sábado llegó a la conclusión de que el avión tenía una pieza rota y que no estaba disponible en el aeropuerto, que nos tocaba irnos a un hotel, pasar la noche y esperar a un avión nuevo que saldría al día siguiente después de comer y haría que me perdiese casi todas las charlas del domingo.
Así que pacientemente me puse en la cola, dispuesto a intentar mejorar mi situación. Cuando me llegó el turno, y tras entregar el papel de reclamación, soprendentemente la pregunta de: ¿quedan plazas en un vuelo que salga antes? tuvo respuesta afirmativa, y encima sin coste extra. Es cierto que quedaban muy pocas plazas, pero me sorprendió que nadie antes que yo formulase esa pregunta.
También me sorprendió la arbitrariedad por la que la asignación de las plazas se hizo (primero que pregunta, primero se la lleva...), no fue necesario inventarse ninguna historia por la cual yo fuese más merecedor de la plaza que otros.

jueves, 24 de diciembre de 2009

Calentando motores...

Bueno, como dicen en el CCC, ya tenemos un "fahrplan", aunque el suyo es en otro sentido:
  • Yo ya estoy listo para despegar el día 26 hacia Berlín, y esta entrada es simplemente para anunciar que aquí voy a publicar una crónica del 26th Chaos Communication Congress "Here be dragons"
  • Ellos ya tienen un calendario de todas las conferencias (interesantes y no), y un logotipo, que me he tomado la libertad de iluminar para que se vea de otra manera...

Allí estaré...