Una de las facetas más curiosas de la seguridad informática es que se siguen cometiendo los mismos errores desde hace un montón de años. En SQL injection: The bug that seemingly can’t be squashed nos recuerdan que los fallos de inyección de SQL acaban de cumplir 22 años pero siguen siendo un problema frecuente de seguridad.

December 2020 marked SQL injection’s 22nd birthday (of sorts). Despite this vulnerability being old enough to drink, we’re still letting it get the better of us instead of squashing it for good. In August this year, Freepik Company disclosed that they had fallen victim to an SQL injection blunder that compromised the accounts of 8.3 million users.

La inyección de SQL se produce cuando alguien que utiliza un programa es capaz de hacer que se lancen sus preguntas directamente a la base de datos. De allí puede salir cualquier problema: divulgación de información, modificación o incluso eliminación. El problema tiene que ver casi siempre con desarrolladores que no han tomado las precauciones necesarias para que esto no pueda suceder (esencialmente validar que los datos proporcionados por el usuario corresponden a lo que deben y que no incluyen ‘sorpresas’).

Es un problema especialmente grave porque no tiene que ver con los usuarios: son los desarrolladores los que pueden evitarlo con unas prevenciones mínimas y, aún así, no se remedia.

We keep saying that SQL injection is simple to fix and that code should be written so as to not introduce it at all. Like most things, it’s only easy when you’ve been taught how to do it right.

Aunque siempre pensamos que los ataques son muy sofisticados, lo cierto es que no parece que esto sea siempre así.

En la nota dicen, y debe de ser verdad, que muchas personas que estudian informática nunca han llegado a recibir formación sobre estos temas:

This shouldn’t come as a surprise: most engineers complete their degree without having learned much about secure coding (if anything at all). Most on-the-job training is inadequate, especially in an environment where security is not seen as a business priority in their role.

Algunos lenguajes nuevos, más robustos, ayudan con algunos fallos que sigue habiendo. Pero sigue habiendo sistemas legados, código viejo y bibliotecas que no manejan bien estas cosas (y también, esto lo digo yo, desarrolladores que siguen haciendo las cosas ‘a mano’ sin tener en cuenta las amenazas que existen).

Newer, more security-robust languages like Rust are helping to eradicate some of the bugs we’ve dealt with for a long time by utilizing safer functions, but there is an enormous number of legacy software, older systems, and libraries that will continue to stay in use and be potentially vulnerable.

Como siempre decimos, los desarrolladores deben embarcarse en este viaje desde el principio y recibir el apoyo adecuado para desarrollar mejor.

Developers must be brought on the journey from the beginning, and supported to take responsibility for their part in creating safer, better code.

Internet no se diseñó pensando en la privacidad. Esto hace que casi cualquier iniciativa en la red pueda ser usada para ‘conocernos mejor’. En este caso, unos investigadores de la Universidad de Illinois (Chicago) nos hablaban de los ‘faviconos’: Favicons may be used to track users. Los ‘faviconos’ son esos dibujitos asociados a los sitios web que aparecen en la barra del navegador y también en los favoritos, en la barra del navegador…. Como siempre, y por motivos de eficiencia, se almacenan. El problema parece ser que no se almacenan con el resto de objetos temporales del navegador (caches).

Favicons are used by site to display a small site icon, e.g. in the address bar of browsers that support it but also elsewhere, e.g. in the bookmarks or tabs. Favicons are cached by the browser, but are stored independently from other cached items such as HTML files or site images.

Los investigadores prepararon un sistemas para generar el almacenamiento de diferentes ‘faviconos’ según la navegación del usuario y, por lo tanto, mejorar las poosibilidades de identificar a un usuarios conforme se tienen más datos almacenados en su navegador.

A single favicon is not enough to identify users based on it, but the researchers discovered a way to plant multiple favicons in the favicon cache. The site does a series of redirects through several subdomains to save multiple different favicons in the cache. Each saved favicon creates its own entry in the cache, and all of them together can be used to identify users provided that enough favicons are saved using the methodology.

Curioso.

Algunas funciones recursivas se pueden convertir fácilmente en bucles (composiciones iterativas). En general se trata de una buena medida, porque evita las llamadas recursivas a la función y eso, por si solo, ya asegura una mayor velocidad de ejecución (todos sabemos que la llamada a la función provoca una serie de movmientos de información en la pila que tienen un coste, por pequeño que sea).

