Schon wieder gibt es ein ernstes Leck in Windows. Mit einer im Internet verfügbaren Datei kann sich jeder mit einem Mausklick zum Administrator machen. ZDNet zeigt, wie der Exploit funktioniert und welche Abwehrstrategien möglich sind.
Am Dienstag veröffentlichte Tavis Ormandy von Neohapsis[1] einen Exploit[2] für alle 32-Bit-Versionen von Windows. Dabei handelt es sich um eine der gefährlichsten Sicherheitslücken, die bisher für das Microsoft-Betriebssystem aufgetaucht sind. Getestet hat Ormandy sein Programm mit Windows XP, 2003, 7 und 2008. Unter Windows NT 3.1 bis 4.0 und 2000 müsste es jedoch ebenfalls funktionieren.
Die Software setzt sämtliche Sicherheitsmechanismen auf dem lokalen Rechner außer Kraft und gefährdet die Netzwerksicherheit in vielen Windows-Domänen-Netzwerken, wie sie in Unternehmen, Behörden und Regierungen genutzt werden. Ein normaler Benutzer, der an seinem Arbeitsplatz eine beliebige 32-Bit-Windows-Version hat, kann damit jede Identität von Benutzern aus einer Active-Directory-Domäne annehmen.
Das Gefährliche an dieser Lücke ist, dass der Angreifer weder spezielle Kenntnisse benötigt, noch besondere Voraussetzungen vorliegen müssen. Ormandy hat seinen Exploit lückenlos dokumentiert und neben dem Sourcecode auch eine ausführbare Datei erstellt, die man nur herunterladen und anklicken muss. Besonders gefährdet sind Unternehmen, die einen Terminalserverzugang auf einem 32-Bit-Rechner für Mitarbeiter zulassen.
Ein Mitarbeiter, der bereit ist, seine Zugangsdaten wie Password oder Smartcard einem Dritten, eventuell gegen Bargeld, zu überlassen, gewährt diesem einen vollständigen Administratorzugang zu allen Rechnern, auf denen er sich mit entferntem oder lokalem Desktopzugang einloggen kann.
Möglich wird der Angriff durch eine Lücke in der virtuellen DOS-Maschine[3] (NTVDM), die in den 32-Bit-Versionen von Windows standardmäßig aktiviert ist. Die NTVDM führt DOS- und 16-Bit-Anwendungen aus. In 64-Bit-Versionen von Windows ist keine NTVDM vorhanden, da AMD und Intel entschieden haben, im 64-Bit-Betrieb ihrer Prozessoren keinen virtuellen 8086-Mode mehr zu implementieren, um sich von unnötigem Ballast bezüglich der Rückwärtskompatibilität zu befreien.
Normalerweise benötigt man heutzutage keine DOS- und 16-Bit-Anwendungen für die tägliche Arbeit mehr. Der Hauptgrund für das Fortbestehen der NTVDM liegt darin, dass einige 32-Bit-Applikationen einen 16-Bit-Installer verwenden. Diese Programme lassen sich auf 64-Bit-Versionen von Windows nicht automatisch installieren.
Bildergalerie
Adminrechte per Mausklick: So einfach funktioniert der VDM-Exploit[4]
» zur Bildergalerie ...[4]Der System-Account[6] ist das höchste Benutzerkonto auf einem Windows-Rechner. Es hat wesentlich mehr Rechte als das Administrator-Konto.
Microsoft beschränkt diese allerdings auf den lokalen Rechner. Versucht man mit dem System-Account auf einen anderen Rechner zuzugreifen, schlägt das automatisch fehl. Das heißt, die unmittelbare Gefahr liegt darin, dass Benutzer sich auf ihrem Arbeitsplatzrechner Administratorrechte verschaffen können, auch wenn das vom Administrator nicht gewünscht ist.
Allerdings ist es in Domänen-Netzen normalerweise möglich, sich auf jedem Arbeitsplatzrechner anzumelden, beispielsweise auf dem Rechner eines Kollegen, der Urlaub hat oder in der Mittagspause ist. Administratoren, die sicherstellen wollen, dass ein Einloggen auf einem Rechner nur dem Konto des Besitzers erfolgen kann, müssen das für jeden Rechner einzeln konfigurieren. Da das einen hohen Verwaltungsaufwand erfordert, verzichten die meisten darauf.
Grundsätzlich ist es kein Sicherheitsproblem, wenn sich auch andere normale Benutzer an einem Rechner anmelden können. Ein Zugriff auf die Dateien im Benutzerverzeichnis des Besitzers ist damit nicht möglich.
Wer jedoch anschließend vdmallowed.exe von einem USB-Stick anklickt, hat über den System-Account normalerweise Vollzugriff auf alle Dateien der lokalen Festplatte. Wenn das nicht der Fall ist, lassen sich die Zugriffsberechtigungen mit dem System-Account nach Belieben ändern.
Besonders gefährdet sind 32-Bit-Terminalserver, auf die sich normale Benutzer intern oder über das Internet anmelden können. Sie werden meist von vielen Anwendern genutzt, häufig auch von Top-Managern, die Zugang zu vertraulichen Daten haben und diese möglicherweise dort lokal abspeichern.
Mit einer guten Überwachung ist ein Angriff mit dem VDM-Exploit leicht zu entdecken. Ein Administrator wird schnell Verdacht schöpfen, wenn Prozesse wie winword.exe, outlook.exe oder explorer.exe unter dem System-Account laufen.
Generell bieten sich für einen Angreifer zwei Strategien an. Eine davon ist, sein eigenes Benutzerkonto in die lokale Administratorengruppe aufzunehmen. Das lässt sich beispielsweise aus der Konsole mit dem Befehl net localgroup administrators <[Domainname\]Benutzername> /add erreichen.
Wenn der Terminalserver kein Domaincontroller ist, wird das nur in der lokalen SAM-Datenbank[7] gespeichert. In der Active-Directory-Datenbank ist nichts Verdächtiges zu finden. Danach kann der Angreifer die System-Konsole wieder schließen und unter seinem Account mit Administratorrechten arbeiten. Der Angreifer kann darauf hoffen, dass die wenigen Sekunden, in denen cmd.exe unter dem System-Account lief, nicht entdeckt werden.
Für den Fall, dass die lokale Administratorgruppe regelmäßig auf verdächtige Neuzugänge überprüft wird, bietet sich die zweite Strategie an, vom System-Account aus direkt eine fremde Identität anzunehmen. Das ist ohne eine Prüfung von Credentials möglich, etwa Kennwort, Fingerabdruck, oder Smartcard.
Es ist nicht nur möglich, die Identität lokaler Benutzerkonten anzunehmen, sondern auch die aller Accounts eines Windows-Domänen-Forests. Mit einer System-Konsole, wie in Bild 1[5] gezeigt, lässt sich ein Zugang zu jedem weiterem Konto schaffen.
Der erste Test von ZDNet mit dem in neueren Windows-Versionen vorhandenen Befehl runas (ausführen als) schlägt jedoch fehl. Beim Versuch, die Identität eines fremden Benutzers anzunehmen, fragt das Tool nach seinem Passwort, siehe Bild 2[8].
Das liegt aber nur daran, dass das Programm runas.exe nicht prüft, ob es auch ohne Eingabe des Passworts die fremde Identität annehmen kann. Normalerweise ist es nämlich gar nicht möglich, sich unter dem System-Konto anzumelden.
Die Auswahl an quelloffenen Runas-Tools ist groß. ZDNet entscheidet sich für den Posix-API-Layer Cygwin[9]. Darin enthalten sind sämtliche GNU-Tools, unter anderem das von Unix bekannte su[10].
Das Ergebnis ist zunächst wieder enttäuschend, siehe Bild 3[11]. Der erneute Aufruf von whoami ergibt, dass die Konsole nach wie vor unter dem System-Account arbeitet. Einige Nachforschungen zeigen, dass Microsoft die Sicherheit im Laufe der Zeit immer weiter "erhöht" hat. So kann man vom Account System ohne Identitätsprüfung nur zu einem anderen Account wechseln, der lokale Administratorrechte hat.
Das lässt sich unter dem System-Account jedoch leicht bewerkstelligen. Mit dem bereits genannten Befehl net localgroup administrators <[domainname\]username> /add erteilt man dem Konto, unter dessen Identität man arbeiten möchte, kurzfristig die notwendigen Rechte. Sobald man unter dem fremden Account arbeitet, lassen sich die Rechte wieder entziehen. Der Angreifer kann jedoch solange mit dem fremden Konto arbeiten, wie er möchte, siehe Bild 4[12].
Da der Angriff auf ausnahmslos alle Benutzerkonten geführt werden kann, bieten sich neben dem eigenen Chef etwa Mitarbeiter der Gehaltsbuchhaltung oder Konten mit netzwerkweiten Administratorrechten an. Allerdings kann der Angreifer nur darauf hoffen, dass er vertrauliche Daten auf dem Rechner findet, auf dem er sich eingeloggt hat. Netzwerkzugriffe sind nicht möglich, da er keine gültigen Netzwerkcredentials besitzt, beispielweise ein Kerberos-Ticket[13] oder ein NTLM-Token[14].
Gefährlich sind Szenarien, bei denen Anwendungen Kopien von Teilen geöffneter Dokumente im Temp-Verzeichnis speichern. Die kann ein Angreifer leicht auslesen. Da das Temp-Verzeichnis in der Standardeinstellung auf einem Terminalserver beim Abmelden gelöscht wird, muss der Angreifer sich gleichzeitig mit dem auszuspionierenden Benutzer anmelden.
Eine bedrohliche Situation entsteht auch, wenn Terminalserver als Zugang zu E-Mail eingesetzt werden, da man einem Webmail-Zugang wie OWA nicht traut, weil sich Benutzer aus einem Internetcafé nicht korrekt abmelden. Wenn auf einem Terminalserver lokale E-Mail-Dateien liegen, etwa eine Outlook-OST-Datei, ist sie durch Ausnutzung des VDM-Exploits stark gefährdet.
Die Sicherheitslücke ist ohne die Abschaltung des 8086-Emulationsmodus nicht zu schließen. Der Real-Mode des 8086 hat keinen Speicherschutz. Daher muss eine Emulation so programmiert sein, dass innerhalb des 20-Bit-Adressraums einer virtuellen 80x86-Maschine keine Prüfung auf Speicherzugriffsrechte stattfindet. Zudem muss das feste Adressierungsschema des 8086 Speicheradresse = Segmentregister * 16 + Offsetregister exakt im Adressraum des Protected Mode abgebildet werden. Somit können Entwickler Ring3-Code nur den Vollzugriff auf den gesamten Adressraum der virtuellen 8086-Maschine geben.
Grundsätzlich lässt sich der DOS- und 16-Bit-Windows-Emulationsmodus abschalten, indem man den DWORD-Wert VDMDisallowed im Registry-Key HKEY_LOCAL_MACHINE\
Da der Exploit ohne tiefe Kenntnisse ausgenutzt werden kann, sollte man vorher prüfen, ob sich nicht bereits Benutzer in die lokale Administratorgruppe hinzugefügt haben. Diese Prüfung muss für jeden 32-Bit-Arbeitsplatz durchgeführt werden.
Ferner ist zu bedenken, dass vor allem Laptop-Nutzer die Möglichkeit haben, den VDMDisallowed-Parameter in der Registry wieder auf null zu setzen. Dazu benötigen sie nur eine Installations-DVD ab Windows Vista. Dann können sie den Software-Hive im Verzeichnis C:\Windows\System32\config im Registry-Editor laden und ändern.
Nach der Änderung loggt man sich ohne Netzwerkverbindung ein. Das stellt sicher, dass eine eventuelle Group-Policy nicht greift. Erst wenn der Nutzer die Konsole des System-Kontos geöffnet hat, verbindet er sich mit dem Firmennetz.
Gegen Registry-Manipulationen mit einem Boot-Medium schützt nur eine Festplattenverschlüsselung wie Bitlocker. Neben der genannten Registry-Manipulation gibt es seit vielen Jahren fertige Registry-Manipulationstools, die direkt die SAM modifizieren und so Administratorrechte verschaffen. Dazu gehört beispielsweise ntpasswd[15].
Der von Tavis Ormandy am Dienstag veröffentlichte Exploit verschafft jedem Benutzer Admin-Rechte auf 32-Bit-Windows-Rechnern, auf denen er sich interaktiv einloggen kann. Dazu gehören in der Regel Arbeitsplatzrechner, aber auch Terminalserver, die von Mitarbeitern genutzt werden.
Ein Operator, der sich auf einem Domain-Controller mit relativ geringen Rechten anmelden darf, etwa als Mitglied der Gruppe Print Operators, kann sich leicht zu einem Volladministrator machen und mit entsprechenden Tools das Active Directory manipulieren.
Die Gefahr liegt vor allem darin, dass Ormandy eine EXE- und eine DLL-Datei im Internet veröffentlicht hat. Diese Dateien muss ein Angreifer nur in ein beliebiges Verzeichnis kopieren und anklicken. Spezialkenntnisse sind nicht erforderlich.
Die Lücke basiert auf der Funktionsweise des virtuellen 8086-Modus und ist nicht zu schließen. Zwar lassen sich Veränderungen vornehmen, das der derzeit kursierende Exploit nicht mehr funktioniert, das grundlegende Problem liegt jedoch in der Hardware-Implementierung des virtuellen 8086-Modus, so dass neue Exploits geschrieben werden können.
Abhilfe schaffen nur die Installation einer 64-Bit-Version von Windows oder das Abschalten des virtuellen 8086-Modus, der dazu benötigt wird, DOS- und 16-Bit-Windows-Anwendungen auszuführen. In der Regel kann man darauf jedoch verzichten.
Vorsicht ist geboten, wenn ein Nutzer physischen Zugang zu einem Rechner hat, beispielsweise mobile Anwender mit einem Laptop. Dann kann er das VDM-Verbot in der Registry wieder aufheben. Da es zahlreiche Möglichkeiten gibt, die Registry und die SAM mit einem Boot-Medium zu manipulieren, sollten sicherheitsbewusste Firmen über die Einführung einer Festplattenverschlüsselung wie Bitlocker nachdenken.
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:/