Cómo Explotar Vulnerabilidades del Mundo Real

Hola, chicos, gracias por unirse a mi sesión. Vamos a hacer una visión general de lo que vamos a hacer. Vamos a repasar algunas diapositivas para entender el código abierto, por qué es increíble, cómo nos ahorra tiempo y todo, y luego vamos a pasar a hackear una aplicación. Así que empecemos. Mi nombre es Noa. Soy un ingeniero de soluciones en Snyk. Y obviamente, si tienen alguna pregunta durante el taller, tienen el sistema de mensajería de preguntas y respuestas si quieren ser un poco anónimos o pueden preguntarme en el chat. Estaré mirando también allí. Y si aún no lo han hecho, por favor vayan a github.com/Snyk/exploit workshop, ahí es donde se llevará a cabo la sesión práctica y hagan un fork de nuestra aplicación Node.js, que estará conectada con el primer repositorio.

Genial, para empezar, ¿no es increíble el código abierto, nos ahorra mucho tiempo, nos da, ya saben, nos hace menos frustrados, no tenemos que escribir el código nosotros mismos a veces, podemos traerlo de fuera. Y solo una pregunta para reflexionar, ¿cuál es el futuro de la seguridad del software de código abierto? ¿Vamos a tener más código abierto, menos código abierto, ya saben, porque a veces puede traer vulnerabilidades, y vamos a tocar ese tema muy pronto. Entonces, como desarrolladores, ya saben, escribimos código, depuramos código, nos enfrentamos al código y obviamente, nos emocionamos con el código cuando solucionamos problemas. Sin embargo, el código con el que realmente nos enfrentamos todos los días es muy pequeño en comparación con las aplicaciones. Es solo la punta del iceberg. Y para aquellos que realmente han mirado el código, ¿pudieron encontrar algún problema de seguridad? Les daré un segundo, si alguien quiere intentarlo. Enviaré los enlaces del taller aquí en el chat. Ahí vamos. Exactamente. Sí, las entradas no están sanitizadas. Y simplemente las enviamos sin verificar qué son primero. Ese es el problema de seguridad. Buen trabajo. Genial. Cuando pensamos en el código, como dijimos, solo hemos visto la punta del iceberg. Pero en realidad, el 80 al 90% de la base de código es de código abierto. Y el 80% de las vulnerabilidades se encuentran en las dependencias transitivas. Incluso son las dependencias de las que no somos conscientes en nuestro código. Digamos que traigo una dependencia. Pero no sé qué dependencias están trayendo ellos.

Así que el 80% de las vulnerabilidades se encuentran en las dependencias transitivas. Aquí tengo un ejemplo de un paquete de código abierto, Dust.js LinkedIn, y veo que tiene una vulnerabilidad. Puede que no sepa dónde está la vulnerabilidad, pero al menos debería ser consciente de ella. Y ahí es donde necesitamos, ya sabes, ser conscientes de lo que estamos incorporando en nuestro código. Podemos utilizar herramientas como Snyk, que más adelante, durante la masterclass en sí, una vez que lleguemos a la parte práctica, vamos a crear un inicio de sesión, como un usuario en Snyk. Así que realmente podemos encontrar vulnerabilidades. Y más tarde, después de explotarlas, podemos solucionarlas y evitar que vuelvan a ocurrir. Nuevamente, no sé dónde está el problema, pero sé que hay un problema. Y sé la versión en la que estoy en esta dependencia y sé a qué versión quiero solucionarlo, para eliminar el problema. Así que visualicemos esto, supongo, en nuestra cabeza, esta es nuestra aplicación, ¿verdad? Estás trabajando en una aplicación, escribes el código. Esto es lo que pueden estar pensando, algunas líneas de código. Sin embargo, como dijimos, la imagen es mucho más grande. Nuestra aplicación se construye sobre mucho más que solo nuestro código personalizado. Y por eso necesitamos ser conscientes de ello.

