Diez años por aquí

Tarta

En este sitio no hemos ido celebrando aniversarios ni nada de eso.Por este mismo motivo no era consciente del tiempo que llevamos aquí, el 6 de noviembre cumplimos diez añazos, así que he pensado que podríamos reflejarlo aquí.

Ni siquiera estamos muy seguros de que alguien lea, como para pensar en los aniversarios. Seguimos, en todo caso, en el espíritu de que al autor le sirve para leer, anotar, comentar…

Todo ha sido al actualizar un poco la plantilla (aprovechando que he tenido algunas sesiones sobre la web he repasado html y esas cosas) y cuando me puse con este sitio me di cuenta casualmente del detalle.

La seguridad de esos servicios que utiliza y conoce poca gente

T2(.0)

A veces la seguridad se basa en que el servicio es oscuro y utilizado por poca gente, y a la pregunta de ‘¿quién podría intentar atacar esto?’ la respuesta es, efectivamente, ‘nadie’. Pero en algunas ocasiones esta respuesta se transforma en ‘casi nadie’ y eso puede ser un problema.

De un caso de estos nos hablaban en Bypassing airport security via SQL injection donde Ian Carroll y Sam Curry descubren que los sistemas que permiten aligerar el control para algunos de los usuarios más habituales de los aeropuertos (tripulaciones, fundamentalmente) utilizar mecanismos para ahorrarse las verificaciones que sufrimos el resto de los mortales.

El caso es que esto depende de un sistema que la TSA (Transportation Security Agency) subcontrata a otra empresa que no le pone el cariño suficiente a estas cosas y los investigadores descubren que tiene un API que no se preocupa de cosas tan básicas como las comillas en una petición de datos. Tirando del hilo, encuentran la forma de manipular los datos y algunas otros problemas más.

We ended up finding several more serious issues but began the disclosure process immediately after finding the first issue.

Cuidado con los secretos divulgados en las nubes

Callejeando

Un experimento curioso: se dejan credenciales de la API de AWS en diversos sitios y se espera a ver qué sucede, monitorizando la actividad.

In this research, I used AWS API credentials as canary tokens, strategically placing them in publicly accessible locations on the internet.

Los lugares elegidos fueron:

  • Servidores públicos de código (GitHub, Gitlab, itBucket, DockerHub)
  • Servicios públicos manejados por el atuor: servidores de FTP, web, blog
  • Servicios Saas: Pastebin, JSFiddle
  • Gestores de paquetes de código: NPMJS, PyPi
  • Almacenes de datos en la nube (Cloud Storage Buckets): AWS S3, GCP Google Cloud Storage

Los resultados dicen que los intentos más rápidos de ataque viniveron desde las credenciales depositadas en npmJs (menos de 60 segundos), Pypi (119 segundos) y GitHub (127 segundos). En Pastebin tardaron 50 minutos y en otros ya pasamos a más de un día.

Grab Quickness – I find it pretty amazing that some tokens were grabbed and used after a few seconds. The NPMJS token was grabbed in less than a minute which includes the overhead time of logging and detecting the access attempt. GitHub and Pypi were close behind with about 2 minutes until the access attempt.

La otra sorpresa es que no hubo ningún acceso en los servicios BitBucket y GitLab.

No access attempts on BitBucket and GitLab. Going into this I was sure the tokens on these services will be grabbed pretty quickly, probably not as fast as on GitHub, but still, I didn’t’ expect 0 hits. I’m still not sure the reason for this, perhaps it’s due to them being less popular or maybe it is harder to scrape them automatically.

Espeluznante.

Despliegue de URLs, interacción en Slack y sus riesgos

Rocas y agua

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.

Entrada a los programas, visibilidad y posibilidades de espiar

Cambio de gafas. Antes y después.

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.