viernes, 30 de diciembre de 2011

Hackeando el contador de la luz


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.

jueves, 29 de diciembre de 2011

¿Está tu impresora poseída?


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


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.

miércoles, 28 de diciembre de 2011

99% de servidores web vulnerables


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


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

martes, 27 de diciembre de 2011

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


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