03.11.2020 | Sebastian Schwegler | comment icon 1 Comment

Warum selbst das beste Tool einen echten Penetrationstest nicht ersetzen kann

Beim Durchführen von Penetrationstests erlebt man immer wieder Überraschungen und findet Fehler, die man sich in seinen kühnsten Träumen nicht vorstellen kann. So auch bei einem eigentlich ganz normalen Penetrationstest für einen Kunden.

Zu testen war eine digitale Plattform, die einen Produktpreis sowie einen Rabattfaktor mit vertretungsberechtigten Personen verknüpft, sodass diese Personen dann mit den verknüpften Daten ein Geschäft abschließen können. Dem Auftragnehmer wird durch die verifizierte Identität des Käufers die Möglichkeit geboten, seine Zahlungsbedingungen mittels des Rabattfaktors anzupassen.

Wir starteten also mit dem Test und verschafften uns zunächst einen Überblick über offene Ports und eventuell auffindbare Verzeichnisse, aber hier war alles in Ordnung. Anschließend versuchten wir, über eigentlich nicht zulässige HTTP-Methoden auf URLs eigene Daten ins System zu bringen – auch das schlug fehl.

Also nahmen wir die Aufrufe beim Verifizieren der Daten gegenüber dem Shop-Betreiber genauer unter die Lupe. Der prinzipielle Ablauf gestaltet sich wie folgt:

Die Einbindung der Kunden-API erfolgt über ein Javascript-SDK. Dort wird ein Objekt erzeugt, welches einen Eventhandler für den Abschluss des Vorgangs im “Kunden UI” besitzt, sodass die API den Shop-Betreiber benachrichtigt, wenn die Informationen freigegeben werden oder nicht.

Um die Anwendung sicher zu machen, setzt das Entwicklungsteam auf JWT, sodass die Daten jeder Anfrage signiert werden können. Das sah konkret dann so aus:

Man sieht, dass ein JWT mitgesendet wird, welches dieselben Daten aus den Parametern price und discount in signierter Form enthält. Dementsprechend beschränkt waren die Angriffsmöglichkeiten, da die JWT selbst korrekt implementiert waren. Uns fielen sofort die Variablen price und discount ins Auge, sodass wir diese Anfrage mit unserem HTTP-Proxy unterbrochen und manipuliert haben. Mit erschreckendem Ergebnis: Der Server akzeptierte die Anfrage und wir erhielten als Antwort ein JSON-Objekt mit dem Status “VALID”. So könnte ein Kunde die Preise der Produkte, die er bestellen möchte, zu seinen Gunsten manipulieren.

Also mussten wir das Javascript-SDK überprüfen, ob dieses die Manipulation tatsächlich so an den Shopbetreiber weitergeben würde. Nach ein wenig Suche und Debugging im Browser haben wir die betreffende Codestelle gefunden. Mit Entsetzen nahmen wir folgendes zur Kenntnis:

Nachdem der Server unsere Manipulation bereits akzeptiert hatte, erklärt nun auch das Javascript-SDK diese Manipulation für gültig.

Beim Kunden herrschte natürlich blankes Entsetzen – wie konnte das passieren? Man setze doch bereits diverse Tools für Security und Codequalität in Sonar ein. Es stellte sich heraus, dass die falsche Funktion aufgerufen wurde.

Dieses Beispiel zeigt wunderbar, warum selbst das beste Tool keinen echten Penetrationstest ersetzen kann: Ein Tool kann eben nicht herausfinden, ob der Softwareentwickler die semantisch korrekte Funktion aufgerufen hat.

Ohne unseren Penetrationstest wäre diese Sicherheitslücke, mit der sich die gesamte Funktionalität der Anwendung umgehen ließe, wahrscheinlich in Produktion gegangen.

application security penetrationstest pentesting
  1. Bernhard
    Posted on
    Sehr schönes Beispiel! Ja, sowas findet man immer wieder. Deshalb sind Pentests soo wichtig.

Leave a Comment