Frutos del Caos

Hackeando el contador de la luz

2011-12-30T17:00:00.000+01:00

En mi última charla presencial de este año, Dario Carluccio y Stephan Brinkhaus se entretienen con los nuevos contadores inteligentes de la empresa Discovergy, que vende un servicio de contador de la luz electrónico, que a base de medir el consumo eléctrico con una precisión de dos segundos, tiene como objetivo recomendar a los usuarios cambios de comportamiento y proveedor o tarifa de energía. Su modelo de negocio es realmente interesante: si no te ahorra dinero, no le tienes que pagar.

Sin embargo su uso tiene dos inconvenientes: por un lado, la resolución de consumo de energía (2 segundos) es tal que se podría utilizar para espiar al usuario y obtener información sobre sus actividades cotidianas y por otro lado, aunque el proveedor dice que los datos se envían cifrados para que nadie los pueda interceptar, que se envían firmados para que nadie los pueda falsificar y que además se borran al cabo de tres meses, pero no es así.

Dario ha empezado primero demostrando el primer punto, en el cual han mostrado una manera de la que se podría deducir cuál es el programa de televisión que está viendo un usuario: se toma la parrilla de televisión de un determinado momento, y mediante un modelo que tiene en cuenta la cantidad de brillo necesaria en la pantalla, se calculan los perfiles de consumo de energía de los programas.

Esos números se correlacionan con el consumo medido, mediante una correlación de Pearson, y se encuentra que realmente la correspondencia entre el consumo real y el consumo predicho es muy alta.

Sobre el segundo punto, resultó que ninguna de las tres afirmaciones de Discovergy eran correctas:

- Aunque la empresa tiene un certificado y una página HTTPS, las pruebas han mostrado que el envío de datos se realiza en HTTP sin cifrar.

- Han demostrado que los datos se envían sin firmar, porque han podido suplantarlos y enviar un consumo artificial con las palabras “U have been hacked”… o algo parecido. Aparentemente el usuario es identificado por su MAC.

- Y por último, han sido capaces de obtener datos más antiguos que 3 meses, lo que prueba que ellos los almacenan, pero simplemente no los muestran a los usuarios.

Eso sí, parece que cierto control sí que tenían, porque a los tres días de que empezase a trastear con el contador, la recogida de datos de su contador se paró repentinamente, y comenzó a volver a recoger datos sólo tres días antes.

Pero lo más divertido de la presentación fue cuando le pasaron el micrófono a una persona del público y sorprendió a todos diciendo “soy el CEO de Discovergy”. La verdad es que no entró en mucho detalle sobre el tema del cifrado (simplemente reconoció que no era correcto y que estaban trabajando en arreglarlo), aunque sí expuso que lo de recoger datos con alta resolución era para poder detectar si el usuario tenía electrodomésticos antiguos, u otros tipos de mejoras. También aprovechó como otros en el congreso para ofertar posibilidades de trabajo a cualquiera que tuviese interés en resolver problemas como el de la identificación de los programas de televisión.

¿Está tu impresora poseída?

2011-12-29T18:30:00.000+01:00

Con el sugerente título de “Imprime si te atreves”, Ang Cui ayudado por Jonatan Voris, empiezan su charla mostrando dos impresoras HP y un par de respuestas a preguntas frecuentes de HP, que se contradicen entre sí: por un lado, dicen que sus impresoras multifuncionales no son susceptibles a virus y gusanos, mientras que en la respuesta siguiente dice que es posible, pero altamente improbable, porque los hackers prefieren atacar los ordenadores y servidores porque requieren menos especialización.

La vulnerabilidad ha sido hecha pública el 23 de noviembre y ha tenido ya mucho impacto en los medios, incluyendo exageraciones sobre la posibilidad de convertir las impresoras en bombas incendiarias. Esto es absolutamente falso: ellos lo han intentado pero no es posible quemar el papel de la impresora (por diseño: hay electrónica que apaga las resistencias si la temperatura es muy alta), y han mostrado este papel como prueba.

Ver la demostración en vivo es impresionante: es posible transmitir un virus a una impresora láser (por ejemplo a través de un documento infectado que una empresa recibe de fuera – ellos ponían el ejemplo de un CV), de modo que a partir de ese momento, esa impresora por un lado puede enviar una copia de todos los documentos que se imprimen a otra impresora externa, y por otro lado puede servir de vector de ataque hacia otros PCs que estén en la misma LAN.

El parche para la vulnerabilidad se ha publicado muy recientemente (23 de diciembre), por lo que los investigadores no han contado todos los detalles. Lo que sucede es que muchos modelos de impresoras HP (hasta 56 han sido actualizadas) pueden ser actualizadas con un comando de impresión, que dado que muchas utilizan el protocolo lpr, no tiene autenticación. Lo crucial es que independientemente de eso, esos ficheros sólo tienen protección de integridad (un CRC, vamos), no de autenticidad (estar firmados por una clave criptográfica privada).

Con lo que si se consigue descifrar el formato del fichero de actualización (y eso no ha sido sencillo), cualquiera puede escribir un nuevo firmware, y a partir de ahí, es sólo cuestión de tener acceso a imprimir en esa impresora (aunque existe la posibilidad teórica de incrustar el firmware dentro de un documento, eso no ha sido posible demostrarlo – y además llamaría la atención porque el firmware base ocupa 7MB) para infectarla.

El proceso para descifrar el formato del fichero no ha sido fácil, ya que las estrategias más sencillas (mirar el fichero, binwalk, google y la ingeniería social) no dieron resultado. Hubo que recurrir a la fuerza: desoldar el fichero de flash de arranque y sacar el contenido mediante un lector improvisado con un Arduino. En ese proceso se descubrió la faceta más peligrosa del virus: dentro de las cosas que el virus podría hacer, es incluirse en la flash del equipo, y conmutarla a modo “sólo lectura”, un proceso irreversible que dejaría la impresora poseída para siempre.

¿Cuántas impresoras son vulnerables? Se calcula que HP vende unos 40 millones de impresoras al año, aunque de esas, la mayor parte está en redes privadas donde no es fácil encontrarlas. Eso sí, él ha censado 75k impresoras potencialmente vulnerables conectadas directamente a Internet… así que alguna infectable inmediatamente sí que la hay.

¿Y cuál es la mitigación posible? Pues ir corriendo a casa (o a la oficina) y desenchufar la impresora (sobre todo para la impresora objetivo del ataque, la HP 2055DN). Luego, pasado el primer pánico, volver a conectarla y deshabilitar la actualización de firmware remota. Bajarse el nuevo firmware de HP, habilitar de nuevo la actualización y actualizarlo. Y en general: aplicar protección al servidor de impresoras, poner las impresoras en una VLAN aparte y similares medidas habituales en entornos corporativos.

Exploración lunar en la tierra

2011-12-29T11:30:00.000+01:00

Este año, los científicos a tiempo parcial vuelven a mostrarnos su progreso en la creación de su robot lunar de exploración (“rover”).

Este año lo que han avanzado es en montar su primera versión del rover lunar, que tiene el pequeño problema de que está pensado para la gravitación lunar, no la terrestre. Aparte de los problemas de montaje con el pegamento (el pegamento lunar es especial, y no debe ser confundido con el pegamento terrestre – aunque a veces las botellas son tan parecidas…), otro de los progresos de este año ha sido en el diseño del software de movimiento.

Uno de los avances ha sido el algoritmo para conducir el rover por la superficie lunar, pero de modo que las ruedas estén todas orientadas en la dirección adecuada, de modo que el rover pueda girar sin tener derrapar (como hacen en realidad las ruedas de los coches). La solución matemática tal y como la explican es relativamente sencilla: cada rueda está orientada según la suma de un vector de avance recto más un vector de rotación alrededor del centro del rover. Su figura lo explica mucho mejor...

