"Weaponizando Features" de Google Drive para descargar documentos no descargables

En los sistemas de Internet a veces hay características que dan una falsa sensación de seguridad cuando en realidad son "features" más para molestar que para cumplir una determinad misión que, en su confusión, el usuario que la utiliza pudiera creer que ofrece. Y permitidme que explique correctamente esta frase con un ejemplo concreto con la característica que permite configurar un documento de Google Drive como público pero "No descargable".

Figura 1: "Weaponizando Features" de Google Drive para descargar documentos no descargables

Como podéis imaginar, una cosa va contra la otra. Es antinatural que un documento que se pone en Google Drive como público - es decir, que será visualizable por un navegador web - no será descargable. Es un contrasentido porque al final para que el documento se vea en el navegador, el servidor de Google Drive, al final, tiene que entregarlo - de una u otra forma -, produciendo una descarga total o parcial del contenido, en un formato u otro.

Figura 2: El documento se comparte para "ver", pero no para "editar" en Google Drive

Lógicamente se pueden poner barreras que incomoden la función de descargar el documento, pero si se solventan todas esas dificultades y se "weaponizan" con un script o un proceso automático, dicha "feature" será totalmente inútil, tal y como explicó Chema Alonso con el servicio de "Desbloquéame" en WhatsApp que no ha sido hasta esta última versión que se ha corregido esa "feature weaponizable".

Documentos "No Descargables" en Google Drive

Vamos a ver el ejemplo de todo lo dicho anteriormente con el caso de la opción que permite configurar un documento del que no se permite descargar una copia. Le falta el icono del botón de descargar que aparece normalmente arriba a la derecha. En este caso, el guión de la película "Todos lo saben", publicado en la web de La Academia del Cine.

Figura 3: Documento compartido para leer, pero no se puede descargar (falta la opción)

Con esta opción configurada, además de no aparecer el icono con la opción de descargar el documento, Google Chrome no permite utilizar el comando Cntrl+Shift+C para abrir la consola de comandos, ni ver el código fuente. Ni tan siquiera abrir el documento con otro navegador, ya que lo redirige a Google Chrome.

Weaponización de la descarga

Cómo es lógico, el documento está bajando a nuestro equipo, así que solo hay que buscar la manera de automatizar la captura de esas descargas para obtener el documento completo. La primera "Feature 1" de la que vamos a aprovecharnos es que si pulsamos en la parte de Opciones - el icono de los tres puntos verticales -, entonces Google Chrome deja utilizar otra vez el botón derecho para llamar al menú de opciones de contexto del documento. Entre ellas podemos entonces acceder a la opción de "Guardar Cómo" la página web, y hacerlo como un documento normal en formato HTML.

Figura 4: Opción de "Guardar Cómo" en Google Chrome

A pesar de haber podido descargar esta página, la realidad es que éste documento en formato HTML no estará disponible sin conexión a Internet, ya que lo que hacen Google Chrome y Google Drive es que descargan de Internet cada página del documento a medida que se hace scroll sobre ella, lo que es una buena opción de usabilidad, pero malo para los que queremos conseguir el documento completo.

Para continuar con el proceso de "weaponización", nos tenemos que aprovechar de la “Feature 2”. Lo que vamos a hacer es abrir el documento en  formato HTML con otro navegador, por ejemplo MS Internet Explorer o con Mozilla Firefox, ya que a todos los efectos este archivo es un documento local. Si bien al abrirlo, el archivo HTML sigue pidiendo al servidor la información sobre las páginas siguientes del documento, y el botón derecho está desactivado.

Figura 5: Opción de "Inspect Element" en Mozilla Firefox

Ahora bien, no estamos en Google Chrome, así que si repetimos el uso de la "Feature 1", en Microsoft Internet Explorer y accedemos al menú de contexto haciendo clic con el botón derecho, esta vez nos permite seleccionar la opción “Inspeccionar Elemento” y llegar a las herramientas de desarrollador, como se ve en la Figura 5.

Figura 6: URL de descarga de las páginas del documento como imagen

Desde estas herramientas, ya podemos monitorizar las URL que el archivo HTML pide al servidor para acceder a cada página, usando por ejemplo la pestaña Network en MS Internet Explorer o Mozilla Firefox. En estas URL únicas en formato gráfico, tenemos página a página, todo el documento, las cuales sí son descargables.

Figura 7: Cambiando el número de página bajan todas

Solo deberemos ir moviendo el parámetro page hasta el número total de páginas para obtenerlas todas. Así que ahora ya podemos hacer un script completo que "weaponize" el proceso completo de añadir la opción de descargar el documento de Google Drive.

Weaponizando con un sencillo script

En este ejemplo, donde hice solo un caso manualmente, lo que hice fue generar un script que me hiciera, a partir de una URL todas las que tenía que descargar y las metí en un fichero de TXT. Como he dicho, solo modificando el valor del parámetro "page".

