tl;dr: Brute-Force Angriffe im Rahmen eines Penetrationstests bieten so gut wie keinen Mehrwert und stellen in fast allen Fällen eine falsche Verwendung der Prüfungsressourcen dar. Zielführender ist es stattdessen, gezielt den Schutz der Anwendung vor dieser Angriffsart zu untersuchen und zu prüfen.
Um was geht es?
Moderne Angreifer:innen benutzen eine Vielzahl an Angriffstechniken, die eine große Bandbreite von technisch ausgefeilt bis hin zu „auch von Laien ausführbar“ abdecken. Eine der Angriffsarten, die vermutlich jedem geläufig sind und in die letzte Kategorie fallen, werden „Brute-Force“-Angriffe genannt. Auch wenn der Name zuerst die Anwendung von roher Gewalt suggeriert, geht es doch um etwas viel simpleres: Das sture Ausprobieren aller Möglichkeiten, bis man die Richtige gefunden hat.
Das typische Beispiel hierfür ist der Login über einen Benutzernamen mit einem Passwort. Theoretisch besteht immer die Möglichkeit, alle denkbaren Passwörter auszuprobieren, bis das Richtige gefunden wurde. Eine stumpfe, aber dennoch effektive Angriffsart, die tagtäglich eingesetzt wird.
Als Anbieter:in einer IT-Anwendung sollte man also zwangsläufig Sicherheitsvorkehrungen gegen Brute-Force Angriffe treffen. Entsprechend stellt sich die Frage: Sollte diese Angriffstechnik auch Bestandteil eines Penetrationstests sein? Schließlich sollen mit Penetrationstests ja Schwachstellen und Angriffsmöglichkeiten aufgedeckt werden.
Die Antwort hierauf ist weder „Ja“, noch „Nein“, sondern das klassische „Kommt darauf an, was man daraus macht“.
Bleiben wir erstmal beim Passwort-Beispiel. Welche Ansätze könnte man hier, aus Sicht eines Penetrationstests, mit Brute-Force Angriffen verfolgen?
Ansatz 1: „Das Passwort knacken“
Zu versuchen, das Passwort eines bestimmten Benutzerkontos zu berechnen, mag auf den ersten Blick wie ein zentraler Bestandteil eines Penetrationstests erscheinen. Dies ist aber ein Trugschluss und stellt in den meisten Fällen eine Zeitverschwendung dar.
Angreifer:innen können aus dem Passwort natürlich einen „Gewinn“ für sich ziehen. Schließlich hätten sie nun Zugriff auf ein Benutzerkonto, welches für weitere Angriffe, Erpressungen oder andere schädliche Aktivitäten genutzt werden könnte.
Penetrationstester:innen geht es aber (üblicherweise) nicht darum, Zugriff auf ein Konto zu erlangen, sondern Schwachstellen aufzudecken – und hier haben sie wenig Nutzen vom berechneten Passwort. Denn entweder hatten sie sowieso schon Zugriff auf speziell für die Prüfung angelegte Testkonten und deren Passwörter oder sie haben gar nicht die nötige Freigabe, um den Anwendungsbereich zu prüfen, der nach dem Login liegt. In beiden Fällen hat die Durchführung des Brute-Force-Angriffs nur unnötig Ressourcen und die knappe Prüfungszeit beansprucht.
Auch aus Kunden:innensicht ist wenig gewonnen: Findet man das Passwort nicht, dann bedeutet dies nicht automatisch, dass die Anwendung sicher gegenüber dieser Angriffsart ist. Es gibt viele Gründe für den Misserfolg: Es stand nicht genug Testzeit zur Verfügung, um tatsächlich alle möglichen Passwörter durchzuprobieren (Hint: bei einer guten Passwortrichtlinie wird dies zwangsläufig der Fall sein), dass Passwort war zufällig nicht auf der Liste der ausprobierten Passwörter oder der Angriff wurde im Test zu früh beendet, weil man sich anderen (sinnvolleren) Prüfungsschritten zuwendete.
Wurde das Passwort gefunden, lässt sich hieraus ebenfalls keine Sicherheitsaussage ableiten. Dieses eine Passwort sollte dann als schlecht eingestuft und muss geändert werden (da es jetzt nicht mehr geheim ist), aber abseits davon gibt es keinen Wissensgewinn. Insbesondere nicht über die Sicherheit anderer Passwörter oder der Anwendung an sich.
Dies stellt ein inhärentes Problem von Brute-Force-Angriffen dar: Ihre Aussagekraft ist stark begrenzt. Aus einem gescheiterten Brute-Force-Angriff kann niemals eine Aussage über das allgemeine Sicherheitsniveau abgeleitet werden. Welchen Ansatz sollte man stattdessen verfolgen?
Ansatz 2: Brute-Force Schutz systematisch testen
Anders verhält es sich, wenn man systematisch den Schutz vor Brute-Force Angriffen testet. Das Ziel ist jetzt also nicht mehr das Auffinden eines konkreten Passworts, sondern die Untersuchung der allgemeinen Schutzmaßnahmen. Dieser Ansatz lässt sich nicht nur wesentlich effizienter verfolgen, sondern sorgt auch für bessere Aussagen über das Sicherheitsniveau.
Es ist beispielsweise ratsam, einen Login nach einer gewissen Anzahl an falschen Login-Versuchen zu sperren, etwa für eine feste Zeitspanne. Dies kann in einem Penetrationstest sehr schnell überprüft werden, indem einige wenige, bewusst falsche Login-Versuche probiert werden, etwa 100 Stück. Dies kommt einem sehr kurzen und fokussierten Brute-Force Angriff gleich, es ist aber nicht nötig, riesige Passwortlisten mit Millionen Passwörtern komplett durchzuprobieren. Wird hier nicht bereits eine Sperre oder ein anderer Schutzmechanismus aktiv, so ist die Anwendung nicht ausreichend gegen Brute-Force Angriffe geschützt und es wurde eine Schwachstelle identifiziert. Liegen andererseits entsprechende Schutzmechanismen vor, so können diese analysiert werden, um ein tiefergehendes Urteil über sie fällen zu können.
Die Stärke der vorhandenen Passwörter lässt sich ebenfalls anderweitig besser prüfen: es sollte untersucht werden, ob eine Passwortrichtlinie vorliegt. Wenn ja, sollte überprüft werden, ob diese für den Schutzbedarf der Anwendung geeignet ist und ob sie auch tatsächlich technisch sicher umgesetzt ist. Liegt keine, eine zu schwache oder eine technisch nicht ausreichend umgesetzte Passwortrichtlinie vor, wurde erneut eine eindeutige Schwachstelle identifiziert, deren Behebung das Sicherheitsniveau der Anwendung steigern kann.
Des Weiteren haben Penetrationstester:innen Möglichkeiten, die Angreifer:innen nicht zur Verfügung stehen. Allen voran: Kommunikation. Penetrationstester:innen können direkt mit ihren Auftraggeber:innen über das Angriffsziel sprechen.
Das mag erstmal banal klingen, aber bereits Antworten auf einfache Fragen wie „Unter welcher Adresse erreicht man das Administrations-Portal, welche Passwortrichtlinie wird für den Admin-Zugang umgesetzt und welche Schutzmechanismen liegen dabei vor?“ erlauben eine tiefere Aussage über die Sicherheit des Zugangs, als mit Herumprobieren möglich wäre. Angreifer:innen haben hier normalerweise keine Wahl und müssen im Dunkeln stochern – aus der Penetrationstestperspektive lässt sich dieser Prozess deutlich verkürzen, häufig genügt ein kurzes Telefonat oder eine einfache E-Mail. Das schont den Geldbeutel von Auftraggeber:innen und sorgt für bessere Ergebnisse.
Diese Art der Kommunikation ist nicht nur vorteilhaft, sondern für den Penetrationstest auch unerlässlich. Angenommen, die Anwendung setzt eine langfristige Zeitsperre bei zu vielen falschen Login-Versuchen um. Dann könnte es passieren, dass sich Penetrationstester:innen selbst „aussperren“. Bei SSH gibt es beispielsweise Standardpakete, die Sperren von vier Wochen umsetzen. Solche Probleme im Prüfungsablauf können durch eine klare Kommunikation und gute Planung bewusst vermieden werden, bevor sie auftreten.
Passwörter sind natürlich nicht die einzigen Daten, die mit Brute-Force Angriffen berechnet werden können. Weitere potentielle Anwendungsmöglichkeiten für dieses Angriffsart sind beispielsweise:
- Das Aufspüren von versteckten Verzeichnissen auf Servern.
- Berechnung von kryptographischen Schlüsseln, etwa für Zertifikate, die verschlüsselte Kommunikation oder zur Berechnung von JSON Web Tokens.
- Berechnung von Dateipfaden, z.B. falls eine Upload-Funktion angeboten wird und die Dateien scheinbar zufällige Dateinamen erhalten. Hier könnte über das „Erraten“ von anderen Dateinamen probiert werden, Zugriff auf fremde Daten zu erlangen.
- Das Aufdecken von geheimen Eingabeparametern.
- Usw. usf.
Bei all diesen Beispiele ist die Situation aber identisch zum Passwort-Szenario. Durch eine klare Kommunikation und ein analytisches Herangehen kann eine deutlich höhere Testtiefe und eine bessere Aussage über das Sicherheitsniveau erreicht werden.
Wenn es Serververzeichnisse gibt, die für den Penetrationstest relevant sind, dann sollten diese benannt oder anderweitig klar erkennbar sein. Gibt es geheime Eingabeparameter, so sollten diese ebenfalls benannt werden. Sonst besteht die Gefahr, dass sie im kurzen Zeitrahmen eines Penetrationstests übersehen werden. Ob der Zugriff auf fremde Daten möglich ist, lässt sich leichter und effizienter überprüfen, wenn Tester:innen Zugangsdaten von mehreren Testkonten erhalten und entsprechend selbst Daten anlegen können. So können Dateinamen bzw. -pfade selbst in Erfahrung gebracht und versucht werden, vom einem anderen Konto darauf zuzugreifen. Ohne Raten zu müssen.
Ein häufiges Argument für Brute-Force Angriffe in einem Penetrationstest ist, dass Auftraggeber:innen selbst möglicherweise manche Daten, Verzeichnispfade oder Systeme in ihrem Netzwerk nicht (mehr) kennen. Ein durchaus legitimer Punkt – niemand ist perfekt und diese Fälle können durchaus vorkommen. Man sollte aber in Frage stellen, ob hier ein Penetrationstest „von außen“ wirklich die richtige Herangehensweise ist und ob nicht eine Netzwerkarchitektur- oder eine Source-Code-Analyse angebrachter wäre.
Ausnahmen bestätigen die Regel: Viele Anwendungen legen bei der Installation Standardzugänge an (typisch: Benutzername „admin“ mit Passwort „admin“). Wir überprüfen Login-Masken auf versehentlich aktive Standardzugänge, was einem (sehr eingeschränkten) Brute-Force Angriff gleicht. Dies machen wir allein schon deswegen, da gängige Werkzeuge die Möglichkeit bieten, diese Prüfungen automatisch durchzuführen, ohne dass ein wirklicher Mehraufwand entsteht. Aber diese und andere Brute-Force Möglichkeiten sollte man bedacht und zielgerichtet einsetzen, um zum bestmöglichen Ergebnis zu kommen.
/Dr. Björn Kaidel