Cómo salir del cuadro de dialogo que te ha bloqueado Blogger porque te quedaste sin Internet

Que yo publico todos los días es algo que podéis ver en los artículos del blog diariamente. Eso me obliga a tener que conectarme desde cualquier ubicación, ya sea en medio de las montañas, en países de todo el mundo, en mitad de una ciudad, un avión, o en el medio del mar mientras me mecen las olas. Y por supuesto, muchas veces tengo problemas con la conectividad mientras estoy trabajando.

Figura 1: Cómo salir del cuadro de dialogo que te ha

bloqueado porque te quedaste sin Internet

En estas situaciones, me he topado muchas veces con un problema con Blogger. Me permite trabajar off-line bastante bien, pero tiene un par de situaciones de "Deadlock" en las que me quedo bloqueado sin poder grabar el contenido. Como eso me obligaría a re-escribir el artículo completo, aprendí un workaround que es lo que os voy a contar hoy.

Figura 2: Escribiendo un post en Blogger tranquilamente

En la imagen anterior estoy escribiendo un post en mi blog, tranquilamente. Tengo conexión a Internet - o no -, pero sigo trabajando tranquilamente. De repente, quiero poner un enlace y no me doy cuenta de que estoy sin conexión a Internet, y entro en un "Dead-end".

Figura 3: He querido poner un hipervínculo y sin conexión no puedo hacer nada.

En esta situación, la opción de "Apply" no está funcionando, y la tecla de ESC - mi querida tecla roja - no está funcionando, así que no puedo tocar nada más del interfaz. En mi primer incidente de este tipo, restauré la conexión a Internet, esperando que se activara la opción de "Apply", cambiando el enlace varias veces, pero nada.

Figura 4: Una vez roto el cuadro de diálogo, ni con Internet se arregla

Así que automaticé un workaround que, como me ha pasado estos días, os lo cuento hoy. No hay más que entrar en las herramientas de Developer en Google Chrome y buscar el cuadro de diálogo en la sección de ELEMENTS, que está dentro de un DIV y que en el UX se ve resaltado en azul y con el DIV asociado.

Figura 5: Elimina el DIV del cuadro de dialogo y listo.

En Blogger no es suficiente, porque hay una capa que bloquea el acceso al resto del interfaz incluso una vez que hayas borrado este DIV. Así que con un poco de paciencia, encuentras el bloqueador y a borrarlo.

Figura 6: Borra también la capa que bloque el UX

Una vez que hayas borrado estos dos elementos, ya puedes volver a disfrutar del IU, en este caso, de Blogger, y una vez restaurada la conexión, guardar todos los cambios que hayas hecho mientras el equipo estaba off-line.

Figura 7: El UI de Blogger restaurado para que guardes tus contenidos

No sé si esto te ayudará en alguna ocasión, pero a mí me ha salvado la vida varias veces, al evitar que perdiera el trabajo que tenía hecho mientras estaba off-line, porque estos cuadros de diálogos no están preparados para el modo off-line. ¿Es un bug de UX? Pues sí, creo que deberían arreglado, pero llevo tanto años en Blogger que hasta me he acostumbrado a sus límites.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

(Cross)Browser Fingerprinting via OS & HW Level Features

El mundo del Web Browsing fingerprinting es una disciplina que se ha desarrollado mucho durante los últimos años. El poder garantizar que un usuario es un usuario concreto y que es el mismo que estuvo mirando algo en otro sitio es una pieza clave dentro del mundo de la monetización de los datos. Para ello, lo que intentan todos los investigadores de estas disciplinas es estudiar al máximo al huella digital de tu conexión.

Figura 1: (Cross) Browser Fingerprinting via HW & OS

Conocer todos los patrones de ti que te hacen ser tú y poder reconocerte bajo cualquier situación y en cualquier lugar en el que estés navegando. Los trucos para crear tu huella digital son algunos muy conocidos, otros no tantos. Desde mirar todas las características del navegador, hasta mirar el comportamiento de la batería de equipo.

Figura 2: Mozilla Firefox quitó el acceso a Battery Status desde HTML5