La segunda parte es hacer pruebas de control de la navegación, que es compleja porque hay que introducir un retardo de tres segundos en los comandos. El vídeo de la navegación es interesante y está en su página de facebook (y está poblado de botellas vacías de Club Matte, combustible indispensable de todo el hacking en Alemania). Para ello no vale un ratón normal, es necesario uno denominado 3D, que además de moverse, se puede rotar sobre el sitio (y puede enviar esa rotación al rover).

También ha habido que resolver problemas como la interferencia. Si le hubiesen preguntado a un ingeniero de comunicaciones, les habría contado la historia del cable de pares (que es un cable doble y trenzado para disminuir la interferencia). Pero como lo que tenían a mano eran cables de cinta de ordenadores… tenían interferencias procedentes de los motores. ¿La solución? Utilizar cables Ethernet, que tienen un buen aislamiento frente a la interferencia. Eso sí, con un adaptador específico.

¿Y para el año 2012? Pues lo que hay previsto es tener una nueva edición del rover, y con él pasar las pruebas de radiación.

99% de servidores web vulnerables

2011-12-28T15:32:00.000+01:00

Alexander Klink y Julian Zeri han mostrado en esta charla una vulnerabilidad del uso de funciones “hash” que está presente en un 99% de las plataformas de servidor web actuales. La lista es impresionante, parecía que nunca iban a acabar de encontrar sitios vulnerables: PHP, ASP.NET, Java, Python, Ruby, Node.js. Con esta lista y sumando según W3Techs, parece totalmente creíble que el 99% de los servidores web estén afectados.

La verdad es que es mucho más fácil decir dónde no existen problemas: en Perl (que tiene este problema solucionado desde que en 2003 se descubrió que era vulnerable -- la historia se repite a sí misma) y CRuby 1.9 (y para 1.8 parece que hay ya un parche), que ha sido el equipo que han puesto como ejemplo de colaboración.

¿De qué se trata la vulnerabilidad? Enviando una petición POST a un servidor web con una lista de parámetros adecuadamente configurada, la CPU del servidor sube al 99% durante un largo rato (por cada petición). Las cifras de efectividad del ataque en cuanto a ancho de banda son impresionantes: de 1 a 100 kb/s para subir un núcleo al 100% de CPU.

¿Y por qué sucede? Básicamente todas las plataformas afectadas utilizan un “hash” para guardar los parámetros de la petición web. Y el problema está en que utilizan funciones hash que son conocidas, no son resistentes a las colisiones y son fáciles de invertir. Los nombres de los parámetros que se van a meter en el “hash” se pueden elegir de modo que todos tengan el mismo valor de “hash” (construyéndolos a base de cadenas de dos o tres caracteres que todas producen hashes equivalentes), de modo que una operación que normalmente es lineal con el número de parámetros se vuelve cuadrática. Y en cuanto se añaden miles de parámetros en una petición… tu servidor web está perdido.

Pero no todo está perdido: hay mitigaciones rápidas (limitar el número de parámetros de la petición web), que es lo que están haciendo la mayoría, porque la solución buena (que es la que ha adoptado Perl) requiere aleatorizar el hash de modo que no sea posible encontrar las cadenas equivalentes (básicamente con aleatorizar la semilla de una manera diferente para cada estructura es suficiente, no es muy complicado pero es una pieza tan crítica de cada plataforma que el cambio hay que hacerlo con unas buenas pruebas).

Los frutos del átomo y la ingeniería genética

2011-12-28T11:30:00.000+01:00

En esta charla de Zack Denfeld y Cathrine Kramer, parte del centro de Gastronomía Genómica y los autores del vídeo de cocina “Glowing sushi” se repasa la influencia que ha tenido el hombre en la selección de nuevas especies de comida.

Empieza la charla por la descripción de las zanahorias, de las que originalmente había muchas especies, de diferentes colores (blancas, amarillas, naranjas, moradas) y sabores (más o menos amargas y dulces), hasta que un cultivo selectivo consiguió la raza que se utiliza mayormente en la actualidad, la zanahoria naranja que es más dulce que la morada. Hay además motivos políticos para que sean naranjas: en el momento en el que se comenzaron a cultivar, reinaba en Holanda la casa de Orange, por lo que de repente las zanahorias naranjas además comenzaron a ser políticamente correctas.

A continuación la humilde patata sirve para recordarnos la escasa diversidad de especies de las que nos alimentamos: 4 cosechas suponen el 50% de nuestros alimentos, y 30 cosechas consisten en prácticamente todo nuestro alimento, el 95%, de las que la patata es la mayor a nivel mundial.

Si confrontamos esto con el hecho de que además cada cosecha tiene tendencia a basarse en una variedad concreta mayoritariamente, nos supone el mismo riesgo que tener Windows como sistema operativo mayoritario: los virus. Un virus específico de la variedad dominante puede suponer que en unos pocos años haya una crisis alimentaria como la que hubo en Irlanda en 1845.

Afortunadamente por ahora hay muchas variedades de patatas, incluyendo las patatas moradas… incluso en Carrefour, fritas y al doble de precio de las normales.

A continuación pasamos a repasar otra moderna tecnología: la radiación nuclear. ¿Radiación y comida? Eso inmediatamente nos pone en alarma. Pues resulta que hay un montón de investigaciones sobre conseguir variedades alimentarias radiando plantas existentes. Nos muestran fotos de “jardines atómicos” donde se irradian plantas para conseguir variedades nuevas de interés comercial.

Todo esto da paso a la historia del pomelo: en una tienda de Estados Unidos, compraron tres pomelos, y resultó que dos de las tres variedades han sido obtenidas por irradiación, y que se puede consultar en la base de datos conjunta de la FAO y la IAEA de mutantes obtenidos por irradiación. Otras curiosidades que he podido consultar son la cantidad de tulipanes mutantes que se cultivan en Holanda (buscar tulip) y una variedad de Naranja de Valencia que se cultiva en Argentina, que también es un mutante atómico.

Pero como alguien me contó una vez, en los años sesenta los mutantes eran atómicos (Spiderman, Hulk, etc.), pero ahora los mutantes son producidos por ingeniería genética. Y esa fue la siguiente fase de la charla: los alimentos mutantes genéticos, como el tomate pez.

La verdad es que no conocía el mito del tomate pez, pero parece que ha existido: es un tomate modificado por ingeniería genética para ser más resistente al frío con un gen procedente de una platija. Esto sirve para como introducción al pepinillo transgénico (modificado para que sea más dulce, por lo que puede producir pepinillos agridulces) y una de las iniciativas de su centro, las comidas mutagénicas, recetas especialmente formuladas para alimentos transgénicos. Otro alimento transgénico muy polémico fue la berenjena Brinjal, genéticamente modificada por Monsanto, cuya introducción en la India fue muy polémica, aunque ellos argumentan que el problema no era tanto que estuviese modificada genéticamente sino controlada por Monsanto.

Pero lo más curioso es el glofish. Es un pez al que se le han introducido genes que lo hacen brillar en la oscuridad. ¿Y qué pasa si lo cocinas? En general, la proteína fosforescente se estropea al cocinar, por lo que si queremos una comida fosforescente, es necesario comerla cruda. Y ya sabemos, ¿pescado crudo? ¡Sushi! Y de ahí otra de las iniciativas de esta pareja, la creación de sushi fosforescente basado en Glofish… para los que quieran una comida fosforescente. Es muy práctico para las cenas a ciegas.