Figura 8: URLS de todas las páginas generadas en un fichero de TXT

En segundo lugar, usar un sencillo WGET para que descargara todas las imágenes y las metiera en una carpeta.

Figura 9: Descarga de todas las páginas

Y por último, renombramos todos los archivos a formato gráfico y los unimos en un único fichero con el comando MERGE.

Figura 10: Unión de todas las páginas en un solo archivo

Con esto tenemos nuestro documento completo descargado en formato gráfico, pero aún podríamos convertirlo a PDF o usar un sistema OCR para ponerlo en formato gráfico.  Depende de lo que quieras hacer con él.

Figura 11: Archivo completo del guión público

Si lo que se trata es de tener un documento único completo para su lectura offline, ya sería más que suficiente, pero si lo que quieres es editar el texto necesitas interpretar las imágenes de las páginas y pasarlas a texto. Yo probé el servicio de Azure de Visión Artificial para reconocimiento de caracteres y no va nada mal.

Figura 12: Reconocimiento de caracteres con visión artificial

Al final, como decía al principio, es antinatural que un documento que se comparte como visible en la red no se pueda descargar en cliente. Si está en el equipo cliente, solo hay que ver cómo weaponizar el proceso y hacerlo fácil. Lo siguiente será hacer una extensión para Google Chrome o Mozilla Firefox que haga todo el proceso automáticamente y listo. Weaponizado.

Autor: Pablo García Pérez

Web Browser Cache Snooping para espiar tu ubicación GPS

Durante la pasada BlackHat Asia 2015 se publicó un trabajo bastante curioso que tenía ganas de echar un vistazo. La investigación en sí se llama "I Know Where You’ve Been: Geo-Inference Attacks via the Browser Cache" y tiene como objetivo intentar saber en qué país, en qué ciudad o incluso en qué barriada estás mediante la exploración de los objetos que tienes en la caché de tu navegador.  El funcionamiento de estas técnicas es sencillo, pero merece la pena mirar unos detalles.

Figura 1: Web Browser Cache Snooping para espiar tu ubicación GPS

Para que sea fácil de entender, cuando vas a un sitio popular que está en Top 100 de Alexa, estos servidores te entregan unos u otros archivos dependiendo de tu ubicación geográfica. Una página maliciosa podría intentar cargar en su página esos recursos y en función del tiempo que haya tardado el navegador en hacerlo saber si lo tenías en la caché o no. Si lo tenías, significa que es porque estás en una determinada ubicación.

Figura 2: WhitePaper de los investigadores sobre Geo-inferencia por exploración de caché

En el paper, utilizan como ejemplo tres sitios principales, que son Google,  Craiglist y Google Maps. El primero de ellos entrega unos recursos u otros en función de país en el que estés, el segundo lo hace dependiendo de la ciudad en la que estés y el último en función de la barriada en la que te encuentres, por lo que si es posible identificar un archivo de Google Maps en la caché de tu equipo se podría saber dónde estás, si se hace con Craiglist se podría saber en qué ciudad te encuentras y con Google Maps en qué país estás.

Figura 3: Con Google, Craiglist y Google Maps se puede ubicar tu zona GPS

La pregunta  es, ¿cómo localizar si un archivo está o no en la caché? La parte sencilla es medir el tiempo de carga de un recurso en una página maliciosa. Vamos a suponer que Google entrega una imagen llamada Google_ES.jpg cuando visitas Google.com desde España. Ahora entras a una página con contenido externo que quiere saber si estás en España o no, para ello hace un procedimiento que carga contenido externo, haciendo algo como esto:

Figura 4: Geo-inferencia por carga de imagenes

Si el tiempo de carga es grande, entonces es que ha ido a pedirla a los servidores de Internet, pero si el tiempo es pequeño, entonces es que ya estaba en la caché y por tanto es porque lo había visitado recientemente. Esta técnica se basa en las mismas ideas que los ataques de DNS Caché Snooping, con la gracia de que este caso sería equivalente a leer el valor Country de una cookie.

Figura 5: Carga de resultados de XMLHttpRequest generando error de CORS

Para explorar la ubicación, también se pueden utilizar las políticas de Croos-Origin Request Sharing. Google no permite hacer que otras webs lean resultados de XMLHttpRequests desde otras páginas, el tiempo de obtención del error permite saber si esa respuesta ya estaba en la caché o no, lo que de nuevo, al ser distinta por cada ubicación permite saber en qué sitio estaba.

Figura 6: Diferencias en tiempo de generación de error entre documento en caché o no cacheado

La última de las técnicas consiste en acceder a la lista completa de las propiedades de una imagen y ver la diferencia en el tiempo de carga, para saber si estaba o no en la caché del navegador.

Figura 7: Cálculo de tiempo de carga de propiedades de una imagen

