nccgroup/berserkoBurp Suite-Erweiterung zur Durchführung der Kerberos-Authentifizierung
Als Open Source veröffentlicht von NCC Group Plc - http://www.nccgroup.trust/
Entwickelt von Richard Turnbull, richard [dot] turnbull [at] nccgroup [dot] com
http://www.github.com/nccgroup/Berserko
Veröffentlicht unter der AGPL, siehe LICENSE für weitere Informationen
Die weitere Entwicklung von Berserko findet unter https://github.com/rteatea/Berserko statt
Berserko ist eine Burp-Erweiterung, die Unterstützung für die Durchführung der Kerberos-Authentifizierung hinzufügt. Dies ist beim Testen in einer Windows-Domäne nützlich, wenn die NTLM-Authentifizierung nicht unterstützt wird (Burp behandelt NTLM bereits). Berserko erfordert nicht, dass der Rechner, auf dem Burp läuft, in einer Domäne angemeldet ist (oder dass darauf überhaupt Windows läuft).
Die einzige uns derzeit bekannte Lösung zum Testen von Kerberos-Anwendungen mit Burp besteht darin, eine Proxy-Kette über Fiddler einzurichten, wobei die Authentifizierung gemäß diesen Anweisungen eingerichtet wird. Aber Fiddler ist nur für Windows verfügbar, und das Bilden von Proxy-Ketten erhöht die Komplexität und beeinträchtigt die Leistung. Daher ist es schön, die Kerberos-Fähigkeit direkt in Burp zu haben.
Laden Sie die neueste Berserko-JAR-Datei vom Tab Releases oder aus dem Ordner berserko\releases herunter.
Gehen Sie in Burp zum Tab Extender, wählen Sie Add, stellen Sie sicher, dass als Extension type Java ausgewählt ist, und wählen Sie dann die JAR-Datei aus. Wenn alles gut geht, sollte der Tab Berserko zur Burp-Benutzeroberfläche hinzugefügt werden.
Auf dem Tab Berserko in Burp gibt es verschiedene Bedienelemente.
Das Kontrollkästchen Do Kerberos authentication ist ein Hauptschalter. Bis es aktiviert ist, tut Berserko überhaupt nichts.
Die Schaltfläche Restore defaults setzt Berserko auf die Standardkonfiguration zurück (in der keine Domänendetails oder Benutzeranmeldeinformationen vorhanden sind).
Die Schaltfläche Clear Kerberos state löscht alle Kerberos-Tickets und anderen Zustand auf dem Client. Der einzige Grund, dies zu verwenden, wäre, wenn Änderungen an der Kerberos-Konfiguration auf der Serverseite vorgenommen wurden und Sie von einem sauberen Zustand aus starten möchten.
Die Schaltfläche Write tickets to log schreibt Informationen über Ihre aktuellen Kerberos-Tickets in den Log-Stream von Berserko - das kann beim Debuggen/Beheben von Problemen nützlich sein. Um die Logs zu sehen, gehen Sie zum Tab Extender in Burp, wählen Sie Berserko aus und sehen Sie sich den darunterliegenden Tab Output an. Es kann sinnvoll sein, hier die Option Save to file zu verwenden, da die Ticketdaten den Log-Puffer in der GUI leicht füllen können.
Einige Bedienelemente haben eine Hilfe-Schaltfläche, die weitere Informationen einblendet.
Geben Sie mit den Bedienelementen in diesem Abschnitt den Domain DNS Name und den KDC Host an. Die Textfelder können nicht direkt bearbeitet werden; zum Ändern müssen Sie die Schaltfläche 'Change' verwenden.
Der Domain DNS Name sollte der DNS-Name der Domäne sein, gegen die Sie sich authentifizieren möchten (genauer gesagt ist dies eigentlich das Kerberos-Realm). Dies sollte etwa mydomain.acme.local sein. Es sollte nicht der NETBIOS-Name der Domäne sein (der etwa MYDOMAIN wäre).
Der KDC Host sollte der Hostname (oder die IP-Adresse) eines Kerberos-KDC (Key Distribution Center) sein. In einer Windows-Domäne ist ein KDC einfach ein Domänencontroller.
Nachdem Sie den Domain DNS Name angegeben haben, können Sie mit der Schaltfläche Auto versuchen, einen KDC automatisch zu finden. Dies geschieht durch das Senden einer DNS-SRV-Abfrage für den Kerberos-Dienst. Wenn einer Ihrer DNS-Server ein Domänencontroller für die richtige Domäne ist, sollte dies funktionieren. Wenn nicht, funktioniert es nicht. ❗Diese Funktion funktioniert in neueren Versionen von Burp nicht, da die erforderlichen DNS-Bibliotheken nicht im gebündelten JRE enthalten sind. Sie können dies umgehen, indem Sie mit einem vollständigen JRE starten, wie oben in dieser README beschrieben.❗
Wenn der Domain DNS Name und der KDC Host eingegeben wurden, testen Sie mit der Schaltfläche Test domain settings die Konnektivität. Wenn alles gut geht, erhalten Sie eine Antwort Successfully contacted Kerberos service.
Weitere Informationen zum Ermitteln der richtigen Werte für diese Domäneneinstellungen finden Sie in dieser Datei.
Geben Sie mit den Bedienelementen in diesem Abschnitt den Benutzernamen und das Passwort für ein Domänenkonto an. Die Textfelder können nicht direkt bearbeitet werden; zum Ändern müssen Sie die Schaltfläche 'Change' verwenden.
Der Username sollte nur der einfache Benutzername sein. Dies sollte etwa bob sein. Er sollte nicht MYDOMAIN\bob oder [email protected] oder ähnlich sein.
Nachdem Sie die Anmeldeinformationen angegeben haben, können Sie die Schaltfläche Test credentials verwenden. Dabei wird versucht, ein Kerberos-Ticket-Granting-Ticket für den angegebenen Benutzer zu erwerben. Bei Erfolg erhalten Sie eine Antwort TGT successfully acquired. Wenn es nicht erfolgreich ist, beachten Sie, dass dies ein Domänenauthentifizierungsversuch ist; seien Sie also vorsichtig, Ihr Konto nicht zu sperren.
Das Passwort wird nicht für das nächste Mal in der Berserko-Konfiguration gespeichert, es sei denn, das Kontrollkästchen Save password in Burp config? ist aktiviert. Alle anderen Einstellungen werden jedoch gespeichert.
Einige Anwendungen verwenden die Kerberos-Delegierung serverseitig, um die Identität des Clients an andere Server weiterzuleiten (es gibt jedoch keine einfache Möglichkeit, vom Client aus festzustellen, ob dies verwendet wird).
Berserko unterstützt dies, aber es gibt einen Haken. Die Delegierung funktioniert nur, wenn der Benutzer ein forwardable TGT (Ticket-Granting-Ticket) besitzt. Die Java-Implementierung von Kerberos bietet leider keine Möglichkeit, programmatisch festzulegen, dass ein forwardable Ticket erworben werden soll. Dies kann nur durch Hinzufügen eines entsprechenden Eintrags zur Konfigurationsdatei krb5.conf erfolgen.
Damit die Delegierung funktioniert, muss Berserko also auf eine geeignete krb5.conf-Datei zeigen; hier gibt es zwei mögliche Ansätze.
Die einfachste und empfohlene Methode ist die Verwendung der Schaltfläche Create krb5.conf file. Dadurch wird eine geeignete Datei an einem Ort Ihrer Wahl für Sie erstellt. Sie können sie in einem temporären Verzeichnis, in Ihrem Projektverzeichnis oder wo auch immer ablegen. Dieselbe Datei kann jedoch unbegrenzt wiederverwendet werden, daher kann es sinnvoll sein, sie an einem dauerhafteren Ort zu platzieren. Mit der Schaltfläche Change können Sie eine andere Datei auswählen.
Falls es Sie interessiert: Die erstellte krb5.conf-Datei ist sehr einfach und hat den folgenden Inhalt:
[libdefaults]
forwardable = true
Alternativ können Sie mit der Schaltfläche Change auf eine vorhandene krb5.conf-Datei im System zeigen. Der einzige Grund, dies zu tun, wäre, wenn in dieser Datei andere wichtige Kerberos-Einstellungen vorhanden sind, die von Berserko übernommen werden sollen (was theoretisch funktionieren sollte, aber in der Praxis nicht getestet wurde). Beachten Sie, dass der Standard-Speicherort dieser Datei unter Linux /etc/krb5.conf ist - andere Betriebssysteme haben seltener eine solche Datei. Wenn Sie auf eine vorhandene krb5.conf-Datei zeigen, stellen Sie sicher, dass Sie sie bearbeiten, um die Weiterleitung zu aktivieren - fügen Sie forwardable = true im Abschnitt [libdefaults] hinzu (oder einzeln für jedes Realm). Aber seien Sie vorsichtig. Berserko zu bitten, die Datei zu erstellen, ist in 99 % der Fälle die bessere Option.
Wenn Sie wissen möchten, ob Ihre Delegierungskonfiguration erfolgreich ist, verwenden Sie die Schaltfläche Check current config. Diese zeigt an, ob die krb5.conf-Datei gefunden wurde und ob die Einstellung forwardable korrekt ist. Beachten Sie außerdem, dass Berserko Ihnen mitteilt, ob es beim Verwenden der Schaltfläche Test credentials erfolgreich ein forwardable TGT erworben hat.
Es ist eine gute Idee, sicherzustellen, dass Sie ein forwardable Ticket haben, bevor Sie eine Anwendung verwenden. Es scheint, dass IIS den Authentifizierungsstatus eines Benutzers serverseitig so zwischenspeichern kann, dass der Wechsel von einem nicht-forwardable Ticket zu einem forwardable nicht funktioniert.
Die Einstellungen in diesem Abschnitt steuern, ob Berserko die Kerberos-Authentifizierung 'reaktiv' versucht (d. h. auf eine 401-Antwort vom Server warten und die Anfrage dann mit einem hinzugefügten Kerberos-Authentifizierungsheader erneut senden) oder 'proaktiv' (d. h. den Kerberos-Authentifizierungsheader zur ausgehenden Anfrage hinzufügen).
Der Vorteil der proaktiven Authentifizierung besteht darin, dass sie nur einen HTTP-Roundtrip erfordert, während die reaktive Authentifizierung zwei erfordert. Der Nachteil der proaktiven Authentifizierung besteht darin, dass möglicherweise Kerberos-Authentifizierungsheader an Hosts gesendet werden, die diese nicht erwarten. Berserko kann Authentifizierungsfehler bei der reaktiven Strategie außerdem besser diagnostizieren.
Die Option Proactive Kerberos authentication, only after initial 401 received ist ein Hybrid dieser beiden Ansätze: Berserko authentifiziert sich bei der ersten Anfrage an einen Host reaktiv, danach jedoch proaktiv.
In diesem Abschnitt können Sie festlegen, welche Hosts für die Kerberos-Authentifizierung im Geltungsbereich liegen.
Standardmäßig ist das Kontrollkästchen All hosts in this Kerberos domain in scope for Kerberos aktiviert. Das bedeutet, dass Berserko die Kerberos-Authentifizierung nur bei Webservern versucht, deren Hostname mit dem DNS-Namen der Domäne endet. In vielen Situationen reicht dies aus.
Es ist jedoch möglich, Kerberos-fähige Webanwendungen mit einem Hostnamen zu haben, der diese Form nicht aufweist (vorausgesetzt, der Administrator hat einen geeigneten Service Principal Name eingerichtet). Um dem Rechnung zu tragen, können Sie über das Listenfeld auf der rechten Seite zusätzliche Hosts hinzufügen, die als im Geltungsbereich befindlich betrachtet werden. Beachten Sie, dass Platzhalter verwendet werden können (* entspricht null oder mehr Zeichen, ? entspricht jedem einzelnen Zeichen außer einem Punkt).
Alternativ können Sie das Kontrollkästchen All hosts in scope for Kerberos authentication aktivieren. Dies hat offensichtlich den Vorteil, dass Sie den Geltungsbereich nicht manuell festlegen müssen. Der potenzielle Nachteil dieser Konfiguration besteht darin, dass Berserko möglicherweise Kerberos-Anfragen an den KDC sendet, um Service-Tickets für Hosts zu erwerben, die nicht zur Domäne gehören. Dies könnte Leistungsprobleme verursachen und Datenschutzprobleme hervorrufen (wenn Sie nicht möchten, dass diese Informationen an den KDC weitergegeben werden). Dies ist wahrscheinlich ein besonderes Problem bei der Strategie Proactive Kerberos authentication, da Berserko in diesem Fall versuchen wird, jeder durch Burp laufenden Anfrage einen Kerberos-Authentifizierungsheader hinzuzufügen. Diese Kombination von Optionen wird nicht empfohlen, und Berserko wird Sie warnen, wenn sie ausgewählt ist (sie aber nicht tatsächlich verhindern).
Wenn weder All hosts in this Kerberos domain in scope for Kerberos noch All hosts in scope for Kerberos authentication ausgewählt sind, sind nur die Hosts im Geltungsbereich, die dem Listenfeld hinzugefügt wurden.
Die Option Plain hostnames considered part of domain bedeutet, wenn sie ausgewählt ist, dass 'einfache Hostnamen' (d. h. Hostnamen, die nur aus einer einzigen Komponente bestehen) als Teil der Domäne betrachtet werden (und daher automatisch im Geltungsbereich liegen, wenn All hosts in this Kerberos domain in scope for Kerberos ausgewählt ist). Der Hauptgrund, dies zu deaktivieren, wäre, wenn Ihr Rechner einer anderen Domäne beigetreten ist als der, gegen die Sie sich mit Berserko authentifizieren (in diesem Fall beziehen sich einfache Hostnamen wahrscheinlich auf Hosts in der Domäne, der Sie beigetreten sind).
Wenn ausgewählt, weist die Option Do not perform Kerberos authentication to servers which support NTLM Berserko an, keine Kerberos-Authentifizierung gegen Hosts zu versuchen, die zusätzlich zu Kerberos auch NTLM unterstützen (d. h. Hosts, die sowohl WWW-Authenticate: NTLM- als auch WWW-Authenticate: Negotiate-Header zurückgeben).
Der Alert Level und der Logging Level können hier auf NONE, NORMAL oder VERBOSE konfiguriert werden.
Alert Level steuert die Menge an Informationen, die an den Tab Alerts von Burp gesendet werden.
Logging Level steuert die Menge an Informationen, die an die Standardausgabe von Berserko gesendet werden (diese kann auf dem Tab Extender eingesehen werden). Beachten Sie, dass eine Erhöhung des Logging Level auf VERBOSE dazu führt, dass mehr Informationen über etwaige Fehler oder Ausnahmen bereitgestellt werden.
Wenn in Ihrer Umgebung Kerberos-Domänenvertrauensstellungen verwendet werden, finden Sie hier einige Hinweise.
Standardmäßig führt Berserko alle Kerberos-Interaktionen mit dem KDC über UDP (Port 88) durch. Wenn Sie stattdessen TCP verwenden möchten, ist dies möglich. Der häufigste Grund dafür ist wahrscheinlich, wenn eine SSH-Port-Weiterleitung für TCP-Port 88 verwendet wird. Fügen Sie einfach udp_preference_limit = 1 zu Ihrer krb5.conf-Datei hinzu, sodass sie wie folgt aussieht:
[libdefaults]
forwardable = true
udp_preference_limit = 1
Es ist möglich, den SPN zu konfigurieren, der für einen bestimmten Host verwendet wird, indem ein Abschnitt [berserko_spn_hints] in die krb5.conf-Datei aufgenommen wird (siehe oben). Die Syntax ist unten dargestellt.
[berserko_spn_hints]
[email protected]
server2.bar.org=app.domain2.local
Der Zielserver steht auf der linken Seite des Gleichheitszeichens und der zu verwendende SPN auf der rechten Seite. Das Realm für den SPN kann optional angegeben werden (wenn nicht, wird Berserko versuchen, das korrekte Realm wie gewohnt zu ermitteln). Nehmen Sie den HTTP/-Teil des SPN hier nicht auf.
Berserko ist nicht mit Burp v2 vor v2020.5.1 kompatibel. Mit Burp v1 gibt es keine Probleme.
Ursache ist, dass die in früheren Burp-2-Versionen mitgelieferte OpenJDK-Version einige der von Berserko verwendeten Kerberos-Funktionen nicht enthält. Dies führt beim Versuch, Berserko zu verwenden, zu einem Fehler java.lang.ClassNotFoundException: com.sun.security.jgss.ExtendedGSSContext.
Die naheliegende Abhilfe ist ein Upgrade auf v2020.5.1 oder neuer. Alternativ sollte Berserko mit jeder Burp-v2-Version funktionieren, wenn Sie mit einer vollständigen Version der Java-Laufzeitumgebung starten (d. h. nicht mit der in Burp gebündelten).
Angenommen, Sie haben java in Ihrem PATH:
java -jar burpsuite_pro.jar