El Cross-site scripting, XSS (no conozco una buena traducción del término, ¿programación cruzada entre sitios?) es uno de los fallos de seguridad más habituales en la web. En Over 1 Million websites are at risk of sensitive information leakage - XSS is dead. Long live XSS nos recuerdan cómo a lo largo del tiempo se han proporcionado soluciones para evitar el problema, es bien conocido y eso significa que muchos sitios están protegidos.

Throughout the years, many protection layers have been placed to detect XSS and prevent its exploitation. From an attacker’s perspective, these protections pose a real challenge. While XSS is still alive and kicking, it has become astronomically more difficult to exploit it successfully than before, which explains why we gradually see fewer instances of it in the wild.

Sin embargo, aparecen nuevas formas de ataque y eso nos impide poder estar tranquilos. En este caso se trata de una combinación entre el XSS y el sistema de autorización OAuth.

However, similar to many other cases in the cybersecurity ecosystem - sometimes new, seemingly unrelated developments can lead to the reincarnation of old and, at times, forgotten vulnerabilities. In this blog post, we demonstrate why this is exactly the case of XSS when smartly combined with a new emerging technology - OAuth.

El problema del XSS se basa en la inserción de código en JavaScript en el navegador del usuario. Este JavaScript tiene acceso a lo que hay disponible para ese navegador y se pueden conseguir ataques que roban credenciales, sesiones, ….

If you write HTML/JS code instead of the input, the browser will think that the code was generated by the backend and parse it as legitimate HTML/JS.

Hay algunas técnicas para mitigar el problema como pueden ser: limpiar las entradas y codificar las salidas (Manual Input Sanitization and Output Encoding), utilizar entornos de programación modernos, que nos ayudan a manejar estos problemas (Using Modern Web Frameworks), parámetros como HTTP-Only, que evitan que los programitas peligrosos accedan a las cookies (HTTP-Only) y las políticas de seguridad de contenidos (CSP) que permiten especificar de dónde se pueden cargar determinados elementos peligrosos.

Después de esta introducción nos explican cómo encontraron un problema en hotjar, que es una herramienta de analítica web. Descargan sus programas en JavaScript (porque tienen que estar disponibles para enviarlos al navegador), los analizan hasta encontrar algún problema, y enconctaron algún problema. Sin embargo, el sitio estaba bien protegido contra estas cosas (con HTTP-Only) así que no era posible atacar directamente.

Y aquí entra en juego OAuth, gracias que hotjar utiliza login social mediante Google:

One of the features in Hotjar—and almost any other modern website today—is social login, which is based on OAuth (the open standard for authorization).

Esto significa que si pinchamos en la identificación con Google, el sitio confiará en lo que nos mande (si le hemos autorizado en el pasado) y por allí habrá códigos de autorización que estarán visibles para los programas en JavaScript.

In other words - the secret code, at the end of the OAuth flow, will be located in the URL - and that’s something that the javascript code can read.

Por lo tanto, si enviamos una petición adecuadamente preparada en el proceso de autorización, cuando nos vuelva tendremos acceso a esos códigos.

With this method, the javascript code opens a new tab to Google, and Google automatically redirects the user back to https://insights.hotjar.com with the OAuth code in the URL:

A veces los fallos son muy sencillos, y otras veces muy complejos. Aquí estamos en un camino intermedio donde la comodidad de los usuarios (y de los gestores del sitio) junto con la obligada confianza (necesaria para que todo funcione) nos juegan una mala pasada.

En este momento el problema estaría resuelto en este proveedor, pero es fácil que haya muchos sitios donde todavía no sean ni siquiera conscientes del problema.

El consejo que damos normalmente en estos días cuando hablamos de la seguridad de las contraseñas es doble: utiliza un gestor de contraseñas y activa el doble factor de autentificación. Si sólo vas a aplicar una, mejor la segunda (aunque tiene sus propios inconvenientes, cuando los mensajes no llegan y alguna situación curiosa se puede dar…). Como sabemos la autentificación con factor múltiple se basa en que el sistema en el que nos queremos identificar nos puede enviar algún tipo de reto (típicamente una segunda contraseña, un mensaje en alguna aplicación específica, o un mensaje en la misma aplicación pero en otro dispositivo…). Tiene la ventaja de que si adivinan nuestra contraseña podemos esperar que no tengan acceso al dispositivo donde recibiremos ese mensaje y, por lo tanto, la clave no les servirá de mucho.

En How MFA is falling short hablan de este sistema y de algunos de los problemas que pueden aparecer.

• Ingeniería Social.

Bastante frecuente, alguien intenta entrar en nuestra cuenta, se le solicita el factor y trata de engañarnos para que se lo demos.

MFA risk #1: social engineering

What’s the easiest way to steal a user’s authentication factors? Just ask them nicely.

• Robo de la sesión.

Este es un poco más técnico, pero es tan viejo, casi, como la web: robar las cookies que las plataformas envían para mantener nuestra información. Se hace, por ejemplo, a través de extensiones maliciosas del navegador.

MFA risk #2: session hijacking

Cookies have long been the way the internet has saved our browsing information and preferences; however, they also risk allowing threat actors to steal your credentials after login.

• Interposición.

