Hacking III: Webanwendungsangriffe

Eine Benutzerauthentifikation via Passwort finden wir oft in Webanwendungen wieder. Hierbei können den einzelnen Benutzern verschiedene Rollen zugewiesen sein. Zum Beispiel betreibt die Dubius Payment Ltd. als Zahlungsanbieter ein Payment-Gateway, bei dem sog. Merchants Kreditkartentransaktionen tätigen können. Die Merchants werden von einem Administrator angelegt. Abhängig von der Rolle „unseres“ Benutzers, dessen Passwort wir uns angeeignet haben, und seinen Berechtigungen stehen uns somit unterschiedliche Funktionalitäten einer Anwendung zur Verfügung. Grundsätzlich fällt jeder Kommunikationsweg mit einem Dienst bzw. einer Anwendung in unseren Scope (Angriffsfläche). Im Kontext von Webanwendungen umfasst dies folgende Schnittstellen:

• User-Interface (UI) – Formulare und Felder
• HTTP-Headers und Cookies
• (angebundenes) Application-Programming-Interface (API)

Beim User-Interface (UI) können die Benutzereingaben clientseitig eingeschränkt sein. Das Gültigkeitsdatum einer Kreditkarte könnte über eine Auswahlliste von HTML limitiert worden sein, oder der Name des Kreditkarteninhabers wird wahrscheinlich maximal 100 Zeichen umfassen. Im Allgemeinen können auch über JavaScript clientseitige Einschränkungen vorgenommen sein, wie die Validierung von gültigen E-Mail-Adressen. All diese Vorkehrungen können uns als Angreifer aber nicht davon abhalten, „verbotene Werte“ in diesen Feldern an die Anwendung zu übertragen. Denn über einen sog. Web Application Proxy können wir clientseitige Einschränkungen umgehen, indem wir unseren ausgehenden HTTP-Request mit dem Proxy abfangen und alle Parameter nachträglich bearbeiten. Zu diesem Zweck kann die Burp Suite eingesetzt werden (https://portswigger.net/burp). Die frei erhältliche Edition von Burp umfasst u. a. einen Proxy und einen Repeater. Um Burp als Proxy zu verwenden, müssen wir diesen zusätzlich in den Netzwerkeinstellungen unseres Browsers konfigurieren. Über den Repeater von Burp sind wir dann in der Lage, Requests zwischenzuspeichern, um diese in verschiedener Weise abzuändern und erneut zu versenden.

Dies alles hilft uns natürlich nur weiter, wenn wir eine Anwendung zum Testen identifiziert haben. In der Realität können wir aber auch rein statischen Seiten begegnen, wie der Startseite von Apache „It works“ oder der serverseitigen Antwort „403 Forbidden“ auf eine HTTP-Anfrage. Dies muss aber nicht bedeuten, dass sich auf dem Webserver keine Anwendung befindet. Bisher haben wir vielleicht nur nicht das richtige Verzeichnis lokalisiert. So könnte sich das Payment-Gateway der Dubius Payment Ltd. hinter der URL https://paygate.dubius-payment.com/transaction/ verbergen. Mit dem Tool ffuf können wir anhand Wörterlisten automatisiert nach existierenden und versteckten Verzeichnissen bzw. Dateien suchen:

ffuf -w ${Wörterliste} -X GET -u ${URL}/FUZZ

Sobald uns eine Webanwendung vorliegt, können wir verschiedene Angriffsvektoren ausprobieren, um in das IT-System einzudringen. Eine detaillierte Auflistung von möglichen Schwachstellen liefert uns der OWASP Testing Guide (https://owasp.org/www-project-web-security-testing-guide/). Im Folgenden werden wir – wegen ihrer hohen Häufigkeit – SQL-Injections und Cross-Site-Scripting-Angriffe näher betrachten.

Die interne PCI-DSS-Dokumentation der Dubius Payment Ltd. kann in deren Wiki eingesehen und um TODO-Punkte ergänzt werden. Hierbei ist die eingesetzte Software anfällig für eine bekannte Webanwendungsschwachstelle. Ein Hacker wird diese finden und ausnutzen, um eine Befehlsausführung auf dem IT-System zu erlangen. Ein Pentester hingegen wird mindestens drei weitere Schwachstellen in der Webanwendung identifizieren. Bist du nur ein bösartiger Hacker oder ein professioneller Penetration-Tester? ;)