La presentación tiene muchos más detalles, pero el último es una reivindicación: el merengue es habitualmente un 95% de aire, por lo que refleja la composición del aire donde fue creado. Así que ellos fueron y crearon diferentes merengues en zonas muy contaminadas de la India. ¿El resultado? En la sesión de preguntas y respuestas confesaron que todos sabían muy parecidos, ya que el azúcar mata el resto de los sabores… pero en realidad el que se hizo cerca del tubo de escape de un camión tenía partículas carbónicas… visibles al microscópico.

Dan Kaminsky se la toma con bitcoin pero vuelve a sus orígenes

2011-12-27T23:00:00.000+01:00

Dan Kaminsky se la toma con bitcoin pero vuelve a sus orígenes.

En una charla apasionante, como todas las suyas, este año Dan ha empezado metiéndose levemente con bitcoin (a fin de cuentas, 2011 ha sido el año de la madurez de Bitcoin, y eso se ve reflejado en las diferentes charlas al respecto – más información en la descripción de la charla de Bitcoin).

La tesis de Dan es apasionante: Bitcoin tiene bugs, pero son de diseño, no de ejecución. De hecho, confiesa que Bitcoin ha sido revisado a fondo por un experto en seguridad, porque después de mirarlo por arriba y por abajo, no ha encontrado (y sus colegas tampoco) ninguna vulnerabilidad de seguridad.

Si no fuese, por supuesto, por dos pequeñas elecciones de diseño: que no escala y no es anónima. El que no escala es conocido, porque todos los nodos de bitcoin se supone que tienen que almacenar todas las transacciones del mundo realizadas desde su creación en 2009, ¡Para siempre! Dan calcula que para que los nodos procesasen, p.e., el mismo número de transacciones que VISA, tendrían que usar 3 TB cada 21 días, tener un ancho de banda de 8 Gb/s y 50 núcleos de CPU.

Es decir, que habría que pasar a un modelo centralizado con supernodos, que serían muy parecidos a los que usan ahora los bancos… aunque claro, no serían realmente bancos y no queda muy claro de qué se financiarían.

Como anécdota graciosa de la conferencia, ha contado cómo han incluido (por el módico precio de 1 BTC, que se ha perdido para siempre) un homenaje ascii a su fallecido amigo Len, que ahora está incluido en todos los clientes bitcoin y se puede ver con el comando (a estas alturas no han faltado imitadores con todo tipo de comentarios, incluso un rickrolling).

strings --bytes=20 ~/.bitcoin/blk0001.dat

Y respecto a no ser anónimos, además de los métodos triviales en los cuales las personas se ven asociadas a sus direcciones IP en los “bitgrifos”, el muestra un método más ocurrente, de fuerza bruta: si un nodo se conecta a todos los demás nodos a la vez, el primero que indique una determinada transacción, es el autor de esa transacción. ¿Difícil? No tanto, puesto que por ahora “sólo” hay que conectarse a 30k nodos, y la propia red tiene mecanismos para obtener direcciones de los demás nodos.

Y esto sirve para dar paso al siguiente tema de su charla, UPnP. Para todos aquellos nodos bitcoin que están detrás de firewalls, no sería fácil conectarse a ellos por el NAT, salvo por el hecho de que muchos router tienen el UPnP activado para ser usado tanto dentro de la LAN (donde debería) como desde Internet. Este descubrimiento, confiesa, no es original, aunque todavía dista mucho de estar arregrado.

Algo más o menos parecido sucede con la siguiente vulnerabilidad, que miembros de la audiencia argumentaron que era conocida pero que sin embargo sigue sin arreglarse: la posibilidad de crear conexiones TCP asimétricas, en las que no se reciben los paquetes de vuelta porque van con direcciones IP de origen falsas (“IP spoofing”). Y no está arreglado porque la solución que se encontró en su momento asumía que “harían falta millones de paquetes para acertar aleatoriamente una conexión”, y hoy con conexiones de fibra de 10 y 100 Mb/s, son escasamente de uno a diez minutos.

La conexión con su siguiente tema no ha sido tan fluida como la anterior, pero haciendo similaridades con los syn cookies, y aunque sigue insistiendo que “los password son malos”, propone un nuevo enfoque para su uso: el cliente utiliza un password, del que genera un par de claves público/privado, y le proporciona al servidor sólo la clave pública. De ese modo, si algún servidor pierde tus claves, no se pueden usar en otro sitio. Todo esto lo hace a base de una librería llamada Phidelius, una herramienta que intercepta el uso de las fuentes habituales de entropía de modo que un determinado password siempre de origen al mismo par de clave pública / privada. Eso sí, para estar totalmente seguro habría que encontrar una manera de generar una clave pública diferente para cada usuario aunque tengan el mismo password, a base de una semilla que se incluya en la clave pública… un “código mágico” que no llegó a explicar cómo se haría.

La charla terminó explicando su nueva herramienta, N00ter, que permite detectar políticas de no neutralidad de red, a base de comparar el mismo tráfico hacia un servidor final cuando pasa por un determinado proveedor de Internet en claro (y por tanto puede ser manipulado por la política de ese proveedor) y cuando pasa cifrado. La herramienta está por ahora limitada a dos escenarios parciales: uno en la que el proveedor nunca ve el tráfico ascendente y se comparan los casos de cifrar o no el tráfico descendente y otra en la que el proveedor siempre ve el tráfico descendente pero ve o no el tráfico ascendente.

La solución mejor aún no la tiene implementada: sería la que es compara el flujo cifrado con un flujo que no pareciendo cifrado al proveedor sigue pasando por N00ter en los dos sentidos. Aquí la cuestión es que para que el proveedor vea el tráfico no cifrado ascendente, lo tiene que ver también el servidor, y el servidor al ver el tráfico asimétrico puede tirar la conexión.

Así se tiene un tráfico en abierto hacia el servidor que en realidad se descarta y es sólo para desencadenar la política y un tráfico cifrado ascendente que el proveedor no ve, y que es usado por N00ter para recibir y reenviar el tráfico en abierto descendente y asegurarse que pasa por el mismo camino que el cifrado. El proveedor ve los dos tráficos, y por tanto si lo necesita aplicará la política, mientras que N00ter garantiza que el tráfico de verdad sigue el mismo camino que cuando está cifrado. No es totalmente perfecto, pero es a lo que se puede llegar.

Y tras volver a sus raíces explotando el tráfico TCP/IP de siempre, Dan nos dejó para ir trabajando en los ataques del próximo año, no sin antes recomendar la charla de las claves soberanas.

¿Piensas que tus conversaciones de Skype son privadas?

2011-12-27T14:00:00.000+01:00

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

2011-12-27T11:20:00.000+01:00

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

2011-12-27T10:22:00.000+01:00

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...

2011-12-27T00:27:00.002+01:00

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).

Depurar conexiones HTTPS

2011-01-29T15:00:00.033+01:00

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?

Anécdotas finales del 27c3

2011-01-02T09:00:00.049+01:00

Bueno, no puede haber ningún CCC congress sin un poco de blinkenlights, esta vez estaban en el bar del BCC.

Como ya decía al principio, este ha sido uno de los años de CCC en los que en la calle se podía patinar gratis (el logro está en no caerse). Supongo que por eso también las pistas de patinaje público también se puede patinar gratis.

Todo esto está causado por la nieve, que a -10º C, lo cubre todo, las calles.

los árboles

Los coches y las bicicletas

Y claro a esa temperatura hay témpanos de hielo en todas partes, afortunadamente no se caen encima de la gente... al menos hasta el deshielo.

