Unser Kunde in dieser Fallstudie ist ein internationales Unternehmen mit insgesamt Tausenden von Workstations und Servern, die sich auf verschiedene Standorte verteilen. Die Hosts sind in mehreren Domänen organisiert und diese unter einer Gesamtstrukturdomäne zusammengefasst. Unser Kunde wollte wissen, wie groß die Gefahr wäre, wenn ein Mitarbeiter mit minimalen Zugriffsrechten im System des Unternehmens böswillig handeln würde. Gleichzeitig wollte der Kunde die IDS- und IPS-Lösungen testen, die in die Praxis eingeführt werden sollten.
Was können wir als verantwortliche Entscheidungsträger tun, wenn wir uns fragen, wie unsere Gesamtsysteme auf einen realen Angriff reagieren würden? Es ist klar, dass die traditionelle Schwachstellenanalyse in diesem Fall nicht die beste Wahl ist, da es sich dabei eher um ein Sicherheits-Audit als einen echten Hacker-Angriff handelt. Das Ziel von Red-Team-Tests hingegen ist es, dem Kunden realistisch aufzuzeigen, wie effizient die eingeführten Richtlinien und wie gut geschult die IT-Spezialisten sind und wie es um das Sicherheitsbewusstsein des Personals im Allgemeinen bestellt ist. Demensprechend handelt es sich bei Red-Team-Tests um die Simulation echter Angriffe, wobei nur eine kleine Gruppe von Mitarbeitenden des Kunden eingeweiht wird. Das Ziel des Angreifers bei der Simulation ist üblicherweise, das System des Kunden in größtmöglichem Ausmaß zu gefährden, natürlich ohne absichtliche Schäden zu verursachen.
Das Team von Boltonshield hat bereits viele Jahre Erfahrung auf dem Gebiet der Red-Team-Tests und hat im Rahmen verschiedener erfolgreicher Projekte viele interessante Fälle gesehen. Wichtig bei Projekten mit Red-Team-Tests ist, dass der Startpunkt immer nach Absprache gewählt wird. Bevor wir eine Entscheidung treffen können, müssen wir den Bedarf des Kunden ermitteln sowie auch die möglichen Ausrichtungen des Angriffs dorthin, wo das System am wenigsten geschützt ist.
Im vorliegenden Fall dauerten die Red-Team-Tests eine Woche an wie vereinbart. Das Projekt endet frühzeitig, wenn es uns gelingt, nachzuweisen, dass das System maßgeblich gefährdet werden kann, oder wenn unsere Aktivitäten entdeckt werden.
Sprung über den Graben
Zu Beginn der Red-Team-Tests bekamen wir unser eigenes Büro, wo wir ungestört arbeiten konnten. Mit Ausnahme der eingeweihten Mitarbeitenden erhielt das gesamte Personal die Information, dass wir ein Audit im Zusammengang mit den Unternehmensabläufen durchführen würden.
Nach Inspektion der verfügbaren Netzwerk-Ports war uns schnell klar, dass bei unserem Kunden eine portbasierte Netzwerkzugangskontrolle (Port-based Network Access Control, PNAC) gemäß IEEE-Norm 802.1X implementiert war. Mit den geeigneten Konfigurationseinstellungen kann diese ein effizientes Tool sein, da sie Netzwerkzugriffe erkennen und blockieren kann. Wie jedoch bei allen Protokollen, gibt es auch in diesem Fall Schwächen.
Die Zugangskontrolle kann am einfachsten umgangen werden, wenn wir uns Geräte ansehen, die mit Netzwerken verbunden sind und die diese Norm vermutlich nicht unterstützen. Da der Betrieb dieser Geräte trotzdem irgendwie sichergestellt werden muss, werden sie im Allgemeinen als Ausnahmen verwaltet. Im Laufe des Prozesses werden die Geräte anhand Ihrer MAC-Adressen identifiziert und dann können sie sich rechtmäßig mit dem Netzwerk verbinden, auch ohne angemessene Authentifizierung.
Bei einer überragenden Mehrheit an Netzwerkdruckern sind die NAC-Standards noch nicht umgesetzt, sodass diese attraktive Angriffsziele sein können. In einer der hinteren Ecken des Raumes fanden wir einen Netzwerkdrucker, der nur noch als Staubfänger diente. Durch die Verbindung zum nächsten Netzwerk-Port erhielt er sofort eine IP-Adresse vom DHCP-Server, was bedeutete, dass seine MAC-Adresse immer noch als Ausnahme auf dem Authentifizierungsserver vorhanden war.
Obwohl die MAC-Adresse nicht auf dem Bedienfeld des Druckers angezeigt wurde, konnten wir uns durch die Nutzung eines Hubs passiv zwischen den Drucker und das Netzwerk schalten. So konnten wir die Kommunikation zwischen Drucker und Netzwerk abhören und innerhalb kürzester Zeit eine gültige MAC-Adresse erhalten.
Mit Kenntnis dieser MAC-Adresse konnten wir uns auch mit dem Netzwerk verbinden.
Die erste Verteidigungslinie war also erfolgreich durchbrochen. Da einige von uns gleichzeitig arbeiten wollten, wir aber nur eine gültige MAC-Adresse hatten, wandelten wir einen der Computer praktisch in einen Router um. Alle anderen Computer, die an der Analyse beteiligt waren, kommunizierten mit dem Netzwerk über diesen einen Host.
Mauern stürzen ein
Nachdem wir uns erfolgreich verbunden hatten, konnten wir beginnen, das Netzwerk zu erkunden. Wir mussten besonders darauf achten, keine Aufmerksamkeit auf uns zu ziehen.
Wären unsere Aktivitäten aufgefallen, hätte das leicht das Ende des Projekts bedeuten können. Das hieß, dass wir praktisch die meisten Techniken der aktiven Aufklärung nicht nutzen durften. Deshalb versuchten wir zunächst, die gefährdeten Workstations und Server durch passives Abfangen des Netzwerkverkehrs zu identifizieren.
Nach kurzer Zeit hatten wir bereits einige Zugriffspfade von Dateifreigaben im Netzwerk sowie die IP-Adressen einiger Workstations, also begannen wir mit deren Analyse. Während wir die Datenfreigaben genauer analysierten, entdeckten wir etwas Interessantes.
Frei zugängliche Netzwerkfreigaben
Die Freigabe mit dem Namen ADBackupManager unterschied sich stark von allen anderen und war jedem frei zugänglich. In der Freigabe fanden wir eine ausführbare Datei, einige DLL-Dateien und auch eine Datenbankdatei. Dem Namen der Freigabe nach zu urteilen, dachten wir, es dürfte sich lohnen, diese Dateien gründlicher zu untersuchen. Mithilfe von Reverse-Engineering-Techniken gelang es uns, die Anwendung praktisch bis zum Quellcode zu entschlüsseln. Dabei fanden wir heraus, dass die Anwendung dazu diente, Backups für die Netzwerkfreigaben zu erstellen. Damit die Anwendung richtig funktioniert, ist auch ein Zugriff auf Domänenebene erforderlich. Dieser Zugriff war in verschlüsselter Form in der Datenbank gespeichert. Da der Entschlüsselungsalgorithmus und der notwendige Schlüssel im Quellcode der Anwendung fest codiert waren, konnten wir das verschlüsselte Passwort ganz leicht entschlüsseln.
Verschlüsseltes Passwort gespeichert in einer DatenbankEntschlüsselungsfunktion mit IV-ParameterAufruf der Entschlüsselungsfunktion mit dem fest codierten Schlüssel
Wir überprüften schnell den Zugriff und er war gültig. An diesem Punkt konnten wir auf authentifizierte Weise mit dem Domänenserver kommunizieren. Das war der nächste wichtige Meilenstein.
Festung erobert
Mit dem Zugriff konnten wir alle Benutzer der Domäne abfragen sowie deren Gruppen und gültige Access Control Lists (ACL). Der nächste Schritt war die Ausführung eines Kerberoasting-Angriffs, in dessen Verlauf wir mithilfe unseres gültigen Zugriffs Service-Tickets für die Service-Konten der Domäne anfragten.
Jedes Ticket ist mit dem NTLM-Hash des jeweiligen Service-Kontos verschlüsselt.
Wir können versuchen, die beschafften Tickets zu entschlüsseln, indem wir Millionen Passwörter offline ausprobieren.
Wenn ein Ticket entschlüsselt werden kann, haben wir damit auch das Passwort des jeweiligen Service-Kontos. Unseren Erfahrungen zufolge können Service-Konten, die mit einem mittelstarken oder schwachen Passwort geschützt sind, auf diese Weise schnell geknackt werden.
Erfolgreiche Ticket-Anfrage
Es gelang uns, ein Service-Ticket für ein Service-Konto anzufragen, das mit einem Admin-Flag versehen war. Service-Konten sind im Allgemeinen Domänenkonten mit besonderen Berechtigungen, das Admin-Flag deutete jedoch stark darauf hin, dass dieser Benutzer über noch mehr Berechtigungen verfügen könnte. Schließlich schafften wir es innerhalb nur Stunde, das Service-Ticket des Benutzers svc_backupmgr zu knacken. Nach einer schnellen Abfrage fanden wir außerdem heraus, dass dieser Benutzer zu der Gruppe »Backup Operators« gehört.
Besondere Berechtigungen des Benutzers svn_backupmgr
Als dieser Benutzer konnten wir uns über den Dienst »winrm« an einem der Domänencontroller anmelden. Der Privilege-Escalation-Angriff lag mit der Backup-Berechtigung quasi auf der Hand.
Im ersten Schritt dieses Angriffs, fragten wir die SAM- und SYSTEM-Hives aus der Registry ab. Im nächsten Schritt zogen wir den NTLM-Hash des lokalen Administrators aus den Hives. Mit dem Hash und der Pass-the-Hash-Methode konnten wir uns am Server anmelden, auch ohne das Passwort zu kennen und dieses Mal sogar mit Administratorzugriff.
Abfrage von SAM- und SYSTEM-HivesAbbild des NTDS
Mit den passenden Berechtigungen konnten wir ein Abbild des NTDS erstellen, das den Passwort-Hash aller Domänenbenutzer enthielt.
Zu diesem Zeitpunkt ließ sich sagen, dass die Domäne vollständig gefährdet war. Wir beschafften uns die Hashes von Tausenden Benutzern, einschließlich Administratoren der Domäne und des Unternehmens. Ausgestattet mit diesen Authentifizierungsdaten hätten wir die Berechtigungen gehabt, in mehreren Anlagen des Unternehmens beliebige Aktionen in der Domäne auszuführen.
Eine große Überraschung
Die Kombination aus folgenden gravierenden Schwachstellen ermöglichte einen erfolgreichen Angriff:
vorhandene NAC-Ausnahmen (längst ungenutzte Geräte noch als Ausnahmen gelistet)
Netzwerkfreigaben mit sensiblen Inhalten für jeden frei zugänglich
Verwendung fest codierter Authentifizierungsdaten
Service-Konto mit schwachem Passwort geschützt
Service-Konto verfügt über zu viele Berechtigungen (Fernanmeldung über winrm)
Im Verlauf der Red-Team-Tests führten wir fast ausschließlich Aktionen aus, zu denen Benutzer der Domäne üblicherweise berechtigt sind. Dementsprechend verursachten wir keine Sicherheitsvorfälle oder Warnungen in den IDS- und IPS-Tools des Kunden.
Als wir den Entscheidungsträgern bei unserem Kunden nach nur wenigen Tagen unsere Ergebnisse präsentierten, waren diese völlig überrascht. Sie sagten, sie hätten die zuständigen Experten mehrfach gefragt, ob ihnen verdächtige Vorfälle aufgefallen seien, doch als Antwort erhielten sie wiederholt ein klares Nein.
Das Ergebnis bestärkte unseren Kunden darin, Sofortmaßnahmen zu ergreifen und parallel dazu eine vollumfängliche interne Analyse bei uns anzufragen. Im Verlauf der Read-Team-Tests wurden mehrere kritische Schwachstellen erkannt. Basierend auf den Ergebnissen aus mehren Runden gemeinsamer Arbeit kann festgehalten werden, dass das Sicherheitsniveau des Systems unseres Kunden kurz darauf deutlich verbessert wurde.
Treten Sie mit uns in Kontakt, um herauszufinden, wie Boltonshield auch Ihrem Unternehmen helfen kann.
Die Kombination aus folgenden gravierenden Schwachstellen ermöglichte einen erfolgreichen Angriff: