Mithören, ein Konto und die ganze Domäne

Kontext

Eines sprach zunächst für den Kunden: Die Passwortrichtlinie der Domäne verlangte vierzehn Zeichen. Das ist mehr als in den meisten Firmen, die wir besuchen, und sieht auf dem Papier verantwortungsvoll aus.

Das Problem ist, dass diese Regel in den Einstellungen der Domäne lebte, aber nicht in der Wirklichkeit. Als jemand die geforderte Länge anhob, erzwang niemand eine Änderung der bestehenden Passwörter. Neue Konten fingen die neue Vorgabe ein, alte behielten ihre. In der Datenbank, die wir später vom Controller zogen, saßen ganz gemütlich Passwörter mit weniger als neun Zeichen, obwohl das System behauptete, das Minimum sei vierzehn. Selbst das Passwort des Domänenadministrators hatte elf.

Der Test selbst war im Ansatz einfach: ein Pentest des internen Netzes aus der Sicht von jemandem, der bereits Zugang zum Büronetz hat. Ein interner Nutzer: ein Praktikant mit Laptop, jemand an einer Dose im Konferenzraum, eine übernommene Arbeitsstation. Der Umfang waren einige Netzsegmente und eine Frage: Wie weit kommt so jemand.

Herausforderung

Die Umgebung war nicht ohne Überlegung gebaut. Es gab eine Active-Directory-Domäne, es gab eine Segmentierung in mehrere Subnetze, es gab eine strengere Passwortrichtlinie als üblich. Nach einer Audit-Checkliste beurteilt, ließen sich etliche Felder grün abhaken. Das geben wir ehrlich zu, denn die Glaubwürdigkeit eines Tests kommt daher, beide Seiten zu zeigen, nicht nur die schlechten Dinge.

Der schwache Punkt lag woanders, in den Teilen, die aus einem Compliance-Bericht nicht herausschreien. Darin, wie Windows Namen standardmäßig auflöst, wenn DNS versagt. Darin, dass ein Teil der Hosts die Signierung der SMB-Kommunikation nicht erzwang. Und in einem Konto, das entschieden zu viel auf einmal tat.

Was wir getan haben

Wir begannen mit dem Mithören. Wenn eine Maschine in einem Windows-Netz einen Namen nicht im DNS findet, gibt sie nicht auf. Sie ruft ins gesamte lokale Segment eine Frage im Stil von "hey, weiß jemand, wer das ist?" Das ist eine Einladung an jeden, der gerade zuhört. Wir hörten zu. Wir antworteten "ja, ich bin es", und die Maschine versuchte vertrauensvoll, sich bei uns zu authentifizieren, und übergab uns dabei ihren Anmeldeversuch als NetNTLMv2-Hash. Demselben Topf fügten wir einen zweiten Mechanismus hinzu: In einer Windows-Umgebung ist IPv6 standardmäßig aktiv und hat Vorrang, und niemand hatte dafür einen Adressierungsserver konfiguriert. Wir traten in diese Leere, gaben uns als Konfigurationsserver und als Nameserver aus und fingen weitere Authentifizierungsversuche ab.

Dann kam die Weitergabe der Session an die Reihe. Da ein Teil der Hosts die SMB-Signierung nicht erzwang, mussten wir die abgefangenen Zugangsdaten nicht einmal knacken. Wir reichten sie im Flug an andere Maschinen weiter und handelten im Namen dieses Nutzers. Hier setzte der Schneeballeffekt ein: Einer der Nutzer, der in unsere Falle tappte, hatte lokale Administratorrechte auf achtzehn Maschinen. Von jeder holten wir die lokale Kontendatenbank mit Passwort-Hashes ab.

Dasselbe Konto stellte sich als Domänenadministrator heraus, genutzt für die tägliche Arbeit. Wir knackten sein Passwort offline auf unserer Crack-Maschine. Elf Zeichen, unter der eigenen Schwelle von vierzehn, also ging es schnell. Auf Domänenebene war das das Ende.

Mit den Rechten des Domänenadministrators dumpten wir vom Controller die gesamte Active-Directory-Passwortdatenbank. Über dreitausend Zugangsdaten-Sätze. Danach knackten wir sie offline, in Ruhe, ohne Druck durch Kontosperren. Jeder fünfte Hash fiel, genau 22 Prozent. Und zum Schluss die Pointe, für die wir gekommen waren: Ein Passwort wiederholte sich auf 158 Konten.

Der gesamte Weg in der Sprache von MITRE ATT&CK sieht so aus:

Die Mechanik des ersten Schritts lässt sich am leichtesten an einem vereinfachten Ablauf zeigen. Die Daten sind generisch, keine echten Namen, Adressen oder Zeiten:

# maszyna nie znajduje nazwy w DNS i pyta cały segment
[BROADCAST]  kto to jest "fileserv01"?
[NASZ HOST]  to ja, łącz się ze mną
[MASZYNA]    ok, uwierzytelniam się...  (NetNTLMv2)

# host docelowy nie wymusza podpisywania SMB,
# więc przechwyconą sesję przekazujemy dalej
[NASZ HOST] -> [inny host]   loguję się jako przechwycony użytkownik
[inny host]                  dostęp przyznany

Ergebnis

Vollständige Kompromittierung der Domäne aus der Position eines normalen Nutzers, ohne Zero-Day, in zwei Wochen, bei einem als kritisch bewerteten Risiko. Wenn ein Angreifer ein Konto des Domänenadministrators und die gesamte Passwortdatenbank vom Controller hat, bricht er nicht mehr in einzelne Systeme ein. Er bewegt sich durch die Organisation wie ein vertrauter Nutzer. Wiederverwendete Passwörter verwandeln einen einzigen Knack in Zugriff auf Dutzende Konten. Ein wiederverwendetes Passwort des lokalen Administrators sorgt dafür, dass die Übernahme einer Maschine die Übernahme der nächsten nach sich zieht.

Neben dieser Identitätsschicht schleppte die Umgebung eine zweite Altlast mit sich. Drei kritische und über hundert schwerwiegende Schwachstellen auf veralteten Versionen von Webservern, Krypto-Bibliotheken und Datenbankdiensten, dazu schwache TLS-Cipher-Suites. Jede davon ist ein eigener Vektor. Zusammen ergeben sie das Bild einer Umgebung, in der das Patchen mit der Wirklichkeit nicht mehr Schritt hielt.

Was dagegen zu tun ist, in abhakbarer Form:

• Deaktivieren Sie LLMNR und NBT-NS per GPO dort, wo sie nicht gebraucht werden, und blockieren Sie DHCPv6-Verkehr sowie Router-Advertisements, wenn IPv6 nicht im Einsatz ist. Das nimmt dem Angreifer den ersten Schritt, die kostenlosen Zugangsdaten aus dem Mithören.
• Erzwingen Sie die SMB-Signierung auf allen Arbeitsstationen und Servern. Ohne sie lässt sich eine abgefangene Session weiterreichen, und ein Knacken ist nicht einmal nötig.
• Trennen Sie administrative Konten von Konten für die tägliche Arbeit und führen Sie eine Verwaltung der Passwörter lokaler Administratoren ein, zum Beispiel LAPS, damit die Übernahme einer Maschine nicht die nächste öffnet.
• Erzwingen Sie bei jeder Änderung der Passwortrichtlinie einen Reset der bestehenden Passwörter. Eine Regel, die Konten von vor der Änderung nicht erfasst, schützt nur auf dem Papier.
• Erzwingen Sie die Einzigartigkeit der Passwörter über Systeme hinweg und heben Sie die tatsächliche Mindestlänge auf mindestens fünfzehn Zeichen an. Ein Passwort auf vielen Konten ist ein Geschenk an den Angreifer.
• Bringen Sie das Patchen in Ordnung: ein zentraler Prozess zur Aktualisierung von Systemen und Anwendungen, das Abschalten veralteter Protokolle und schwacher Cipher.
• Ergänzen Sie, wo möglich, Multi-Faktor-Authentifizierung und Segmentierung, um die Reichweite eines Man-in-the-Middle-Angriffs innerhalb eines Segments zu begrenzen.

Zum Schluss

Das Interessanteste an diesem Test ist, dass kein Schritt Zauberei war. Mithören, Weitergabe der Session, ein zu stark privilegiertes Konto, ein hundertfach wiederverwendetes Passwort. Jedes dieser Elemente wirkt harmlos, bis sie sich in einer Reihe aufstellen.

Die Frage zum Schluss ist also einfach. Wenn sich heute jemand an eine Dose in Ihrem Konferenzraum anschlösse und nur zuzuhören begänne, wie weit käme er?