# Secure Software Testat 2 - Web App Security
Gruppenarbeit von Dante Suwanda und Janosch Bühler
## Inhaltsverzeichnis
[TOC]
## Aufgabe 1
### 1.1 Beschreibung CVE-2021-22931

<!-- Node.js before 16.6.0, 14.17.4, and 12.22.4 is vulnerable to Remote Code Execution, XSS, Application crashes due to missing input validation of host names returned by Domain Name Servers in Node.js dns library which can lead to output of wrong hostnames (leading to Domain Hijacking) and injection vulnerabilities in applications using the library. -->

Node.js vor den Versionen 16.6.0, 14.17.4 und 12.22.4 ist anfällig auf Remote Code Execution, Anwendungsabstürze und XSS. Aufgrund fehlender Inputvalidierung von Hostnames, die von Domain Name Servern in der Node.js DNS-Library zurückgegeben werden, tritt diese Schwachstelle auf. Dies kann zur Ausgabe von falschen Hostnames (was wiederum zu Domain Hijacking führt) und zu Injektionsschwachstellen in Anwendungen führen, welche die Library verwenden.

Quelle: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22931

<!-- - CVSS Score 7.5
- Confidentiality Impact Partial (There is considerable informational disclosure.)
- Integrity Impact Partial (Modification of some system files or information is possible, but the attacker does not have control over what can be modified, or the scope of what the attacker can affect is limited.)
- Availability Impact Partial (There is reduced performance or interruptions in resource availability.)
- Access Complexity Low (Specialized access conditions or extenuating circumstances do not exist. Very little knowledge or skill is required to exploit. )
- Authentication Not required (Authentication is not required to exploit the vulnerability.)
- Gained Access None
- Vulnerability Type(s) Execute Code Cross Site Scripting -->

- **CVSS-Wert**: 7.5
- **Auswirkungen auf die Vertraulichkeit**: <span style="color:orange">Teilweise</span>
- Es besteht ein erhebliches Mass an Informations Disclosure.
- **Auswirkungen auf die Integrität**: <span style="color:orange">Teilweise</span>
- Die Änderung einiger Systemdateien oder Informationen ist möglich, aber der Angreifer hat keine Kontrolle darüber, was geändert werden kann. Der Umfang dessen, was der Angreifer beeinflussen kann, ist begrenzt.
- **Auswirkungen auf die Verfügbarkeit**: <span style="color:orange">Teilweise</span>
- Es kommt zu Leistungseinbussen oder Unterbrechungen bei der Verfügbarkeit von Ressourcen.
- **Zugriffskomplexität**: <span style="color:red">Gering</span>
- Es gibt keine speziellen Zugriffsbedingungen oder mildernden Umstände. Für die Ausnutzung sind nur sehr geringe Kenntnisse oder Fähigkeiten erforderlich was die Vulnerability auch für "Skript-Kiddies" anfällig machen kann.
- **Authentifizierung**: <span style="color:red">Nicht erforderlich</span>
- Für die Ausnutzung der Schwachstelle ist keine Authentifizierung erforderlich.
- **Erlangter Zugriff**: <span style="color:green">Keiner</span>
- **Art der Sicherheitsanfälligkeit**: Execute Code Cross Site Scripting

### 1.2 CVE-2021-22931 und OWASP Juice Shop

Der OWASP Juice Shop verwendet node.js, welches bis zu bestimmten Versionen von dieser Schwachstelle betroffen ist. Der Juice Shop unterstützt mehrere Versionen von node.js wie auf GitHub vermerkt ist.


> OWASP Juice Shop officially supports the following versions of node.js in line with the official node.js LTS schedule as close as possible. Docker images and packaged distributions are offered accordingly.

| node.js | Supported | Tested | Packaged Distributions | Docker images from `master` | Docker images from `develop` |
|:--------|:---------------------|:-------------------|:--------------------------------------------------|:-------------------------------------------------|:--------------------------------------------------|
| 18.x | :x: | :x: | | | |
| 17.x | :heavy_check_mark: | :heavy_check_mark: | Windows (`x64`), MacOS (`x64`), Linux (`x64`) | | |
| 16.x | :heavy_check_mark: | :heavy_check_mark: | Windows (`x64`), MacOS (`x64`), Linux (`x64`) | `latest` (`linux/amd64`) | `snapshot` (`linux/amd64`) |
| 15.x | (:heavy_check_mark:) | :x: | | | |
| 14.x | :heavy_check_mark: | :heavy_check_mark: | Windows (`x64`), MacOS (`x64`), Linux (`x64`) | `latest-arm` (`linux/arm/v7`, `linux/arm64`) | `snapshot-arm` (`linux/arm/v7`, `linux/arm64`) |
| 13.x | (:heavy_check_mark:) | :x: | | | |
| 12.x | :heavy_check_mark: | :heavy_check_mark: | Windows (`x64`), MacOS (`x64`), Linux (`x64`) | | |
| <12.x | :x: | :x: | |

Quelle: https://github.com/juice-shop/juice-shop

