Grundlagen

Pass-the-Hash-Angriffe

Mit einer erfolgreichen Pass-the-Hash-Attacke wird ein Angreifer leicht Administrator der Windows-Domäne. Doch weil es technisch sehr schwierig ist, Inhalte des Arbeitsspeichers zu verteidigen, gibt es für die seit mehr als zwei Jahrzehnten bekannte Sicherheitslücke keinen Patch, sondern nur Empfehlungen für eine bessere Organisation der IT. Der ursprünglich sehr aufwendige Pass-the-Hash-Attacke ist heute nur noch eine Sache weniger Klicks. Wir beleuchten die Grundlagen dieses Angriffsvektors.
Pass-the-the-Hash (PtH) ist nunmehr seit 25 Jahren als Angriffsvektor bekannt, doch ist die uralte Problematik praktisch über Nacht kritisch geworden, denn der Angriff war technisch gesehen vor 25 Jahren echte Raketenwissenschaft. Der Angriffshebel existierte zwar, dessen Einsatz war aber fern jeder Realität, da er vor allem im Vergleich zu anderen Angriffsmethoden zu schwierig umzusetzen war. Heute gibt es Werkzeuge wie mimikatz, pwdump und andere, die vor 20 Jahren nicht existierten.

Ein PtH-Angriff ist immer noch eine High-End-Technik, aber jetzt erlauben Werkzeuge, dass jedermann einen solchen Angriff mit wenigen Klicks durchführen kann. Das Level des benötigten Wissens ist mit diesen Tools extrem niedrig. Verraten wir gleich den besten Schutz vor Pass-the-Hash: die interne Organisation. Es gibt keine "Klick-Aus"-Lösung – abgesehen von Credential Guard (CG). Diesen gibt es ab Windows 10, allerdings nur in der Enterprise-Variante, und er erfordert die passende Hardware wie UEFI, TPM et cetera.

Viele Administratoren ziehen prinzipiell eine simple Software jeglichem organisatorischen Ansatz vor, andernfalls würde es ja bedeuten, dass sie 20 Jahre alte Gewohnheiten ändern müssten – der viel schwierigere Lösungsweg. Gegen Pass-the-Hash gibt es ein paar technische Hebel, die Sie in Bewegung setzen können und die kleine oder auch größere Hürden für den Angreifer generieren, aber am Ende ist alles eine Frage der Organisation.

Der Pass-the-Hash-Mechanismus

Warum Pass-the-Hash als enorm effektiver Angriff funktioniert, zeigt sich, wenn wir das Vorgehen skizzieren und einige technische Grundlagen klären. Windows speichert Benutzeranmeldekennworte als Hash, also als Prüfsumme und nicht im Klartext. Eine Ausnahme bildet hier der Fall, wenn der Administrator die Checkbox "Kennwort speichern" bei einer RDP-Verbindung über "mstsc.exe" aktiviert oder die Kennwortspeicherung für Outlook/Office365-Konten und Webkonten über die Anmeldeinformationsverwaltung (Anmeldetresor) nutzt.

Das ist eine andere Technik und ein anderes Problem, über das wir später noch reden. Doch zurück zum Standard: Nach Eingabe des Kennworts über ein Frontend, die Windows-Anmeldmaske oder auch interaktiv über den Explorer, wird beim Zugriff auf eine Ressource die Eingabe beziehungsweise deren Prüfsumme vom Ziel bestätigt und der Zugriff gewährt oder nicht. Das Ziel prüft und bestätigt also. Der Punkt, der uns jetzt unter anderem als Angriffsvektor dient, ist, wie die Quelle mit der Bestätigung des Ziels umgeht.