Al final, se trata siempre de intentar acceder a un recurso y ver cuál es la diferencia entre el tiempo de acceso cuando el recurso está y cuando el recurso no está en la caché. Esto aplicado con Craiglitst permite discernir en cuál de las 171 ciudades en que es diferente el sitio se ha estado conectando.

Figura 8: Cálculo de tiempo de iframe cacheado o no de Craiglist

Y lo mismo con Google Maps, que si se accede desde una determinada ubicación, el recurso que se carga deja en la caché un fichero con las coordenadas de la barriada, permitiendo saber tu ubicación.

Figura 9: Cálculo de imágenes de recursos de Google Maps a cargar según ubicación GPS

Según los investigadores, el 62 % de los sitios del TOP 100 de Alexa tienen recursos dependientes de la información Geográfica que pueden ser descubiertos en la caché con estas técnicas y por tanto descubrir tu ubicación. Por supuesto, si borras la caché o usas el modo de navegación incógnito o privado que borra en cada sesión el contenido de la caché, esto es poco útil. Aquí tienes un vídeo de cómo funcionan estas técnicas en una demostración.

Figura 10: Vídeo demostrativo de Geo-inference por caché (visto en hackplayers)

No obstante, para las empresas que se dedican a dar servicios de WebBrowsing Fingerprinting puede ser muy útil, ya que conseguir el scoring de un transacción web en escenarios de Malware-in-the-Browser podría ser útil o para cuando una persona utilice un navegador para comprar con tarjetas fraudulentas o robadas desde ubicaciones extrañas.

Figura 11: Técnicas y navegadores afectados

Las técnicas, como bien indican los investigadores son útiles en los principales navegadores de Internet, incluyendo TorBrowser.

Saludos Malignos!

HSTS Super Cookies: Cómo te pueden espiar la navegación

El pasado 2 de Enero el investigador Sam Greenhalgh ha publicado una Prueba de Concepto que lleva un paso más allá cómo los sitios web de Internet y, en concreto las empresas de publicidad, pueden utilizar SuperCookies para saber quién eres. Esto va mucho más allá que las EverCookies - que permiten a un sitios crear cookies en una gran cantidad de sitios del navegador web haciendo muy complicado para el usuario eliminarlos todos - ya que lo que utiliza son flags de la especificación HSTS (HTTP Strict Transport Security) para guardar un identificado que le permita al sitio reconocer al usuario desde cualquier web, incluso si navegas desde un navegador en modo anónimo o privado.

Figura 1: Cómo te pueden espiar los sitios web con SuperCookies

Cookies y Privacidad: Cookies, EverCookies & SuperCookies

El objeto de las cookies es guardar información en la sesión de navegación de un cliente. La información que se guarda en una cookie puede ser utilizada para identificar de forma unívoca a una persona, creado para ello un identificador único. Ese valor se puede leer desde el sitio web que lo creó cada vez que se visite la web. Sin embargo, las cookies se pueden borrar fácilmente y por tanto el sitio web no podría saber que una persona es la misma que visitó el sitio hace dos días.

Figura 2: Funcionamiento de las EverCookies

Para conseguir ponerle difícil las cosas al usuario se crearon las EverCookies, un sistema que utiliza no solo las cookies normales para guardar el identificador, sino que utiliza todas las opciones posibles para almacenar datos, que van desde el almacenamiento local en HTML5 hasta las cookies de plugins como Adobe Flash. Aún así, estas EverCookies podrían llegar a ser eliminadas todas si un usuario se lo empeña, o si cambia su navegación a modo Privado o Incógnito.

Figura 3: Identificador único creado en Google Chrome con SuperCookies

Con las SuperCookies esto es no es tan fácil, y es necesario que las implementaciones de Mozilla Firefox, Google Chrome o MicroSoft Internet Explorer cambien, ya que abusan del funcionamiento de la implementación de HSTS. Con HSTS, una web le puede indicar al navegador que siempre que se conecte a ella debe hacerlo usando HTTPS y no HTTP. Esta es una forma para ayudar a que los usuarios dejen de navegar bajo HTTP y pasen a hacerlo sobre HTTPS. Para ello, el servidor web le contesta al cliente con una serie de flags HTTPS que le hacen recordar al navegador esa configuración y ya siempre irá con HTTTPs el tráfico a esa web.

Figura 4: Identificador Único leído desde la SuperCookie en una sesión Incógnito

Entre esos flags, el sitio web puede guardar un Identificador Único utilizando el valor de Max-AGE, que además podrá ser leído desde cualquier pestaña, y desde cualquier navegación, incluso si esta navegación se hace desde otra instancia del navegador en modo Privado o Incógnito.

Doxing y desenmascaramiento

