jueves, 30 de diciembre de 2010

Extensión sensorial

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

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

miércoles, 29 de diciembre de 2010

Cuidado con las tarjetas de Chip

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

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

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

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)

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.

martes, 28 de diciembre de 2010

Otro sitio más donde buscar troyanos...

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

¿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?

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

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?

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

Capturar GSM

Como continuación de la charla del año pasado sobre la rotura del protocolo A5/1, viene Karsten Nohl junto con Sylvain Munaut, a mostrar cómo superar el último obstáculo que quedaba por saltar el año pasado: la captura del tráfico GSM del aire.

Para capturar una llamada, lo primero es identificar la ubicación del teléfono, que se hace a base de dos pasos: primero una consulta a la base de datos llamada HLR que es necesaria para localizar usuarios en "roaming" y que proporciona una ubicación a grandes rasgos.

Una vez localizado groseramente, a base de enviarle mensajes SMS estando en la misma celda (ya que para ello se envían mensajes en abierto buscando el teléfono) se puede averiguar los datos esenciales que permiten localizarlo, en concreto el TMSI y la celda concreta.

Cuando se hace una llamada, primero se activa el cifrado y sólo de manera cifrada se envía la secuencia de saltos de frecuencia que habría que capturar para identificar el patrón de saltos de frecuencia que sigue el teléfono, por lo que no es fácil distinguir una llamada (con un espectro de unos 200kHz) en un trozo de espectro de 35 MHz de un operador o la parte asignada en una celda (que aunque es más pequeña, siguen siendo varios MHz). Este era el principal problema que había el año pasado.

Aunque las agencias gubernamentales tienen dispositivos caros con un coste de decenas de miles de euros que capturan toda la banda, el foco de la charla es conseguir usar teléfonos baratos (que capturan sólo un canal GSM cada vez) para capturar el tráfico de un usuario.

El procedimiento utilizado es tomar cuatro teléfonos baratos, sustituirles el firmware por uno abierto que tiene capacidad para entrar en modo de monitorización, quitarle el filtro de la banda de subida ("uplink", esto es una modificación del hardware) para mejorar el rango de acción hasta los 100 metros y controlarlo por USB desde un PC. Sólo con proporcionar el TMSI se pueden capturar todas las tramas no cifradas que van en el canal de control (y las demás, solo que las cifradas... no se sabe de quién son).


Y el último paso es el descifrado de la llamada. Para ello han hecho una segunda versión de las tablas del año pasado que son un poco más rápidas. Sobre la captura obtenida por estos teléfonos, se intenta enfocar el trabajo en los primeros paquetes cifrados que están todavía en el canal común (antes de comenzar los saltos de frecuencia), cuyo contenido en unos casos es fácil de anticipar (sobre todo porque el relleno de los paquetes es sistemático). Una vez identificado el paquete y descifrado (y eliminados algunos falsos positivos), son capaces de recuperar la clave de sesión (que se reutiliza durante varias sesiones).

Y la charla ha terminado con la gran demo final, en la que con la clave de sesión capturada los teléfonos de escucha son capaces de seguir la secuencia de salto de frecuencias del teléfono víctima, y han demostrado una captura de una conversación en vivo.

Aunque no todas las herramientas han sido publicadas todavía, claramente la confidencialidad de GSM en este momento ya está en peligro... con cuatro teléfonos de 10€.

La charla termina con una nota de esperanza de cinco medidas que dificultarían este ataque:
  • Enviar los mensajes SMS directamente a la red origen dificulta localizar el teléfono.
  • Simplemente aleatorizando el dato de relleno de los paquetes GSM sería mucho más difícil este tipo de ataque, al hacer los paquetes mucho más predecibles.
  • Cambiar las claves de sesión más frecuentemente, idealmente para cada llamada...
  • Cambiar el TMSI más frecuentemente.
  • Mantener el "frequency hopping" (a pesar de lo que esto complica el ataque, hay operadores que aún no lo hacen).
