Eine Designschwäche sorgt dafür, dass die Passwortverschlüsselung in Windows keinen Effekt hat. ZDNet zeigt, wie Hacker mit frei zugänglichen Tools jeden Domänenserver in Unternehmensnetzen übernehmen können.
Wenn man unter einem fremden Benutzerkonto arbeiten möchte, ist die einfachste Möglichkeit, Benutzername und Kennwort zu kennen. Wer im Besitz solcher Zugangsdaten ist, braucht keine speziellen Kenntnisse, um sich einen Zugang zu verschaffen.
Eine Möglichkeit, an solche Zugangsdaten zu kommen, ist das Abhören von Leitungen mittels eines Netzwerksniffers. Allerdings sind die meisten Protokolle mittlerweile gegen ein Abhören abgesichert. Oft werden ältere Protokolle, die von sich aus keine Verschlüsselungstechnologie mitbringen, in SSL/TLS getunnelt.
Eine weitere Möglichkeit, an Benutzernamen und Kennwörter zu kommen, ist der Diebstahl von Passwortdatenbanken auf Servern. Das ist natürlich nicht so einfach wie das Abhören einer Leitung mit einem Sniffer. Die Datenbanken sind in der Regel gut gesichert.
Mit einer gut durchdachten Passwortdatenbank ist es einem Angreifer nicht möglich, sich unter einem fremden Benutzernamen anzumelden, denn Passwörter sind normalerweise nicht im Klartext oder reversibel verschlüsselt abgelegt.
Um derartigen Diebstählen vorzubeugen, werden Passwörter in der Regel als Hashwert abgespeichert. Aus dem Hashwert ist es nicht möglich, das ursprüngliche Passwort wieder zu ermitteln. Um ein Passwort auf Gültigkeit zu überprüfen, muss das vom Nutzer eingegebene Passwort in einen Hashwert umgewandelt werden. Diesen vergleicht man mit dem in der Datenbank hinterlegten Hashwert.
Auch Windows verwendet normalerweise eine Passwortdatenbank, die nur aus Hashwerten besteht. Allerdings hat Microsoft in seiner Implementierung eine Besonderheit eingebaut, die für Angriffe ausgenutzt werden kann: Die Umwandlung des Passwortes in den Hashwert geschieht auf dem Client und nicht auf dem Server.
Wenn man den Hashwert aus der Passwortdatenbank kennt, kann man diesen an einen Server schicken, um vorzutäuschen, ein anderer Benutzer zu sein. Diese Vorgehensweise bezeichnet man als Pass-the-Hash-Angriff.
In vielen anderen Situationen tritt das Problem nicht auf. Bei einer HTTPS-Sitzung wird beispielsweise das Klartextpasswort auf dem Übertragungsweg verschlüsselt und erst auf dem Server in den Hashwert umgewandelt. Ein Angreifer, der den Hashwert aus der Passwortdatenbank gestohlen hat, kann damit in einem Angriff von außen nichts anfangen.
Unter Windows gilt hingegen der Grundsatz: Der Hashwert des Passworts ist genauso gut zum Einloggen geeignet wie das Passwort selbst. Ein Angreifer muss dazu nur in der Lage sein, die richtigen Tools aus dem Internet herunterzuladen, was recht einfach ist. Schwieriger ist es die Passworthashes zu stehlen. Doch auch dazu bietet Windows Ansätze.
Bashar Ewaidar und Kristof Boeynaems haben im Januar 2010 für das SANS Institute[2] eine Bestandsaufnahme[3] (PDF) gemacht. Das Ergebnis ist ernüchternd: Zwar funktionieren viele Tools für die Durchführung von Pass-the-Hash-Angriffen und den Diebstahl von Passwortdatenbanken nicht mehr unter Windows Versionen ab Vista, jedoch ist das grundsätzliche Problem nicht behoben.
Darüber hinaus erzielt man mit gut gepflegten Penetrationstest-Suiten, beispielsweise dem Metasploit-Framework[4], nach wie vor sehr gute Ergebnisse gegen alle aktuellen Windows-Versionen wie Windows Server 2008 R2. Viele Antivirenlösungen melden die zahlreichen Proof-of-Concept- und Penetrationstesting-Tools als Malware, siehe Bild 1[5], so dass Angreifer sie nicht nutzen können.
Administratoren müssen jedoch bedenken, dass die meisten Tools im Sourcecode vorliegen, etwa das Pass-the-Hash-Toolkit[6]. Ein Angreifer muss das Tool nur neu kompilieren, um der Entdeckung durch ein Antivirenprogramm zu entgehen.
Um an Hashwerte von Passwörtern zu kommen gibt es mehrere Möglichkeiten. Wer lokale Adminrechte am Arbeitsplatz hat, kann die Passwortdatenbank des lokalen Rechners auslesen. Fehlen diese Rechte, so lässt sich sich Zugriff auf das Dateisystem verschaffen, indem man den Rechner mit einer eigenen Install-DVD von Windows 7 oder Vista bootet.
Das im Internet kursierende Tool pwdump6 leistet gute Dienste mit allen Windows-Versionen einschließlich Windows 7 und 2008 R2. Bild 3[7] zeigt, dass das Tool bereitwillig alle Hashwerte ausgibt. Es berücksichtigt den sogenannten SYSKEY, mit dem neuere Windows-Versionen die Password-Hashes zusätzlich verschlüsseln. Diese Verschlüsselung ist allerdings reversibel und der Key befindet sich im System-Hive der Registry. Die Ausgabe erfolgt im sogenannten Pwdump-Format, das im Wesentlichen mit der smbpasswd-Datenbank[8] von Samba identisch ist.
Das Tool pwdump7 kann auch offline arbeiten, das heißt, wenn ein Rechner von einer Install-DVD gebootet wurde. Es kommt jedoch nur mit Windows-Versionen bis einschließlich XP zurecht.
Bild 3[7] zeigt ferner, dass für jeden Benutzer zwei Hashwerte existieren. Der erste ist der sogenannte LM-Hash, der primär aus Gründen der Rückwärtskompatibilität zu Windows 95 und 98 genutzt wird. Standardmäßig wird er nicht mehr verwendet, da er grundsätzliche kryptologische Schwächen aufweist. Der zweite ist der sogenannte NTLM-Hash, der manchmal auch NT-Hash genannt wird. Er wird in aktuellen Windows-Versionen verwendet.
Man erkennt, dass die Benutzer Administrator, christoh und named dasselbe Passwort haben, da der Hashwert ebenfalls identisch ist. Der NTLM-Hash ist nicht mit einem Salt[9] versehen, wie man an Bild 4[10] erkennen kann. Es zeigt die smbpasswd-Datenbank eines Samba-Rechners. Die Benutzer root, christoh, www-data und bind besitzen dasselbe Passwort wie auf dem Windows-Rechner. Die Hashwerte auf dem Windows- und auf dem Samba-Rechner sind daher ebenfalls identisch.
Viele Administratoren richten sich auf den Arbeitsplatzrechnern der Mitarbeiter ein Administratoraccount mit demselben Kennwort ein, das auch das Domänen-Administratorkonto besitzt. In diesem Fall kann ein Mitarbeiter die lokale Benutzerdatenbank verwenden, um Domain-Administrator zu werden.
Wesentlich gefährlicher sind die sogenannten gecachten Domain-Accounts: Damit man sich auch dann auf einem mobilen Rechner anmelden kann, wenn man nicht im Firmennetzwerk ist, merkt sich Windows die Hashwerte von Domänen-Konten in der lokalen Registry. Ein Angreifer muss also nur den Administrator dazu bewegen, sich auf seinem Rechner einzuloggen, beispielsweise indem er einen Support-Fall vortäuscht. Danach kann der Mitarbeiter den Hashwert des Domänen-Administrator-Passworts auslesen - notfalls durch ein Boot-Medium.
Im Internet kursieren weitere Tools, die durchaus kreative Ansätze zu bieten haben. Das Tool whosthere.exe aus dem Pass-the-Hash-Toolkit klinkt sich in den Prozess lsass.exe[11] ein und liest die Hashwerte aller Passwörter von allen eingeloggten Benutzern aus. Dieses Program nutzen häufig Administratoren von einzelnen Servern oder Unterdomänen, deren Administrationsrechte nicht firmenweit gelten.
Mit whosthere.exe müssen sie nur darauf warten, dass sich ein globaler Unternehmensadministrator einloggt, beispielsweise über die Remote-Desktop-Services. Dann können sie ihre Befugnisse durch Diebstahl des Passwort-Hashwerts eines höheren Administrators erweitern. whosthere.exe funktioniert allerdings nicht mit Windows Versionen ab Vista. Windows Server 2008 lässt sich also auf diese Weise nicht ausspionieren.
Wenn ein Angreifer Passwort-Hashwerte gestohlen hat, muss er diese nur noch mit den richtigen Tools einsetzen. Bis einschließlich Windows XP SP3 ist dazu iam.exe aus dem Pass-The-Hash-Toolkit gut geeignet. Wie whosthere.exe klinkt es sich in den Prozess lsass.exe ein. Auf diese Weise tauscht man seine NTLM-Sitzungsauthentifizierung einfach gegen die eines Administrators aus.
Ab Windows Vista hat Microsoft die Nutzung von iam.exe unterbunden. Der Hashwert des Passworts liegt nicht mehr unverschlüsselt im Prozessspeicher von lsass.exe. Dabei wird allerdings nur die Nutzung des spezifischen Tools iam.exe verhindert. Das Prinzip funktioniert weiterhin. Durch Reverse Engineering neuerer Windows-Versionen ließe sich auch ein neues Tool herstellen.
Derzeit kann man unter Windows ab Vista das Metasploit-Framework für Pass-the-Hash-Angriffe einsetzen. Es besitzt einen PsExec-Exploit, der nach dem Sysinternals-Tool PsExec[12] von Microsoft benannt ist. Der wesentliche Unterschied zum Original besteht darin, dass der PsExec-Exploit die komplette NTLM-Authentifizierung mit eigenem Code emuliert und keine Windows-Systemcalls benutzt.
Das erlaubt, dass der Exploit nicht nur Klartextpasswörter, sondern auch Hashwerte akzeptieren kann, siehe Bild 5[13]. Metasploit kann auf Windows- und Unix-Rechnern ausgeführt werden. Der PsExec-Exploit kann gegen jede Windows-Version, inklusive Windows Server 2008 R2, gefahren werden. Man kann ihm einen beliebigen Payload aus dem Metasploit-Framework mitgeben. Besonders gut geeignet ist Meterpreter[14] (PDF).
Bild 5 zeigt außerdem, dass ein Angreifer, der nur einen Passwort-Hash besitzt, sich mit dem Meterpreter-Kommando hashdump alle weiteren Hashwerte besorgen kann. Neben weiteren nützlichen Befehlen, ist vor allem das Kommando execute von Interesse. Damit lassen sich beliebige Programme ausführen, beispielsweise die Kommando-Shell cmd.exe, siehe Bild 7[15]. Die Anweisung whoami zeigt, dass der Angreifer unter dem SYSTEM-Account auf dem fremden Rechner arbeitet und somit alle Rechte hat.
Windows-Versionen ab NT 4.0 SP4 verwenden neben der NTLM- die NTLMv2-Authentifizierung. Sie unterscheidet sich von NTLM dadurch, dass beim Austausch der Passwort-Hashes nicht nur eine Server-Challenge, sondern auch eine Client-Challenge eingesetzt wird. Ferner wird ein Zeitstempel verwendet, damit Replay-Angriffe ausgeschlossen sind. Beide Authentifizierungsmechanismen nutzen jedoch denselben NTLM-Hashwert.
Windows Versionen ab Vista authentifizieren sich nicht mehr mit NTLM, sondern nur noch mit NTLMv2. Allerdings akzeptieren sie aus Kompatibilitätsgründen auch noch LM und NTLM. Diese Einstellung lässt sich zwar ändern, so dass alle Rechner im Netzwerk NTLMv2 beherrschen müssen, jedoch wird davon kaum Gebrauch gemacht.
Der PsExec-Exploit im aktuellen Metasploit-Framework 3.3.3 arbeitet nur mit NTLM. Er ließe sich jedoch leicht auf NTLMv2 erweitern. In der Feature-Liste für die Version 3.4 steht NTLMv2-Support derzeit mit der Priorität "Medium", da kein ernsthafter Bedarf daran bestehe. NTLMv2-Support für den PsExec-Exploit ist im Wesentlichen eine Fleißarbeit.
Administratoren, die ihre Netze auf NTLMv2-only umstellen, können zwar derzeit Pass-the-Hash-Attacken mit dem Metasploit-Frameworks verhindern, sind aber nicht grundsätzlich dagegen geschützt. Sie riskieren dabei auch Inkompatibilitäten mit manchen Linux- und Mac-OS-Rechnern.
Windows ist grundsätzlich anfällig für Pass-the-Hash-Angriffe. Das liegt an einer Designschwäche der LM- und NTLM-Authentifizierung, die vorschreibt, dass das Klartextpasswort auf dem Client in einen Hashwert umgewandelt wird, der mit dem Hashwert der Passwortdatenbank auf dem Server verglichen wird.
Auch die neueste Variante der Windows-Authentifizierung NTLMv2 schützt nicht vor diesen Angriffen, sondern lediglich gegen Angriffe mit Rainbow-Tabellen und Replay-Attacken. Der einzige Schutz, den NTLMv2 bei Pass-the-Hash-Angriffen derzeit bietet, besteht darin, dass viele fertige, für jedermann einsetzbare Hackertools nicht mehr funktionieren.
Um eine Pass-the-Hash-Attacke durchzuführen, muss der Angreifer Hashwerte von Administratorkonten stehlen. Die sind zwar nicht einfach zugänglich, lassen sich aber unter bestimmten Bedingungen, die in Firmennetzen meist erfüllt sind, von normalen Domänenbenutzern beschaffen.
Auf einem Arbeitsplatzrechner, auf dem ein Benutzer Admin-Rechte hat oder den er mit einem Boot-Medium starten kann, reicht es normalerweise aus, einen Administrator dazu zu bringen, sich einmal auf dem Arbeitsplatzrechner einzuloggen. Dann ist der Hashwert des Administratorpassworts auf dem lokalen Rechner gecacht.
Natürlich gibt es Möglichkeiten, sich vor dem Passwortdiebstahl zu schützen. Ein Unternehmen, das Notebooks für mobile Nutzer einsetzt und damit auf Passwort-Caching angewiesen ist, kann beispielsweise lokale Administratorkonten auf jedem Rechner definieren. Dabei muss jedoch jeder Arbeitsplatzrechner ein eigenes Passwort haben. Mit diesem Passwort kann sich ein Administrator im Bedarfsfall lokal anmelden.
Solche Sicherheitsrichtlinien führen jedoch zu einem sehr hohen Verwaltungsaufwand. Hinzu kommt, dass Passwort-Caching nur eine von vielen Methoden ist, um an Passwort-Hashwerte von Administratorkonten zu kommen. Einen hundertprozentigen Schutz gegen Pass-the-Hash-Angriffe kann es nur geben, wenn Microsoft in kommenden Windows-Version das grundsätzliche Authentifizierungsverfahren ändert.
URLs in diesem Artikel:
[1] = http:/
[2] = http:/
[3] = http:/
[4] = http:/
[5] = http:/
[6] = http:/
[7] = http:/
[8] = http:/
[9] = http:/
[10] = http:/
[11] = http:/
[12] = http:/
[13] = http:/
[14] = http:/
[15] = http:/