Según el investigador, el equipo de Chromium está viendo cómo puede solucionarlo pero que no es fácil, ya que hay que gestionar el equilibrio entre seguridad y usabilidad. Lo cierto es que con esto, se acaba de abrir un nuevo mundo de posibilidades para el Doxing, es decir, para el desenmascaramiento de quién está detrás de una determinada identidad falsa en redes sociales o visitas a la web, ya que poner este Identificador ayudaría al sitio web a tener todos los datos de todas las sesiones de navegación que se hagan contra esa web desde un navegador concreto.

Saludos Malignos!

Certificate Pinning: Un estudio sobre el estado del arte

En la última RECSI (Reunión Española de Criptografía y Seguridad Informática) 2014 que tuvo lugar en Alicante, participamos con un par de trabajos que puedes encontrar en el canal Slide Share de Eleven Paths. Uno de ellos estuvo centrado en las técnicas de Certifica Pinning, titulado: "Contramedidas en la suplantación de identidades. Certificate Pinning", que puedes descargar y/o leer en formato PDF.

Figura 1: Un estudio del estado del arte de las técnicas de Certificate Pinning

Las técnicas de Certificate Pinning se basan en extremar las medidas de protección a la hora de aceptar por bueno un certificado digital en una conexión segura. Hasta que comenzaron a extenderse los navegadores y/o sistemas operativos venían con un almacén de las claves públicas pertenecientes a las entidades de certificación en las que se confía, y la validación de un certificado digital enviado desde cualquier servidor se basa en analizar la cadena de confianza de certificación para ver si termina en uno de los certificados almacenados en los que se confía.

Figura 2: Contramedidas en la suplantación de autoridades de certificación. Certificate pinning

Podríamos decir que el proceso de tener la lista de certificados digitales de las entidades de confianza es el pinning "clásico", pero con la aparición de certificados falsos para dominios populares, como los que vimos que aparecieron tras el robo de la entidad certificadora Diginotar, el posible uso de entidades de certificación intermedias, o la creación de certificados falsos por medio de colisiones de hashes, tal y como se vio en el caso de The Flame o en el reciente caso de los certificados de Windows Update, lo cierto es que parece que no basta solo con pinnear el certificado de la entidad, sino el certificado concreto del servidor al que nos conectamos completamente.

Figura 3: Posibilidad de hacer Certificate Pinning con EMET en Windows

Cuando lo que se guardan son los certificados únicos de los servidores, y se hace una validación de toda la clave completa en cada conexión, es entonces cuando se está realizando Certificate Pinning, algo que se ha hecho muy popular entre los expertos en seguridad. De hecho, la herramienta EMET que se usa para maximizar la seguridad de sistemas Windows permite hacer Certificate Pinning, y para que fuera muchos más sencillo de usar, desde el laboratorio de Eleven Paths lanzamos EMET Rules para hacer Certificate Pinning a todo Internet - si quieres - hace ya algún tiempo.

Figura 4: Plugin DNSSEC TLS Validator para Firefox

En el blog de Eleven Paths le dedicamos una serie completa a Certificate Pinning: El qué, el cómo y el porqué. En ese trabajo se habla también de algunas implementaciones enfocadas en validar los certificados digitales por otras vías, como son DANE( DNS-Based Authentication of Named Entities) o TACKS (Trust Assertions for Certificate Key).

Figura 5: Fallo de Certificate Pinning en Mozilla Firefox explicado en el Blog de Eleven Paths

Todos estos puntos, así como la aplicación de estas técnicas en los navegadores Google Chrome, Internet Explorer y Firefox - incluida su última implementación de Certificate Pinning con dudoso éxito - se tratan en detalle en ese artículo, así que si te interesa conocer más sobre estas técnicas, es la lectura de este sábado para tu e-book reader. Seis páginas en Español que te permitirán tener una idea clara del estado del arte en técnicas de Certificate Pinning.

Saludos Malignos!

Doxing y las zonas de seguridad de Microsoft Outlook

Las técnicas de Doxing se utilizan para desvelar identidades ocultas en la red. Saber quién está detrás de un perfil falso de Facebook, quién es el que maneja una cuenta de Twitter o el que está detrás de un correo electrónico. El objetivo de todas estas técnicas de doxing es poder averiguar nueva información de la persona detrás de la cuenta. Una nueva dirección IP, un número de teléfono o una versión de software pueden ayudar a avanzar en una investigación y por tanto son muy delicadas y codiciadas todas las nuevas técnicas que se conocen a este respecto.

Algunos ejemplos de doxing

Por ejemplo, la fugas de información por metadatos han ayudado a resolver muchos casos en el pasado, como el ejemplo de las notas de prensa de anonymous o el de la filtración del ERE del PSOE a lo medios. 

Figura 1: En el cliente Mail de iOS se revelaba la dirección IP, y en el USER-Agent la info del dispositivo

Pero no solo eso, por ejemplo los bugs de seguridad que permitían utilizar técnicas click to call en las apps de iOS dejaban a un atacante la posibilidad de conseguir la revelación del número de teléfono, o la carga insegura de imágenes en correos electrónicos, como vimos en el cliente iOS durante mucho tiempo, podría ser utilizado para localizar siempre a una persona.