En la tanda de preguntas no han identificado las vulnerabilidades de los operadores alemanes, pero dice que los cuatro tienen "capacidad de mejora" dentro de estas cinco coordenadas... (no ha divulgado el que no hacía bien el último punto).

Charlas relámpago (sesion 1 día 2)

Desafortunadamente no se puede estar en dos sitios a la vez, así que me he perdido una interesantísima charla sobre la ingeniería inversa del 6502 en el que han hablado cómo han conseguido reproducir el microprocesador a base de fotos de alta resolución a través de un microscopio... Pero he estado mentalmente en las charlas relámpago, de 4 minutos, de los temas más variados. Un resumen:
  • Un proyecto para crear una infraestructura de protección de datos privados, de modo que cualquier dato privado se almacena cifrado con una clave de su propietario.
  • El proyecto Starfish, que quiere hacer una red más distribuida que Internet. Lo que mejor lo describe es su gráfico... aunque por ahora no queda muy claro que tengan más que un concepto.
  • El proyecto Freedombox, correo, tor, almacenamiento de fotos, páginas web, etc. Todo esto transportable, con backup en el Freedombox de tu amigo. Y ya se ha identificado hardware que lo hace, todo ello basado en P2P para hacerlo más robusto que "la nube". De todas, quizá ésta es la más inspieradora de todas.
  • Mitch Altman, un clásico del CCC que es el autor de TV b-gone, ha anunciado su seminario de Arduino. Que empieza desde aprender a soldar y llega hasta montar un Arduino...
  • Telecomix DNS: Una raíz DNS alternativa, que desafortunadamente todavía no está disponible.
  • Una segunda charla sobre múltiples problemas de seguridad de SAP (ayer hubo una pero todavía no he terminado de redactar el post). Como ejemplo: hay protecciones para que no todo el mundo pueda acceder a las tablas de datos. Pero sin embargo, todo el mundo puede ejecutar el depurador de código... que permite cambiar los permisos de las tablas de datos. Interesantes las referencias para saber más:
  • SMS port scanner. Alguien ha escrito un escaneador de puertos SMS y lo está ejecutando en la red GSM local... No sé si quiero conectar mi teléfono a la red.
  • La TSA y los derechos. El autor de la charla sobre Psicología Cognitiva que no se dio ayer, nos ha contado su experiencia con los controles de seguridad de la TSA americana. Nos ha ilustrado que tenemos derecho a no usar los rayos X (aunque a cambio seremos registrados manualmente... siempre que haya que registrar... por ejemplo poco si se va en "shorts"), y que se puede declarar un zumo especial como un líquido médico. Y para todos aquellos que los controles de seguridad nos ponen de mal humor, va a hacer un seminario de meditación para estar calmado.
  • Un juego/seminario de seguridad: NetS-X, que permite aprender sobre seguridad de una manera más entretenida, pidendo ayuda para terminar de traducir toda la documentación.
  • Al final ha aparecido un hacker anónimo que ha contado cómo se replican los cables de Wikileaks...

Una impresora de cera para crear placas de circuito impreso

Para empezar el día, Jeff Gough nos ha contado cómo queriendo tener placas de circuito impreso rápidamente, se ha construido un prototipo de impresora de cera que imprime cera sobre una placa de cobre sin imprimir y luego se corroe con un baño químico.

Aunque primero ha contado por qué tener este proceso (que tiene sólo dos pasos: imprimir y bañar frente a los más de 16 que tiene un proceso industrial): los 3 días y 50€ que puede costar una placa comercial eran demsiado para él (sobre todo en la parte del tiempo, supongo que esos 16 pasos al final acaban sumando tiempo), lo más entretenido ha sido la pare de ingeniería de cómo lo ha hecho.

