¿80-20 o mejor... tanto como puedas?

Muralla

Cuando debemos proteger un sistema normalmente tenemos que decidir a qué prestaremos atención primero. Luego, en qué punto debemos parar porque ya estamos razonablemente protegidos. Sin embargo, son decisiones que no son tan sencillas y en los que las reglas habituales para otros asuntos no siempre tienen sentido. En Why the 80-20 rule no longer works for cybersecurity hablaban justamente de eso.

El principio de Parto nos dice que aproximandamente el 80% de las consecuencias provienen del 20% de los motivos posibles, y esta es una regla que se utiliza en productividad, ventas, aseguramiento de la calidad y gestión de proyectos.

COMMENTARY: We’ve all heard about the Pareto Principle, the idea that approximately 80% of consequences result from 20% of causes. Organizations have long applied this “80-20 rule” to areas such as productivity, sales, quality assurance, and project management.

Esto también sucede en ciberseguridad, afirmando que con vigilar el 80% de los activos puede mitigar el riesgo. En algunos casos, incluso vigilando menos (pero los más importantes) puede ser suficiente:

Cybersecurity is no exception. Over the last 25 years, cybersecurity leaders have leveraged this principle to manage and secure assets, asserting that adequately monitoring 80% of assets can effectively mitigate risks. Some have gone as far as to believe that closely monitoring the crown jewel assets alone, even if they constitute just 1% of the total exposure, might be “good enough.”

Pero claro, la naturaleza de los ataques es tan variada y diversa que descuidar una parte puede ser justo lo que abra la puerta a nuestros problemas.

What does that unexamined 20% mean for these organizations? Most of the risk now gets concentrated in that bracket, which now contains the most attractive and exploitable assets for attackers.

Así que nos toca trabajar un poco más y estar atentos a todo lo que puede pasar, porque los problemas pueden venir por donde menos los esperemos.

Invest in the means to close the coverage gap now to future-proof the organization’s security strategy for the coming years. Leave the 80-20 rule behind.

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.