daily.out
2009-03-21
Windows 7: Weiße Liste ermöglicht stille Rechte-Erhöhung für Schadprogramme
Die Situation
Achtung: Dieses Thema hat nichts zu tun mit dem ähnlich klingenden "Windows 7: UAC broken by design". Dort geht es um die stille Änderung der Sicherheits-Einstellungen und hier geht es um die Einschleusung von Code in whitelisted Programme.
Wenn man auf Windows 7 in Werkseinstellung arbeitet, was den Benutzer und die UAC angeht, dann wird Schadprogrammen das System auf einem silbernen Tablett serviert, weil die Integritätsstufen, die darauf aufbauende UAC und auch der vermeintlich eingeschränkte Internet Explorer kein Hindernis mehr darstellen, um von einem unprivilegierten Prozeß aus Systemrechte zu erlangen. Damit ist die gesamte UAC praktisch wertlos, beziehungsweise für die Sicherheit nutzlose Augenwischerei.
Long Zheng beschreibt, wie Schadprogramme im Rucksack mitlaufen: Second Windows 7 beta UAC security flaw: malware can silently self-elevate with default UAC policy
Leo Davidson zeigt, wie der Angriff funktioniert: Windows 7 UAC whitelist: Code-injection Vulnerability (and more)
Ein "kaputtes Gefrickel" urteilt ars technica: Opinion: Windows 7's UAC is a broken mess; mend it or end it
Die weiße Liste
Mit Windows 7 wurde eine weiße Liste von Programmen eingeführt, denen eine stille Rechte-Erhöhung erlaubt ist. Diese Liste ist nicht konfigurierbar und fest einprogrammiert.
Die weiße Liste besteht offenbar aus drei Teillisten:
Die erste Kategorie der aufgeführten Programme löst keine UAC-Abfrage aus, wenn sie die erhöhten Administrator-Rechte, die vollen Systemzugriff bedeuten, nutzen wollen.
Die zweite Kategorie legt fest, daß anscheinend alle mit Windows 7 ausgelieferten und zertifizierten Programme bestimmte Objekte mit erhöhten Rechten erzeugen dürfen ohne einen UAC-Dialog auszulösen. Dazu gehören auch Explorer.exe, Calc.exe, Notepad.exe und MSPaint.exe.
Und die dritte Kategorie legt fest, welche Objekte mit erhöhten Rechten erzeugt werden können.
Das Problem
Auch Windows 7 hat immer noch eine
API, die es ermöglicht,
auf sehr einfache Weise eigene Prozesse mit zusätzlichem Code zu versehen:
Mit
WriteProcessMemory und
CreateRemoteThread injiziert und startet man Code in einem
anderen seiner Prozesse.
Es steht einem frei, dieses auch mit einem der Prozesse zu tun, die in der weißen Liste stehen: Man injiziert also über eine ganz offizielle Programmier-Schnittstelle von einem unprivilegierten Programm aus den gewünschten Code in ein ebenfalls unprivilegiert laufendes anderes eigenes Programm, was aber auf der weißen Liste steht. Der Einfachheit halber in den Explorer.exe, weil der immer läuft. Der injizierte Code läuft nun in dem Programm, das in der weißen Liste steht, und darf alles tun, was dieses Programm auch tun darf. Konsequent erzeugt man nun ein Objekt mit erhöhten Rechten und hat ab dann praktisch Systemrechte.
Windows 7 erteilt den Programmen auf der weißen Liste besondere Ausnahme-Genehmigungen. Beliebiger fremder Code kommt ebenfalls in den Genuß dieses Freifahrtscheins, sobald man ihn eingeschleust hat. Dieses Einschleusen erfordert keinen bösen Angriff oder Hacker-Kunst, denn man verwendet einfach die ganz offiziellen Schnittstellen, die Windows dafür anbietet.
Die sicherheitsrelevanten Folgen
Windows 7 bietet mit den Integritätsstufen und der UAC nur noch ein Sicherheits-Schauspiel, aber keine effektive Hürde für Schadprogramme, die von eingeschränkten Rechten aus an Systemrechte kommen wollen. Es ist wohlgemerkt kein Bug, der dies ermöglicht, sondern gewollte Funktionalität und so entworfen. Es ist ein weiterer Punkt, in dem Windows ganz gefährlich "broken by design" ist.
2009-03-20
MacBook wieder nicht gehackt in zwei Minuten
Genau wie im letzten Jahr beim gleichen Thema geistern wieder Artikel durchs Netz, die sich von wesentlichen Tatsachen verabschiedet haben.
Der Wettbewerb
Es ging darum, bisher nicht veröffentlichte Programmierfehler im Browser zu finden und derart auszunutzen, daß durch den Besuch einer präparierten Website eigener Code in den Browser eingeschleust und von diesem ausgeführt wird.
Die Auswirkung des Fehlers
Der Code wird, da es sich um einen Fehler im Browser
handelt, zwangsläufig unter dem Benutzer ausgeführt, der den Browser
verwendet. Wenn er normaler Benutzer ist, bedeutet das vollen Zugriff auf sein privates
Verzeichnis. Wenn er in der Administrator-Gruppe ist, dann hat der eingeschleuste
Code auch noch vollen Zugriff auf /Applications und
/Library, die der Administrator-Gruppe unterstehen. Das /System und
Systemprogramme wie beispielsweise unter /usr/bin oder /usr/sbin sind
nicht betroffen, weil sie root und dessen primärer Gruppe wheel
gehören. Die Administrator-Gruppe hat dort wie die normalen Benutzer nur Leserechte.
Charlie Miller bestätigte, daß er keine Systemrechte hatte.
Für eine Rechner- oder System-Übernahme müßte noch der Schritt zu root
gemacht werden. Es gab und wird möglicherweise auch später immer mal wieder Fehler in
Systemprogrammen geben, die das ermöglichen.
Auf OS X ist also ein Fehler im Browser, der beim Besuch einer ausreichend bösen Seite die Einschleusung von Code ermöglicht, und ein zusätzlicher Fehler, um das System übernehmen zu können (Local Root Exploit), notwendig, wenn man den Mac per Seitenbesuch übernehmen möchte.
Auf dem Wettbewerb wurde auch der Internet Explorer 8 auf Windows 7 übernommen. Dort ist aufgrund eines Design-Fehlers von Windows 7 jedoch die Systemübernahme ohne einen zusätzlichen Privilege Escalation Bug möglich. Die Details hierzu führe ich in einem folgenden Artikel auf.
Die Vorbereitung: Über ein Jahr
Die Teilnehmer hatten sich vorbereitet, indem sie vor dem Wettbewerb nach geeigneten Fehlern im Browser suchten und dann einen passenden Exploit erstellten. Diese Exploits wurden dann von den Teilnehmern in ausgeloster Reihenfolge vorgeführt. Wenn er funktionierte, hat man gewonnen. Das Vorführen besteht im Besuch der präparierten Seite.
Das Knacken der Browser erfolgte also keineswegs innerhalb von zwei Minuten, denn das Finden des Fehlers und die Entwicklung des diesen Fehler ausnutzenden Demo-Schadprogrammes erfordert Tage, meistens aber Wochen von Arbeit. Nur das Vorführen dauert zwei Minuten: Rechner starten, Browser starten, Adresse eintippen. Wer dies als die "Knack-Zeit" angibt, dem spreche ich jede Befähigung zum Schreiben technischer Artikel über Rechner-Sicherheit schlicht ab.
Charlie Miller bereitete den Angriff sogar seit über einem Jahr vor. Wörtlich sagte er:
Es war ein Exploit gegen Safari 4, der auch mit Safari 3 funktioniert. Tatsächlich fand ich diesen Bug vor dem Pwn2Own-Wettbewerb des letzten Jahres (2008), aber zu der Zeit war es schwieriger, ihn auszunutzen. Ich kam im letzten Jahr (2008) zu CanSecWest mit zwei Bugs, aber mit nur einem Exploit. Im letzten Jahr konnte man nur einmal gewinnen, deshalb habe ich mir den zweiten Bug aufgehoben. Es stellte sich heraus, daß er dieses Jahr immer noch vorhanden war, also schrieb ich einen weiteren Exploit und benutzte ihn dieses Jahr.
Er konnte den Bug also in 2008 nicht verwenden, weil er nur einmal gewinnen durfte und er letztes Jahr noch keinen Weg gefunden hatte, den Fehler auszunutzen. Es war also nicht leicht für ihn, denn sein erster Versuch, dafür einen Exploit zu schreiben, scheiterte. Ein Jahr später schließlich konnte er dann einen funktionierenden Exploit für diesen Bug, den er seit über einem Jahr kannte, programmieren. "Über ein Jahr" ist ein Zeitraum, der wesentlich länger ist als zwei Minuten, aber das interessiert die Regenbogen-Presse nicht.
Der Alltag
Warnung: Die Aufmerksamkeit heischende Form eines Wettbewerbs verführt leider zu der irrigen Annahme, daß es sich bei solchen Fehlern im Browser oder anderen Programmen um eine Besonderheit handelt. Tatsächlich sind sie jedoch alltäglich. Wenn man sich beispielsweise die Beschreibung der Sicherheits-Aktualisierungen durchliest, die für OS X-Programme herausgegeben werden, dann stößt man häufig auf Fehler, die das Einschleusen von Code ermöglichen. Man muß also davon ausgehen, immer derartige Fehler in seinen Programmen zu haben.
Aber warum sind Browser besonders gefährdet? Sie erleichterm dem Angreifer die Arbeit: Browser finden besondere Beachtung, weil der Benutzer damit den Code selbst auf seinen Rechner lädt. Ansonsten müßte sich der Angreifer erst noch überlegen, wie er auf den Zielrechner gelangt.
Was kann man gegen diese dauerhafte Bedrohung tun?
Der beste Schutz
Wie ich schon früher zu diesem Thema anführte, gibt es aufgrund der Alltäglichkeit solcher
Fehler nur eine
sinnvolle Schutzmaßnahme: Safari im
Sandkasten einsperren. Damit kann man auch seine eigenen Daten schützen, die
ansonsten selbst im Normal-Benutzer-Betrieb ausgelesen oder verändert werden könnten.
So ein Sandkasten funktioniert selbst dann, wenn der Browser unter
root laufen würde.