También podemos ver que se utiliza mucho el código abierto. Se crean nuevos paquetes por ecosystem al año. Simplemente sigue creciendo y no se detiene. Porque, nuevamente, nos ahorra mucho tiempo. Nos ahorra mucha frustración y es súper útil para nosotros. Entonces, el hecho de que estemos utilizando código abierto es genial y fantástico, y nos ayuda. Pero no deberíamos sorprendernos cuando se agreguen nuevas vulnerabilidades a nuestros proyectos. Entonces, el código abierto es genial, pero también trae nuevas vulnerabilidades. Así que hay como esta pregunta, ¿es asombroso? ¿O no es asombroso? Nuevamente, la conciencia es clave aquí. Entonces, ¿qué tan bien conoces realmente lo que hay dentro de tus dependencias? ¿Las conoces bien? Y en realidad, hubo un problema de seguridad en la cadena de suministro en 2018. Sé que volvió a ocurrir en 2019.

Ahora voy a intentar hacer lo mismo o tal vez subir ya sabes, un directorio. Y estoy obteniendo algo extraño aquí. Sabes, la mejor forma de hacer el tonto que es la página principal. Así que déjame intentar uno más. Subir un directorio más. Y en realidad estoy obteniendo el mismo resultado. Entonces para aquellos que ya llegaron allí o aquellos que aún no lo han hecho pero aún quieren responder cómo puedo evitar el punto-punto aquí. ¿Alguna idea? Sí, exactamente. No cómo defenderse aún contra eso. Queremos primero hackear y luego defendernos. Entonces, codificación de URL, ¿alguien sabe qué son? ¿Cuáles son las codificaciones de URL para los puntos? Sí, exactamente. Entonces necesitamos dos de esos, ¿verdad? Ahora vamos a subir uno. Así que nos movimos, bien, ¿qué significa eso? Nos movimos uno y en realidad, hagamos esto. Oh, un segundo. Curl, en lugar de retroceder clave por clave. Bien, nos movimos desde lo público. Y ahora podemos buscar y encontrar cosas. Por ejemplo, si veo el package.json, puedo ver todas las dependencias que hay en este proyecto. Y al conocer las dependencias de este proyecto, puedo encontrar dónde están esas vulnerabilidades. Correcto. Entonces, por ejemplo, no quiero arruinar la sorpresa, pero marked es el próximo ejercicio que vamos a explotar. Entonces, al saber que están usando mark 0.3.5, sabemos que es vulnerable y sabemos que podemos explotarlo. Entonces, la traversión de directorios en realidad me permite llegar a lugares a los que no debería llegar. Y, por ejemplo, si incluso tienen permisos de escritura, puedo sobrescribir archivos y, ya sabes, obtener contraseñas y nombres de usuario y cosas realmente confidenciales si es necesario. Voy a borrar esto. Y vamos a volver aquí, presentar. Les voy a dar el siguiente escenario y ustedes me dirán qué problema podría ser. Entonces, si uno de sus usuarios recibe un enlace malicioso de su sitio web, ¿qué podría ser eso? Cross site scripting.

Esto. El siguiente es este. Cross-site scripting. Me salté uno y vamos a volver a él. Entonces, cross-site scripting. Y tienen aquí. Explicación. Qué es cross-site scripting. Y, por supuesto, la pista. Cómo hackear esto. Así que les daré cinco minutos y repasaremos la solución. Si no hay voluntarios, repasaré la solución. De manera sencilla, cuando pensamos en cross-site scripting, en realidad pensamos en agregar un script JavaScript. Usando algo como esto, y no lo estoy escribiendo porque cuando haga clic en él, verán todas las respuestas. Así que lo haremos paso a paso. Por ejemplo, si intento usar scripts y agregar una alerta, no pasará nada. Y la razón de esto es que cuando se construyó esta aplicación, se utilizó el paquete. Así que si en realidad jugamos y lo hacemos en negrita y hermoso. Y eso en realidad proviene de esto. Vemos a Mark aquí. Y en realidad estamos usando un sanitizador para Mark. Y ese sanitizador busca algunas cosas específicas sobre JavaScript. Por ejemplo, ve el script, alert1. Porque ve el script, sabe que es algún tipo de JavaScript y simplemente lo crea como una cadena. Y por eso lo vemos así. Entonces, si leemos sobre Markdown y lo que realmente nos permite hacer, podemos usar enlaces Markdown. Y esos enlaces Markdown se usan así, por ejemplo.