Los alrededores del BCC tienen su propia cosecha de viejos edificios comunistas pendientes de renovación, como éste que gracias a eso alberga uno de los relojes más precisos del mundo... una vez al día.

No sé cómo leer esto, pero todas mis nociones de alemán me hacen pensar que Thomas le ha caído bien a alguien...

Una traducción resumida dice: "Hey Thomas, nos hemos conocido en Matrix, lo he pensado y me gustaría volver a verte..." Eso sí, era más interesante cuando pensaba que Matrix era "la Red" en vez de una discoteca de Berlín. Claramente debe de ser que piensa que Thomas pasa cerca de esa farola con frecuencia...

Los hackers hackeados

2011-01-01T12:00:00.019+01:00

En el congreso del CCC, este año los tickets de entrada no han sido tan fáciles de obtener como el año pasado. Sin embargo, los tickets son igual que los años pasados: sencillos.

En concreto, son unas pulseras que se sellan de modo que una vez cerradas sobre la muñeca de alguien no puedan intercambiarse más que cortándolas: un método anónimo, pero desafortunadamente tiene algún problema de fiabilidad: es posible quitárselas sin que se note demasiado, y después pasársela a otro. He aquí las pruebas...

Eso sí, no parece que haya afectado a la concurrencia de gente: las salas seguían estando igual de llenas que los últimos dos años, con mucha gente en pie, dificultades para sentarse y masificación en general. Y eso que además hay muchas personas que atienden remotamente. Quizá sea el momento de repensárselo para el año que viene...

Extensión sensorial

2010-12-30T14:00:00.001+01:00

Aviso: este artículo habla de cosas dolorosas, si eres sensible quizá es mejor saltárselo (a mí me duele sólo de escribirlo y por eso no voy a incluir fotos...), así como el blog referenciado. Para terminar el congreso (para mí, al menos), la charla más extraordinaria de todas: Lepht Anonym nos cuenta sus experimentos en ampliación de los sentidos (básicamente implantarse dispositivos que le permiten percibir cosas nuevas).

Una pequeña mujer sin miedo al dolor y con una curiosidad casi mortal, ha probado casi de todo sobre sí misma para que los demás no tengan que pasar por las partes peores. Su objetivo: implantes subdérmicos que le permitan percibir temperatura, magnetismo y dirección (ah, y mejorar la autenticación).

Cuando habla de dolor y casi suicida es porque debido a las restricciones legales en el Reino Unido, ha tenido que autoimplantarse parte ella sola, sin ni siquiera quirófano y con un presupuesto mínimo (parte de las cosas que se ha hecho han simplemente mejorado el coste de procedimientos existentes).

Lo primero que se ha implantado es razonablemente común: una ampolla RFID. Aunque lo utiliza para autenticarse a su ordenador, no lo recomienda demasiado porque parece ser que criptográficamente no son muy seguros, al menos como método único de autenticación.
Un siguiente paso era para superar un efecto secundario que le provocan las múltiples medicaciones a las que está sometida (la verdad es que su vida es, digamos, original; para más información recomiendo leer su blog): de vez en cuando pierde el sentido de la temperatura y no es capaz de percibirla correctamente. La solución: un sensor de temperatura conectado a unos leds. Aquí todavía no ha conseguido el éxito.
El siguiente paso también ha sido hecho antes: implantarse imanes de neodimio. ¿El problema? Los implantes son caros porque hay un sólo fabricante. Y no se pueden usar los imanes de neodimio que uno puede comprar en cualquier tienda porque el neodimio es muy tóxico. Así que en lugar del recubrimiento de plata y silicio de Hawthorn (aunque en su web Hawthorn habla de oro y silicona -- algo no cuadra), ha experimentado con varios elementos antes de decidirse por el sugru. Aunque dice que el adhesivo termoplástico también funciona bien.
Su último proyecto todavía está en la fase de diseño, y es rediseñar el hardware del proyecto Northpaw (que es un dispositivo externo que mediante vibradores de móvil sobre la piel permite tener una sensación constante de hacia dónde está el norte) de modo que sea implantable: se va a llamar Southpaw. Su idea es miniaturizarlo todo para que se pueda implantar en la pierna izquierda y prescindir de los vibradores y usar directamente electrodos... se verá.

Bueno, pero dado que alguien ha experimentado, será bueno conservar las lecciones: hay que esterilizarlo todo, las cosas implantadas no sólo tienen que ser resistentes al agua sino biocompatibles, la autocirugía debería ser el último recurso (en donde sea legal otra cosa), y para algunas cosas (como las yemas de los dedos) es mejor una aguja gorda que un bisturí...

Yo mientras tanto espero que nada de esto sea obligatorio.

Idiosincrasias de PDF

2010-12-30T12:30:00.114+01:00

Después de la lección abreviada sobre PDF de Julia Wolf, ya no podré volver a leer un documento PDF de la misma manera.

Resulta que yo pensaba que PDF era simplemente una especie de evolución de Postscript para describir documentos y poder imprimirlos... Pues resulta que es mucho más, de hecho Adobe Acrobat tiene más líneas de código que Firefox y Linux juntos. O que Windows NT... Vamos, que Adobe no ha hecho un ordenador con AcrobatOS porque no ha querido (bueno, igual estaban ocupados al 100% en lugar de al 80%, 15 millones de líneas dan mucho trabajo).

A medida que las transparencias de todo lo que un documento PDF puede hacer iban pasando mi sorpresa era cada vez mayor: tiene la posibilidad de incuir OpenGL, Flash, audio, video, formularios, RFID (sí, se puede imprimir un campo a la etiqueta RFID del documento...), y cualquier fichero arbitrario. Eso sí, para los ficheros tiene que lanzar aplicaciones externas para interpretarlos... no sin antes pedir permiso.

Además de la sintaxis principal, que es parecida a la de Postscript, el formato también soporta código Javascript, lo que abre infinitas posibilidades... para bien y para mal. En concreto, los actuales virus esconden el código en cualquier campo informativo del documento del que lo saca un pequeño trozo de código Javascript.

Pero Julia ha mostrado nuevas maneras que podrían ser utilizadas para escaparse de los antivirus (y que por ahora son efectivas y pocos antivirus tienen contramedidas), basadas en la gran tolerancia a los fallos que tiene el formato.

En concreto, dado que el comienzo del fichero con %PDF-1.1 no necesita estar justo al principio del fichero, que Acrobat se salta todos los datos no reconocidos y que no verifica la tabla final de contenidos, Julia ha demostrado que se puede crear un fichero que según se mire es un fichero PDF o zip: la mayor parte de los antivirus piensan que es un fichero zip (y le aplican el procesamiento de zip) porque empiza como un fichero zip y así podría escapara a la vigilancia para ficheros PDF, pero si Acrobat abre el fichero buscará %PDF-1.1 y si lo encuentra en los 1024 primeros bytes, lo da por bueno y lo va a interpretar como PDF.

Y por supuesto, esto no sólo se puede aplicar a ficheros zip, sino que se puede introducir un fichero PDF en un fichero gif, html o incluso en un URI (aunque esto en realidad no funciona). ¿Consecuencia? La mayor parte de los antivirus no están bien preparados para detectar esto, y la mayor parte de los virus PDF hoy no son detectados... así que si ya les tengo un poco de manía a los PDF por lo que tardan en verse en Adobe Reader o su plug-in (en Mac OS X no pasa ;-p), cada vez los abriré menos.

La charla se termina con múltiples ejercicios interesantes que se podrían hacer con PDF, entre los que más interesantes estarían:

