lunes, 29 de diciembre de 2014

Charlas relámpago.

Unas pocas charlas relámpago de la segunda tanda del tercer día:
  • OONI: Es una infraestructura que mide irregularidades de las comunicaciones por Internet que pueden ser síntomas de una escucha o interferencia o conformado del tráfico de una comunicación: manipulación del tráfico (DPI, conformado, etc.) o bloqueos de contenido. Además, los datos son totalmente abiertos y públicos.
  • Blocked: Una web sobre los sitios web que bloquean cada uno de los proveedores de UK, en cada uno de sus servicios. Propone una mejora para el bloqueo de contenidos: añadir al protocolo HTTP los códigos 450 (bloqueado por control parental) y 451 (bloqueado por razones legales).
  • Campaña de Ciberpaz. Plantean un entorno en el que se plantee un control de todas las herramientas que puedan ser consideradas ciber armas.
  • Hacks con modems USB 4G. Se pueden hackear, al estar todos gestionados como una página web. En general, cuando se conectan al ordenador le crean un interfaz ethernet, pero el modem aparece también como otro equipo con su propia dirección IP que se puede accder (incluso desde fuera). Los portales web de los modems están muy mal hechas desde el punto de vista de seguridad, de modo que son sensibles a XSS, por ejemplo desde un SMS enviado al modem y en algún caso tienen incluso un CGI para ejecutar comandos. Lo más peligroso es explotarlos remotamente por ejemplo transformándolos en un teclado que daría un acceso remoto total a un portátil, lo rearranca, y en el momento en que rearranca se convierte en un CD-ROM... La charla iba acompañada de un vídeo que mostraba todos los pasos.
  • Nueva distribución de Linux, llamada Void, basada en el sistema de paquetes XBPS. Usa runit como sistema de init, no usa systemd. Tiene 4,5k paquetes. XBPS surgió como una alternativa a pkgsrc de NetBSD. De los 4,5k, 3,3k pueden ser complidados para armv6, armv7, etc. El sistema mide y optimiza todos los pasos de instalación.
  • Estado de la autenticación WPA Enterprise. Ese estándar está basado en 802.1x, que crea un túnel al servidor de auenticación RADIUS con PEAP/TTLS para enviar los datos de autenticación. Es susceptible a un ataque de hombre en el medio: si se crea una WiFi falsa, se puede capturar los login y password de los clientes que se intentan conectar a ella. El problema es que es necesario activar la comprobación de los certificados del servidor. En los móviles habituales, el estado es mixto: Apple permite distribuir los certificados necesarios con el perfíl de conexión, pero en Android no permite hacerlo de ninguna manera a pesar de tener la posibilidad por debajo... así que mejor no conectarse a la WiFi de empresa con un Android si no se quiere perder el control de la propia identidad.
Habia tres o cuatro más, pero había quedado a comer y me fui.

Construir un computador cuántico

Andreas Dewes contó en esta charla una introducción a la computación cuántica y describió el que él construyó como parte de su tesis doctoral, desmitificando un poco y aclarando el concepto.

Qué son y para qué sirven.

Originalmente, los computadores cuánticos se pensaron para simular sistemas de física cuántica, probablemente inspirados en una conferencia de Richard Feynman. Pero luego se vio que podrian ser útiles para otras cosas, en concreto en paralelización de algoritmos.
Mientras que en la computación tradicional se trabaja con registros binarios y puertas universales (como la NAND o la NOR) y la prueba de si un password es válido requiere tiempo lineal, en la computación cuántica se trabaja con qubits y funciones probabilísticas.
Un Qubit es una especie de átomo con dos estados, |0> y |1>. Todo Qubit estáen una combinación de esos dos estados, pero cuando se mide está sólo en uno de los dos estados.
Cuando se tiene un registro de varios qubits, cada qubit está en una superposición de los dos estados, y el registro total está en una superposisicón de los 2^N estados.
También existe un conjunto de puertas universales, pero lo que no se puede realizar con qubits es copiarlos, por lo que una puerta cuántica da como resultado el registro original y un cálculo específicoque es funcioón de para todos los qubits de entrada y sus 2^N estados.
Otro ejemplo de puerta útil es la de mezclado (la traducción que se me ocurre de "entanglement"): cuando se toman como entrada dos qubits y los asocia de modo que la salida es una combinación de |01> y |10>, de modo que si una salida está a 0, la otra estará a 1 y viceversa.

Algoritmos cuanticos

En el hipotético caso de que tuviésemos una función cuyo resultado fuese un bit de si, por ejemplo un password fuese válido o no, con un ordenador cuántico, se podría realizar un cálculo para comprobar todos los password a la vez, pero el problema principal sería cómo medir cuál es el resultado, ya que como el vector de resultado tendría todos los password posibles, el único estado que contiene el password correcto es uno de los estados menos probables del estado cuánto del sistema.
Andrew ha explicado que una manera es mediante el algoritmo de Grover (descubierto en 1996), que transfiere todas las probabilidades de los estados no interesantes al estado que nosotros queremos. Por ejemplo, para 10 qubits sólo hace falta hacer la operación de Grover 25 veces para restringir el resultado más probable al que nos interesa. El algoritmo de Grove tiene una complejidad de O(sqrt(N)). Para factorizar números, se puede usar otro el algoritmo denominado de Shor que es de O(log(n)^3).

Constuir un ordenador cuántico simple (de dos qbits)

Tras repasar por encima varios sistemas de realizar bits cuánticos, como la trampa para iones que puede llegar a 50-100 qubits, Andrew se ha centrado en procesadores cuánticos mediante superconductores. Se basan en las propiedades de los superconductores que son cuánticos a bajas temperaturas, y él hizo uno de dos qubits para su tesis.
Está basado en niobio que es superconductor a -264ºC y una unión cuántica que consiste en dos trozos de superconductor separados por un hueco de sustrato que conduce cuánticamente a bajas tempertuaras. Hay dos puertas de estas con un filtrado a ambos lados que lo separa del resto del circuito y una unión mediante un condensador que los acopla para hacer los cálculos.
Todo eso se introduce en un recipiente capaz de refrigerar a 20mºK.
Luego se encadenan los cálculos de varias puertas, y se repiten los cálculos varias veces para varias combinaciones con lo que se puede ver que el resultado correcto tiene probabilidades de 52-60% para ese estado frente a los otros tres.
Si se puede hacer un computador de dos qubits, ¿por qué no se puede hacer de dos mil (p.e. lo que haría falta para atacar un password RSA)? Una de las principales limitaciones es lo que se llama la decoherencia que es que el estado cuántico que liga todos los bits se desvanece al cabo de un tiempo. En los primeros sistemas cuánticos, sucedía al cabo de unos pocos nanosegundos, y además al aumentar el número de estados aumenta la dificultad de mantener la conexión entre todos los qubits la medición correcta de los resultados.

Estado del arte

Para terminar, Andrew ha repasado las arquitecturas cuánticas más avanzadas en las diversas partes del mundo:
  • UCSB con su arquitectura RezQu / Surface Code, que es muy parecida a la suya pero con más qbits.
  • Delft y Yale: utilizan resonadores de tres dimensiones (cajas metálicas donde los estados cuánticos se acumulan en determinados puntos por resonancia, en vez de microchips, que mantienen el estado cuántico más tiempo.
  • Un laboratorio de Yale que es el más avanzados en corrección de errores cuánticos: .
  • CEA Saclay: Sistemas cuánticos híbridos que se pueden transferir a centros NV en diamante. Esto queda muy poco claro, pero se explica en una charla posterior.
Para acabar, ha mostrado la evolución del tiempo de decoherencia a lo largo de la (corta) historia de la computación cuántica: de 1ns al principio de las investigaciones en 1999, hoy ya se llega a unos pocos centenares de us.
Como resumen, Andrew comenta que realmente vamos a tener computadores cuánticos en breve, pero probablemente de la mano de investigación corporativa o estatal que son los que tienen el dinero para hacerlo.

domingo, 28 de diciembre de 2014

El impacto de Heartbleed en CloudFlare

En mi última charla de hoy, Nick Sullivan nos habla de cómo se abordó Heartbleed en la empresa CloudFlare.
Desde el punto de vista de CloudFlare, lo que pasó es que un amigo notificó a Nick que había una vulnerabilidad en los Heartbeats de TLS, así que Nick recompiló SSL sin Hearbeats y los parcheo todos. Antes de que la vulnerabilidad fuese pública. ¿Por qué era importante en CloudFlare? Porque un millon de sitios Web están en CloudFlare.
El 7 de abril, después de dos horas (12:00 aprox.) CloudFlare ya anunciaba que todos los clientes estaban parcheados. A las 13:00 la noticia llegó a los medios, se creó heartbleed.com y la madre de Nick se aseguró de que su hijo estaba bien.
En ese momento, CloudFlare admitió un Hearbleed Scanner en su plataforma, que recibió de 10k a 20k escaneos por minuto. En total, unos 200M de escaneos.
Desde entonces. registraron todas las peticiones de hearbleed malformadas: 69% eran de una longitud de 16384, probablemente de ssltest.py, 22% de filippo.io y un 2% de longitud 0 (ZMap).
El problema de Hearbleed es que normalmente no queda registrado, se puede conseguir hasta 64k de memoria del servidor y esto puede tener todo tipo de datos secretos.
¿Qué permite OpenSSL descubir? En principio, nada, porque en la biblioteca de OpenSSL bignum se borra todo nuevo número que se crea o se destruye.
Pero para demostrarlo, crearon el desafío: crearon un servidor con una clave privada, y desafiaron a cualquiera que enviase un programa firmado con la clave privada. Pero llegó un tuit de Fedor Indutny en menos de 10 horas con la clave robada.
¿Y cómo se obtuvo la clave? No mediante Heartbleed, sino que había un segundo bug en OpenSSL, habia tres números que se liberaban sin borrarlos. Aunque no se conseguía toda la clave en cada petición, había varios métodos para conseguirla en varias peticiones.
Como consecuencia de esto, tuvieron que revocar los certificados, la revocación más masiva de todo internet, un orden de magnitud de lo que había hasta entonces.
Pero el problema es que el servidor de certificados revocados CRL no aguantó la carga, Chrome no comprueba OCSP y además no funciona bien; y el sistema de Google, CRLSets, no incluyó los certificados de Cloudflare.
Así que recurrieron a un hack en Chromium (en el código fuente del navegador) y revocaron sus certificados.

Conclusiones.

  • Descubrir cosas de código abierto no es sencillo de hacer.
  • Las nuevas funcionalidades deberían estar deshabilitadas por defecto.
  • Esperar lo inesperado.
  • Muchos de los ataques eran realmente escaneos como el de ZMap.
  • Crowdsourcing les ayudó a encontrar la solución a su duda sobre la vulnerabilidad.
  • No existe todavía una solución a la revocación de certificados
  • Hay que soprotar OpenSSL monetariamente.

¿Qué hizo Heartbleed?

En la penúltima charla del día, Zakir Durumeric de la Universidad de Michigan habla de que pasó después de que Heartbleed fuese descubierto.
En abril de 2014, cuando se descubrió el bug Heartbleed en OpenSSL se estima de que el 24-55% de los servidores HTTPS era vulnerable.
La extensión de TLS denominada Heartbeat permite establecer el estado activo de una conexión, no era muy usada porque en la mayoría de los casos se podía hacer eso a nivel TCP. El problema era muy sencillo: la extensión tiene un campo de longitud para los datos que se utilzaban como respuesta a la pregunta de si estaba vivo, que no se comprobaba al responder, con lo que se respondía con datos de otras partes de la memoria del servidor.
Una vez descubierto, el equipo de Zakir se puso a la tarea de modificar su herramienta ZMap para examinar el millón de mayores sitios web de Internet y si tenían la vulnerabilidad, a base de enviarles un paquete con una longitud de cero, que en las versiones correctas no devolvía ningún paquete y en las versiones vulnerables enviaba un paquete con cero bytes de respuesta.
48 horas después de publicarse, hicieron su scan, con el resultado:
  • 45% soportaban SSL
  • de esos, sólo 60% soportaban Heartbeat
  • De esos, 18% eran potencialmente vulnerables, ...
Con ese porcentaje, estimaron que entre 25% y 55% eran vulnerables.
¿Y respecto al resto de internet? se estima que el 11% de las direcciones IPv4 soportaban Heartbeat, y aproximadamente la mitad eran vulnerable, un 6% de las direcciones IPv6 eran vulnerable.
¿Cuándo se parchearon todos? Pues respecto a los top 1M, hacia el 19 de abril sólo había un 4% de ellos vulnerables, pero no ha bajado del 3% todavía.
El problema es que a partir de 22 horas después, ya había ataques indiscriminados a toda la Internet. Pero el número de atacantes era pequeño, sólo 11 equipos escanearon Amazon y la universidad de Michigan a la vez, lo que significaría que pocos hosts estaban escaneando toda la Internet, per sí que había más escaneos centrados por ejemplo en Amazon (201 hosts).
Pero midiendo el nivel de parcheado, se vio que los sitios que fueron notificados que eran vulnerables el 28 de abril tenían un nivel de parches un 50% de los que fueron notificados el 5 de mayo.
El problema más grave es que la vulnerabilidad requería cambiar el certificado de la web, pero sólo un 11% de los notificados lo cambiaron, y muchos de ellos los cambiaron por otros certificados con la misma clave pública que era vulnerable.
Conclusiones:
  • El ecosistema de código abierto no recibió la atención suficiente para evitar esta vulnerabilidad.
  • El ecosistema de HTTPS es muy frágil, después de Heartbleed hubo varias vulnerabilidades adicionales.
  • El uso de una PKI no está listo para revocar miles o millones de certificados de una vez.

Internet of toilets

En esta charla, una charla que es como los premios IgNobel, que primero nos hace sonreír y luego nos hace pensar, se presenta una panorámica de todos los intentos de poner toilets online.
  • Bathroom hall
  • En el MIT.
  • Un juego: You're in control, un juego en el que una pantalla se ve dónde está impactando un chorro de agua artificial
  • Internet Loo roll Browser: permite imprimir en el rollo de papel higiénico trozos de internet  para entretenerse mientras uno hace lo que necesita.
  • MSN iLoo: el primer WWW.C, con teclado impermeable.
  • Poo Power, del museo de Ciencia de Londres. No está claro si esto pasó de la fase de ideación, pero se estimaba que los 3M de visitantes podrían iluminar un edificio de siete plantas.
  • For free water, permite utilizar el agua de la cisterna para lavarse las manos después. Por supuesto, el agua de la próxima vez.
  • Shit happens, en São Paulo, Brazil.
  • Twit shitters.
  • Mike's toilet. Con un sensor ultrasónico que cuesta 30$, permite detectar la presencia de alguien en el toilet.
  • hacklab.TOilet, en Toronto, Canada. Es un arduino, pero desapareció después de investigar él sobre el tema.
  • c-base space station, Berlin. Instalada desde 2012, en este momento está parada por la renovación del lugar, pero funcionó en 2014.
  • Internet of Toilets, una instalación que muestra el agua consumida cada día con el hashtag #IoT.
  • Internet of Things Toilet, permite detectar cuándo se acaba el papel.
  • Smart loos at Heathrow Terminal 2. Cuentan anónimamente el número de personas que los usan, para avisar a las personas de mantenimiento para limiearlo, además de adaptarse a la demanda de cuáles son los más usados.
  • Bio-Bus en Gran Bretaña, que funciona con biometano entre el aeropuerto de Bristol y la ciudad de Bath.
  • El estado del arte en Japón: Neorest: Secador, extracción de olores, calentamiento del asiento, masajes, apertura automática de la tapa, tirado automático de la cadena, etc.
  • Estado del arte en Medicina: unos para uso médico, permite medir el nivel de glucosa y otros indicadores de salud.
  • Vulnerabilidad del PIN bluetooth: el fabricante del equipo Satis de SpiderLabs, tiene la debilidad es que cualquiera puede controlarlos remotamente al ser el PIN 0000.
Como resumen, se pueden controlar un montón de variables de los toilets: el consumo de agua, el uso del papel, la ocupación, el audio, análisis de los gases, mejoras del confort, uso para animales, en trenes, aeropuertos, su uso energético y médico.
Pero en realidad los inodoros son un problema a nivel global, y tienen su día, el ¿29? de noviembre.