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.

Esta es una batalla perdida: yo mismo utilizo clientes de correo que lo interpretan y envío mensajes en HTML. Sin embargo, es bueno recordarlo, y de vez en cuando alguien lo hace. En Kobold letters. Why HTML emails are a risk to your organization nos recordaban algunos aspectos relevantes.

Es un problema desde el punto de vista técnico, tanto de interpretación del mensaje, como desde el punto de vista de la seguridad, nos dice:

Anyone who has had to deal with HTML emails on a technical level has probably reached the point where they wanted to quit their job or just set fire to all the mail clients due to their inconsistent implementations. But HTML emails are not just a source of frustration, they can also be a serious security risk.

En esta caso hablan de las llamadas Kobold letters que, esencialmente, tienen diferente aspecto cuando se reciben por primera vez; y cambian cuando son reenvíadas (forward).

The email your manager received and forwarded to you was something completely innocent, such as a potential customer asking a few questions. All that email was supposed to achieve was being forwarded to you. However, the moment the email appeared in your inbox, it changed.

Esto se debe a la posibilidad de utilizar las hojas de estilo en cascada (CSS) y los cambios que se producen al reenviar un mensaje, que permiten activar reglas diferentes, que muestran alguna parte del mensaje que el receptor original no podía ver.

This attack is possible because most email clients allow CSS to be used to style HTML emails. When an email is forwarded, the position of the original email in the DOM usually changes, allowing for CSS rules to be selectively applied only when an email has been forwarded.

Desde el punto de vista del usuario no hay mucho que podamos hacer (algunos clientes permiten ver HTML básico, sin estilo, o podemos desactivarlo completamente, pero entonces habrá correos que no podremos leer completamente). Según nos cuentan en la historia, los diversos clientes toman medidas contra esto, dentro de sus posibilidades.

El protocolo HTTP (Hypertext Transfer Protocol) es el que proporciona las bases fundamentales para la web. A mi me parece bastante interesante saber cómo funciona (aunque sea a nivel generalista) para comprender un poco mejor la web y por eso me gustó leer HTTP/2 and HTTP/3 explained.

Conviene recordar que la web, tal y como la conocemos se basa en un lenguaje para escribir documentos (HTML), un protocolo de transmisión (HTTP) y en una arquitectura cliente (el navegador) servidor (el que nos proporciona la información cuando nos conectamos).

El protocolo ha pasado por varias versiones, desde la HTTP/0.9, que fue el primer borrador hasta el más moderno, la versión 3 del protocolo (que apareció en 2012) que todavía no es de uso mayoritario (ver, por ejemplo, el dato de Examining HTTP/3 usage one year on, que tiene datos del año pasado).

Hacia el final nos recuerdan que HTTP/3 nació para dar mejor servicio a las conexiones menos estables, como los teléfonos móviles.

HTTP/3 was designed for unstable connections, such as cellphone and satellite networks. To counter network instabilities, QUIC has a great degree of independence between the data streams and good resilience if packets are lost.

Así como las mejores prestaciones de la versión 2 del protocolo cuando las conexiones son estables.

On reliable and stable connections, HTTP/2 many times offers better performance than HTTP/3.