Y si lo hago, puedo hacer clic en él y me llevará a la interfaz de sincronización, lo cual es genial. Y si voy, digamos que quiero algo más. Así que en realidad puedo hacer algo que se vea así tal vez. Si lo intento, sabes, tengo mi JavaScript alerta aquí y mi enlace malicioso. Y estoy rezando para que funcione. Bueno, pero aún no funcionó. Y la razón de esto es que el sanitizador de Mark busca esta palabra JavaScript, ya sabes, JavaScript, y luego los dos puntos. Entonces, tiene una expresión regular detrás de escena que en realidad busca esto y si coincide, no te permitirá publicarlo. Así que podemos ser inteligentes y tal vez intentarlo nuevamente con algunas codificaciones, y representar el punto y coma y el corchete, así. Así que, con esperanza de nuevo de que esto funcione. Bueno, esto tampoco funcionó. Y la razón de eso es el mismo concepto, la expresión regular también está buscando JavaScript punto y coma, y JavaScript y signo, signo de almohadilla, 58, así que en realidad está buscando todo esto. Y está diciendo, bueno, sé que esa es la representación del punto y coma, así que tampoco lo dejaré pasar. Así que, pensando de nuevo, pensando de nuevo. Bueno, ¿qué pasa si agrego esto? Agregando esto. Así que este truco. En realidad funciona. ¿Alguien sabe la razón por la que esto funciona para nosotros? Entonces, de alguna manera, específicamente esto se usa para confundir al navegador. Entonces, el navegador está diciendo, bueno, esta palabra this realmente no coincide aquí, pero probablemente quisieron decir que fue probablemente un error y quisieron tenerlo sin this. Entonces, en este caso de uso específico, el navegador en realidad ignora esto, pero la expresión regular, dado que hay un this, no lo captura. Entonces, el navegador es en realidad la razón por la que podemos explotarlo.

Y de hecho, otro problema con la comunidad de código abierto es que nadie es realmente responsable de nada. Y si voy aquí, este fue en realidad un problema que se planteó específicamente, que si usamos documentos o esto, va a causar un problema de scripting entre sitios. Y esto se planteó en mayo de 2015. Perdón, mayo de 2015. Y en realidad se cerró un año después. Entonces, en términos de usar código abierto, ya sabes, no hay responsabilidades. Es solo una comunidad que lo hace. Y si la comunidad no lo mantiene, podría ser explotable.

En lugar de esta alerta. Intentemos eso. En realidad no estoy seguro. Intentemos. Esto. Eliminar. No, no funcionó. Si estoy enviando el enlace de GitHub. Genial, eso fue scripting de próstata. Continuemos.

Y ahora Otro caso para ti. Entonces, es Navidad y tienes una tienda de suéteres muy bonita, y la gente quiere comprar en línea, y algo está bloqueando al usuario para acceder a tu sitio. ¿Qué podría ser? Muy negación. Sí. Denegación de servicio. Entonces, nuevamente, el mismo concepto. Tenemos, tenemos los pasos aquí. Y quiero que crees algunos, ya sabes, usa la línea de comandos, usa lo que necesites y bloquea tu sitio web, congélalo. Este problema en realidad proviene de mis dependencias directas.