Tanto es así, que hasta Firefox cortó el acceso de las funciones de consulta de la batería desde HTML5. Toda información que se pueda conseguir desde el navegador puede servir para identificarte y puede convertirse en algo que utilicen para monitorizar tus movimientos a través de diferentes sitios web.

Figura 3: Cross Browser Fingerprinting via OS and HW Level Features

Cada cierto tiempo salen nuevas formas de identificar propiedades del navegador - como este trabajo con los códigos de estado HTTP -, de generar una supercookie con algún leak de información, o de hacer que la cookie sea persistente de una forma u otra. Nosotros también estuvimos jugando con esto, y publicamos un trabajo hace mucho tiempo en Informática 64 sobre cómo usar los códigos de error de algunas funciones JavaScript para identificar el navegador. Todo por identificarte de la mejor forma posible. 

Figura 4: Resumen (no actualizado) de algunas técnicas de Webbrowsing fingerprinting utilizadas

Ahora, unos investigadores han ido un poco más lejos y han creado un conjunto de pruebas aprovechando WebGL para forzar al navegador a hacer llamadas que se ejecuten directamente en el hardware.

Figura 5: Forzado de figuras con WebGL que dependen del HW y el OS

Estas pruebas de dibujo, renderización de imágenes y materiales, se ejecutan directamente en las tarjetas gráficas y se ven afectadas por el tipo de hardware que tengan en ellas y el sistema operativo que las gestiona, así como de la potencia de la CPU del equipo. Es decir, la implementación del estándar WebGL en el navegador (ya sea Google Chrome, Firefox o Microsoft Edge) no incide en los cálculos que se obtienen en cada prueba.

Figura 6: El código del (Cross) Browser fingerprinting en GitHub

Esto quiere decir que cada prueba se puede hacer desde diferentes navegadores en el mismo hardware y se obtienen los mismos resultados, lo que lleva a que el Fingerprinting de un cliente web no se haga sobre el navegador, sino sobre el hardware y que si un mismo usuario se conecta con dos navegadores distintos, al final pueda ser identificado de igual forma.

Figura 7: Proceso de identificación de "huellas digitales" por medio de tareas de rendering

Esto no quiere decir que haya que dejar de hacer el resto de los cálculos de WebBrowsing Fingerprinting - ni mucho menos - sino que añaden un conjunto de pruebas que permite a las empresas que se dedican a esto la posibilidad de generar un parámetro más en la identificación de los usuarios basado en el equipo de conexión.

Figura 8: Big Data y Privacidad

Al final, cuando te conectas a Internet, el que te puedan identificar de una forma u otro es algo ya maduro y difícil de parar y en esta charla sobre Big Data y Privacidad hablé de esto tiempo atrás, por si quieres saber más de ello.

Saludos Malignos!

Ataques de Phishing a Webs con Links en Target="_Blank" sin modificador NoOpener

Cuando en una página web se añada un enlace, y el visitante hace clic en él, automáticamente el navegador hace una redirección hacia la página indicada en el hipervícunlo. Es decir, a la URL indicada en el valor href del enlace en la etiqueta HTML. Para evitar que esto suceda, en la página donde se pone el enlace con la etiqueta a href se puede añadir un modificador llamado Target que puede tener diferentes valores como "_self", "_top", "_parent", el nombre de un iframe o "_blank", que hace que el navegador abra el contenido del enlace en una nueva pestaña o ventana.

Figura 1: Ataques de Phishing a webs con links en Target="_blank" sin NoOpener

En este entorno, cuando la Pestaña1 que tiene el contenido del SitioA ha establecido un hipervínculo al SitioB con el modificador Target="_blank", el documento enlazado se mostrará en una nueva Pestaña2. Y hasta ahí, un proceso muy normal que muchas páginas web realizan.

Figura 2: Modificador Target de la etiqueta A para crear hipervínculos

Ahora bien, la Pestaña2 guarda cierta relación aún con la Pestaña1 después de este proceso. Incluso si se ha abierto con el modificador Target="_blank", el contenido abierto en la Pestaña2 puede hacer navegar la Pestaña1 hacia una dirección arbitraria, accediendo a esa ventana por medio del manejador Window.Opener. Es decir, un enlace en el SitioA que se muestra en la Pestaña1 y que apunta al SitioB con un enlace con Target="_blank", da acceso al SitioB para hacer desde la Pestaña2 que la Pestaña1 navegue a dónde él quiera.

