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 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.
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. Darin enthalten sind sämtliche GNU-Tools, unter anderem das von Unix bekannte su.
Das Ergebnis ist zunächst wieder enttäuschend, siehe Bild 3. 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.
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 oder ein NTLM-Token.
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.
Neueste Kommentare
7 Kommentare zu Adminrechte per Mausklick: gefährliche Lücke in Windows
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
Download?
Ich habe zu Testzwecken versucht die exe/dll-Dateien von verschiedenen Sites runterzuladen. GData sagt: niet! Es braucht offensichtlich ein beachtliches Mass krimineller Energie um diese Lücke auszunützen und ich denke diese Energie würde auch unixoide 32-bit Systeme problemlos aushebeln.
Grundsätzlich kein Risiko für Privat-User,
weil nur ein am PC angemeldeter User das Programm starten und sich höhere Rechte verschaffen kann. Allerdings kann ein User im Firmennetzwerk sich damit u.U. Zugang zu für ihn gesperrten Informationen verschaffen oder Schlimmstenfalls auch gezielt Schaden anrichten.
Artikel von Herrn Hochstaetter
Es waere wuenschenswert, wenn im Artikel zu Beginn explizit darauf hingewiesen wuerde, dass jeder Nutzer zu Hause von der Windows-Luecke NICHT betroffen ist.
Der Hacker muss lokal angemeldet sein, wenn er die Luecke ausnutzen will, wie man spaeter erfaehrt.
Alle anderen muessten die Bootpartition verschluesseln, um ganz sicher zu sein, da sonst die Registry mittels CD wieder manipuliert werden kann.
Tom
Wer booten vom Rechner zuläßt, geht immer ein Sicherheitsrisiko ein.
Das man mit einem Bootmedium alle Dateien auf einem Rechner auslesen kann, ist nicht neu. Insofern liegt hierin auch keine neue Bedrohung.
Wer seine Rechner absichern will kann das jedoch im Bios verhindern und somit das auslesen der lokalen Dateien zumindest erschweren. Zugleich verhindert er auch Änderungen in der Regestry.
Thomas Hoffmann
AW: Wer booten vom Rechner zuläßt, geht immer ein Sicherheitsrisiko ein.
Was hat das Problem mit Booten zu tun? Das ist doch gar nicht nötig.
Netzwerkzugriff geht ja nicht.
Da ein Zugriff aufs Netzwerk über diese Exploit nicht möglich ist, muss man vor der lokalen Kiste sitzen und sich wohl zumindest als GUEST anmelden. Da nützt es schon, den PC mit BIOS Passwort zu schützen, vorausgesetzt man vergisst das herunterfahren nicht.
Biometrische Kennungen kann das ebenfalls nicht aushebeln.
AW: Netzwerkzugriff geht ja nicht.
Das schon, nur ist das in meinen Augen ein paralleles Problem. Die hier geschilderte Problematik funktioniert auch mit BIOS Paßtwort und Bootmöglichkeit. Und in größeren Netzwerken kann man sich auch über das Netz verbreiten, weil größere Netzwerke i.d.R. einige Rechner aufweisen, auf denen sich jeder anmelden kann mit seinem Account.