Así que vamos a ser buenos hackers de nuevo y vamos a ir a la línea de comandos y vamos a usar ese comando. Usar el paquete M.S. y vamos a, ya sabes, vamos a quieres agregar otra cosa en mi lista de tareas, quiero comprar leche en cinco minutos. Voy a ingresar eso y vemos que ha terminado y si voy aquí y actualizo la página veo mi leche en cinco minutos. Genial. Así que voy a hacer eso de nuevo. Así que cinco correcto, muchos cincos. Veamos qué sucede. OK. Voy a actualizar mi página de nuevo. Sigue funcionando bien. Así que ahora en lugar de escribir manualmente todos esos cincos en realidad voy a usar este comando que imprime muchos cincos muchas veces. Así que voy a hacer eso. Y vemos que empezamos a ver que hay un pequeño retraso entre cada uno. Así que hagamos lo mismo y agreguemos otro cero. OK, así que empezamos a ver ese retraso Así que lo voy a hacer con uno, dos, tres, cuatro ceros. Eso es cuatro. Sí, estoy ciego. Sí, cuatro ceros. Y. OK, está tardando un poco más y quiero eliminar cosas y agregar cosas. Agregando mi nombre muchas veces y realmente no está sucediendo nada. Así que detrás de escena, algo que se llama retrotrazabilidad catastrófica está.

Lo siento, se me olvidó por completo eso. En realidad. Bueno, disculpas por esto. Me salté un paso en mi explicación y lo olvidé por completo. Entonces, lo que sucede aquí en este paquete específico es que estamos buscando algún tipo de número. Y luego usando regex y luego buscando la palabra minutos u horas o cualquier otra cosa, realmente. Entonces, esto es lo que estamos buscando ahora en regex.

Hay algo que se llama retrotrazabilidad catastrófica, que es decir. Está intentando buscar una coincidencia. OK, lo que hice que causó la denegación de servicio es que Cambié la S al final por una A. Entonces, si volvemos al último comando que ejecuté, ves aquí, cambié la S por una A. Y esa es la razón que causa la retrotrazabilidad catastrófica. Entonces, lo que hace es buscar, ya sabes, está pasando por todos esos números, ya sabes, como muchos cincos, buscando en todos ellos finalmente obtiene. Es como, OK, los encontré. Genial. Encontré una I. Genial. Todo el camino. Encontré una última letra increíble. Oh no, no es una S. ¿Qué hago? Entonces comienza a entrar en pánico. El regex comienza a entrar en pánico. Así que retrocede y realmente intenta encontrar esa coincidencia. Este es un ejemplo más pequeño y a menor escala porque no tenemos tiempo para ir a cientos de ejemplos.

En este ejemplo, tenemos una a y luego B o C más. Así que muchos C, al menos debe haber uno. Y luego toda esta expresión debe ocurrir al menos una vez y luego debe tener una D al final.

Entonces, la forma en que se vería esto es algo así. Estos son los pasos. OK. Ahora, si eliminamos la D aquí y la cambiamos por algo más. Podemos ver que de nueve pasos, saltó a treinta y ocho pasos y esto es solo por cinco letras. Así que ahora entra en pánico y trata de encontrar esa coincidencia nuevamente. Y eso es lo que está sucediendo con 'minutes' con una A al final en lugar de una S.

Entonces ahora vemos que después de que pasó el tiempo, finalmente agregó todos mis Noah's. Y milk. ¿Alguna pregunta sobre esto? ¿Tuvo sentido eso? Lo siento. Me salté ese paso súper importante por completo.