Un ejemplo de doxing con un documento Microsoft Word

Para el último Security Innovation Day le dedicamos una pequeña parte de una de las charlas a esto, y en concreto a sacar a la dirección IP de una conexión forzando un callback home con un documento Microsoft Word especialmente creado para cargar una imagen remotamente - desde una máquina controlada - sin que le diera una alerta al usuario que abría el documento.

Figura 2: Un documento de Microsoft Word para hacer Doxing

Sin embargo, si el documento es abierto después de haber llegado por Internet, ya sea por el correo electrónico o descargado por medio de un navegador para conectarse a la web, entonces el documento al ser abierto muestra una alerta genérica de seguridad, tal y como puede ser visto. 

Figura 3: Alerta de Seguridad en Microsoft Word por la seguridad de la zona

En nuestra demo, esta alerta salía porque para el ejemplo enviábamos el documento como adjunto de un correo electrónico que es enviado a la víctima, y tanto si haces doble clic sobre el fichero adjunto como si guardas el fichero con las opciones del menú contextual y lo abres después, la alerta indica que el documento viene de Internet y puede ser peligroso.

Figura 4: Zonas de seguridad en Outlook

Esto lo explica Sergio de los Santos (@ssantosv) en su libro de Máxima Seguridad en Windows cuando muestra que las Zonas de Seguridad de Internet Explorer también existen en Microsoft Outlook, como cliente de un servicio de Internet que es. Así, estas se pueden igualmente personalizar y configurar para decidir cuáles deben ser los controles a aplicar.

El drag & drop y el cambio de zona de seguridad

El asunto está en que, si el documento que viene como adjunto, en lugar de ser abierto haciendo doble clic o usando la acción de guardar de Microsoft Outlook, es extraído mediante un drag & drop, es decir, arrastrando el documento desde el adjunto del correo electrónico hasta, por ejemplo el escritorio, todo cambia.

Figura 5: El documento es arrastrado al escritorio desde el cliente de Microsoft Outlook

Con ese proceso se ha cambiado el documento de una Zona de Internet a un Zona Local, por lo que todas las opciones de seguridad también cambian y no sale ninguna de las alertas anteriores. Esto provoca que inmediatamente, nada más abrir el documento se comunique la dirección IP al servidor controlado por el atacante y se descubra la dirección IP original.

Figura 6: El documento se abre sin alertas de seguridad y reporta la dirección IP al servidor del atacante

El problema es que los usuarios, que siempre luchan contra las medidas de seguridad que ellos consideran "molestas", puedan haber tomado como costumbre esto para evitarse la alerta de seguridad que sale en el documento, y sin darse cuenta están quitando una medida de seguridad que no solo protege frente a doxing, sino que tiene medidas de seguridad que ayudan a evitar las infecciones de malware o dificultando el éxito de exploits. Si usas Microsoft Outlook, ten presente este funcionamiento para mantener tu sistema Microsoft Windows más seguro.

Saludos Malignos!

X-XSS-Protection HTTP Header y los filtros Anti-XSS

Cuando salió el filtro Anti-XSS en Internet Explorer 8 - el primer navegador de Internet que lo aplicó - se generó mucha polémica. El que un filtro del lado del cliente pudiera modificar el contenido que venía mostrado desde el servidor - pese incluso a que pudiera ser mediante un ataque de XSS Reflejado - levantó muchas opiniones a favor y en contra. De hecho, rápidamente los investigadores buscaron formas de saltarse el filtro e, incluso, de utilizar la manipulación del filtro para convertir páginas no vulnerables en páginas vulnerables.

Figura 1: Bugs de XSS Reflejados reportados a Apple

Hoy en día Google Chrome, Apple Safari e Internet Explorer lo implementan por defecto, pero queda en manos del usuario el poder deshabilitarlo en caso de así desearlo, sobre todo por si le da problemas al trabajar con alguna web que, más que probablemente, está mal diseñada. En un ataque de XSS, saltárselo siempre es un paso que hay que hacer, por lo que los bugs de estos filtros de seguridad se hacen también muy populares, como los casos que os he publicado por aquí en algunos artículos:

- El 0day para saltarse el Anti-XSS de Google Chrome que duró 24 horas.
- Unos trucos para pasar el filtro AntiXSS en Chrome y Safari
- Saltándose el filtro Anti XSS de Google Chrome 11

Por otro lado, al mismo tiempo que se da al usuario la posibilidad de controlar el filtro Anti-XSS, los servidores web también tienen un HTTP header que pueden enviar al navegador para habilitar o deshabilitar dicho filtro, en caso de que el usuario haya deshabilitado el filtro y el servidor web no quiera que así sea, o viceversa, es decir, en caso de que el filtro esté habilitado en el cliente y el servidor web desee que se deshabilite. Ese HTTP header es el X-XSS-Protection.