Figura 3: Manejador window.opener

Si el propietario del SitioB detecta que el manejador Window.Opener trae una referencia valida a una ventana, aún podría saber más sobre la ventana en la estaba, accediendo al valor Document.Referer para saber si viene de Facebook, de Twitter o de cualquier otro sitio en el que pueda estar incrustado un hipervínculo al SitioB. Con esta información, un SitioB malicioso podría intentar hacer un ataque de Phishing al SitoA, haciendo que la Pestaña1 original navegue a una web de Phishing creada especialmente para cada tipo de SitioA del que se proceda.

Figura 4: Propiedad Document.Referrer de una ventana

La experiencia para el usuario sería que hace clic en un enlace en una pestaña, se abre otra pestaña donde se carga el contenido del hipervínculo que toma el primer plano del navegador, y por detrás la pestaña original navega hacia un sitio que es una copia de Phishing especialmente creada, haciendo creer al usuario cuando regrese a la pestaña original que, por ejemplo, se le ha cerrado la sesión y tiene que volver a introducir las credenciales. Esto lo ha publicado el investigador Ben Harpelm, y afecta a multitud de aplicaciones web, y servicios de Internet.

Una servidor para hacer Phishing

Es muy sencillo hacer la comprobación para saber si a tu web se está llegando a través de un Target="_blank". Es suficiente con añadir un código que compruebe si el manejador Winddow.Opener tie un valor null . Si no está vacío, entonces de puede forzar que se haga un redirect en la página origen con una llamada tan sencilla como ésta.

Figura 5: Redirección a sitio que crea el phishing apropiado para cada referrer

Para evitar esto, los enlaces deben añadir un modificador rel="noopener" que hace que en la nueva ventana el contenido de Window.Opener se transfiera con valor null. Este modificador no funciona aún en Mozilla Firefox. Para proteger los enlaces Target="_blank" contra cualquier intento de ataque similar en la página destino, se debe añadir rel="noopener noreferrer" para que además de no transferir el manejador de Window.Opener no se de información de cuál es la página que hace el enlace con Document.Referrer y evitar que se pueda hacer un ataque de Phishing dependiendo de la dirección web del sitio del que proviene el usuario.

Figura 6: Valores del modificador rel de la etiqueta A para crear hipervínculos

Si se quiere añadir más protección ante un posible navegador que no entienda el modificador noopener, una posible solución es asegurarse de configurar manualmente el valor de Window.Opener en la nueva ventana abierta, mediante este pequeño script.

Figura 7: Para borrar el valor de Window.opener

La verdad es que los ataques que se pueden hacer con esta técnica son similares a las técnicas de tabnabbing, pero en este caso aprovechándose de enlaces legítimos en las webs de procedencia, así que merece la pena que siempre que se añada un enlace en una aplicación crítica se añadan las opciones de noreferrer y noopener en tus enlaces para evitar facilitar que le hagan ataques de Phishing a tus visitantes.

Saludos Malignos!

HTML5 Games Box: El troyano Cloudsota en Google Play

Como os contaba hace poco, el contar con Tacyt, la plataforma de investigación de apps, nos permite realizar lo que yo denominaba la "Limpieza de Área". El proceso consiste en localizar, a partir de singularidades existentes en apps maliciosas aquellas otras apps relacionadas, con el objeto de eliminar cualquier rastro de software dañiño y de tener el máximo de información posible. En este trabajo, cuando salió publicado por los investigadores de Cheetah Mobile la existencia de un troyano pre-instalado en algunas tablets baratas con Android de Amazon, procedimos a investigarlo. 

Figura 1: El troyano Clousota en Google Play

El resultado fue que, dentro de las 4.6 Millones de apps que tenemos en Tacyt, localizamos una única app con una fuerte relación con este malware. La app en sí, llamada HTML5 Games Box, está aún disponible en el market de Google Play, a pesar de que nosotros hemos podido constatar que el troyano Cloudsota - que es como se ha bautizado a este malware - está presente en ella.

Figura 2: HTML5 Games Box en Google Play

Lógicamente, para hacer esta afirmación, una vez que llegamos a ella por medio de singularidades, hubo que proceder al análisis manual de la misma que está disponible en el artículo que han publicado nuestros compañeros Sergio de los Santos y Miguel Ángel García en el blog de Eleven Paths que puedes leer aquí: "El troyano preinstalado en tablets baratas de Amazon también está en Google Play".

Figura 3: Análisis de HTML5 Games Box en el blog de Eleven Paths

Algunos antivirus para Android marcan ya esta app como maliciosa, pero más por usar el SDK AirPush, para muchos un SDK de Adware. Además, como curiosidad se puede ver como esta app tiene miles de descargas y solo pocos comentarios, lo que podría indicar que ha sido descargada de forma automática con algún proceso malicioso para conseguir inflar los resultados visibles en la misma.

Saludos Malignos!

El IronFrame para luchar contra ataques de ClickJacking

En una entrevista concedida antes de DefCon, el hacker Dan Kaminisky ha dejado entrever una idea para luchar contra los ataques de ClickJacking que me ha gustado. Aunque no he visto los detalles de la misma, la poca información que hay sobre el IronFrame, que así se llama la medida de protección, me ha parecido digna de investigar y ha hecho que mi mente juegue un poco con los detalles. 

Figura 1: El IronFrame para luchar contra los ataques de ClickJacking

Los ataques de ClickJacking se basan en conseguir superponer un iframe transparente sobre la página que está viendo la víctima. En ese iframe transparente se coloca la web con la que se quiere que la víctima interactúe para así conseguir mediante engaños que la víctima configure cosas inseguras en su equipo sin darse cuenta.

Figura 2: Ejemplo en Hacker9 de ataque de ClickJacking para robar cuentas bancarias

Para conseguir que el usuario haga clic en las zonas de la capa transparente, el atacante utiliza trucos de ingeniería social que engañan a la víctima. En este vídeo se puede ver cómo un atacante podría utilizar una ataque de ClickJacking para cargar la página de configuración de Adobe y activar la webcam a la víctima con solo robar unos clics.

Figura 3: Ataque de ClickJacking para activar la webcam de la víctima

Si un atacante consigue inyectar un código en el cliente y poner un iframe, se podrían hacer infinidad de cosas. Una de las que más me gustó - abusando de nuevo de la gran potencia que tiene HTML 5 - fue la de aprovechar las funciones de Speech to Text para grabar lo que una persona diga en frente del navegador. En este artículo os conté cómo se podría hacer que una web te escuche y grabe lo que digas.

Figura 4: Cómo conseguir que una web te oiga inyectando un iframe malicioso

Al final, todos los ataques de ClickJacking se basan en poder superponer una capa sobre lo que está viendo el usuario, para conseguir el robo de los comandos que emite la víctima, que podrán ser clics, acciones de drag&drop, introducciones de teclado y hasta comandos de voz.

Protecciones contra ataques de ClickJacking

Para evitar que esta inyección se produzca, debe fortificarse al máximo la conexión entre el cliente y el servidor, para lo que se toman distintas medidas paliativas de fortificación desde el servidor, y en en los navegadores que puedan ser atacados. Las principales son:

- Evitar la inyección de código en ataques man in the middle: Si alguien es capaz de manipular la página en tránsito, entonces podría inyectar código directamente por la red. El uso de conexiones HTTPs y el forzado de estas conexiones HTTPs con el protocolo HSTS (HTTP Strict Transport Security) ayuda a mitigar estas posibilidades.

- Evitar la inyección de código en el cliente: El gran esfuerzo se pone siempre en evitar que se pueda hacer una inyección de código en el lado del cliente por medio de un ataque de XSS o HTML Injection. Para ello, se toman las siguientes protecciones:

- Filtros Anti-XSS: Los navegadores se fortifican con filtros Anti-XSS que los investigadores de seguridad constantemente tratan de saltarse. Debido la complejidad de las tecnologías web, conseguir que un filtro Anti-XSS sea perfecto es casi imposible, por lo que de cuando en cuando van apareciendo bugs para saltarse el filtro Anti-XSS en todos los navegadores. Algunos ejemplos tenéis en estos artículos:

- El 0day del filtro Anti-XSS de Google Chrome que duró 24 horas
- Saltarse el filtro Anti-XSS de Google Chrome 11
- Unos trucos para saltarse el filtro Anti-XSS de Google Chrome y Apple Safari

- Forzado de filtros Anti-XSS con HTTP Headers: Estos filtros pueden ser anulados desde el cliente. Es decir, el usuario podría configurar su navegador para quitar esta protección, pero aún así pueden ser forzados desde el servidor web por medio de los HTTP headers de servidor X-XSS-Protection. Aunque el cliente lo hubiera deshabilitado, el servidor lo puede volver a habilitar.

Figura 5: Servidores de Google activando el filtro con X-XSS-Protection: 1

- Content-Security Policies: La última de las medidas que un servidor web puede aplicar para evitar la inyección de código en su web es el uso de las CSP. Con la configuración de una CSP, el administrador de un sitio podría anular la ejecución de código JavaScript en toda una parte de la web, lo que evitaría que se ejecutara cualquier código inyectado vía un bug de XSS en esa web.

Figura 6: Configuración CSP en la web de Facebook

- Evitar la inclusión de un web en un iframe: La última de las protecciones que se aplican generalmente es la de evitar que una web pueda ser incluida dentro de un iframe. Al final, cuando el atacante quiere hacer un esquema de ClickJacking, inyecta un iframe en una web vulnerable y en ese iframe incluye la web de la que quiere robar los clics a la víctima. Por ello, para evitar que roben los clics de tu web, se introducen protecciones por medio de HTTP Headers X-Frame-Options, además de comprobaciones en JavaScript para ver si una web está en la ventana principal o no del navegador.

Todas estas medidas, cuando se hace una auditoría de seguridad a una web, se revisan una a una. Nosotros en nuestro servicio de pentesting persistente Faast miramos a ver si están todos los HTTP Headers en su sitio y la robustez de la conexión HTTPs, pero aún así, no hay garantía de que no se pueda llegar a encontrar un resquicio para un ataque de ClickJacking

La propuesta del IronFrame para luchar contra el ClickJacking

Vaya por delante que de la propuesta de Dan Kaminisky conozco lo que he leído, entre otros sitios en Dark Reading, pero me gusta desde el principio. La idea se basa en que los navegadores tengan un IronFrame que siempre sea la capa más cercana al usuario, es decir, que sobre ese IronFrame no pueda situarse ningún iframe. De esta forma, la aplicación web se aseguraría que ninguna capa pudiera superponerse y engañar la visión que tiene el usuario de la web.

Figura 7: Entrevista a Dan Kaminisky sobre el IronFrame

Quedan muchas cosas por definir sobre cómo gestionar ese IronFrame, pero de base es un buen punto de partida. Añadir la política de gestión de ese IronFrame desde las Content-Security Policies, usar HTTP Headers para manejarlo que solo puedan incluirse en conexiones HTTPs para evitar que nadie pueda incluir un IronFrame malicioso vía bugs de XSS o HTML Injection, o mediante ataques de man in the middle, usar HSTS para evitar que alguien, con esquemas similares al de Evil Foca pueda hacer ataques de Bridging HTTPs(IPv4)-HTTP(IPv6) o directamente SSLStrip, son detalles que quedarían por limar y ver cómo se podrían definir en un estándar, pero a mí el concepto me gusta.

Figura 8: Ningún iFrame podría estar por encima del IronFrame

Además, se podrían añadir opciones para que desde el lado del servidor se pudiera acceder a imágenes rasterizadas de qué es lo que se está pintando en el IronFrame, lo que daría grandes posibilidades de testing e incluso de detectar ataques man in the browser - que o de mitigarlos, ya que si hay un troyano en cliente estaríamos hablando de otros ataques y no de ClickJacking -. ¿Qué os parece a vosotros la idea de construir este IronFrame en los navegadores?

Saludos Malignos!