Microsoft ist als Single-Sign-on-System ausgelegt, die Eingabe eines Kennworts erfolgt also nur einmalig für die Laufzeit der Sitzung. Die einmalig als richtig bestätigte Information wird gespeichert und anschließend nicht mehr über eine Aktion des Anwenders hinterfragt und erneut angefordert. Die Quelle merkt sich, mit welcher gültigen Prüfsumme auf ein Ziel zugegriffen wurde. Bei jeder weiteren Interaktion mit dem Ziel fragt diese nach den Authentifizierungsdaten und sowohl Ziel als auch Quelle einigen sich darauf, dass die Kenntnis des Hashs völlig ausreicht. Die Übergabe erfolgt automatisch.

Die Logik dahinter ist, dass ein Anwender das Kennwort zuvor eingegeben hat, dieses als Hash berechnet und vom Ziel bestätigt wurde. Es ist also keine erneute Eingabe notwendig, denn der Anwender kennt in dieser Logik offensichtlich das Kennwort, sonst gäbe es auch keinen gültigen Hash. Wenn beide das Geheimnis, sprich Endergebnis, kennen, ist es gültig und sicher. Wir halten fest, dass das Ziel den Hash nur bestätigen muss und danach jegliche Information auf der Quelle liegt.

Alle Verbindungsinformationen liegen in deren Speicher. Hier kommt Pass-the-Hash ins Spiel, indem es nicht das Ziel angreift, sondern die Quelle. Es wird keine Kennwortattacke gefahren, in der Kennworte probiert werden, sondern es wird einfach direkt die Verbindungsinformation inklusive Hash ausgelesen, bei der der Angreifer schon weiß, dass diese Informationen funktionieren und gültig sind.

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.

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 Default-Konfiguration 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.

Ein ganz wichtiger Punkt an dieser Stelle: Der Administrator-Account ist nur das erste Angriffsziel, damit der Angreifer sich flächendeckend Systemzugriff verschaffen kann – auch dort, wo es den Admin- Account nicht als Benutzer gibt. 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.

Fazit

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. Welche technischen Maßnahmen sich zumindest als Bausteine zum Schutz vor Pass-the-Hash-Angriffen anbieten, erfahren Sie im Sonderheft I/2020 [1] ab Seite 98.
23.06.2020/Mark Heitbrink/dr

Nachrichten

Android-Smartphones gefährdet [7.08.2020]

Check Point hat nach eigenen Angaben mehrere Sicherheitslücken im Code von Qualcomms "Digital Signal Processor" (DSP) gefunden – einem Chip, der in fast 40 Prozent aller Smartphones weltweit verbaut ist. Sie sehen darin eine Bedrohung, die über Monate oder Jahre bestehen könnte, weil die Behebung kompliziert sei. [mehr]

Schwachstellen auf meetup.com entdeckt [6.08.2020]

Das Research Team von Checkmarx hat zwei Sicherheitslücken auf der Onlineplattform "meetup.com" entdeckt – einem Portal, um persönliche oder virtuelle Treffen zu organisieren. Mithilfe der Schwachstellen könne ein Angreifer sich bei Meetup-Events zunächst Co-Organisatorrechte sichern und dann Zahlungen der Teilnehmer auf beliebige PayPal-Konten umleiten. [mehr]

Tipps & Tools

SUSE übernimmt Rancher Labs [17.07.2020]

SUSE hat mit dem US-Open-Source-Unternehmen Rancher Labs den Anbieter einer marktführenden Kubernetes-Managementplattform akquiriert. Rancher Labs' Plattform ist für die Verwaltung sehr großer Kubernetes-Installationen ausgelegt und unterstützt dabei auch Multiclouds. [mehr]

vCenter-Zertifikat austauschen [7.06.2020]

Jede vCenter-Serverinstanz hat nach der Installation ein selbst ausgestelltes Zertifikat. Sobald die Website der vCSA aufgerufen wird, erscheint eine Warnung bezüglich der Sicherheit. Um dies zu verhindern, können Sie entweder das Root-Zertifikat herunterladen und in den vertrauenswürdigen Speicher installieren oder das Machine-Zertifikat gegen ein eigenes ersetzen. Unser Tipp zeigt, wie das funktioniert.  [mehr]

Buchbesprechung

Microsoft Office 365

von Markus Widl

Anzeigen