Figura 2: Filtro Anti XSS en Internet Explorer 8 modificando la web

Los HTTP headers que empiezan por X- son variables extendidas que no se encuentran dentro del estándar, pero que se pueden popularizar más o menos dependiendo de quién las utilice. De estos hay muchos, como el famoso X-Frame-Options para evitar ataques de Clickjacking, o como alguna que otra política de contenido que ya os contaré más adelante en algún post. En este caso, el HTTP header X-XSS-Protection se entendido tanto por Google Chrome, Apple Safari como por Internet Explorer desde la versión 8 hasta la actual y permite configurar el filtro Anti-XSS del navegador por medio de esta política.

Figura 3: Google Chrome permite deshabilitar el filtro Anti-XSS,
llamado XSS Auditor, por parámetros en el arranque de la aplicación

Cuando el valor del HTTP Header X-XSS-Protection de una web tiene un valor 1; mode=block, está forzando a que el filtro Anti-XSS esté habilitado en el navegador - incluso si el cliente lo ha deshabilitado -, mientras que si se configura con valor 0 se está deshailitando incluso si el cliente lo tuviera habilitado. Si no se pone el HTTP Header X-XSS-Protection con ningún valor, entonces es elección del cliente habilitar o deshabilitar el filtrado Anti-XSS, aunque por defecto casi todo el mundo lo tiene activo en Google Chrome, Apple Safari e Internet Explorer.

Figura 4: X-XSS-Protection:1 en un servidor de Google

Dicho esto, la recomendación de seguridad es forzar la activación del mismo, consiguiendo una mejor fortificación del entorno, ya que un ataque de XSS puede afectar a la seguridad de los clientes y por tanto a la seguridad del servidor web completo. Sin embargo, puede pasar que, como se ve en este caso de Facebook, temporalmente hayan forzado deshabilitarlo.

Figura 5: X-XSS-Protection 0 en un frontal de Facebook

Hacer esto tiene unos riesgos que se asumen por problemas de compatiblidad, pero que son un mal menor en un proceso de continuidad de negocio. Este HTTP Header de X-XSS-Protection = 0 en Facebook está dejando sin protección Anti-XSS a los clientes de Google Chrome, Apple Safari e Internet Explorer que se conecten a estos frontales, por lo que se deben extremar la protección contra este tipo de ataques dificultándolos con algunas otras medidas, como las Content Security Policies, algo que Facebook sí que utiliza.

Saludos Malignos!

El servidor de tarjetas de embarque de acceso prioritario

Era la noche antes del último día de estancia en Bogotá y mi compañero me trajo impreso la tarjeta de embarque del vuelo que me iba a traer de regreso a esta Madrid y esta España que tanto quiero. Estabamos en el lobby del hotel en el que me alojaba y fue entonces cuando vi que en el hotel tenían un equipo preparado con una impresora a modo de mini business center para que cualquiera pudiera imprimirse sus tarjetas de embarque libremente, quitanto esa molestia al personal de recepción.

Ya en el año 2008, cuando estuve viviendo una temporada en Londres me había topado con algo similar, y en aquel entonces pude darme cuenta de que la gente es capaz de dejar cualquier cosa en estos equipos, pudiendo hasta ver las fotos que la gente se hacía en sus visitas a Londres.

Figura 1: Copias de mensajes de correo electrónico en la caché de Internet Explorer

Me acerqué entre curioso y aburrido, pues estaba un poco cansado de todo un día largo de trabajo, a ver qué localizaba. Iba más pensando en si tenían algún sistema de fortificación en el equipo que no permitiera hacer cosas - ya sabéis como si fuera un Internet Kiosk o similar - que pensando en negligencia de uso, pero en estas cosas puede pasar de todo. 

La sesión estaba abierta, no sabía si estaba así por que era su estado natural o porque el último usuario había olvidado cerrarla. En el primer acercamiento, pulsé la tecla de Windows + E para ver si había alguna restricción pero.. nada. Todo abierto, incluida la red del hotel de los equipos de trabajo. La seguridad parecía no ser una prioridad, así que ya pierde un poco la gracia.

En ese punto, viendo que el equipo estaba entregado, lo único que se me ocurrió pensar es. "Vamos, no uso yo este equipo ni en broma.... pero.. ¿cuánta gente lo usará?" Como todo estaba abierto, se me ocurrió ir a ver qué gente habría uado el equipo mirando el historial de navegación, las descargas, las cookies, etcétera, pero en ese camino, cuando llegué a las descargas me paré, ya que no solo había bastantes archivos, sino que muchos de ellos eran tarjetas de embarque de vuelos.

Figura 2: Tarjetas de embarque (y correos electrónicos) en la carpeta de descargas del perfil del usuario de Windows

