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.

El diablo está en los detalles y la realidad se empeña en mostrárnoslo (poco a poco, eso sí) continuamente. En este caso, The definitive guide to “Modulo Bias and how to avoid it”! habla de lo que llaman sesgo del módulo (modulo bias), y sus consecuencias.

Como sabemos, nos dice, las operaciones modulares se utilizan ampliamente en criptografía, y también en informática en general.

The modulo operation is used a lot in Cryptography, since we are usually dealing with number theory and algebraic structures that rely on the modulo operation at their core. But it is also used more broadly in Computer Science. It is typically represented in code by the symbol % and it is a binary operator that will take two integers as input and give one integer as output.

Pero el sesgo aparece cuando elegimos un número aleatorio y queremos obtener valores en un determinado rango. La causa es que típicamente utilizaremos un generador que proporciona números en otro rango diferente, y nosotros haremos la conversión. Pero si la cantidad de números de uno y otro rango no son compatibles (la grande es múltiplo de la pequeña), nos vamos a llevar un disgusto si medimos las frecuencias de los números generados: los primeros (el exceso de ese múltiplo) va a estar ligeramente sobre-representados.

The problem is basically the same as when you’re cutting a rope into smaller pieces of a given size: the last piece will most likely not be of the same size as the others, except if the initial length of your rope was perfectly divided by the length of the pieces.

No parece un problema muy grave, nos dice, pero quién sabe por dónde pueden evolucionar las técnicas de criptoanálisis.

It is true in general that biases are “just” reducing the actual entropy of a randomly generated value and thus are not as dangerous as for the above schemes, but future cryptanalytic breakthroughs might exploit them. As such we definitively prefer to have uniformly distributed random values, plus they also usually allow us to really rely on the mathematical proofs of security, when we have one.

¿Se puede remediar?

Existen varias formas, la primera sería descartar los valores que no pertenecen a nuestro rango a la hora de obtener números aleatorios.

Rejection sampling consists in sampling a random value and rejecting all values that do not fall into the right range.

El problema de este método es que si la diferencia entre rangos es muy grande podemos añadir un coste extra a la obtención de valores. Se puede aliviar un poco truncando el número al tamaño adecuado, pero no resuelve el problema completamente.

Otra posibilidad es seguir usando el módulo, pero teniendo en cuenta las limitaciones señaladas: esencialmente se puede utilizar el módulo para un conjunto de valores ‘equilibrado’; esto es, los números del final, que son los que nos provocarían las desigualdades pueden ser rechazados cuando salgan y calcular el módulo para el resto.

As we discussed earlier, if you are generating a value between 0 and 106, using one byte of randomness, then you can combine both rejection sampling and modulo reduction

Siguen pudiendo aparecer problemas, sobre todo si el exceso de números con respecto a la operación modular es grande.

Me gustó mucho leerlo, y no era consciente del problema, la verdad.