Einleitung
In diesem Lab lernen Sie, wie Sie mit Situationen umgehen, in denen Gobuster TLS-Zertifikatsfehler aufweist, insbesondere bei selbstsignierten oder ungültigen Zertifikaten. Standardmäßig führt Gobuster, wie viele andere Tools auch, eine strenge TLS-Zertifikatsprüfung durch, um eine sichere Kommunikation zu gewährleisten. In bestimmten Testszenarien müssen Sie diese Überprüfung jedoch möglicherweise umgehen. Dieses Lab führt Sie durch die Identifizierung eines solchen Ziels, die Beobachtung des Standardfehlers und die anschließende Verwendung des Flags -k, um die Zertifikatsüberprüfung zu deaktivieren und den Scan fortzusetzen. Abschließend werden wir die Sicherheitsauswirkungen der Deaktivierung der TLS-Überprüfung erörtern.
Ziel mit einem selbstsignierten oder ungültigen TLS-Zertifikat identifizieren
In diesem Schritt identifizieren Sie eine Ziel-URL, die ein selbstsigniertes oder anderweitig ungültiges TLS-Zertifikat verwendet. Für dieses Lab verwenden wir eine öffentlich zugängliche Testseite, die bekanntermaßen Zertifikatsprobleme aufweist, die Gobuster kennzeichnen wird. Dies ermöglicht es uns, das Problem und seine Lösung zuverlässig zu demonstrieren.
Öffnen Sie Ihr Terminal und versuchen Sie mit curl, auf die Ziel-URL zuzugreifen. Sie sollten einen Zertifikatsfehler beobachten, der darauf hinweist, dass das Zertifikat von Ihrem System nicht als vertrauenswürdig eingestuft wird. Dies ist die Art von Szenario, bei dem Gobuster ebenfalls auf Probleme stoßen würde.
Führen Sie den folgenden Befehl aus:
curl https://self-signed.badssl.com/
Sie sollten eine Ausgabe ähnlich der folgenden sehen, die ein Zertifikatsproblem anzeigt:
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about such a situation and
how to fix it, please consult the relevant articles in the links above.
Diese Ausgabe bestätigt, dass das Ziel https://self-signed.badssl.com/ ein Zertifikat präsentiert, dem standardmäßig nicht vertraut wird, was genau das ist, was wir für dieses Lab benötigen.
Scan versuchen und Zertifikatsfehler beobachten
In diesem Schritt versuchen Sie, Gobuster gegen das identifizierte Ziel auszuführen, ohne die TLS-Zertifikatsüberprüfung zu deaktivieren. Wie erwartet wird Gobuster auf das selbstsignierte Zertifikat stoßen und mit einem Fehler beendet, ähnlich dem, was curl angezeigt hat. Dies demonstriert das Standardverhalten von Gobuster, strenge Zertifikatsvalidierung durchzusetzen.
Führen Sie den folgenden Gobuster-Befehl aus:
gobuster dir -u https://self-signed.badssl.com/ -w /usr/share/wordlists/dirb/common.txt -q
dir: Gibt an, dass wir eine Verzeichnis-/Datei-Brute-Force-Prüfung durchführen.-u https://self-signed.badssl.com/: Legt die Ziel-URL fest.-w /usr/share/wordlists/dirb/common.txt: Gibt die zu verwendende Wortliste für Brute-Force an.-q: Unterdrückt das Banner und andere nicht wesentliche Ausgaben, wodurch der Fehler deutlicher wird.
Sie sollten eine Ausgabe ähnlich der folgenden sehen, die einen TLS-Handshake-Fehler anzeigt:
[!] GoBuster is unable to connect to the target: Get "https://self-signed.badssl.com/": x509: certificate signed by unknown authority
Diese Fehlermeldung bestätigt, dass Gobuster aufgrund des nicht vertrauenswürdigen Zertifikats keine Verbindung herstellen konnte, was den Scan verhindert.
Scan mit dem Flag -k erneut ausführen
In diesem Schritt führen Sie den Gobuster-Scan erneut aus, diesmal jedoch mit dem Flag -k. Das Flag -k (kurz für --no-tls-validation) weist Gobuster an, die TLS-Zertifikatsüberprüfung zu überspringen. Dies ist nützlich in kontrollierten Umgebungen oder beim Testen gegen Ziele mit selbstsignierten Zertifikaten, bei denen Sie dem Ziel trotz der Zertifikatswarnung ausdrücklich vertrauen.
Führen Sie den folgenden Gobuster-Befehl aus und fügen Sie das Flag -k hinzu:
gobuster dir -u https://self-signed.badssl.com/ -w /usr/share/wordlists/dirb/common.txt -k -q
-k: Dies ist das entscheidende Flag, das die TLS-Zertifikatsüberprüfung deaktiviert.
Dieses Mal sollte Gobuster nicht sofort mit einem Zertifikatsfehler beendet werden. Stattdessen beginnt es mit dem Verzeichnis-Brute-Force-Prozess. Möglicherweise sehen Sie keine sofortige Ausgabe, wenn die Wortliste groß ist und keine Verzeichnisse schnell gefunden werden, aber das Fehlen des vorherigen Fehlers zeigt den Erfolg an.
Beobachten, dass der Scan nun fortfährt
In diesem Schritt bestätigen Sie, dass der Gobuster-Scan dank des Flags -k nun aktiv läuft und die Wortliste verarbeitet. Da das Flag -q verwendet wurde, um die meisten Ausgaben zu unterdrücken, sehen Sie möglicherweise nicht viel Aktivität, es sei denn, ein Verzeichnis wird gefunden. Um den Fortschritt sichtbarer zu machen, entfernen wir das Flag -q und lassen Gobuster für kurze Zeit laufen.
Führen Sie den folgenden Befehl erneut aus, diesmal jedoch ohne das Flag -q, damit Sie den Fortschritt sehen können:
gobuster dir -u https://self-signed.badssl.com/ -w /usr/share/wordlists/dirb/common.txt -k
Sie sollten nun die normale Ausgabe von Gobuster sehen, die anzeigt, dass es den Zielserver aktiv scannt. Die Ausgabe zeigt den Fortschritt und alle gefundenen Verzeichnisse oder Dateien an. Zum Beispiel:
===============================================================
Gobuster vX.X.X -- by OJ <@_odejim> & @Neohapsis
===============================================================
[+] Url: https://self-signed.badssl.com/
[+] Threads: 10
[+] Wordlist: /usr/share/wordlists/dirb/common.txt
[+] Status codes: 200,204,301,302,307,401,403,405
[+] User Agent: gobuster/X.X.X
[+] Timeout: 10s
[+] Allow redirects: false
[+] Follow new location: false
[+] No TLS validation: true
===============================================================
2023/10/27 10:30:00 Starting gobuster in directory enumeration mode
/admin (Status: 301)
/login (Status: 301)
...
Sie können Strg+C drücken, um den Scan zu stoppen, sobald Sie bestätigt haben, dass er läuft. Die wichtigste Erkenntnis ist, dass der Scan ohne den vorherigen Zertifikatsfehler erfolgreich gestartet wurde.
Die Sicherheitsimplikationen der Deaktivierung der Verifizierung verstehen
In diesem letzten Schritt besprechen wir die Sicherheitsimplikationen der Deaktivierung der TLS-Zertifikatsverifizierung. Während das Flag -k für spezifische Testszenarien nützlich ist, ist es entscheidend zu verstehen, warum es mit Vorsicht und nur bei Bedarf verwendet werden sollte.
Wenn Sie die TLS-Zertifikatsverifizierung deaktivieren, weisen Sie Gobuster (oder jedes andere Tool) im Wesentlichen an, jedes vom Server präsentierte Zertifikat zu vertrauen, unabhängig davon, ob es gültig, abgelaufen, selbstsigniert oder von einer nicht vertrauenswürdigen Behörde ausgestellt wurde. Dies öffnet die Tür zu mehreren Sicherheitsrisiken:
- Man-in-the-Middle (MitM)-Angriffe: Ein Angreifer könnte Ihre Verbindung zu einem legitimen Server abfangen und sein eigenes gefälschtes Zertifikat präsentieren. Wenn die Verifizierung deaktiviert ist, würde Ihr Tool unwissentlich eine Verbindung zum Server des Angreifers herstellen, was ihm ermöglicht, Ihren Datenverkehr abzuhören oder zu manipulieren.
- Identitätsdiebstahl (Impersonation): Sie könnten versehentlich eine Verbindung zu einem bösartigen Server herstellen, der Ihr beabsichtigtes Ziel imitiert. Ohne Zertifikatsverifizierung gibt es keine kryptografische Zusicherung, dass Sie mit dem echten Server kommunizieren.
- Kompromittierung der Datenintegrität und -vertraulichkeit: Wenn ein Angreifer erfolgreich einen MitM-Angriff durchführen kann, kann er potenziell Daten in Ihrer Kommunikation lesen, ändern oder einschleusen und sowohl die Vertraulichkeit als auch die Integrität kompromittieren.
Wann ist die Verwendung von -k akzeptabel?
- Kontrollierte Testumgebungen: Wenn Sie eine Anwendung oder einen Server in einer Laborumgebung testen, in der Sie den Server explizit kontrollieren und sich der selbstsignierten oder ungültigen Zertifikate bewusst sind.
- Interne Netzwerke: Für interne Tools, die innerhalb eines vertrauenswürdigen Netzwerks kommunizieren, in dem Sie die vollständige Kontrolle über alle Endpunkte haben und die Risiken verstehen.
- Debugging: Vorübergehend zu Debugging-Zwecken, aber aktivieren Sie die Verifizierung immer für Produktions- oder sensible Vorgänge wieder.
Best Practice: Priorisieren Sie immer eine starke TLS-Zertifikatsverifizierung. Deaktivieren Sie sie nur, wenn es absolut notwendig ist und mit einem vollständigen Verständnis der damit verbundenen Risiken. Stellen Sie für Produktionssysteme sicher, dass immer gültige, vertrauenswürdige Zertifikate verwendet werden.
Damit ist das Lab zur Deaktivierung der TLS-Zertifikatsverifizierung in Gobuster abgeschlossen. Sie haben gelernt, wie Sie ein Ziel mit Zertifikatsproblemen identifizieren, das Standardverhalten von Gobuster beobachten und dann die Verifizierung mit dem Flag -k umgehen, während Sie gleichzeitig die kritischen Sicherheitsimplikationen verstehen.
Zusammenfassung
In diesem Lab haben Sie erfolgreich gelernt, wie Sie die TLS-Zertifikatsverifizierung in Gobuster verwalten. Sie haben damit begonnen, ein Ziel mit einem selbstsignierten Zertifikat mithilfe von curl zu identifizieren, was den typischen Zertifikatsfehler demonstrierte. Anschließend haben Sie beobachtet, wie Gobuster standardmäßig aufgrund strenger TLS-Validierung ein solches Ziel nicht scannen kann. Der Kern des Labs bestand darin, das Flag -k mit Gobuster zu verwenden, um die Zertifikatsverifizierung zu umgehen und den Scan fortzusetzen. Schließlich haben Sie ein Verständnis für die erheblichen Sicherheitsimplikationen der Deaktivierung der TLS-Verifizierung gewonnen und betont, dass diese nur in kontrollierten oder spezifischen Testszenarien mit Vorsicht eingesetzt werden sollte. Dieses Wissen ist entscheidend für die effektive und sichere Nutzung von Web-Scanning-Tools.