Las tarjetas de embarque son documentos que contienene información personal, lo que parece que a la gente no le preocupaba en demasía, pero además tienen el E-Ticket Number y el código del billete. Este código, además de utilizarse para entrar dentro del avión, donde se hace una comprobación fuerte de la identidad con la presentación del documento de identificación, se usa en otras dos zonas en los aeropuertos.

Figura 3: Una tarjeta de embarque de Iberia entre las descargas

El acceso a la zona de embarque y el acceso prioritario por el Fast Track

La primera de las zonas en las que se utiliza la tarjeta de embarque es para pasar - como era de esperar - a la zona de embarque, una zona que se supone que tiene control de acceso por las normas especiales que rigen allí. No es que a mí me motive visitar el aeropuerto más de lo que ya lo visito, así que lo único que me llamó la atención de los billetes que allí vi es que tenían el acceso Priority, que en algunos aeropuertos  - como el de Adolfo Suarez en Madrid - da la posibilidad de pasar el control de seguridad por el Fast Track que es mucho más cómodo y donde no se hace una autenticación fuerte. ¿Qué pasaría si alguien pasa el control con el código de una tarjeta de embarque y luego viene el autentico dueño a pasar el control? No lo sé.

El acceso a la Sala VIP

La segunda de las zonas en las que se puede utilizar una tarjeta de embarque con acceso prioritario es en la Sala VIP, por supuesto. Allí, en mi experiencia personal, tampoco he visto un proceso de autenticación fuerte en la que se exiga documentación, y preguntando sobre este asunto algunas personas me han confesado que con un billte business de una persona entran varios haciendo fotos al código de barras y entrando con unos minutos de separación. Al final, una persona puede entrar y salir de la Sala VIP tantas veces como quiera, y por tanto el sistema no da muchas alertas sobre esto... en algunas salas.

De cualquier forma, si tienes costumbre de imprimir las tarjetas de embaque en Business Center, o usas equipos en ciber cafés u hoteles, intenta no dejar ningún dato personal, no usar ninguna contraseña y si te ves obligado a hacerlo, borra absolutamente todo, cambia las passwords o cierra el Latch mientras puedas.

Saludos Malignos!

Google Chrome aún no alerta de passwords enviadas en URLs

Hace ya tiempo que, cuando aún andábamos por Informática 64, publiqué un artículo sobre la desprotección que había en ciertos navegadores cuándo se pedía una URL en la que se envían el usuario y la contraseña. Esto es una forma de explotar ataques CSRF que abusen de dispositivos que cuenten con contraseñas por defecto. En aquel entonces os contaba que tanto Microsoft Internet Explorer, como Apple Safari tenían una protección basada en una alerta de seguridad que se muestra al usuario. Esta es la que aparece en Apple Safari. En aquel entonces ni Google Chrome, ni Mozilla Firefox tenían esa protección.

Figura 1: Alerta de envío de passwords en Apple Safari

Ahora, en la lista, como me alertó mi compañero Ricardo, se ha quedado solo Google Chrome, ya que Mozilla Firefox SÍ que ha añadido esta alerta, tal y como se puede ver en la siguiente captura.

Figura 2: Mozilla Firefox ahora alerta del envío de passwords en las URLS

Esta alerta existe en cualquier situación en la que vayan credenciales, incluso cuando se envía el usuario y la password a un sitio que no lo está requiriendo. Se informa de esto para que el usuario tenga la mayor información posible ya que esto puede ser más peligroso aún.

Figura 3: Mozilla Firefox alerta también cuando se envía a sitios que no lo piden

Google Chrome sigue sin alertar de nada, lo que no parece tener mucho sentido desde el punto de vista de seguridad, así que vaya este post para llevar una cuenta de cuánto tarda en añadirlo.

Saludos Malignos! 

Man in the Middle con Web Proxy Auto-Discovery en iPv6

La principal novedad de la versión de Evil FOCA que presenntamos en esta edición de DEF CON 21 es la implementación del ataque Web Proxy Auto-Discovery tanto en IPv4 como en IPv6, tal y como se podía ver en las diapositivas de la presentación que os dejé ayer. Además de eso, también se metió como "bonus extra" la implementación del strippeado de los resultados de Google, para que los ataques fueran más efectivos. Esta es la demo que realicé durante la presentación, paso a paso.

Descubrimiento del servidor Web Proxy Auto-Discovery

Los navegadores de Internet, por defecto, vienen configurados para buscar al servidor Web Proxy Auto-Discovery de la red mediante un registro DNS well-known llamado WPAD. Este registro es uno de los que la FOCA busca, por ejemplo, para sacar información de la red interna de una organización. Esta opción está activada en los navegadores, tal y como se puede ver en las opciones de este Internet Explorer.

Figura 1: Opción de buscar auutomáticamente la configuración de la red

