Blog
Aus dem Leben eines Pentesters: Ein altes Haus heißt alle willkommen
Der weiße Hut ist übrigens das Erkennungszeichen all derer, die Software im Dienste des Guten hacken: um Schwachstellen zu finden und sie zu schließen, bevor kriminelle Hacker, die so genannten Black Hats, diese ausnutzen können.
Als Pentester hat man ja schon einiges erlebt. Überraschendes, Amüsantes, auch Gefährliches. Der Klassiker: Wir betreten die zu testende Software wie ein altehrwürdiges Gemäuer, etwas in die Jahre gekommen zwar, aber noch immer solide und funktionstüchtig.
Denkste. Denn schnell müssen wir feststellen: Auch wenn die Bausubstanz noch gut in Schuss scheint – jemand hat wohl Türen und Fenster offen gelassen. Es zieht.
So auch bei einem meiner letzten Aufträge: eine auf den ersten Blick stabile Vermarktungsplattform, die tatsächlich „handgemacht“ war. Also keine Stangenware, sondern eine Anwendung, die seit über 20 Jahren durch viele Hände gegangen, weiterentwickelt, vergrößert und renoviert worden war.
Wenn jeder Zimmermann und jede Maurerin im Codegebäude indes eine eigene Handschrift hinterlässt, merkt man dem Code das irgendwann an. Wenn zudem noch die Zeit oder das Budget fehlen, technische Schulden zu begleichen, wird aus der schönsten Prachtvilla irgendwann eine Rumpelkammer. Wenn wir Pech haben, mit undichten Fenstern.
Schwachstellen finden, bevor es andere tun
Mein Auftrag: Die Anwendung nicht nur auf Sicherheit zu prüfen, sondern, wie bei professionellen Pentester:innen üblich, Lösungen vorzuschlagen.
Im konkreten Fall war die Plattform schon mehrfach getestet worden. Aber wie das so ist: Cyberkriminelle schlafen nicht, sie hoffen vielmehr darauf, dass wir es tun. Während sie in aller Seelenruhe fortlaufend neue Angriffsmuster ersinnen. Gerade eine historisch gewachsene Anwendung wie diese sollte darum regelmäßig auf ihre Bausubstanz geprüft werden.
„Hereinspaziert!“
Und die Sollbruchstelle war schnell entdeckt. Durch einen Serverfehler konnten potenzielle Angreifer völlig ohne Anmeldung direkt auf die gesamten Administrationsseiten zugreifen.
Nicht einmal ein Schlüssel aka Zugangsdaten waren nötig. Vielmehr war es so, dass das Backend Tag der offenen Tür zu feiern schien. Als Pentester konnte ich nach Belieben Funktionen ausprobieren: Angebote einsehen und verändern, Gebote manipulieren, Statistiken abrufen, Im- und Exporte durchführen – ganz so, als wäre ich dort König und Kaiser zugleich.
Zwei Dinge waren hier regelrechte Einfallstore für Unbefugte:
Broken Access Control
Erstens die Broken Access Control: Die berüchtigte Klassikerin, die zu Recht auf der Liste der OWASP Top 10 ganz oben steht, hat mich geradezu hereingebeten, um meine Kompetenzen im Backend schamlos zu missbrauchen. Sie setzt nämlich das Rollen-Rechte-System einer Plattform außer Kraft und ermöglicht es, Aktionen auszuführen, die weit über die Rechte der zugewiesenen Rolle hinausgehen.
Das sind ihre Spielarten:
- Sie hebelt das Prinzip der geringsten Berechtigung aus:
Jeder und jede hat plötzlich Zugriff auf alles. Die Plattform wird zum Selbstbedienungsladen. - Sie umgeht die Zugriffskontrolle:
Angreifende können die URL, diverse Parameter oder die App manipulieren, um Zugang zu erhalten. Sie nutzen dazu spezielle Tools und verändern API-Anfragen. - Sie legt fremde Konten offen:
Es wird zum Kinderspiel, fremde Konten einzusehen und zu verändern, wenn man zum Beispiel deren ID kennt. - Sie ermöglicht unbefugte API-Zugriffe:
Ohne Zugangskontrollen können unbefugte Personen API-Funktionen wie POST, PUT oder DELETE ausführen.
- Sie weitet Rechte aus:
Angreifende können sich als Nutzende oder sogar als Administrator:innen ausgeben, ganz ohne Berechtigung oder Anmeldung. - Sie erlaubt die Manipulation von Zugangsdaten:
Angreifende ändern Tokens, Cookies oder versteckte Felder, um ihre Rechte eigenmächtig zu erweitern oder Sicherheitsmechanismen zu umgehen. - Sie nutzt fehlerhafte CORS-Einstellungen:
Wenn die CORS-Konfiguration falsch ist, können Fremde von nicht erlaubten Webseiten auf die API zugreifen.
Cross Site Scripting
Zweitens das Cross Site Scripting (XSS): In eine Funktion, die das Bearbeiten der Startseite erlaubte, hätte ich nur ein paar Zeilen Javascript einfügen müssen, schon wäre bei jedem Aufruf der Seite auf dem zugreifenden Rechner mein Schadcode ausgeführt worden. Ein solcher Schadcode kann sehr viel Unheil anrichten – bis hin zu Datenklau und Angriffen auf einzelne User oder das ganze Unternehmen.
Wo ein Pentester, da ein Lösungsweg
Um diese sicherheitslücken zu schließen und künftiges Unheil vom Unternehmen anzuwenden, war unser Rat an den Betreiber der Plattform sonnenklar:
- Zugriffsrechte sauber trennen und niemals ohne Authentifizierung sensible Bereiche erreichbar machen,
- Härtung der Serverkonfiguration zur Vermeidung von Fehlkonfigurationen,
- in regelmäßigen Abständen und auf jeden Fall nach größeren Umbauten einen weiteren Pentest einplanen, egal ob Backendfunktion oder Infrastruktur.
Fazit
Nur weil einmal ein Pentest gemacht wurde, heißt das nicht, dass eine historisch gewachsene Plattform dauerhaft sicher ist. Alte Anwendungen sind wie alte Häuser: Gerade, wenn man daran herumbastelt, sollte man regelmäßig checken, ob noch alles fest sitzt – sonst hat man irgendwann ungebetene Gäste im Haus oder gar Mitbewohner, die nicht nur keine Miete zahlen, sondern das alte Haus regelrecht ausplündern.