Básicamente ha tomado una cabeza de impresión piezoeléctrica de una impresora Epson (que básicamente funciona empujando la tinta mediante cambios de forma de material piezoeléctrico a través de 180 injectores entre color y blanco y negro) y le ha acoplado un bloque metálico que mantiene la cera caliente (a base de un transistor). En la foto podemos ver arriba el bloque y abajo la cabeza de impresión.



El proceso aún no está depurado del todo, aunque ha sido demostrado durante la charla, principalmente porque la adhesión entre el bloque metálico y la cabeza de impresión todavía no es perfecta (está buscando un material nuevo, ha probado la silicona pero sin aire no se solidifica).

Por supuesto, lo que más me impresiona es que pasó rápidamente por la parte más compleja: anclar la cabeza a otra impresora (con motores paso a paso más fáciles de controlar) y que funcione. Bueno, sí que ha mostrado que ha tenido que hacer ingeniería inversa de las señales necesarias para controlar la cabeza con éxito, que tampoco es trivial.

Para terminar, ha sugerido que la técnica también podría ser usada para impresión tridimensional de alta resolución, como el Makerbot, aunque todavía quedaría mucho por hacer...

lunes, 27 de diciembre de 2010

(In)seguridad de SAP

Viendo lo complicado que fue crear el virus Stuxnet sobre firmware de PLCs exóticos y pobremente documentadso, el experto en seguridad SAP Ertunga Arsal acaba reflexionando lo sencillo que sería dirigir virus a sistemas SAP para atacar a las mayores empresas del mundo.

Y es que no parece que haya más de una o dos empresas especializadas en seguridad SAP, y los potenciales agujeros son muchos...

En una típica instalación de SAP como la que se puede ver en el dibujo,


el protocolo más vulnerable es el protolo RFC (Remote Function Call), que se puede acceder desde múltiples APIs y desde la línea de comando, y que además permite la administración remota y la creación de usuarios con privilegios máximos (SAP_ALL). No sólo, sino que además puede ser encapsulado en SOAP y por tanto puede entrar en la empresa a través del proxy...

Otro punto de ataque son los ficheros donde se almacenan las credenciales de la autenticación unificada (Single Sign On), sassys.pse, y que se pueden utilizar para autenticar en el nombre de cualquier usuario, o incluso pueden ser accedidos por una RFC.

Y por supuesto, conociendo el lenguaje de programación de SAP (ABAP), hay múltiples posibilidades de inyección de código, a través de una llamada remota que permite ejecutar código almacenado en una tabla, otra que permite crear tipos genéricos sobre la marcha (RTTC) o incluso "EXEC SQL".

Y por si fuera poco, también puede añadir código a los ejecutables directamente, mediante la sentencia "INSERT REPORT" (con un cómodo editor gráfico), lo cual abre la puerta a la creación de rootkits de SAP que faciliten la tarea de "administración remota" de los sistemas.

Pero como siempre, hay que terminar con una nota de esperanza... Basta con auditar todos los problemas de seguridad, quitar las claves por defecto, restringir los permisos de los desarrolladores y mejorar los procesos de rotación de personal y de actualización de parches de SAP. ¿Y qué es eso para cualquier empresa del "Fortune 500"? Y supongo que contratar a Ertunga Arsal... :-)

Expositio Interruptus: Linux Desktop

A veces las cosas no salen como las pensabas. Datenwolf, un administrador de sistemas por profesión y desarrollador de motores de juego por pasión había preparado detalladamente su charla sobre los sistemas de ventanas de Linux (Desktop).
Pensaba exponer todos los problemas de arquitectura y complejidad innecesaria que hay en el entorno Desktop de linux:
  • La complejidad del entorno de sonido (la combinación de Phonon, GStreamer y PulseAudio)
  • Todos los procesos que se arrancan junto con Gdm para poder mostrar sólo la pantalla de login
  • La escasa protección que da la gestión de permisos que hace ConsoleKit (por ejemplo, su página de documentación está incompleta y no es fácil saber para qué sirve: cambiar los permisos del hardware local para que cuando un usuario entre sólo él pueda acceder -- y el resto no le pueda p.e. enceder la videocámara subrepticiamente)
  • El abuso de dbus que multiplica los interfaces y no resulta en interoperabilidad (cada programa crea su interfaz y no sirve para que se reutilicen entre programas)
  • Todos los defectos de la nueva gestión de la bandeja del sistema (comparado con el antiguo XSystemTray)