Escribir un quine en PDF. Aunque esto ya existe, entiendo que la dificultad está en que en lugar y/o además de imprimirse en el visor se duplique en otro fichero, aunque con ese punto de partida debería ser fácil (aunque hace falta más que la presentación y un par de horas... al menos para mí).
Dado que la capacidad gráfica de PDF es tan grande (puede multiplicar tensores de datos sin pestañear demasiado), otra manera de esconder cosas dentro de un PDF es tener arrays de datos aparentemente inocentes y que mediante un par de operaciones gráficas extraigan su "shellcode".
Mi favorita: crear fractales dentro de PDF mediante las operaciones gráficas simil-Postscript. Ya va siendo hora de actualizar mi firma Postscript a un lenguaje más moderno...

Cuidado con las tarjetas de Chip

2010-12-29T21:30:00.101+01:00

Justo cuando toda la industria bancaria creía que había encontrado una solución para el fraude de tarjetas de crédito falsificadas, perdidas y robadas, vienen los especialistas en seguridad y le empiezan a encontrar fallos... ¡qué fastidio!

Steven Murdoch, un investigador de seguridad de la universidad de Cambridge, ha venido a contar un fallo de seguridad que ha encontrado en la implementación del protocolo EMV, el que utilizan las tarjetas de chip que van a sustituir a las viejas tarjetas magnéticas.

Resulta que las tradicionales tarjetas de crédito magnéticas son muy fáciles de reproducir (ya que basta un lector bastante sencillo para hacerlo -- creo que hasta se puede hacer con un cabezal de cassette reciclado), lo cual hace que la segunda causa de fraude de tarjetas de crédito sea precisamente el de tarjetas duplicadas (el primero se produce en el caso de transacciones sin tarjeta... en los que hay que trabajar de otra manera).

Para ello, un consorcio de los tres medios de pago dominantes en Europa (Europay, Mastercard y Visa) han creado una especificación de cuatro mil páginas que describe unas tarjetas chip con capacidad criptográfica para autenticar transacciones de crédito. Como las tarjetas nunca entregan su clave secreta a nadie, son difíciles de duplicar. Adicionalmente a eso, para dificultar su uso cuando la tarjeta física cambia de manos, es necesario pasarle un número secreto (PIN) a la tarjeta de modo que sin ese número, una tarjeta robada no puede ser usada. Esto disminuye las dos causas siguientes de fraude: tarjetas robadas y tarjetas enviadas pero nunca recibidas.

La verdad es que la introducción había tenido poco éxito en contener el fraude hasta el año 2009, en el que se han aplicado dos medidas: por un lado, ya es obligatorio usar el chip en todas las transacciones con tarjeta chip (antes se podía usar la banda magnética todavía), y por otro, los bancos han empezado a aplicar la política de que el sistema EMV es tan seguro que si hay fraude, el cliente es el culpable porque el sistema no puede fallar... ¿o sí?

El caso es que estos investigadores han encontrado una manera en la que se puede usar una tarjeta con éxito sin conocer el PIN. Para abrir boca, nos han enseñado como se hace con este vídeo (de este artículo de la BBC):

En la charla lo que además han revelado es lo sencillo que es el ataque:

En resumen, la transacción tiene tres fases: la tarjeta presenta su certificado al terminal, el terminal le envía a la tarjeta el PIN del cliente para verificarlo, y por último el terminal le envía la transacción a la tarjeta para que ésta la firme y la valide. Esta última transacción es independiente de modo que se puedan hacer también transacciones sin pedir el PIN. El problema está en que en la segunda transacción, los datos que se le envían a la tarjeta son los mismos en el caso de que no haya que pedir el PIN y en el caso de que haya que pedir el PIN y la tarjeta lo ha dado por bueno.

Así, en la transacción fraudulenta se introduce una tarjeta falsa (la tarjeta roja en el diagrama de arriba) y un pequeño ordenador (la versión revisada desarrollada por un estudiante de Cambridge tiene el tamaño de un paquete de cigarrillos) entre el terminal y la tarjeta verdadera. Así, cuando el terminal envía el PIN, el ordenador responde que el PIN es correcto, sea el que sea, y por un lado la tarjeta piensa que el terminal no le ha pedido el PIN y el terminal (y el banco) piensan que la tarjeta ha dado el PIN como correcto (y así lo imprimen en el recibo).

