Alltag eines Penetration Testers: Ein Fallbeispiel
Warum sind Penetrationstests wichtig?
Wenn ein ausführbarer Mailanhang unüberlegt geöffnet wird, ein Mitarbeiter zum Download verleitet wird oder die VPN-Einwahl ohne einen zweiten Faktor erfolgt, dann muss man früher oder später damit rechnen, dass sich ein potenzieller Angreifer im internen Netzwerk befindet. Doch was passiert danach? Zur Verwaltung von Benutzern, Gruppen, und Berechtigungen kommt bei den meisten Unternehmen und Behörden ein Active Directory zum Einsatz. Nach dem eine Entität gekapert wurde, wird der Angreifer üblicherweise versuchen, sich höhere Privilegien zu verschaffen, um weitreichenden Zugriff auf Ihre Daten zu erhalten. Das Active Directory bietet hierfür leider etliche Hintertüren, welche es häufig in kürzester Zeit ermöglichen, sich administrative Rechte zu verschaffen.
Genau hier kann Ihnen ein Penetrationstest helfen: Prüfen Sie Ihre Domain auf fehlerhafte Konfigurationen, zu offene Berechtigungen und schwache Kennworte, bevor es ein möglicher Angreifer tut.
Fallbeispiel: "Es war einmal ein Active Directory..."
Der nachfolgende Fall steht exemplarisch für eine Vielzahl an durchgeführten Penetrationstests von SHD und skizziert in anonymisierter Form die Kompromittierung einer Bildungseinrichtung.
Während des Kick-Offs wurden folgende Ziele für den simulierten Angriff festgelegt:
- Zugriff auf das interne Netzwerk erhalten
- Kompromittierung eines Domainaccounts
- Erlangen von domainadministrativen Rechten
Der Angreifer schafft es ins Netzwerk
Zur Erreichung des ersten Ziels genügte ein kurzer Besuch vor Ort: Bedingt dadurch, dass der Campus, die Verwaltungsgebäude sowie die dazugehörige Bibliothek öffentlich zugänglich sind, war der Weg hin zu einer Netzwerkdose nicht weit. Der erste Versuch, das Gerät des Angreifers in das Netzwerk zu bringen und einfach anzustecken, scheiterte allerdings durch die eingesetzte NAC-Lösung (Network Access Control) mit der einhergehenden 802.1X-Authentifizierung. Dieses Protokoll wird häufig für den sicheren Netzwerkzugriff genutzt, setzt allerdings voraus, dass das Endgerät dieses unterstützt.
Ein Blick in das Konfigurationsmenü der Drucker, welche in einem abseits gelegenen Verwaltungstrakt standen, verriet jedoch, dass der Netzwerkzugriff hier ohne erweitere Schutzmaßnahmen vonstattenging. Durch die Verwendung der MAC-Adresse des Druckers auf dem Ethernet-Adapter des Notebooks konnte sich letztlich Zugriff auf das interne Netzwerk verschafft werden.
Ein Domainaccount wird gekapert
Doch wie gelangt man nun als Angreifer in den Besitz eines Benutzeraccounts? Beispielsweise durch das Ausnutzen von einem der ältesten Angriffsvektoren in windows-verwalteten Netzwerken: Neben der Möglichkeit, Hostnamen per DNS aufzulösen, kommen bei Windows drei weitere "Fall-Back"-Protokolle zum Einsatz: LLMNR, NBT-NS und mDNS. Diese können verwendet werden, um innerhalb des eigenen Netzsegments die Namensauflösung zu manipulieren und um die Clients dazu zu bringen, sich mit dem Notebook des Angreifers zu verbinden. Dadurch konnten nach einer Weile mehrere Anmeldeversuche (Net-NTLMv2 Challenge-Response) von Verwaltungsangestellten aufgezeichnet werden. Das Programm "Hashcat" war anschließend das Mittel der Wahl, um die Kennworte aus den Anmeldeversuchen zu knacken und um an "Ziel Nummer 2" einen Haken zu setzen.
Die Rechte des Accounts werden erweitert
Frisch ausgestattet mit einem internen Domainaccount der Hochschule ging es nun darum, möglichst weitreichende Rechte zu erhalten. Die Wege zur Kompromittierung einer Domain können sehr vielfältig und komplex sein. Allerdings gibt es bei den Angriffsvektoren eine Handvoll von "Quick Wins", welche unter den richtigen Umständen direkt zu domainadministrativen Rechten führen können. Einer dieser Wege führt beispielsweise über die Zertifizierungsstelle (CA).
Die CA vor Ort wurde mit der microsoft-eigenen Lösung "Active Directory Certificate Service (ADCS)" realisiert. Und um die Zertifikate bequem über eine Weboberfläche zu beantragen, wurde während der Installation auch das sogenannte "Web Enrollment" in den Serverrollen aktiviert. Sofern keine weiteren Änderungen vorgenommen werden, geht die Grundeinstellung der Webschnittstelle mit einer unsicheren Anmeldemethode einher und stellt ein eklatantes Sicherheitsrisiko dar. Diese Grundeinstellung konnte letztlich dazu genutzt werden, um in den Besitz eines "Domaincontroller (DC)"-Zertifikats zu kommen und um sich als Domaincontroller zu authentifizieren.
Und da jeder Domaincontroller das Recht "Verzeichnisänderung replizieren" hat, konnten anschließend alle Benutzer samt ihrer gespeicherten Zugangsdaten abgefragt werden (auch von allen Domainadministratoren).
DAS ERGEBNIS: Alle gesetzten Ziele wurden vom Angreifer erreicht.
Lessons learned?
Der hier geschilderte Fall zur Kompromittierung der Domain ist nur einer von vielen und hat weniger als einen Tag in Anspruch genommen. Sofern eine Domain in der Standardkonfiguration vorliegt, ist es für einen potenziellen Angreifer häufig ein Leichtes, diese zu übernehmen.
Ergänzt wird die Problematik durch mögliche Lücken im Rollen- und Berechtigungskonzept, welche in einer sogenannten "historisch gewachsenen" Domain früher oder später auftreten.
In Anbetracht dessen, dass nahezu täglich Änderungen innerhalb der Domain durchgeführt werden − sei es beim Anlegen von Benutzern oder beim Ändern von Gruppen − sollten regelmäßige Sicherheitsüberprüfungen durchgeführt werden. Dies kann durch Audit-Tools wie "Ping Castle" oder "Purple Knight" unterstützt werden. Allerdings ersetzen diese Tools keinesfalls einen eigenständigen Penetration Test des Active Directory. Einerseits werden von solchen Tools die Konfigurationen auf Client/Server-Ebene nicht geprüft, und andererseits, weil der individuelle Kontext zu Ihrem etablierten Rollen- und Berechtigungskonzept nicht interpretiert werden kann.
Sie suchen einen zuverlässigen Partner für Pentests? Sprechen Sie uns an!
Autor: David Häntzschel
Bildquellen: SHD, Shutterstock