Pero el infierno está lleno de buenas intenciones y coincidió (¿quizá les avisó él?) que en la sala estaban los desarrolladores / mantenedores de GStreamer, de Gdm, de ConsoleKit que a cada observación le comentaban todos los principios de diseño que justificaban perfectamente la complejidad y despreciaban sus propuestas alternativas.
El caso es que sobre los últimos temas tuvo que pasar corriendo porque con todas las interrupciones creo que sólo consiguió cubrir satisfactoriamente la mitad del contenido... De todos modos, aunque quizá sus alternativas no fuesen demasiado buenas, sí que estoy de acuerdo con él que en algunos casos la complejidad es un poco alta...

Vías de ataque a "smartphones"

Aunque la charla de Ilja van Sprundel no mostraba demasiados ataques con éxito a smartphones, lo más interesante es la clasificación de los métodos de ataque para identificar aquellos que están menos explorados. Clasificaba los métodos de ataque en:
  • Primarios, a través de los protocolos directos de SMS, MMS y en general los protocolos comunes a todos los teléfonos. Aquí mostraba algunas ideas generales sobre los SMS que también han sido expuestas en otras charlas, pero su principal contribución es que en muchos casos el tcp/ip necesario para recibir MMS ha sido poco explorado como vía de ataque y además es una fuente muy valiosa para identificar el teléfono a base de enviar SMS falsos identificando un servidor MMS propio.
  • Secundarios, a través de los protocolos de aplicación comunes a otras aplicaciones (correo, web...). Aquí ha aceptado que no aportaba nuevas investigaciones.
  • Terciarios de proximidad: protocolos adicionales que requieren cercanía al teléfono afectado pero que por ese mismo método no siempre han sido bien protegidos (WiFi, bluetooth, infrarrojos e incluso banda base). Aquí ha señalado que la pila de comunicaciones por  infrarrojos (IRDA), que muchos teléfonos tienen procedentes de Linux, tiene bastantes errores explotables (ellos encontraron 3 en poco tiempo), pero que es un protocolo que ha perdido vigencia hasta tal punto que ya todos los teléfonos nuevos no lo llevan, o incluso hay algunos que lo llevan pero no llevan el software, así que toda su investigación... para casi nada.
  • Terciarios mediante aplicaciones maliciosas: aquí ya los problemas de seguridad no son sin conocimiento del usuario, ya que requieren que el usuario instale una aplicación maliciosa y cómo éstas pueden atacar al sistema  ya otras aplicaciones.
    • Aquí ha encontrado varias vías de vulnerabilidad en iPhones, a base de la función UIWebView, que permite crear UI directamente, aunque está protegida, también mediante los mecanismos que se usan para hablar entre aplicaciones, los URLHandlers que no tienen ninguna protección entre aplicaciones, mediante el visor de documentos que tiene que manejar tantos formatos que es imposible que los maneje todos bien y finalmente mediante cadenas de formato mal comprobadas, que es la vulnerabilidad mostrada en la charla.
    • Por otro lado, en los Blackberry se encuentra con un sistema mucho más robusto en general porque por ejemplo el navegador hace una interpretación muy simple de las páginas. Aunque la principal vía de ataque identificada es que aunque las aplicaciones pueden proteger su compartición de datos entre aplicaciones, las listas de acceso para protegerlas están desactivadas por defecto (¡!)

Ataques a teléfonos normales a través de SMS

En la charla de Colin Mulliner y Nico Golde sobre los ataques a teléfonos normales (¿tontos?) mediante SMS, nos han contado todo el proceso desde las pruebas hasta las posibles implicaciones de desastres totales en la red... :-)

