El desplegado de URLs (unfurling) tiene que ver con esas aplicaciones que cuando tienen una URL la descargan para mostrarnos una previsualización de la página. Se puede ver, por ejemplo, en redes sociales, pero en este caso nos hablan de Slack.

En The dangers of AI agents unfurling hyperlinks and what to do about it nos hablan del problema que esto puede supone cuando, por ejemplo, cuando un chatbot puede recibir a través de este proceso datos y generar un ataque de inyeción de preguntas (prompt injection attack).

This becomes a threat in LLM (large language model) powered Chatbots and Slack Apps when untrusted data enters a chat, for instance via a prompt injection attack.

Podría ocurrir, por ejemplo, que un atacante provocara el desplegado de enlaces que contengan parte de algun de las conversaciones de nuestro Slack. Al hacer la consulta este contenido terminaría en el registro de actividad (log) del servidor.

Now, during a prompt injection attack an attacker can cause rendering hyperlinks that contain past chat information in the URL (or other data that might be accessible), and Slack would send the data off to the third party server automatically.

La verdad es que parece un poco truculento, pero ya sabemos que el diablo está en los detalles.

En Why you should use STDIN to read your program arguments nos recordaban hace unas semanas que la lectura de parámetros para un programa es más segura si se hace desde la entrada estándar que desde variables de entorno o parámetros de la línea de órdenes.

STDIN is more secure than environment variables or command-line arguments

Algunas razones son que los parámetros de la línea de órdenes son visibles cuando se ejecuta la instrucción ps, lo que significa que cualquier usuario local podría verlos y, por lo tanto, obtener información útil.

When you pass command-line arguments to a program, they are visible to anyone who can run the ps command. Allowing others to read arguments is a security risk if the arguments contain sensitive information like passwords or API keys.

Por otra parte, cuando hablamos de las variables de entorno también son accesibles para alguien que pueda ejecutar ps (ps eww <PID>), y además son visibles para el programa y, por lo tanto, cualquier parte de nuestra aplicación podría tener acceso a ellas.

Environment variables are also visible to anyone who can run the ps command. They are also globally visible to the program, so any arbitrary code in your application can extract the environment variables.

Sin embargo, si usamos STDIN, lo que hay allí no es visible para ps, y tampoco es visible de manera global para todo el programa.

STDIN is more secure because it is not visible to the ps command and is not globally visible to the program. Thus, only the parts of the program that explicitly read from STDIN can access this data.

Luego da algún ejemplo sobre la forma de hacerlo en Go, y cómo integrarlo con otros mecanismos para guardar información.

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!