Wenn eine Version verwendet wird, die nicht auf dem aktuellsten Stand ist und den Sicherheitspatch noch nicht bekommen hat, ist der Shop anfällig, sonst nicht.

<!-- Attackers can leverage these vulnerabilities to carry out Remote Code Execution, XSS, Applications crashes, and even more attacks on the target. Adversaries can abuse these vulnerabilities to carry out DNS-cache injection attacks in case an application implements a cache based on the library. And, these vulnerabilities can be used to tunnel all kinds of injection payloads. -->

Nehmen wir nun die Version 12.20.0, die bei der DNS-Anfrage den Input nicht gut genug bereinigt, können wir die Schwachstelle nachstellen und einen Angriff simulieren, wie es in dieser Anleitung gezeigt wird: https://hackerone.com/reports/1178337.

Diese Anleitung zeigt, wie man die Schwachstelle der alten Node-Versionen ausnützen kann.
Hier wollen wir aber nicht weiter auf das eingehen, da die Sicherheitslücke schon geschlossen wurde und es den Rahmen dieser Aufgabe sprengen würde. Man sollte seine Software grundsätzlich aktuell halten, wenn man deren Sicherheit gewährleisten möchte. Es gibt ein paar wenige Ausnahmen (praktisch keine), bei denen man argumentieren könnte, dass Sicherheit kein grosses Thema ist. Ein Shop, wie der Juice Shop, gehört aber definitiv nicht dazu.

In anderen Versionen geht es, zumindest bei frischen Installationen, nicht mehr, da es ab 16.6.0, 14.17.4 und 12.22.4 gepatched ist und Angular CLI, welches vom Juice Shop verwendet wird, mindestens v12.20, v14.15, or v16.10 braucht. Das heisst es geht nur in den Versionen 12.20.0 bis 12.22.4 und 14.15.0 bis 14.17.4. Man könnte natürlich die verwendete Version von Angular CLI manuell verändern in den Konfigurationen und dies dann umgehen, was in der Praxis aber hoffentlich niemand, ohne es zu wollen, machen würde.

Es ist allgemein wichtig, dass man die neusten Versionen installiert oder auf diese upgraded um genau solche Sicherheitslücken zu verhindern. Im Normalfall werden bekannte Sicherheitslücken innerhalb von wenigen Tagen oder Wochen in einem neuen Patch behoben. Dies geschieht in der Regel auch bevor die Sicherheitslücken veröffentlicht werden.

### 1.3 Mitigation

Der beste und sicherste Weg um dieses CWE zu beheben ist ein Upgrade auf eine neuere Version von node.js. Dadurch ist diese Vulnerability, durch korrekte Inputvalidierung, behoben und auch anderen Vulnerabilities wird vorgebeugt. Normalerweise sollte es bei keiner Applikation ein Problem sein, wenn man ein Upgrade auf eine neuere Minor Version macht und deshalb ist dies der schnellste, sicherste und einfachste Weg. Häufig sind die Sicherheitslücken schon geschlossen bevor sie publik gemacht werden. Die Chance, dass man es also selber herausfindet, bevor es gepatched worden ist, ist sehr gering.