De eso hablan en How Tail Call Optimization Works. Nos explican cómo funcionan las llamadas a funciones, en particular la necesidad de copiar el contador de programa (program counter) en la pila, hacer un salto y luego otro…

The PC is pushed onto the stack so the called function can return back to the right spot. To return from a function, a function executes ret which pops the top value on the stack and then jumps back to that location.

Nos muestra el código en ensamblador y lo hace con bastante detalle. También cómo los compiladores son capaces de detectar los casos de este tipo de recursión ‘al final’ (tail call optimization) sustituyendo la llamada a la función por un salto (esto es evitando la copia de datos y todo eso).

This is tail call optimization. Tail call optimization happens when the compiler transforms a call immediately followed by a ret into a single jmp. This transformation saves one instruction, and more importantly it eliminates the implicit push/pop from the stack done by call and ret.

Una buena descripción del problema y la solución.

En How to Build HTML Forms Right: Security otro resumen de los que estamos trayendo últimamente. En este caso, sobre cómo preparar formularios en HTML teniendo en cuenta la seguridad.

Cifrado, la diferencia entre GET y POST (más visible o menos visible, pero también otras), spam, honeypots, mecanismos basados en retos, APIs, cortafuegos de aplicaciones, validación de datos (siempre en el servidor), saneamiento de datos …, tokens, CSRF, y otros elementos más infraestructurales.

Un buen repaso.

Hacer un sistema invulnerable es muy difícil. Hay personas muy ingeniosas que encontrarán formas de ir consiguiendo lo que quieren. En Stealing Your Private YouTube Videos, One Frame at a Time David Schütz nos cuenta sus experimentos para tratar de ver vídeos privados del sitio. Estos vídeos son los que sólo puede ver el propietario o personas a las que se les de permiso de manera explícita.

… and Private, where only you can watch the video, or other accounts you’ve explicitly given permission to do so.

Después de intentarlo directamente, pensó que podría tratar de probar con otros servicios de Google, de forma que a través de ellos pudiera saltarse las protecciones (el típico caso en el que una herramienta confía en otra, más de lo que debería).

A great thing to do in a situation like this, is to try to look for other products/services which are not your main target, but are somehow interacting with its resources internally. If they have access to its resources, it might be possible that they don’t have every level of protection that the main product has.

Y entre ellos encontró el servicio de anuncios (Ads) que, efectivamente, accede a los vídeos para poder seleccionar en qué momento es mejor mostrar la publicidad.

It had an embedded player, some statistics, and an interesting feature called Moments. It allowed advertisers to “mark” specific moments of the video, to see when different things happen (such as the timestamp of when the company logo appears).

Siguiendo con la investigación descubrió una llamada para ver el pantallazo de un momento determinado.

Looking at the proxy logs, every time I “marked a moment”, a POST request was made to a /GetThumbnails endpoint, with a body which included a video ID:

La prueba, entonces, era evidente: poner allí el identificador de un vídeo ‘privado’ y ver qué sucedía (pista: devolvía el pantallazo).

I did what I did a bunch of times already, and replaced the ID to my second account’s Private video in the request, and to my surprise, it returned a base64 response!

Esto sólo es un pantallazo, claro, pero con esa información ver el vídeo completo es relativemente sencillo. Sólo hay que descargar una imagen cada 33 milisegundos del vídeo en cuestión.

So I just have to download every image starting from 0 milliseconds, incrementing by 33 milliseconds every time, and then construct some kind of video using all of the images I have acquired.

Interesante, aunque seguro que todos están pensando que hace falta el identificador del vídeo (el mundo es imperfecto). Además, nos dice, no podremos escuchar el sonido y la resolución no será muy buena.

In the real world you would have to know the ID of the target video. Mass-leaking those would be considered a bug on its own.

Since these are just images, you can’t access audio.

The resolution is very low. (but it’s high enough to see what is happening)

En todo caso, desde el punto de vista de la seguridad, logro conseguido. Y recordatorio de una vieja lección: sistemas seguros pueden interactuar entre sí de forma no tan segura. Y darle algún beneficio al atacante.

The takeaway from this bug is that situations where two different products interact with each other under the hood are always a good area to focus on, since both product teams probably only know their own systems best, and might miss important details when working with a different product’s resources.

Una historia interesante.