Por supuesto, yo os recommiendo a todos que las quitéis si estáis en una red que no es vuestra, y si es una red gestionada por vosotros, aplicad alguna política para erradicar su activación en todos los navegadores si no hacéis uso de esto.

Este registro WPAD es buscado automáticamente por la red mediante el protocolo LLMNR, tal y como se puede ver en la siguiente imagen, tanto por IPv4 como por IPv6, pero buscando un registro tipo A, es decir IPv4.

Figura 2: Búsqueda del servidor WPAD por medio de LLMNR

La búsqueda de WPAD se hace por multicast, y en nuestro entorno, Evil FOCA captura la petición a multicast IPv6 y contesta con una dirección IPv6 en un registro AAAA, usando el mismo truco que usamos en el ataque SLAAC para pasar de A a AAAA.

Figura 3: Evil FOCA contesta con un registro AAAA

Al cliente parece que esto le deja un tanto preocupado, así que realiza una confirmación, buscando el registro WPAD por LLMNR, pero esta vez preguntando por su valor AAAA.

Figura 4: El cliente pide por LLMNR el valor de WPAD para AAAA

Para que Evil FOCA confirme que sí, que este es el servidor Web Proxy Auto-Discovery de la red y está en una dirección IPv6. Como se puede ver en la imagen, la dirección IPv6 que se usa es una dirección de vínculo local IPv6, por lo que no es necesario hacer un ataque SLAAC previamente para confgurar un gateway en IPv6.

Figura 5: Evil FOCA confirma la dirección IPv6 del WPAD

El fichero de configuración WPAD.PAC para descubrir al servidor Web Proxy

Una vez que el cliente descubre la dirección IPv6 en donde está el servidor Web Proxy Auto-Discovery, se conectará a este para conseguir la información del servidor Web Proxy de la red, que no tiene porqué ser el mismo. Es decir, el servidor Web Proxy Auto-Discovery es un servidor web donde se almacena un fichero de configuración que le dice al cliente web dónde se encuentra el servidor Web Proxy.

Figura 6: Solicitud al servidor WPAD del fichero de configuración WPAD.PAC

Este fichero de configuración se llama WPAD.PAC y es solicitado por el cliente, para que la Evil FOCA se lo entregue conn la información del lugar donde está levantado ese servidor Web Proxy.

Figura 7: Contenido de WPAD.PAC entregado por Evil FOCA con información del Web Proxy

Hay que tener en cuenta que si el cliente utiliza Google Chrome, este ataque no funcionará, ya que IPv6 viene desactivado por defecto. En ese caso se hace exactamente lo mismo, pero seleccionando en Evil FOCA el ataque WPAD en IPv4.

El ataque con Evil FOCA

Por supuesto, en Evil FOCA esto es tan sencillo como arrastrar el equipo al panel del ataque WPAD en IPv6, hacer clic en Start y Evil FOCA se encargará de interceptar la petición del registro WPAD del cliente, servirle vía web el fichero WPAD.PAC y hacer de servidor proxy HTTP, aunque vamos a confgurar la opción de usar un servidor proxy remoto para hacer algo similar a lo de la JavaScript Botnet del año pasado.

Figura 8: El ataque WPAD en IPv6 con Evil FOCA

Una vez acabada esta fase, el cliente podrá navegar por Internet, pero lo estará haciendo a través de un servidor Web Proxy en IPv6 que hará de man in the middle. Y ya que está en el medio, una de las cosas que le hemos añadido a Evil FOCA es la posibilidad de hacer SSLStrip de todos los resultados de una respuesta de Google, quitando el redirect que implanta, y cambiando los enlaces HTTP-s por enlaces HTTP.

Figura 9: Resultados de Google a través de Web Proxy en IPv6 strippeads

Por supuesto, cuando el cliente solicita una página que pide ir por HTTP-s, como la de Facebook, la herramienta Evil FOCA implementa Bridging HTTP (Pv6) / HTTP-s (IPv4), es decir, negocia con el servidor de Facebook en HTTP-s con IPv4, pero al cliente le entrega todo bajo HTTP con IPv6.

Figura 10: Facebook vista bajo HTTP(IPv6)

Esto tiene algunas implicaciones con respecto a las cookies que van marcadas como Secure, obligando a tener cuidado con la información que se envía al cliente y al servidor, pero al final, todos los datos se envían sin cifrar desde el cliente a Evil FOCA, pudiéndose robar las credenciales.

Figura 11: Credenciales de Facebook interceptadas en WireShark

Esta sermana publicaremos la versión en el blog de Eleven Paths, para que podáis testearla vosotros mismos, y en el libro de Ataques en Redes de Datos IPv4 e IPv6 tenéis más información sobre ataques man in the middle en estas redes. Las otras dos demos que realicé en la presentación las tenéis paso a paso en los artículos de Ataque SLAAC con Evil FOCA y Ataque Neighbor Advertisement Spoofing con Evil FOCA.

Saludos Malignos!