Genial, ahora que realmente hemos explotado. ¿Cómo lo hacemos bien para verlo? Puedo enviártelo aquí. Solo está en línea, es un sitio web muy útil. Me gusta mucho, para aquellos que aman las expresiones regulares, este es un sitio web realmente bueno para encontrar coincidencias y todo eso. Casi como Tinder. Solo bromeo. Así que ahora hemos explotado. Hemos explotado la aplicación y ahora realmente queremos solucionarlo. Entonces, si vas a Snyk y ya tienes todas esas cuestiones específicas. Cada una. Esta es la marca que estamos buscando. Cada una tiene, por ejemplo, SD, el primer problema que explotamos. Así que podemos ver toda esta información al respecto. Vemos que se introdujo desde la versión 0.2.4 y dónde se solucionó. Entonces, si lo actualizamos solo 0.01 versión más arriba, ya no es vulnerable. Y en realidad, si quieres aprender más sobre esta vulnerabilidad de recorrido de directorios, hay un módulo de aprendizaje completo que puedes hacer aquí que realmente te enseña de manera práctica qué es este problema, aunque ya lo hayamos hecho. Así que ahora todos ustedes son expertos. Y también, una descripción general de qué es este problema.

Para evitar que esto suceda, no podrás lidiar con ello. Por supuesto, información adicional como el sistema común de puntuación de vulnerabilidades, que es un estándar de la industria, y por supuesto, si quieres aprender más sobre esta biblioteca específica, puedes leer todo al respecto aquí. Así de fácil, ya sabes, con solo hacer clic en un botón.

Voy a acceder a la vulnerabilidad. Pero va a llevarme a una página donde puedo agregar si quiero corregir más vulnerabilidades, por ejemplo, tengo un recorrido de directorios aquí por Adam's. Pero no quiero corregirlo ahora mismo, solo quiero centrarme en St. Así que voy a abrir una solicitud de extracción corregida.

Ahora Snyk, detrás de escena, va a escribir un mensaje de confirmación y abrir una nueva rama para este problema. Tomará un poco de tiempo. Abro mi GitHub y voy a mi aplicación tonta. Puedo ver que no es esta. Vale, mi Internet está un poco lento. Pero en general, una vez que abres esa solicitud de extracción corregida, se verá así. Se verá así. Y en realidad tendrás ese mensaje de confirmación con toda la información sobre este problema. Si está corregido o no, el sistema común de puntuación de vulnerabilidades o qué tipo de problema es. Así que este en realidad también es un problema de fuera de servicio. Pero está llegando a través de mime, es un problema diferente.

Además de eso, Snyk ejecutará pruebas adicionales en esta rama para asegurarse de que no estés agregando nuevas vulnerabilidades a tu aplicación. Porque tenemos una especie de fase inicial donde solo queremos limpiar nuestra aplicación de vulnerabilidades en lugar de agregar nuevas. Así que nos aseguramos de que no estemos agregando problemas de seguridad de código abierto, problemas de licencia y problemas de análisis de código estático en el plan gratuito, creo que solo verás este. Así que nos aseguramos de que no estemos agregando nuevas vulnerabilidades a esto. ¿Alguien pudo probarlo? ¿Pudieron probar la solicitud de extracción corregida? ¿Alguien? Permítanme intentar corregirlo. Creo que tal vez sea un problema de mi lado. Pero una vez que las corrijas, puedes ejecutar tu aplicación nuevamente. Después de reconstruirla, obviamente. Y una vez que lo hagas, intenta hackearlo nuevamente. Intenta explotar la aplicación nuevamente. Y verás que la versión realmente importa.

Entonces, las conclusiones de la sesión de hoy son: conecta tu repositorio de código fuente para escanearlo continuamente. Y obviamente, conoce tus fuentes. Si estás utilizando nuevas dependencias, puedes utilizar el asesoramiento de Snyk para verificarlas antes. De esa manera, sabrás qué versión es vulnerable y cuál estás esperando que pase la prueba. Increíble. Por lo tanto, puedes utilizar el asesoramiento para comprender realmente lo que estás incorporando a tus proyectos antes de descargar el paquete. Y sí, puedes utilizar Snyk de forma gratuita. Aquí mismo. Y mantente seguro en tu trayecto.