Llevamos mucho tiempo (tal vez demasiado) en el que hacer programas inseguros no era algo que preocupara mucho a nadie. Desde hace algún tiempo venimos escuchando llamadas a la responsabilidad, regulaciones y tímidas amenazas para mejorar el tema. En CISA boss: Makers of insecure software must stop enabling today’s cyber villains Jen Easterly, directora de la Cybersecurity and Infrastructure Security Agency (CISA) de los EEUU ha ido un poco más allá, diciendo que los vendedores son los que están creando problemas, abriendo la puerta a los malos para atacar a sus víctimas.

“The truth is: Technology vendors are the characters who are building problems” into their products, which then “open the doors for villains to attack their victims,” declared Easterly during a Wednesday keynote address at Mandiant’s mWise conference.

Ya puestos, se quejaba también de darles nombres ‘molones’ a los grupos criminales, dándoles aspectos ‘glamourosos’.

Easterly also implored the audience to stop “glamorizing” crime gangs with fancy poetic names. How about “Scrawny Nuisance” or “Evil Ferret,” Easterly suggested.

Y no sólo eso, porque también afirmaba que el nombre de vulnerabilidades de los programas (software vulnerabilities) contribuía a difuminar la responsabilidad y que deberían llamarse defectos de los productos (product defects). No se trata de señalar las víctimas por no actualizar, sino a los autores por desarrollar productos que requieren esas actualizaciones Ya puestos, se quejaba también de darles nombres ‘molones’ a los grupos criminales, dándoles aspectos ‘glamourosos’.

Easterly also implored the audience to stop “glamorizing” crime gangs with fancy poetic names. How about “Scrawny Nuisance” or “Evil Ferret,” Easterly suggested.

Y no sólo eso, porque también afirmaba que el nombre de vulnerabilidades de los programas (software vulnerabilities) contribuía a difuminar la responsabilidad y que deberían llamarse defectos de los productos (product defects). No se trata de señalar las víctimas por no actualizar, sino a los autores por desarrollar productos que requieren esas actualizaciones.

Even calling security holes “software vulnerabilities” is too lenient, she added. This phrase “really diffuses responsibility. We should call them ‘product defects,’” Easterly said. And instead of automatically blaming victims for failing to patch their products quickly enough, “why don’t we ask: Why does software require so many urgent patches? The truth is: We need to demand more of technology vendors.”

Muy interesante.

Modestamente, ese mensaje también lo decíamos en En las Mesas de Debate AICAR ADICAE sobre ciberseguridad , aunque creo que es un mensaje que hay que trasladar cuidadosamente en determinados sitios porque hay gente que tiene comportamientos casi ‘suicidas’ y no deberíamos formentar tampoco eso.

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.

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.

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.

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.