„Wenn man eine Schwachstelle findet, dann soll man diese ausnutzen, um den Beweis anzutreten, was mit der Schwachstelle alles möglich sein kann“
So oder so ähnlich formulieren es manche Pentester:innen. Dieser Artikel soll beleuchten, warum nicht jede bei einem Penetrationstest gefundene technische Schwachstelle (vollständig/in Tiefe) ausgenutzt werden sollte und verdeutlichen, wie wir beim Auffinden von Schwachstellen vorgehen.
Ein Pentest hat aber das Ziel Schwachstellen aufzudecken und nur dann auszunutzen, wenn das Ausnutzen einen echten Mehrwert liefert.
Schrödingers Schwachstelle
Schwachstellen stellen generell ein Risiko dar – ganz gleich ob bei IT-Systemen, IT-Anwendungen oder anderen Dingen. Und um den Beweis anzutreten, dass eine Schwachstelle in einem IT-System real existiert, müssen manchmal Schwachstellen tatsächlich ausgenutzt werden. Sonst ist es wie mit Schrödingers Katze: eine Schwachstelle existiert entweder oder eben nicht. 🤷♂️ (Stark vereinfacht!)
Wie soll man da nun den Beweis einer Schwäche antreten bzw. die Verifikation einer Schwachstellenmeldung vornehmen?
Nützt nix. Ausnutzen. Was aber, wenn durch das Ausnutzen von Schwachstellen im Rahmen von Penetrationstests überhaupt erst ein Risiko des geprüften Gegenstandes (oder vor- bzw. nachgelagerter IT-Systeme oder Komponenten) entsteht? Oder das beim Ausnutzen entstehende (Betriebs-)Risiko größer ist, als das gesamte Risiko der eigentlichen Schwachstelle?
Kenne deinen Exploit
Um manche bekannte Schwächen auszunutzen, bedient sich ein Penetrationstester ganz gerne öffentlich bekannter Exploit-Scripts oder Proof of Concepts (PoCs). Diese sollte man jedoch eigentlich nur ausführen, wenn bekannt ist, was dabei alles angestellt/ausgeführt wird. Wie wichtig das ist, haben wir bereits in einem anderen Blogbeitrag einmal dargelegt.
Kenne deinen Prüfgegenstand
Pentester:innen sollten jedoch neben dem Exploit auch das Ziel zumindest ansatzweise verstehen, um Risiken abschätzen – oder besser – abwägen zu können. Das gelingt mal mehr, mal weniger. Doch wozu?
Rien ne vas plus!
Abhängig von Begleitumständen beim Ausnutzen einer Schwachstelle kann dabei der geprüfte Gegenstand oder dessen vor- bzw. nachgelagerte(n) Komponente(n) der Gefahr ausgesetzt werden, in einen „geht-nicht-mehr“-Zustand (Denial of Service) überzugehen. Das ist der Zustand, den keiner gebrauchen kann und der auch dem Penetrationstester sprichwörtlich den Prüfgegenstand unter dem Mauszeiger wegzieht, wenn nichts mehr geht.
Im Vorfeld von Prüfungen wird daher an den Stellschrauben der Vorgehensweise bei Penetrationstests gedreht. So auch beim Kriterium der Aggressivität (nach der Studie Durchführungskonzept für Penetrationstests des BSI). Unterschieden wird zwischen
- passiv scannend,
- vorsichtig,
- abwägend oder
- aggressiv.
Passiv scannend bedingt, dass möglicherweise vorhandene Schwachstellen nicht ausgenutzt werden. Vorsichtig erlaubt nur Prüfungen, bei denen absolut ausgeschlossen werden kann, dass nach bestem Wissen eine Beeinträchtigung ausgeschlossen werden kann – aber wer kann das schon? Beim abwägenden Vorgehen wird bei wahrscheinlichem Erfolg ausgenutzt, auch wenn es zu Beeinträchtigungen führen könnte. Das toppt nur noch „aggressiv“ – hier wird keine Rücksicht auf Verluste genommen und nicht auf mögliche Ausfälle geachtet.
Atlantis is calling…
Was wir bis hierher gelernt haben: Ausnutzen kann zu Problemen führen, muss aber ein Stück weit gemacht werden, um die Existenz einer Schwäche möglichst zweifelsfrei nachzuweisen.
„Was wäre das Leben, hätten wir nicht den Mut, etwas zu riskieren?“ (Vincent van Gogh).
Doch bis wohin zählt das Ausnutzen einer Schwäche noch zur Verifikation der Schwachstelle und ab wann beginnt das Erforschen neuer Abgründe Schwächen? Und welchen Mehrwert bietet das Ausnutzen für den Kunden?
Ein Beispiel, wo Exploiting sinnhaft sein kann:
Eine SQL-Injection-Schwachstelle in einer Webanwendung. Kenner wissen: Zugriff auf das Datenbank-Managementsystem über die Webanwendung, das kann weh tun und unter Umständen den Super-GAU bedeuten. Es gibt aber sehr viele Ausprägungen (Fehlerbasiert, Zeitbasiert, beides, …. und viele Untergruppen) der Schwachstelle. Um zu verifizieren, ob die Schwäche existiert und um abschätzen zu können, welches Risiko von dieser Schwachstelle ausgeht, sollte man sie ausnutzen. Man sollte prüfen, ob das Managementsystem verrät, welche Berechtigung(en) man gerade hat. Denn um das Risiko zu bewerten, sollte man die Auswirkungen eines erfolgreichen Angriffs auf die Schutzziele der Daten in Erfahrung bringen. Ob man z. B. nur lesenden Zugriff auf alle Daten (und nicht nur die der Anwendung) hat wiegt ggfs. weniger oder gleich schwer im Vergleich zu lesendem und schreibendem Zugriff (weil hier neben der Vertraulichkeit auch die Integrität betroffen ist) auf die Daten der betroffenen Anwendung (und nur auf diese). Wenn also durch das Ausnutzen der Schwachstelle nur Daten aus der Datenbank ausgelesen werden können, ist das weniger kritisch, als wenn Daten sowohl gelesen, als auch geändert oder gar gelöscht werden können.
Übersetzt mit technischen Begriffen bedeutet das, ich sollte feststellen, ob ich wirklich (und mit welchem) DBMS gesprochen wird, welche Berechtigungen der verwendete Datenbankzugang besitzt (ob man gar DB-Administratorrechte besitzt) und in welchem Umfang auf Daten zugegriffen werden könnte. Weiter / tiefer sollte man nicht aus unserer Sicht beim Ausnutzen nicht gehen. Schließlich liegt der Prüffokus ja meist auf dem Prüfgegenstand und darauf, welche Gefahren von ihm ausgehen und nicht, welche Gefahr dieser für andere Systeme darstellt. Das ließe sich mit anderen Methoden mit weniger Aufwand feststellen.
Es ist nur eine Nummer!
Ein Gegenbeispiel, warum Exploiting nicht viel an Mehrwert bringen kann:
Bei Prüfungen von Systemen bzw. Adressen über die Netzwerkschnittstelle werden mitunter Dienste angetroffen, die sich mit einer Versionsnummer zu erkennen geben oder anhand bei denen sich durch das Antwortverhalten mittels Fingerprinting der Dienst und die im Einsatz befindliche Version ableiten lassen. Mit dieser Information sucht entweder ein Schwachstellenscanner in seiner Datenbank nach bekannten Schwachstellen oder der Penetrationstester sucht selbst danach (denn nicht jede bekannte Schwäche besitzt ein Plugin zur Prüfung durch den Scanner). Soweit, so gut.
Mit Versionsnummern haben Pentester aber so ihre Schwierigkeit. Belastbar oder besser gesagt „sicher“ sind diese Angaben meist nicht. Was, wenn der Admin die Versionsangaben (ver)fälscht, indem z. B. bei einem Apache Webserver mit aktiviertem mod_security vorgegaukelt wird, es sei ein veralteter IIS? Oder das Problem, dass sich bei manchen vom Distributor des Betriebssystems installierten Paketen die Versionsnummer nicht ändert, obwohl die mit einer neuen Version veröffentlichten Schwachstellenbehebungen installiert wurden (Backporting).
Wird in den beiden genannten Fällen versucht eine oder alle für eine Versionsnummer bekannte Schwachstelle(n) auszunutzen, kostet dies wertvolle Zeit, aber die Erfolgsaussichten sind verschwindend gering. Mehrwert bietet es also auch nicht wirklich.
Pentests sind keine realen Angriffe
Im Gegensatz zu realen Angreifern können Penetrationstester mit Ihren Mitarbeitenden reden? Wenn ein Gespräch effizienter ist, als Exploiting, dann reden wir. So ist es oft sinnvoller eine Analyse gemeinsam mit verantwortlichem Personal des Kunden im Gespräch vorzunehmen. Das ist weniger zeitaufwändig, als das Erforschen von Folgen durch das Ausnutzen aus Pentester-Sicht oder ein Restore einer oder gleich mehrerer Komponenten durch den Kunden nach einem misslungenen Exploiting-Versuch. Noch dazu ist das Ergebnis eindeutiger. Nur weil der Exploit nicht funktionierte, heißt es nicht, dass die Schwachstelle nicht existiert.
Man kann sich nach dem erbrachten Beweis wieder seinem Prüfplan zuwenden und nach weiteren Schwachstellen des eigentlich im Prüffokus stehenden Gegenstands zuwenden und läuft nicht Gefahr, am Ende des Testzeit- und Aufwandsrahmens noch offene Prüfungen übrig zu haben.