El caso es que encima los medios de pago ingleses no han llevado bien el tema, no lo han arreglado y han intentado suprimir la información que estaba creando la universidad al respecto (en concreto, el desarrollo miniaturizado del ordenador y tarjeta intermedios. Siendo la prensa inglesa lo que es, lo que han conseguido es el efecto contrario... y que la tesis que lo describe sea víctima del "efecto Slashdot".

¿Soluciones? Parece que Barclays ya ha encontrado una solución en sus sistemas (hablan directamente con la tarjeta y le preguntan si el PIN ha sido correctamente validado o no), pero el resto de los bancos por ahora son vulnerables. Y por la parte de los usuarios, la recomendación ha sido que en ningún caso se proceda a la destrucción de la propia tarjeta (aparentemente es la recomendación del banco en el caso de que haya sido víctima del fraude al recibir la nueva), ya que contiene un contador de transacciones que puede servir para demostrar que ha habido transacciones con otras tarjetas a la hora de pelearse con el banco por la devolución del dinero sustraído.

Terminales GSM de código abierto

2010-12-29T19:30:00.050+01:00

Cuando conté ayer de cómo se consigue capturar una llamada de GSM, había algo que no me cuadraba del todo... Yo citaba en la charla cómo para capturar los datos se sustituía el firmware de un teléfono de 10€ por otro de código abierto llamado OsmocomBB. Sin embargo, era la primera vez que oía hablar de él.

En años pasados se ha hablado de una estación base de código abierto (openBTS) o un controlador de estaciones base de código abierto (openBSC), pero nada de teléfonos. Hay pocos fabricantes y son completamente cerrados, decía Harald Welte el año pasado. Pues bien, este año se ha tomado tres meses sabáticos para iniciar un proyecto más, OsmocomBB, que ha desarrollado toda la pila de protocolos (bueno, casi toda) de GSM a partir de cero (bueno, tenía de partida el código de openBSC).

Y en nueve meses, el proyecto ya puede mostrar un estado de avance considerable (aparte de servir para capturar tráfico como vimos ayer):

Pueden establecer canales de control para llamadas con y sin saltos de frecuencia
Pueden enviar cualquier dato por esos canales de control... incluyendo las solicitudes de llamada y SMS. En concreto en la charla han demostrado que podían acceder a todos los datos de control de potencia de la llamada, por ejemplo.
Pueden soportar enviar audio en los canales de tráfico, es decir, establecer llamadas (y también lo han demostrado en la charla)

Todo esto, con la posibilidad de captura y decodificación del tráfico (han hecho todo esto con una versión de Wireshark modificada con soporte de GSM).

Eso sí, el desarrollo sólo sirve para el chipset de banda base que incluye el procesador de banda base digital Calypso, junto con el conversor a analógico y modulador en FI llamados Iota (TWL3025) y Rita (TRF6151), con el diseño que podemos ver en este diagrama.

El chipset ha sido escogido sobre todo por la disponibilidad de documentación y de teléfonos ampliamente disponibles (eso sí, de segunda mano porque desde 2008 no se fabrican): es la banda base de los teléfonos Compal/Motorola con nombres C1[1-5]? Como ejemplo, he aquí el teléfono con el que han hecho las demostraciones, destripado.

El acceso para programarlo se hace... por el conector de auricular, utilizándolo como RS232. Y no es que sea algo que se hayan inventado ellos, es el procedimiento estándar para acceder al firmware...

¿Qué queda por hacer? Bueno, todavía bastante: "hand-over" entre celdas, llamadas de datos, GPRS... y todo tipo de comprobaciones de seguridad. Harald sigue insistiendo que se deje de mirar al TCP/IP y se empiece a mirar a GSM, y el mundo será más entretenido, y posiblemente más seguro (sobre todo si tu teléfono es 3G). Como decía una compañía que ya no lo dice tanto: "La vida es móvil".

Llevando un teléfono Android ya no te perderás...

2010-12-29T18:15:00.080+01:00

Cuando uno tiene un teléfono móvil, puede hablar desde cualquier sitio. Por otro lado, la posibilidad de movilidad conlleva también la posibilidad de perderse, tanto intencional como no.

Contra esto la tecnología nos ayuda mediante los métodos de localización. Aunque para una localización precisa lo mejor es un GPS, tiene bastantes limitaciones: consume carga de batería, no funciona en interiores y no todos los teléfonos lo tienen. La alternativa más fácil, pero por otro lado poco precisa, es usar la identidad de las celdas GSM de las que el teléfono recibe la señal, ya que las antenas están todo el rato transmitiendo su identidad y hay bastantes maneras de traducir entre la identidad de la celda y su posición geográfica.

En la charla al respecto de Renaud Lifchitz, ha comenzado por contarnos que en realidad no es necesario disponer de una base de datos para hacer esa traducción, ya que se pueden aprovechar las API que Google utiliza para ello:

Por un lado, se puede intentar aprovechar el URL que Google Maps utiliza para este propósito, aunque en su experiencia no era muy fiable.
Más fiable es el API obsoleta de geolocalización de Google Gears, que aparentemente sigue funcionando y es bastante precisa.

Pero lo más preocupante venía en la segunda parte de la charla: resulta que los teléfonos Android tienen unos ficheros de log en los que van registrando los cuatro parámetros que forman el identificador de todas las celdas por las que va pasando el teléfono. Con lo que si hay un atacante que tiene acceso al log, puede reconstruir todos los movimientos del usuario accedido durante las últimas horas o hasta un día entero.

¿Es fácil que una aplicación maliciosa del Android Market tenga acceso a los logs? No es trivial, aunque la granularidad de los permisos funciona un poco en contra de los usuarios.

Por un lado, hay varias combinaciones de permisos que una aplicación maliciosa puede pedir para ello, la más ingeniosa es simplemente pedir acceso a lectura de los logs. No es necesario pedir acceso a Internet, ya que una vez leídos los datos interesantes, la aplicación lo único que tiene que hacer es escribir esos datos en el log, leer un puntero nulo, y entonces ya se ocupa Google de hacerle llegar los datos al atacante, en forma de log de fallo de la aplicación...

Menos complicado es simplemente desarrollar una aplicación con las bibliotecas de desarrollo nativas (NDK), que se ejecutan fuera de la "sandbox" de Android y por tanto tienen permiso de acceso a todo...

La charla ha terminado con una prueba de concepto en la que Renaud ha mostrado el resultado de analizar los logs de su teléfono después del viaje desde su trabajo a su casa... y ahora, claro ya todos sabemos dónde trabaja y dónde vive por si algún día las aplicaciones de Android nos impiden perdernos.

Rápida introducción a la psicología cognitiva...

2010-12-29T15:30:00.067+01:00

Los humanos en general no somos tan racionales como lo pensamos. En 45 minutos, Sai Emrys, ha hecho un repaso a una buena parte de los comportamientos más sorprendentemente irracionales que forman parte de nuestra naturaleza (en la línea de otros autores como Daniel Kahneman o Dan Ariely), proponiendo algunos posibles remedios. Os recomiendo la visión de la charla (creo que sólo las transparencias no permiten sentirlo todo, aunque no todo haya funcionado como se esperaba), yo me quedo con un par de lecciones:

Somos generalmente malos al estimar las probabilidades de las cosas:

El detalle nos despista: simplemente añadiendo detalles a la descripción de un hecho, pensamos que es más probable.
El miedo nos puede: cuando una cosa nos da más miedo, inmediatamente pensamos que es más probable. Por ejemplo, esto es lo que hace que pensemos que es más probable que acabemos muriendo a manos de un asesino en lugar de las nuestras propias (en USA es al revés -- pero creo que hay más países en los que sucede).
En el otro sentido, la familiaridad nos hace perder el miedo: es por ello que tenemos más miedo a los accidentes de avión que a los accidentes de coche. Y así ocurren los accidentes.

Aquí aparentemente la única solución es la que proporciona la estadística y los actuarios: no estimar intuitivamente sino usar los datos reales.

Sólo destriparé un punto más: en general, no podemos des-conocer algo. Una vez que nos presentan un hecho, no podemos ignorarlo por mucho que queramos. Por ejemplo, en la imagen inferior, clásica en los libros de psicología.

La primera vez no se entiende demasiado, pero una vez que se dice "perro" o "dálmata", todo está más claro y ya no se olvida nunca. De la misma manera, en la práctica el "difama, que algo queda" es triste pero cierto.

A mí me pasó algo parecido con el logo de Carrefour, en el que tras varios lustros mi hermano me dijo que entre las flechas había una letra C y desde entonces ya la veo... y no dejo de verla. Pero igual es una limitación mía...

Frente a esto, lo único que queda es fomentar el espíritu crítico: en vez de intentar confirmar lo que sabemos, intentar encontrar el dato o experimento que podría contradecirlo.

Y por supuesto, añadiré los libros recomendados en la charla a la lista de pendientes...

Charlas relámpago (día 3 sesión 2)

2010-12-29T13:48:00.000+01:00

Otro resumen de otras charlas relámpago. Lo mejor está al final: ¡realmente Dan Kaminsky sí tenía una charla en el 27c3! (pero no sobre DNS o DNSSEC):

Una metacharla sobre cómo hacer charlas relámpago. Bastante clásico, pero puede servir para cualquier presentación corta.
La historia de cómo se crea un hackerspace en Galway. Lo más importante es la comunidad.
Petición de ayuda para crear un directorio de sistemas libres y gratuitos y muchos otros atributos deseables para una plataforma que se pueda usar y compartir.
El Chaos Codegolf Challenge: un concurso del CCC para conseguir el código más corto para un par de problemas.
Los problemas legales de Skype: Ilustra el proceso por el cuál Skype dificulta la investigación sobre sus protocolos. La cuestión es que su departamento legal es muy eficiente para impedir la investigación, y si no se responde adecuadamente, la defensa legal puede ser cara.
Un grupo que se dedica a analizar datos (de varias fuentes) sobre violaciones de derechos humanos, que han conseguido detenciones en Guatemala y Chad, pidiendo reconocimiento y apoyo.
CryptoMinSAT es un software que resuelve problemas de "Boolean satisfiability", el mejor de acuerdo al presentador. ¿Y qué es eso? Pues un problema difícil de resolver, NP, pero que el presentador no ha explicado en sus 4 minutos... Y la página de la competición que va ganando, tampoco.
Creeper: Un par de sitios web suecos y otro alemán han creado unas pequeñas imágentes que controlan si alguien del gobierno o de periódicos accede a una determinada página (obviamente, los sitios web tienen que incluirla). ¿Qué tal hacer eso en otros países?
Bilbioteca CUV: Permite hacer prototipos rápdiamente mediante Python para usar el entorno CUDA de Nvidia (para utilizar tarjetas gráficas para hacer cálculos intensivos), según ellos es tan fácil de usar como Matlab o Numpy.
Otro hackerspace: Shackspace, en Stuttgart, en busca de un nuevo local.
Un pequeño proyecto que intenta hacerle la competencia a Google: Seeks, utiliza la búsqueda y navegación colectiva para intentar juntar a las personas que buscan lo mismo y ofrecerse los resultados unos a otros.
Un proyecto para falsificar tickets enviados por SMS en Austria: coupwn. Por ahora sólo vale para N900.
Penpho: un programa que permite cifrar con RSA y AES256 las fotos de un móvil de modo que no puedan ser descifradas por nadie que te capture el móvil. Ni siquiera por ti mismo, para ver las fotos tienes que sacarlas del móvil.
DanKam: Realmente Dan Kaminsky tiene una charla en el CCC, pero esta vez no es acerda de DNS: ha creado una pequeña aplicación para iPhone (de pago, $3) que ayuda aquellos que són daltónicos aumentando el contraste de color, y haciendo los rojos más rosas y los verdes más azules, y permitiéndoles funcionar mejor en la vida diaria.

Otro sitio más donde buscar troyanos...

2010-12-28T23:45:00.062+01:00

Para terminar el día más intranquilo, Ralf-Philipp Weinmann nos ha contado otro sitio más dónde un atacante podría esconder un troyano que registre todas nuestras claves y las transmita a algún sitio dónde nos suplantarán para oscuros propósitos.

Resulta que todos los portátiles manejan el control de temperatura, los ventiladores, los LED, la carga de la batería y el teclado con un controlador integrado (EC, embedded controller). Este controlador es en realidad un pequeño procesador que funciona a 10 MHz. Las primeras versiones utilizaban ROM, las siguientes EPROM pero todas las actuales funcionan con Flash ROM.

Por tanto, cambiar el programa de ROM por uno malicioso dejaría a disposición de un atacante un procesador con capacidad para almacenar de 4 a 60 kB de pulsaciones de teclado e incluso comprimirlas para que ocupen menos.

¿El problema? Sacar los datos de esa memoria... Descartando la vía fácil de infectar también el procesador central (parte de lo que hace este tema preocupante es que se puede reinstalar totalmente el sistema operativo y este troyano ni se inmuta), Ralf nos cuenta un par de maneras de hacerlo:

Una relativamente difícil de recibir, aunque podría utilizarse remotamente de manera casi invisible sería codificarlo en los retrasos entre pulsaciones de teclado... lo cual requiere que el usuario envíe pulsaciones remotamente... no muy sencillo.
La que se ha demostrado en la charla en realidad envía las pulsaciones de dos maneras: dado que el procesador controla también los LED, el primer camino es modular de manera invisible la luz de los LED del ordenador. Pero además resulta que en los ordenadores Thinkpad atacados, el LED está en la parte de arriba del ordenador y el controlador está cerca del teclado, por lo que modulando la luz además se dispone de una antena... que puede emitir en varios MHz ya que el procesador funciona a 10 MHz, recibiéndose a una distancia moderada (aunque eso no se demostró en la charla).

Eso sí, la opción de usar los ventiladores... la descartó por el exceso de ruido.

¿A cuántos ordenadores aplica este ataque? Ralf sólo ha creado una modificación para el procesador Reneses RS8 que tienen los ordenadores ThinkPad y que está muy bien documentado. Pero dice que el mercado está en manos de un número relativamente pequeño de procesadores (ENE, ITE, Nuvolon y Fujitsu), tres de los cuales tienen más o menos el mismo tipo de procesador basado en los controladores 8051 y 8052.

Aunque los Apple están a salvo de este ataque porque conectan el teclado directamente al ordenador vía USB (¡!), eso no significa que no se pueda atacar directamente su teclado...

¿Soluciones? Pues la sugerencia es tener un repositorio centralizado de firmas de los "firmwares" de los controladores de cada ordenador, de modo que por ejemplo en el arranque se pueda comprobar que un ordenador no está comprometido. Por ahora estamos relativamente seguros porque su "firmware" modificado no va a ser publicado...

Recuperar datos de discos duros

2010-12-28T22:45:00.062+01:00

¿Se te ha caído el ordenador al suelo y el disco duro ya no se mueve? ¿Se te ha caído el USB a la piscina o a la barbacoa y todos tus archivos de meses ya no se pueden leer?

Bueno, pues existe una compañía de recuperación de datos que hará lo imposible para recuperar tus datos de lo que quede, como nos contaba Peter Frank.

La charla estaba maravillosamente ilustrada de ejemplos como el de arriba (irrecuperable). Básicamente contaba que los principales problemas irrecuperables para discos duros son la pérdida de la superficie magnética, tanto por arañazos de las cabezas (lo más frecuentes, en el de arriba lo dejaron girar demasiado y no quedó nada) como por otras causas.

A partir de ahí, si no tiene muchos arañazos lo que es fundamental es hacer girar los discos en otro eje y con otras cabezas lectoras, y es casi indispensable que sean las mismas (lo cual no es fácil, porque acaba siendo que bajo el mismo modelo se entregan discos mecánicamente diferentes). Uno de los problemas más frecuentes en las caídas es que el eje se dobla y entonces el disco no puede girar (y cambiando de eje se suele poder recuperar). Si no se consigue hacer girar el disco se pueden leer trozos, pero tan despacio que la recuperación es casi imposible.

En general, el resto de los problemas (incendios, inundaciones, etc. ) son recuperables siempre que el disco no haya sufrido químicamente. Para presumir un poco nos puso una foto de su despacho (lo siento, pero me salió un poco borrosa).

Para los discos de estado sólido, la cosa es mucho más binaria: si el chip está entero, en general se puede desoldar y leer con una máquina lectora. Otra cosa es que el sistema de ficheros esté corrupto debido a errores en el software, en el que la recuperación es mucho más incierta.

¿Cómo cifraríamos todo el tráfico de Internet?

2010-12-28T21:15:00.161+01:00

Pues con mucho cuidado.

Justo cuando estaba pensando que era una lástima que uno de los oradores que más me gustaba de estos congresos era Dan Kaminsky he estado en la charla de djb, Daniel J Bernstein, que propone una aproximación a la seguridad en internet enteramente opuesta a la que proponía Dan el año pasado.

Y cuando digo que es opuesta es que la mitad de la charla ha sido para apuntar todos los problemas que presentaría añadir más seguridad a Internet mediante DNSSEC:

Para empezar, el hecho de que los servidores DNSSEC incluyan certificados en sus respuestas en lugar de lo que habitualmente responde un servidor de DNS (direcciones), hace que los paquetes de respuesta sean mucho más grandes que las preguntas. ¿Es esto un problema? En sí no lo es, pero resulta que (por ahora) es fácilmente explotable para crear denegaciones de servicio, ya que si se falisfica la dirección origen, se puede hacer que el servidor envíe hacia la víctima un tráfico mucho mayor del que dispone el atacante (factor de amplificación: entre 30x y 50x). Y según cálculos que ha mostrado en la charla, la implantación de DNSSEC está teniendo un éxito relativo y ha crecido el último año hasta llegar a 2,5k servidores (una gota de agua, todavía) que conjuntamente podrían conseguir un tráfico de 10-40 Gb/s. Esto da por supuesto que los propietarios de los servidores no tienen ningún tipo de protección y que se puede suplantar la dirección origen... algo que cada vez es más difícil en las redes comerciales.
Muchas implantaciones de DNSSEC son más bien de cara a la galería, por ejemplo .org ya tiene DNSSEC, pero fundamentalmente es para decir que ninguno de sus dominios de siguiente nivel (cita por ejemplo wikipedia.org) está realmente firmado.
Las respuestas de DNSSEC son seguras porque están precalculadas "offline" y por tanto son estáticas, pero la web es dinámica (por ejemplo para balancear el tráfico) y por tanto difícil de firmar. Esto mismo hace que sea una pesadilla actualizar los certificados de una raíz.

Curioso que Kaminsky parece que acepta la crítica de que las respuestas de DNSSEC son relativamente grandes en un post de hace un par de días, aunque por supuesto no piensa que eso sea razón suficiente para abandonarlo.

Pero directamente a la propuesta: el uso de criptografía de clave pública de 256 bits mediante curvas elípticas. Resulta que este cifrado ha mantenido su complejidad desde 1985, a diferencia de otros tipos cuyos ataques se han ido simplificando con el tiempo (RSA, MD5, DES...). Además ya existen implementaciones con gran capacidad: djb cita que esa implementación es capaz de crear 10M de pares clave pública/privada (la operación más compleja de los cifrados con clave pública) en 10 minutos.

Nota al margen: dentro de sus argumentos para identificar qué es seguro o no, djb pone el límite de lo que es alcanzable hoy en día en 2^80 operaciones, que estima que son 2048 tarjetas gráficas calculando durante un año, o una pequeña botnet utilizada únicamente para criptografía... Pero eso quizá será el tema de otra charla.

Utilizando por tanto el hipotético protocolo CurveCP, basado en UDP, con cada paquete cifrado independientemente y con el control de flujo en la parte cifrada (reimplementando TCP pero protegido), se tendría por fin una Internet segura (confidencial, íntegra y disponible, que son los tres atributos que djb propone como básicos para la seguridad de las comunicaciones).

Como en realidad además hay que arrancar de alguna manera, propone añadir una modificación de este protocolo al DNS, el DNSCurve, de modo que con el mismo tipo de cifrado se puedan conseguir transacciones DNS seguras. Eso sí, para la raíz y por ejemplo .com propone que quizá no sea la mejor idea tener un único certificado para proporcionar redundancia...

Hay que aceptar que djb es casi tan buen orador como Kaminsky, pero en realidad el tiempo y las implementaciones dirán si su idea es práctica. Aunque sea más segura, su impacto en la red es mucho mayor, ya que no hay reemplazar sólo el DNS sino prácticamente todo el tráfico de Internet... que es precisamente el título de la charla.

Desensamblando Stuxnet

2010-12-28T19:00:00.001+01:00

Uno de los clásicos del CCC, Felix 'FX' Lindner, de Recurity Labs (aunque normalmente al CCC viene como FX de Phenoelit en su charla usaba los logos de Recurity), ha contado en una entretenida charla cómo construyó un desensamblador de código STEP7 para los PLC programables S7 de Siemens.

¿Y por qué una materia tan exótica puede ser interesante (las charlas de FX suelen ser de las que se llenan en el CCC)?

Fundamentalmente porque este código ensamblador estaba en la carga del virus Stuxnet, que es uno de los temas de moda de este congreso (en una charla que me perdí). El objetivo no se conoce del todo, pero parece ser que las centrales nucleares de Irán utilizan estos controladores... y suponemos que orderandores con SO Microsoft.

Además, el virus tenía un nivel des sofisticación elevado: utilizaba cuatro errores de Microsoft que aún no habían sido arreglados, estaba depurado de manera que no tuviese fallos (muchos virus se conforman con funcionar bien un gran porcentaje del tiempo, ya que tienen posibilidad de hacer muchos intentos), y claramente era el producto de un equipo bien coordinado (con diferentes especialidades, ya que cada fallo estaba en una parte diferente de Windows) y con conocimientos muy específicos.

Parte de la razón de la charla es que nadie tenía muy claro qué hacía el virus realmente, cosa que se pudo averiguar con el desensamblador de FX, que incluye saber que las partes del código son relativamente antiguas, y en concreto la última es del 24/9/2007, casualmente el día en que Ahmadineyad hizo un discurso muy duro en la Univesidad de Columbia...

¿Cómo va eso de ir a la Luna?

2010-12-28T16:45:00.002+01:00

En una segunda parte de la charla del año pasado, los científicos a tiempo parcial han vuelto este año, insistiendo que la mayoría de ellos realmente tienen otros trabajos y planean enviar a un robot a la luna... en su tiempo libre. Y lo están haciendo bien, según una clasificación en Internet (de EVAdot), tras 18 meses de desarrollo van segundos.

Lo primero que han presentado es una nueva versión de su robot, llamado Asimov R2, que podemos ver en esta foto sacada de su web, comparado con el R1 que nos enseñaron el año pasado.

Una de las novedades más visibles es que han añadido ya las cámaras y lentes con las que capturarán las imágenes de la Luna. Son alemanas (de su nuevo socio Schneider Kreuznach). También han añadido un nuevo diseño para los motores capaces de funcionar en la Luna, pensando también en el calor (120º) del día lunar, ya que sin aire es más difícil disiparlo.

Como todo esto hace que los prototipos del robot es caro (>10k€), por lo que han hecho una segunda versión con servos y materiales que son asequibles. También usan la BeagleBoard. Se llama el Asimov R0 y se puede conseguir de ellos directamente (no tengo los datos todavía...). Y luego nos han enseñado un video de ese robot transportando una caja de Club Mate... como primicia. Aquí lo podemos ver reposando después de la función, al lado de su hermano mayor.

A continuación han contado algo más de lo que no contaron el año pasado: el lunar Lander, del que podemos la versión R0 ver esta imagen, construida a escala 1:10:

Tiene tres partes, de abajo a arriba:

El motor y los pod de aterrizaje.
El módulo de carga, donde va alojado el robot en una caja en posición de reposo en la que está plegado.
Los tanques de combustible. En el exterior de los tanques se incluyen los paneles solares que a la vez son una antena de radio (del tipo "phased array").

A continuación han hablado de sus progresos con el hardware electrónico, del que ya tienen controladores de motores y equipamiento que es capaz de encaminar paquetes IP teniendo en cuenta un entorno radiativo que puede cambiar aleatoriamente bits de los paquetes o los niveles de las señales.

Ya han decidido que van a emitir el video por DVB-S y las señales podrán ser recibidas por cualquier antena parabólica de 10m que uno tenga en el jardín... o donde le quepa. O sea que si llegan ellos los primeros todo el mundo podrá tener su propia señal de video desde la Luna.

Para terminar este repaso de la misión, nos han contado cuáles son las tres etapas del viaje hasta la Luna:

Lo primero es llegar a una órbita baja, a 100km (LEO). Eso lo hace el lanzador comercial socio del premio
Lo segundo, que tiene que hacerlo el Lander por sí solo, es pasar de la órbita LEO a una órbita lunar también baja (LMO, Low Moon Orbit). Esto se hace encendiendo los motores del Lander periódicamente en el momento justo.
Y el aterrizaje... que tiene que ser blando, de acuerdo a las normas del premio. Que no significa que haya que poner un colchón, sino que el módulo lunar tiene que sobrevivir al aterrizaje.

Han vuelto a explicar el Lunar X-Prize, pero como ya se contó el año pasado no lo voy a repetir...

El resto ha sido para hacer un poco de propaganda del proyecto, un punto crucial si lo que haces es sobre todo trabajar a tiempo parcial, lo cual te obliga a agradecer cualquier ayuda, como un grupo de estudiantes con los que están explorando ideas como por ejemplo crear prototipos del robot con Lego. Eso incluye los anuncios en primicia de que han acordado una alianza con la agencia espacial alemana, de la que piensan aprovechar su experiencia en crear robots para el espacio. Pero no es la única, han utilizado gran parte del año haciendo networking y consiguiendo socios para apoyarles en el desarrollo del software (TUHH), encontrar el sitio de la luna para aterrizar (Universidad técnica de Berlín) y las nuevas lentes del robot (Schneider Kreuznach).