Vor dem Sicherheitspatch konnte man hier spezifisch den img-Tag für XSS und Injections ausnützen weil der Response der DNS-Library ungefiltert ist. Wie man hier in diesem Codebeispiel aus dem Report (https://hackerone.com/reports/1178337) erkennen kann:

$ node main.js cnamexss.test.xdi-attack.net

node     resolveCname     cnamexss.test.xdi-attack.net  - -  IN    CNAME <img/src=''/onerror='alert&#x28&#x22xss&#x22&#x29'>.a.cnamexss.test.xdi-attack.net

Selber lösen könnte man dieses Problem, indem man den Output der DNS-Library validated bevor man ihn irgendwo verwendet. Somit ist es nicht mehr möglich bösartige Scripte oder sonstigen Code dadurch auszuführen.

<!-- To mitigate this vulnerability, do not use DNS:: based iRulesLX commands for any custom written iApps. F5 does not use DNS:: based iRulesLX commands in the default, standard, and recommended published iApps. However, an administrator may choose to create a custom iRulesLX rule that uses DNS:: based commands.
https://support.f5.com/csp/article/K53225395 -->

## Aufgabe 2
### 2.1 Injection Angriff auf den JuiceShop

Hier setzen wir den OWASP JuiceShop als lokalen Docker Container auf:

1. Zuerst pullen wir die Docker Instance für den Juice Shop.

docker pull bkimminich/juice-shop:v8.7.3

2. Danach starten wir den JuiceShop als Docker Instanz, die auf den Port 3000 hört.

docker run --rm -p 3000:3000 bkimminich/juice-shop:v8.7.3

Sobald der Docker Container läuft kann man darauf über [localhost:3000]() zugreifen.

Die Login-Felder des OWASP Juice Shops sind anfällig für SQL-Injektion, was unbefugten Zugriff auf das System ermöglicht.

Wir wollen SQL in das Login-Feld injizieren, um das Login zu umgehen und uns als erster Benutzer in der Datenbank anzumelden. Dies ist in der Regel der Admin Benutzer und der OWASP Juice Shop ist hier keine Ausnahme.

Zuerst erzeugen wir einen Fehler, indem wir `'` als Eingabe in das E-Mail-Feld und einen beliebigen String in das Passwortfeld eingeben wie z.B. `abc123`.

Danach kann man die Response im Browser im Network-Debugging sehen. Hier sucht man die, bei der Anmeldung verwendete SQL-Abfrage, welche eine der untersten sein sollte. Im untenstehenden Bild ist die SQL Anfrage, die wir abändern werden blau markiert.


SQL Anfrage:

SELECT * FROM Users WHERE email = ''' AND password = 'e99a18c428cb38d5f260853678922e03' AND deletedAt IS NULL

> Das Passwort könnte auch durch eine Bruteforce-Attacke herausgefunden werden, da wir den Hash besitzen. Dies ist aber hier nicht die Aufgabe und wir deshalb nicht weiter erläutert.

Jetzt wissen wir, wie die SQL Anfrage aussieht, die wir abändern müssen. Wir ersetzen hierbei den Teil `WHERE email = '''` mit `WHERE email = '' OR TRUE -- ` indem wir im Inputfeld für den Usernamen `' OR TRUE --` eingeben. Das Passwort kann wieder ein beliebiger String sein.

Die SQL Anfrage sieht dann im Hintergrund in etwa so aus:

SELECT * FROM Users WHERE email = '' OR TRUE -- AND password = 'e99a18c428cb38d5f260853678922e03' AND deletedAt IS NULL

Wenn die Attacke funktioniert ist man als Admin User eingeloggt und bekommt eine Meldung, dass man erfolgreich eine Challenge gelöst hat:


Der User mit welchem man eingeloggt ist ist `[e-mail]`


Danach kann man sehr viel Schaden anrichten, da man der Admin des Webshops ist. Man kann das Passwort ändern, viele Daten einsehen, das eigene Profil anpassen etc.


### 2.2 CWE Referenz
Hier handelt es sich um CWE-89 "Improper Neutralization of Special Elements used in an SQL Command", welche zur CWE Kategorie "Data Neutralization Issues" gehört.
CWE-89 ist ebenfalls eine Subklasse von CWE-943: "Improper Neutralization of Special Elements in Data Query Logic".

Diese Klasse der Vulnerabilities beschreibt das Generieren von SQL Queries in, nicht dafür gedachte, User Input Felder.
Im Inputfeld verändert man die Query-Logik so, dass man Security Checks umgehen, zusätzliche Abfragen machen oder System Commands ausführen kann.

Diese Schwachstelle ist für Angreifer sehr lukrativ, da solche Schwachstellen auf Datenbank-basierten Webseiten einfach gefunden und ausgenutzt werden können. Somit ist die Integrität von sensiblen Daten schnell verletzt.

Quelle: https://cwe.mitre.org/data/definitions/89.html

### 2.3 Mitigation

Eine sehr einfache und rudimentäre Funktion um diese Injection zu beheben:

function sanitize(string) {
    const map = {
        '&': '&',
        '<': '&lt;',
        '>': '&gt;',
        '"': '&quot;',
        "'": '&#x27;',
        "/": '&#x2F;',
    };
    const reg = /[&<>"'/]/ig;
    return string.replace(reg, (match)=>(map[match]));
}

Hiermit bereinigt man den User-Input, indem man Sonderzeichen als HTML-Codes umschreibt und somit deren Funkionalität für Injections raubt.

Danach muss im File `routes/login.ts` des OWASP Juice Shops noch folgende Zeile ersetzt werden:

models.sequelize.query(`SELECT * FROM Users WHERE email = '${req.body.email || ''}' AND password = '${security.hash(req.body.password || '')}' AND deletedAt IS NULL`, { model: models.User, plain: true }) // vuln-code-snippet vuln-line loginAdminChallenge loginBenderChallenge loginJimChallenge

ersetzen durch:

models.sequelize.query(`SELECT * FROM Users WHERE email = '${sanitize(req.body.email) || ''}' AND password = '${security.hash(req.body.password || '')}' AND deletedAt IS NULL`, { model: models.User, plain: true }) // vuln-code-snippet vuln-line loginAdminChallenge loginBenderChallenge loginJimChallenge

Es wird jetzt hier das Inputfield des Usernamens bereinigt durch die oben erstellte Funktion. Diese Lösung ist aber auch eher unschön und dient nur der Illustration. Man sollte eigentlich eine Library verwenden, welche die Sanitization für einen übernimmt. Somit würden mehr (Edge) Cases gedeckt werden und diese sind generell besser getestet und von Entwicklern geschrieben, die viel Zeit investiert haben.

Ein Test zeigt, dass unsere einfache Sanitize Funktion funktioniert. Die Response im Network-Debugger des Browsers zeigt jetzt an, dass das Passwort falsch ist weil die Zeichen sanitized worden sind und man wird nicht mehr eingeloggt: