Lesezeit
3 Minuten
Seite 2 - Pass-the-Hash-Angriffe vermeiden (1)
Auch alte Hashes auslesbar
Es geht aber noch einen Schritt weiter: Das Perfide an PtH ist, dass alle Hashes aller Kombinationen von Benutzer und Kennwort der Anwender gespeichert werden, die sich an diesem Rechner anmelden. Neben den flüchtigen, sitzungsbasierten Informationen gibt es statische Informationen. Bei jedem Zugriff von einem Domänenrechner auf einen Workgroup-Rechner wird jedes Mal wieder nach dem Kennwort gefragt, sobald der User sich einmal abgemeldet hat. Diese Verbindungsdaten sind sitzungsbasiert.
Logischerweise gilt das auch für den Zugriff auf eine Ressource innerhalb der Domäne, der Unterschied zur Workgroup ist nur, dass Benutzername und Kennwort beim ersten Zugriff automatisch übergeben und in der Regel direkt bestätigt werden, sodass der Dialog unterdrückt wird.
Bild 1: Tools wie mimikatz machen aus dem komplexen Pash-the-Hash-Angriff eine Angelegenheit weniger Mausklicks.
Wer als Benutzer das Häkchen bei "Kennwort speichern" aus Komfortgründen setzt, hat soeben aus einer flüchtigen eine statische Information gemacht. Statisch sind alle Benutzername/Kennwortkombinationen der lokalen Benutzer eines Rechners. Das sind in der Regel der Administrator oder ein alternativ eingerichteter "LocalAdm", aber auch die Cached Credentials einer Domäne. Per DefaultKonfiguration werden die zehn Konten, die sich zuletzt angemeldet haben, und deren Hashes lokal gespeichert, damit eine Offline-Anmeldung ohne den Domänencontroller (DC) zur Bestätigung erfolgen kann. Bei Anmeldung der elften Kennung fällt die älteste heraus.
Wer als Angreifer Zugriff auf das System und diesen Teil der Sicherheitsinformationen hat, kann diese auslesen und weiterverwenden. Das ist der "Pass", die Weiterverwendung/Weitergabe des Hashes. Jetzt wird es etwas unangenehm für Microsoft, denn dessen Entwickler haben vor 25 Jahren nicht daran gedacht, dass jemand schlau genug ist, den Speicher selber zu schreiben. Das ist der zuvor genannte "ein Schritt weiter": Es werden nicht nur die Hashes gelesen, mit denen ein Angreifer nicht direkt etwas anfangen kann (Stichwort: Rainbow Tables), sondern die notwendigen Einträge selbst erzeugt.
Die Angriffswerkzeuge lesen im ersten Schritt alle interessanten Hashes aus und dann erzeugen sie selbstständig den Eintrag im Speicher, in dem vermerkt ist, mit welcher Kombination von Benutzernamen und Hash auf ein Ziel zugegriffen werden kann. Das ist trivial und effizient. Ziel und Quelle gehen davon aus, dass diese Kombination nur im Speicher existiert, weil jemand das Kennwort eingetippt hat. Sonst gäbe es den Eintrag nicht. Da er existiert, ist er logischerweise ordentlich entstanden. Diese Fehleinschätzung nutzt Pass-the-Hash. Tools wie "mimikatz" erzeugen einen Eintrag, der alles Notwendige enthält, und so gibt es keine weitere Anfrage nach Authentifizierung.
Admin-Account nur erste Anlaufstelle
Es gibt nur eine einzige Hürde im aktuellen System: Der Angriff benötigt zwingend Vollzugriff auf das System. Der Angreifer muss in der Gruppe der lokalen Administratoren sein oder als System agieren. Grundsätzlich lassen sich aber zunächst einmal die größten Einfallstore für PtH definieren, die wir uns später im Detail ansehen werden:
- Administrator werden ist trivial.
- Das Lokale Admin-Konto ist aktiv.
- Der Administrator hat aus Deployment-Gründen auf jedem Rechner dasselbe Kennwort.
- Clients dürfen miteinander reden.
- Es melden sich sensible Konten an unsicheren Rechnern an.
- Es gibt viel zu viele Konten.
Dabei sollten Sie aber unbedingt bedenken, dass der Hash-Diebstahl eines "normalen" Benutzers, der vielleicht Mitglied Ihrer Forschungs- und Entwicklungsabteilung ist, sicherlich das viel kritischere Ziel darstellt. Beziehungsweise sind diese Accounts genau das, wonach ein Angreifer sucht, nachdem er sich zum Administrator gemacht hat. Dort liegen schließlich die wirklich spannenden Informationen einer Firma. Kaputtmachen und Zerstören ist einfach als Admin, mehr Geld wird aber mit Daten generiert. Angreifer nisten sich in das System ein, tauchen geduldig unter, verhindern mit allen Mitteln aufzufallen und verschwinden dann still und heimlich wieder.
Es gibt keine technische Lösung für das Problem, weil keine Technik der Welt einen Keylogger oder andere Werkzeuge blockieren kann, sobald jemand physischen Zugriff auf den Rechner hat. Die Lösung ist organisatorisch und umfasst Prozesse zur Reduktion der Angriffsfläche. Der angesprochene Credential Guard verhindert den Zugriff auf die Hashes. Vereinfacht dargestellt versteckt CG die Hashes in einer virtuellen Umgebung und stellt einen Türsteher davor. Dieser prüft jegliche Anfrage nach Information und erlaubt überhaupt nur Anfragen von Microsoft-zertifizierten Mechanismen. Die anfragende Datei benötigt ein spezielles Zertifikat von Microsoft und selbst dann wird der Hash niemals herausgegeben, sondern CG übergibt die Informationen an das Ziel. Diese Methode kann die Authentifizierung nur initiieren und erhält im Erfolgsfall eine Bestätigung, aber niemals den Hash. Der Job wird in einer sicheren Umgebung ausgeführt, bietet aber keinerlei Schutz vor Keyloggern oder schlechten Kennworten.
Seite 1: Der Pass-the-Hash-Mechanismus
Seite 2: Admin-Account nur erste Anlaufstelle
Im zweiten Teil der Workshopserie veranschaulichen wir, warum Angreifer sich im Handumdrehen als Administrator ausgeben können und warum identische Kennworte tunlichst zu vermeiden sind. Im dritten und letzten Teil geht es unter anderem darum, warum sie überflüssiges Clientgeschwätz abschalten und generell die Anzahl der Konten reduzieren sollten.
<< Vorherige Seite | Seite 2 von 2 |
jp/ln/Mark Heitbrink