Cómo una sola vulnerabilidad puede tirar abajo todo el ecosistema de JavaScript.
En el mundo del software development muchas veces, claro, damos por hecho la seguridad de todas nuestras herramientas y plataformas.
Pero claro, ¿qué significa esto? Que tú das por hecho que tú haces un NPM install y que todo funciona perfectamente y que nada, que no va a pasar nada.
Pero NPM, el registro de NPM, tiene 2 millones de paquetes y lo utilizan 17 millones de desarrolladores en todo el mundo.
Bueno, fijaos el ataque aquí que es interesantísimo.
Imagínate que muchas veces hablamos de, no, es que han cambiado esta dependencia, es que han atacado esto y tal.
Pero es que este ataque es todavía más bestia.
Porque han encontrado que NPMJS, el repositorio de dependencia de JavaScript más importante del mundo, es vulnerable a un ataque que sería desastroso.
Entiendo que ahora lo han arreglado, pero fijaos, registry en NPMJS.org es vulnerable.
¿Y cómo es vulnerable? Pues es vulnerable con un ataque de caché.
O sea, caché poisoning denial of service.
Que básicamente la idea, un poquito así, es una técnica web que lo que permitiría es, explotando estas vulnerabilidades, vas a atacar al sistema de cacheo.
De forma que el recurso que está cacheado lo vas a cambiar por otro, sin que nadie se dé cuenta.
O sea, tú no atacas el servidor real, tú no haces nada.
Sino lo que haces como atacante es manipular cómo funciona la caché y lo que guarda y cómo se sirve el contenido.
Y lo que haces es inyectar contenido en la caché, no en el real, porque seguramente el contenido real va a estar mejor protegido, va a ser más difícil.
Sino lo que haces es atacar la caché.
Y los usuarios, cuando piden, hacen una petición para ese recurso, lo que hace automáticamente, pues para que vaya mucho más liviano el sistema, lo que hace es ir a la caché.
Y la caché es la que va a tener ya ese contenido malicioso, sin que te des cuenta.
Esto sería un poco el tema, pero fijaos que todo esto encima te lo...
Ahora, disable caché, eso sería lo buenísimo.
Dice, el atacante utilizó diferentes headers hasta que encontró un trigger, un error en el backend.
Y enviando una petición especial con estos headers, el atacante pudo manipular la información que estaba guardada en la caché.
Entonces pudo cambiar ya la respuesta.
Fijaos aquí cómo va haciendo...
Está muy bien porque está súper bien explicado, ¿eh?
Cómo va dando aquí...
Y aquí se puede ir viendo cómo lo fue haciendo, ¿no?
Entonces, una vez que descubrieron cómo la caché funcionaba temporalmente, empezó a seguir utilizando ahí un montón de peticiones, haciendo un montón de peticiones, hasta que al final consiguió el hecho de inyectar la suya propia, ¿no?
Entonces estaba ejecutando el ataque.
Y ahora ya podría inyectarle a cualquier dependencia...
Claro, imagínate, Express.
Express.
Se instala 30 millones de veces a la semana.
Claro, es una dependencia que muchas veces va a llegar a la caché.
Explotando esta vulnerabilidad, el atacante al final lo que estábamos haciendo es tener un DNS of service del MPM y el usuario, como se dirá, ya no va a tener acceso al contenido real, el atacante va a poder decir, bueno, pues venga, ve a la caché y ahí lo tienes.
Así que está muy interesante, aquí en el artículo lo tenéis súper bien explicado.
En GitHub le han escrito, esto normalmente lo publican una vez que ya han visto el ataque.
O sea, una vez que ya tienes el ataque, avisas a la gente de GitHub, GitHub es que son los dueños de MPM.
Y una vez que hacen esto, pues entonces lo explican.
Pero dicen la gente de GitHub, y esto es verdad, que la complejidad, la forma de reproducirlo es bastante limitada, que puede ser complicado, que necesitas acceso a muchos sitios.
Pero también es cierto que el problema no es tanto la complejidad, sino el impacto que podría tener, ¿sabes?
Porque si con que jodas Express, por ejemplo, el impacto que tendrías en el ecosistema sería impresionante.
Así que si queréis saber más toda la información del caché Poisoning en MPM, os dejo el artículo por ahí, que la verdad es que está muy interesante.
Igualmente, mira, aquí tenéis un poco el timeline, como el 3 de marzo, pues reportaron la vulnerabilidad, se lo explicaron a GitHub.
Y la gente de GitHub le han confirmado que van a arreglar el issue, o sea, que no os penséis que ahora os lo vais a leer y vais a poder fácilmente arreglar esto y tal.
Porque ya están comentando que ya están trabajando en ello y que van a hacer que esto sea más complicado, que lo podáis retomar y todo esto, ¿eh?
Sí, sí, desde el año pasado, el 3 de marzo del año pasado.
Fijaos que el año pasado se lo comentaron y no ha sido hasta el 1 de junio que GitHub ha confirmado que están arreglando el problema.
O sea, imagínate cómo está la cosa.
Porque cerraron el problema e incluso, incluso dijeron que no les iban a pagar.
Habían encontrado este error y fijaos que dice, ah, no, sí, sí, les pagaron 500 dólares.
Es que al principio le cerraron el reporte diciendo que estaba duplicado, luego lo reabrieron y finalmente consideraron que le pagaran 500 dólares.
Esto es porque, no sé si lo sabéis, esto es muy interesante el tema del backhunting, en el que un montón de empresas, si tú encuentras un error de seguridad,
por ejemplo, lo tienes en Google, lo tienes en GitHub, lo tienes en un montón de sitios, pues tenéis el backbunty, ¿ves?
Esto, que puedes llegar a ganar hasta 30.000 dólares.
500 dólares es poco porque me entiendo que sería difícil de replicar.
Y entonces, por eso le habrán pagado poco.
Porque entiendo que cuanto más grave es, más puedes ganar.
Pero si lo encuentras, mira, aquí tenéis rewards.
Si es crítico, haz 20.000 dólares.
Si es alto, de 10.000 a 20.000.
Si es medio, 4.000.
¿Ves? Low, de 617 a 2.000.
Y esto es a nivel de GitHub.
Claro, estamos hablando de uno que han encontrado de NPM.
Que entiendo que es menos importante, aunque es importante, pero menos importante que GitHub.
Así que, bueno, si alguna vez encontráis algo de seguridad, pues no lo digáis gratis.
Lo hacéis desde aquí, ¿veis?
Podéis hacer un Summit a Vulnerability.
Aquí tenéis que explicar paso por paso cómo lo tenéis que hacer.
Y una vez que lo confirma y dicen, vale, sí, este error tiene razón, ha sido así, pues entonces os van a dar bastante dinero.
Fijaos que 4.800.000 dólares han dado ya a día de hoy.
De media se dan de 617 a 1.000 dólares.
Y lo más alto que se ha pagado han sido 75.000 dólares.
En los últimos 90 días han pagado 250.000 dólares de bugs o de vulnerabilidades.
También Google tiene, ¿eh?
O sea, esto lo podéis encontrar para todos, cada uno de los servicios que hay ahí fuera.
Así que echarle un vistazo a ver si conseguís dinerito, ¿eh?
Primero se vende la data, pues primero se vende la data, luego te le dicen la vulnerabilidad.
Y así es un 2x1, lo consigues todo.
Me parece buena idea, me parece buena idea.
Buena idea.