daily.out

2009-03-21

Windows 7: Weiße Liste ermöglicht stille Rechte-Erhöhung für Schadprogramme

Die Situation

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.

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.

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.

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:

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.

---