LegacyHive: Ein normaler Nutzer mountet das Hive des Admins, und einen Patch gibt es nicht

Am 14. Juli schloss Microsoft mehr als 600 Schwachstellen. Wenige Stunden später veröffentlichte ein Forscher, der als Nightmare Eclipse signiert (oder Chaotic Eclipse, je nachdem, welches Konto ihm gerade nicht gelöscht wurde), einen PoC, der auf Systemen mit genau diesen Korrekturen funktioniert. Er nannte ihn LegacyHive. Bis heute gibt es dafür weder eine CVE-Nummer noch eine Microsoft-Meldung.
Das ist ein Fehler im Benutzerprofildienst ProfSvc. Derselbe Dienst, der bei der Anmeldung Ihre Hintergrundbilder, Verknüpfungen und Word-Einstellungen lädt. Es zeigt sich, dass man ihn dazu bringen kann, die eines anderen zu laden.
Was der Exploit wirklich tut
In Windows ist ein Hive eine Datei mit einem Ausschnitt der Registry. Ihre Einstellungen liegen in NTUSER.DAT und UsrClass.dat, die Einstellungen der Kollegin im Nachbarkonto in deren eigenen Dateien, und das System sorgt dafür, dass Sie sich gegenseitig nicht hineinsehen.
LegacyHive umgeht diese Kontrolle. Der Angreifer tauscht den Wert aus, der auf den Pfad der Anwendungsdaten zeigt, leitet den Dienst in den Namensraum des Objekt-Managers um und wartet dann auf den Moment, in dem ProfSvc nach der Datei greift. Diesen Moment fängt er mit einem Oplock ab, einer opportunistischen Sperre auf einer Köderdatei, und tauscht im Bruchteil einer Sekunde den symbolischen Link aus. Der Dienst läuft als SYSTEM, also öffnet er, was ihm vorgelegt wurde. Das Hive des Opfers landet im Classes Root des Angreifers, mit Schreibrecht.
Ein klassisches Wettrennen um eine Datei, nur gewinnt es die Seite, die nicht einmal an der Startlinie stehen dürfte.
Vereinfacht läuft die Logik des Angriffs auf eines hinaus: den Dienst dazu zu bringen, eine untergeschobene Datei in den Profilzweig zu laden. Das folgende Schema zeigt nur die Idee, keinen funktionierenden Code.
// Uproszczony schemat logiczny ataku LegacyHive
// Atakujący manipuluje usługą profili, aby załadować celowy plik hive
// do gałęzi HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
void TriggerLegacyHive() {
std::string targetUser = "Administrator";
std::string maliciousHivePath = "C:\\temp\\fake_hive";
// Próba wymuszenia załadowania ula w kontekście obecnego procesu
if (LoadUserHive(targetUser, maliciousHivePath)) {
printf("Success: Target hive mounted in current user classes root.\n");
}
}Der echte Exploit ist deutlich verschlungener, denn das Schwierige daran ist allein, den Austausch des Links mit dem Moment zu synchronisieren, in dem der Dienst nach der Datei greift. Das Schema lässt diesen Teil bewusst aus.
Einen ähnlichen Fehler behob Microsoft 2015 als CVE-2015-0004. Dieselbe Klasse, ein neuer Weg hinein.
Was der Exploit nicht tut
Hier beginnt der Teil, den die meisten Schlagzeilen auslassen.
Der veröffentlichte PoC ist bewusst beschnitten. Er benötigt die Zugangsdaten eines weiteren gewöhnlichen Nutzers und den Namen eines dritten Kontos und mountet nur UsrClass.dat. Der Autor behauptet, die ursprüngliche Version habe keine zusätzlichen Passwörter gebraucht und ein beliebiges Hive genommen, aber diese Version zeigte er nie.
Matei Badanoiu von Pentest-Tools brachte es nüchtern auf den Punkt: Für jemanden, der bereits einen Fuß in der Umgebung hat, ist das ein wirklich nützliches Primitiv, während das Zusammenkleben mit Diebstahl von Zugangsdaten und dauerhaftem Zugriff zu einer „vollständigen Übernahme“ eher Anspruch ist als das, was tatsächlich veröffentlicht wurde.
Ich stimme zu. Für sich genommen macht LegacyHive niemanden zum Domain-Admin und dringt nicht aus dem Internet ein. Sie müssen bereits auf der Maschine sein, ein Konto haben und ein zweites Konto zur Verfügung haben.
Warum das trotzdem zählt
Weil diese Voraussetzung in der Praxis banal ist. Ein per Phishing übernommenes Konto, ein nach einem Weggang weitergereichter Laptop, eine Laborstation, an der sich die halbe Abteilung anmeldet, ein technisches Konto, das drei Personen nutzen. Ein Fuß auf der Ebene eines gewöhnlichen Nutzers ist selten die Hürde; er ist der Ausgangspunkt.
Und wenn Sie ihn haben, ist das Schreibrecht auf den Klassenzweig eines anderen Nutzers überraschend stark. Will Dormann, der den Exploit getestet hat, zeigte es an einem Beispiel: Man kann .txt-Dateien mit dem Rechner verknüpfen, sodass der Administrator sich anmeldet, eine Notiz öffnet und Ihren Code ausführt. Der Rechner ist natürlich ein Scherz. An seine Stelle lässt sich alles setzen, auch Dinge, die kein Klicken des Opfers verlangen.
Der Mechanismus ist also dieser: Sie haben das Konto eines Praktikanten, warten, bis sich jemand mit lokalen Administratorrechten an derselben Maschine anmeldet, und erhalten Codeausführung in dessen Kontext. Von dort LSASS, Zugangsdaten, seitliche Bewegung. Seit Jahren bekannt, nur der Einstieg ist neu.
Für die Geschäftsleitung läuft es auf einen Satz hinaus: Die Trennung der Konten auf gemeinsam genutzten Stationen, auf die viele von uns ihr Risikomodell stützen, hält in diesem Szenario nicht, und Microsoft hat noch nichts veröffentlicht, das daran etwas ändert.
Was tun, wenn es keinen Patch gibt
Der Standardrat, die Systeme zu aktualisieren, hilft diesmal nicht, denn die Updates haben Sie bereits, und der Exploit läuft genau auf ihnen. Bleibt, die Voraussetzungen einzuschränken und zu erkennen.
Beginnen Sie mit einer Bestandsaufnahme der Stationen, an denen sich mehr als eine Person anmeldet. Sie sind hier das Ziel, nicht die Server. Gemeinsam genutzte Arbeitsplätze, Rechner in Schulungsräumen, Servicegeräte, alles mit einer Historie mehrerer lokaler Profile.
Prüfen Sie, wo sich administrative Konten interaktiv an gewöhnlichen Arbeitsstationen anmelden. Jede solche Anmeldung hinterlässt ein Profil, und ein Profil ist ein Hive, das sich mounten lässt. Wenn sich ein Domänenadministrator an der Maschine eines Nutzers anmeldet, um „schnell etwas zu prüfen“, haben Sie ein Problem, das älter ist als LegacyHive.
Richten Sie im EDR eine Warnung ein für den Versuch von Benutzerprozessen, Registry-Hives zu laden, und für ungewöhnliche Änderungen an den Profilpfadwerten in ProfileList. Das Wettrennen blockieren Sie damit nicht, aber es hinterlässt eine Spur.
Sehen Sie durch, wer lokale Administratorrechte hat und ob das noch begründet ist. Nicht weil es diesen konkreten Exploit stoppt, sondern weil es die Kette danach verkürzt.
Und verabschieden Sie sich von der Vorstellung, die Veröffentlichung verschwinde aus dem Netz. Die Konten dieses Forschers wurden bei GitHub und GitLab bereits gelöscht, und er kommt mit dem nächsten Werkzeug zurück. Von seinen sechs früheren Zero-Days wurden drei in Angriffen genutzt, bevor die Korrekturen erschienen.
Zum Schluss
Ich schreibe das an einem Tag, an dem Microsoft weiter schweigt, daher kann ein Teil des Obigen binnen einer Woche veralten. Erscheint eine Meldung, aktualisieren wir den Beitrag.
Es bleibt eine Frage, die sich vor Montag zu beantworten lohnt: Wie viele Stationen haben Sie im Unternehmen, an denen sich im letzten halben Jahr sowohl ein gewöhnlicher Nutzer als auch jemand mit Administratorrechten angemeldet hat? Wenn Sie es nicht wissen, ist das genau die Zahl, bei der wir in einem internen Test beginnen.
Vereinbaren Sie eine kostenlose Beratung: 30 Minuten, auf den Punkt, unverbindlich. Wir zeigen, wie ein interner Test nachvollzieht, wohin ein einziges gewöhnliches Konto auf einer gemeinsam genutzten Station wirklich führt.