En cuanto al método de prueba, en buena parte se basa en herramientas públicas, pero con añadidos propios. Han utilizado una versión de OpenBSC modificada para permitir inyectar mensajes y detectar los fallos de los teléfonos, además de una aplicación java en los teléfonos que monitoriza que los teléfonos sigan vivos.
Eso sí, no todo el mundo tiene una caja de Faraday como ellos para poder operar las pruebas sin necesitar una licencia de uso del espectro.
Con esto pueden automatizar gran parte del proceso de enviar 120 mil mensajes a cada teléfono para ver cuál de ellos tiene algún efecto negativo sobre el teléfono, variando los diferentes parámetros de un SMS que son vulnerables: la cabecera utilizada para mensajes multiparte, la notificación de MMS que tiene varias cadenas de longitud variable, los Flash SMS (una funcionalidad poco utilizada y por eso poco depurada) y el propio alfabeto del texto, sobre todo.

Contodo esto, ¿qué han encontrado? Pues que casi nadie se salva...
  • En el sistema operativo de Nokia S40, sobre todo en teléfonos antiguos (en los nuevos los errores ya están arreglados), hay un mensaje que causa que el teléfono rearranque. Además, hay un "watchdog" en el teléfono que si detecta varios rearranques seguidos, apaga el teléfono. Para empeorar las cosas, el error causa que el mensaje no sea confirmado, y así la red intenta reenviar el mensaje, causando los rearranques.
  • Sony Ericsson: Con un campo TP-PID inválido, el teléfono le pasa más o menos lo mismo que al Nokia, el teléfono rearranca. Eso sí, un teléfono se estropeó permanentemente.
  • LG: aunque sólo probaron con un teléfono (GM360), también era vulnerable a notificaciones de MMS alteradas que causan un "buffer overflow". En este caso, además si el teléfono tiene PIN se queda permanentemente desconectado de lared.
  • Samsung: en el caso del Samsung Star y el Corby, encontraron dos problemas: uno que muestra un mensaje de varios Megas que no se puede borrar y otro lo desconecta de la red sin que el usuario se entere (la maldición del silencio).
  • Motorola: Los Razr y Rockr son bastante frágiles y si se mandan mensajes multi parte incompletos no se muestran pero tampoco se pueden borrar. No lo probaron demasiado porque se caían fácilmente.
  • Micromax (un teléfono de la India, el tercer fabricante del país): También se desconecta de la red mediante un mensaje incompleto (pero Flash SMS).
Una vez encontradas las vulnerabilidades, los fabricantes al final no han sido fáciles de contactar: han conseguido reportar los problemas a Nokia y Sony Ericsson (que por otro lado son de los más grandes). El resto no han sido contactados, y las vulnerabilidades siguen existiendo.

El hecho de que algunas vulnerabilidades hagan que los mensajes no sean asentidos ha prmitido probar el tiempo de reenvío de los operadores alemanes: van aumentando el tiempo entre reenvios, y algunos se dan por vencidos antes que otros, siendo el que más intentos hace T-mobile, que además va aumentando gradualmente el tiempo entre intentos.

Si existen todas estas posibilidades de ataque, ¿qué problemas plantean? Por un lado, alguien podría atacar un teléfono concreto a base de enviar SMS cada segundo... lo cual sólo es útil si un teléfono concreto es muy importante.
Pero por otro lado, ¿qué pasaría si hubiese ataques a gran escala? Tres ejemplos de ataque:
  • Desconectar 10k usuarios a la vez de un operador móvil virtual. ¿sobreviviría su red a un grupo tan grande de usarios reconectándose todos al mismo tiempo? 
  • Alguien malicioso que ataca los teléfonos de un fabricante, para que parezcan malos podría arruinarlo...
  • Incluso se podría causar serios problemas a los servicios públicos de emergencia o a las grandes concentraciones de gente...
Pues todavía no lo sabemos, pero nos han contado hasta tres maneras de poder hacerlo:
  • Operadores de envío de SMS, que no suelen comprobar demasiado qué hacen los clientes (HSL, clickatell, routomessaging).
  • Crear una botnet con smartphones y utilizarla para el ataque. Tiene la ventaja que al atacante le sale barato... aunque todavía no es fácil de conseguir.
  • El nirvana sería claramente tener un enlace SS7 de verdad, lo cual sólo está al alcance de unos pocos....
Y el caso es que el problema no es fácil solucionarlo, porque estos teléfonos son tan baratos que unos fabricantes no ofrecen actualizaciones, o si las ofrecen en muchos casos dependen de los operadores porque personalizan los teléfonos, e incluso si funciona, no hay manera fácil de comunicáreselo al cliente (sólo aparecería en la aplicación de actualización que la verdad, casi nadie utiliza).

La conclusión es que claramente es necesario mejorar este proceso de actualizaciones de los teléfonos y revisar su seguridad.

Perfilar usuarios web y romper su anonimato

La creación de Internet mejoró el anonimato que se puede tener en la vida diaria, como muy bien ilustró una clásica viñeta de Peter Steiner:


Pero la tecnología avanza, y por un lado los autores de las páginas web y las autoridades investigan maneras de encontrar los rastros de la navegación y por otro lado se han creado herramientas anonimizadoras como Tor, JAP (mencionada porque sus autores vienen al congreso al ser alemanes) y otras que yo no conocía como PHProxy o Glype (que sirven para filtrar el javascript de las páginas que se cargan para evitar que deje huellas).

En la charla de Dominik Herrman y lexi sobre "Usar anominmizadores y ser pillado de todos modos", analizan varios aspectos de cómo estas herramientas de anonimización no protegen totalemente a los usuarios:
  • Por un lado, los anonimizadores de Javascript tienen múltiples limitaciones que todavía podrían permitir identificar al usuario: el usuario sigue enviando múltiples cabeceras al servidor web e incluso permite el acceso del javascript a ciertas características del ordenador y el navegador que conjuntamente pueden identificar únicamente al usuario (el tamaño de su pantalla, el navegador, el reloj y su comportamiento de desviación, etc.). Pero no sólo: desde Javascript se pueden cargar applets de Java y al revés, las applets Java pueden ejecutar código Javascript localmente.
  • En otro estudio han mostrado cómo aunque un bot que se baja páginas cambie su atributo "User Agent" para intentar parecer un usuario normal, el conjunto del resto de las cabeceras siguen permitiendo diferenciarlo de un usuario normal.
  • Por otro lado, únicamente utilizando los hostnames (tal y como se podrían obtener los datos de Google DNS u Open DNS), se hizo un experimento con 28 usuarios voluntarios, en el que se entrenó a un reconocedor en los patrones de navegación (qué sitios se visitan y en qué orden y durante cuánto tiempo), y luego se aplicó durante 57 días de datos de navegación. ¿Resultado? En el 77% de los casos se podía identificar de qué usuario era una determinada sesión correctamente. Y esto se mantiene incluso si las sesiones son de corta duración (como los 10 minutos que tarda Tor en cambiar de dirección).
  • Una de las partes que más me ha hecho pensar es cuando han empezado a analizar el tráfico cifrado de varias herramientas de anonimización (Tor, JAP y otros proxy de un sólo salto), que es capturado en la red local del usuario (como por ejemplo seguro que estará ocurriendo con mi tráfico aquí en el BCC). Pues resulta que si se dan un par de condiciones (se conoce el SO y el navegador del usuario), y el usuario sólo está descargando una página por vez, resulta que se puede identificar qué sitios web está visitando el usuario. ¿Cómo se hace? Se navega con un ordenador conocido a los 775 sitios de internet más populares, se miden los tamaños de los paquetes en 20 descargas cada uno y se pasan por un par de herramientas de inferencia (llamadas Bayes ingenuo multinomial y Máquinas vectoriales de soporte... no, no han llegado a explicar en detalle). ¿Resultado? Todos los proxys de un nivel se identifican con una probabilidad del 95%, JAP del 20% y Tor sólo un 3%. ¿Podríamos pensar que estamos seguros? Pues no del todo, porque otro investigador, mejoró el procedimiento y ya conseguía un 50% de aciertos en Tor y un 60% de aciertos en JAP
  • Por último, aplicaron el mismo algoritmo a un problema similar pero diferente: dado un conjunto reducido de servidores (con contenidos prohibidos por algunas religiones, por ejemplo, y no estamos hablando precisamente de jamón), intentar identificar si un usuario los está visitando. ¿Resultado? Pues para poder identificar con una tasa de falsos positivos inferior al 1% es necesario únicamente obtener muestras de sólo unos dos mil sitios extra. Claro que todavía la tasa de identificación positiva es relativamente baja (un 67%).
Pero se despiden dándonos un consejo para evitar todos estos algoritmos: hacer dos cosas a la vez. Si en estos algoritmos mezclamos dos tráficos diferentes por la misma conexión, los algoritmos siguen sin poder hacer nada... Basta con un reproductor de radio por Internet, por ejemplo.

De robot a robot

He estado en una charla, que trata de una manera de conseguir más hackers para mejorar el mundo. Pero claro, ¿por qué queremos tener mas personas de ese tipo en el mundo?

El razonamiento de Robert Spanton es que eso va a permitir mejorar nuestra vida en general. El ejemplo que ha puesto es que el piensa que los bancos tendrían que tener una API, no porque queramos sacar todo el dinero más rápido del banco o gestionarlo mejor, sino porque eso abre infinitas posibilidades que no se pueden imaginar cuando se crea el API.

El ejemplo que ha puesto es el del "MIT proverbial wallet", tres tipo de carteras enlazadas con los bancos con características originales: una se abre más difícilmente cuanto menos dinero haya en el banco, otra que vibra con cada transacción y una tercera que se hincha a medida que el saldo del banco sube (supuestamente como la cola del pavo real, para impresionar a las mujeres). ¿Quién podría imaginar que para hacer algo así es necesario algo tan técnico como tener una API para el banco?

Pues el razonamiento es el mismo: ¿Quién podría pensar que tener más hackers pueda desarrollar más la sociedad?
Bueno y hacia el objetivo, ¿cómo conseguir más hackers? Robert comenzó contando su historia: se inició en en un club de robótica, que desarrolló en seis semanas un robot capaz de participar en un concurso en USA. Éste en concreto fue su robot (le falta la horquilla, que tuvo que ser desmontada)

Pero cuál era su problema: que todos los concursos en los que podía participar estaban en USA o Canadá, e ir hasta allí requiere una gran cantida de financiación, que para unos estudiantes no siempre es fácil de conseguir.
Afortunadamente, consiguieron interesar a la fundación Motorola para crear un concurso de robótica en Reino Unido en 2008. El concurso tiene varios juegos, que varían cada año, pero lo más importante es que los organizadores les dan a todos los equipos un kit de hardware, software y tutoría (lo más importante, conseguir que sepan qué hacen). Con eso, los estudiantes desarrollan robots como éste:

Que en realidad, aunque no era muy bueno en su tarea (tenía que coger los bloques rojos y subírselos encima), como lo intentaba incansablemente y a veces lo conseguía, consiguió la mayor conexión con el público, que lo animaba como a ese niño que está aprendiendo.

El proyecto está basado en una tarjeta llamada BeagleBoard, al que le añaden tarjetas de interfaz para actuar sobre motores, para recibir datos de una webcam, etc. Este año, le han incluido un display que es el mismo que el que usan las PSP (y se puede jugar al doom con él).
El entorno de desarrollo se programa en Python, está aquí.Y todo ello los estudiantes participantes lo reciben gratis para participar en el concurso... me dan ganas de entrar en Student Robotics para apuntarme a concursar. Pero claro, yo no necesito que me convenzan para que me guste hacer robots (sólo necesito un par de clones...).
Nota de humor: en vez de reuniones, que son muy aburridas, tiene acciones, donde todos se juntan para hacer cosas.