Se trata de interponer entre el sistema real y el usuario algún otro que puede obtener la información que vamos transmitiendo.

MFA risk #3: man-in-the-middle (MITM) attacks

In MITM attacks, hackers create a fake network/server/webpage that intercepts user credentials when a user thinks they’re entering them into the legitimate destination.

• Robo de la SIM

En este caso engañamos al proveedor de comunicaciones de la persona atacada: conseguimos un duplicado de la SIM, después de conseguir tanta información como sea posible, para que sea más sencillo el engaño.

MFA risk #4: SIM swapping

They then contact the target’s phone carrier and impersonate them to receive a new SIM card. This allows the attacker to insert the SIM card into the mobile device of their choosing and effectively take over the target’s number.

• Hartazgo de notificaciones.

Si hacemos que al usuario le llegen tantas que está ya cansado y nervioso por el bombardeo es posible que baje la guardia y tengamos éxito.

MFA risk #5: MFA fatigue/bombing/flooding

The goal of an MFA bombing attack is to coerce the victim into confirming their identity via notification, which is almost always the second factor.

Después pasa a analizar algunas alternativas, y por donde podemos esperar que evolucionen las soluciones y recomienda, a día de hoy:

• Formación de los usuarios
• Utilización de un gestor de contraseñas
• Prestar atención a los dispositivos (para que no estén comprometidos).

La afirmación habitual de muchos desarrolladores, a veces, es: ¿quién usaría esto para hacer esto otro?. La respuesta de muchos atacantes es: vamos a ver qué podemos hacer con esta característica a la que no han prestado mucha atención.

En este caso hablamos de los comentarios de GitHub y cómo han sido utilizados para enviar malware GitHub comments abused to push malware via Microsoft repo URLs.

La clave está en que al enviar un comentario en GitHub es posible adjuntar un fichero (documentos, archivos, …) que se subirá al sitio que tienen previsto para ello y que tendrá una dirección web (URL) con el nombre del proyecto.

When leaving a comment, a GitHub user can attach a file (archives, documents, etc), which will be uploaded to GitHub’s CDN and associated with the related project using a unique URL in this format: ‘https://www.github.com/{project_user}/{repo_name}/files/{file_id}/{file_name}.’

Pero el problema es que la URL no se genera después de publicar el comentario, sino que está disponible incluso cuando el comentario no ha sido ni siquiera guardado todavía.

Instead of generating the URL after a comment is posted, GitHub automatically generates the download link after you add the file to an unsaved comment, as shown below.

Se genera la URL, se almacena el fichero, incluso cuando no publiquemos el comentario.

Even if you decide not to post the comment or delete it after it is posted, the files are not deleted from GitHub’s CDN, and the download URLs continue to work forever.

Y estas direcciones parece que son legítimas del proyecto, así que ahí tenemos una vía para distribuir cosas peligrosas.

¡Qué cosas!

En How an empty S3 bucket can make your AWS bill explode un (otro) recordatorio de la importancia de los nombres de las cosas.

En este caso, descubierto por casualidad: el autor habilita un entorno en la nube para una prueba de concepto de un cliente suyo, sube unos documentos y dos días después, cuando vuelve a mirarlo, se encuentra con una factura importante. En un servicio que en teoría casi no había tenido uso:

A few weeks ago, I began working on a PoC of a document indexing system for my client. I created a single S3 bucket in the eu-west-1 region and uploaded some files there for testing. Two days later, I checked my AWS billing page, primarily to make sure that what I was doing was well within the free-tier limits. Apparently, it wasn’t. My bill was over $1,300, with the billing console showing nearly 100,000,000 S3 PUT requests executed within just one day!

¿El problema?

El nombre que había elegido para su recurso coincidía con uno que utiliza una conocida herramienta por defecto.

Was it some kind of DDoS-like attack against my account? Against AWS? As it turns out, one of the popular open-source tools had a default configuration to store their backups in S3. And, as a placeholder for a bucket name, they used… the same name that I used for my bucket.

Eso era un riesgo solo por los accesos de consultas, pero también podría ser un asunto de seguridad si se permite escribir, porque alguien lo hará y puede encontrarse con sus datos confidenciales por ahí.

I opened my bucket for public writes and collected over 10GB of data within less than 30 seconds. Of course, I can’t disclose whose data it was. But it left me amazed at how an innocent configuration oversight could lead to a dangerous data leak!

Además del susto, algunos aprendizajes:

• Si alguien conoce los nombres de nuestros recursos puede darnos un buen susto con la factura

Lesson 1: Anyone who knows the name of any of your S3 buckets can ramp up your AWS bill as they like.

• Siempre es una buena idea añadir un sufijo aleatorio a nuestros recursos para que sea más difícil que el nombre coincida con el que alguien pueda usar.

Lesson 2: Adding a random suffix to your bucket names can enhance security.

• Controlar desde dónde se puede acceder a los recursos, por lo menos.

Lesson 3: When executing a lot of requests to S3, make sure to explicitly specify the AWS region.

Hoy una entrada ligera y que no va a llamar la atención de nadie que venga por aquí habitualmente, salvo por la visualización. En Most Common Passwords justamente eso.

Para ver, jugar, y -tal vez- concienciarnos un poco más.