Bienvenida...

Como todos los años, el congreso comienza con una charla introductoria de Rop Gonggrijp en la que se reflexiona sobre el congreso, cómo de difícil ha sido este año conseguir las entradas y vencer a la nieve para llegar, lo importante que es el congreso para el mundo en general... y una nota de humor al final:
Habitualmente Nick Farr, viene con una chaqueta, pero para demostrar que los frutos del caos no son incompatibles con vestir bien, se ha demostrado que cada vez más asistentes vienen con chaqueta... y claro, Nick Farr, ha tenido que venir con un "hoodie" estilo hip-hop, y le han colgado un reloj gigante con una nota de originalidad: no es un reloj gigante, sino un medidor de ancho de banda... en Mb/s y con bittorrent como medida máxima
Damos por comenzada la recolección.

Luchando contra los elementos...

Bueno, está visto que viajar a Berlín en invierno es siempre una aventura... Y por supuesto, aunque el aeropuerto de Berlín está acostumbrado a la nieve que hay por todas partes (ayer aterrizamos en una pista nevada sin pestañear), y en el de Madrid no hay ni rastro de nieve (todavía), el avión viene de París, donde tienen nieve pero no están acostumbrados...

 ¿Resultado? 3 horas de retraso... Pero finalmente, el cohete está a la vista.

sábado, 25 de diciembre de 2010

Preparándose... vamos en son de paz

Entradas del CCC, hotel, ropa de abrigo, controladores, anticongelante... Creo que está todo así que salvo nevadas en Madrid esta noche, Alguien de Alguna parte va a ir otro año más a recoger los Frutos del Caos.

Y aquí está mi versión alternativa del banner del 27c3, en el que el congreso viene en son de paz y el contacto está a punto de suceder.

martes, 27 de julio de 2010

Frutos del Campus: vulnerabilidades de navegadores.

Sección especial aprovechando que en verano es la Campus party, donde también hay alguna presentación de seguridad interesante, y dispositivos interesantes (aunque mayormente son mods como éste)




O éste.



Bueno, este no es realmente un mod, es auténtico...

Pero no nos desviemos, Rubén Santamarta, de Wintercore ha dado una charla interesante sobre como todos los navegadores tienen fallos, y los seguirán teniendo por siempre (aunque su favorito como más seguro de todos es Chrome). Y como ejemplo, ha mostrado tres fallos con sus explicaciones recientes:
  • Una disección de cómo se hizo el ataque "Aurora" a Google, básicamente un script que aprovechaba una vulnerabilidad de Explorer de "use after free": poner código en el "heap" y aprovechar que al liberar la memoria no se borra para hacer saltar la ejecución hacia allí, ejecutado desde un puntero no inicializdo. Todo esto, aprovechándose de la ingeniería social, haciendo creer a un empleado de Google que el enlace malicioso provenía de alguien de su confianza.
  • Otra vulnerabilidad recientemente publicada por él, mucho más destructiva ya que afectaba al plugin de Java de Internet Explorer, Firefox e incluso Chrome, y que consiste en utilizar una opción no documentada del comando que ejecuta ficheros de java para introducirle una dll maliciosa y que por tanto permite tener permisos ilimitados en el ordenador local. Y pensar que este problema estaba ahí desde hace años...
  • Y por último, una vulnerabilidad presentada en Rootedcon, que permite hacer XSS (ejecución de código malicioso propio en páginas de otros), mediante cambios en la configuración de los ficheros que autentican los complementos ActiveX. Y lo peor es que parece que hace un mes que está en una página de la AEAT... sin arreglar. ¡Pobres contribuyentes! Encima de pagar, poseídos...