TPM und IE7 auf dem Prüfstand
Wie sicher ist Windows Vista?
Die Sicherheit von Windows Vista ist derzeit ein viel diskutiertes Thema. Der folgende Artikel greift zwei zentrale Aspekte heraus: Welche Chancen hat ein Angreifer, ein mit Bitlocker chiffriertes Dateisystem zu lesen, und: Wird der IE7 wirklich soviel sicherer sein?
Ohne Frage ist Windows Vista ein großer Schritt vorwärts zu mehr Sicherheit. Einige
Publikationen (siehe etwa [3]) zeigen bereits Details und weisen zugleich auf zukünftige Probleme
wie etwa die schwierige Administration hin, die doch wieder Sicherheitslücken aufreißt.
Dieser Artikel geht nicht auf Einzelheiten von Benutzung und Konfiguration ein, sondern versucht
sich an einer allgemeineren Analyse zweier Fragen:
Der Schlüssel des Bitlocker-Dateisystems ist "nicht auslesbar" in einem
TPM-Chip versteckt – wirklich?
Der Internet Explorer läuft unter Vista mit niedrigerer Priorität. Werden
dennoch Angriffe möglich sein, und wenn ja, welcher Art?
Die Betrachtungen stützen sich dabei auf aktuelle Literatur, aber auch auf Informationen, die
der Autor während der RSA-Konferenz in Nizza direkt am Microsoft-Stand sowie in einem Interview mit
Stephen Toulouse erhielt, dem Security Program Manager vom Microsoft.
Zunächst zum chiffrierten Bitlocker-Dateisystem. Es ist bekannt, wie oft Notebooks mit sensiblen
Daten gestohlen werden, und es ist auch keine neue Erkenntnis, dass sich die Anwender dagegen
unzureichend schützen. Die Verschlüsselung kritischer Dateien, oder besser gleich der Einsatz
chiffrierter Dateisysteme, spielt deshalb eine immer größere Rolle. Wenn jedoch EFS (Encrypted File
System) unter Windows genutzt wird, dann sollte das Passwort beim Start eingegeben oder auf einem
USB-Stick ausgelagert werden. Diese beiden Möglichkeiten scheinen dem bequemen Anwender allerdings
zu aufwändig zu sein, weshalb er das Passwort meist "gut versteckt" auf der Platte unterbringen
lässt, sofern er überhaupt EFS einsetzt – ein gefundenes Fressen für Hacker und vor allem für
Industriespione.
Dieses Dilemma erläutert der Kryptologe Niels Ferguson, einer der Mitentwickler des
Bitlocker-Dateisystems, in "AES-CBC + Elephant diffuser" [2] und begründet damit, warum man auf die
Idee kam, die auf den meisten modernen Mainboards vorhandenen TPM-Module ("Trusted Platform Module"
, früher "TCPA-Chip" oder auch "Fritz-Chip" genannt) zu diesem Zweck einzusetzen. Der umstrittene,
typische Einsatzfall von TPMs ist zwar DRM (Digital Rights Management), doch warum sollte ein TPM
nicht auch "guten Zwecken" dienen?
TPM-Probleme
Nach Microsoft-Angaben ist der Schlüssel nun "unauslesbar" in der Hardware verborgen. Dies ist
im Prinzip erst einmal richtig: Aus dem TPM-Modul lassen sich Informationen unbefugt nur mit sehr
hohem Aufwand (zum Beispiel durch Zerstören des Chips) auslesen. Um dennoch Angriffspunkte
aufzuzeigen, ist eine kurze Erklärung notwendig, welche Features eines TPM bei Vista überhaupt
genutzt werden.
Ein TPM kann neben dem Berechnen und Überprüfen digitaler Signaturen kleinere Datenmengen – in
der Regel kryptografische Schlüssel – intern erzeugen und speichern. Die Besonderheit eines
TPM-Chips ist, dass er diese Schlüssel nicht jedem Interessenten ausliefert, sondern nur nach "
Vorzeigen" einer bestimmten Prüfsumme (Hash-Summe) ausgibt. Zu diesem Zweck besitzt ein TPM so
genannte PCRs (Platform Configuration Register), die beim Start des Rechners genullt sind und nicht
zurückgesetzt werden können. Wohl aber kann der TPM über den Wert eines PCR und eine vorgelegte
Hash-Summe einen neuen Hash-Wert berechnen und diesen im gleichen PCR ablegen (inkrementelles
Hashen). Erst wenn der Wert des PCR einem vorgegebenen Wert entspricht, rückt der TPM den Schlüssel
heraus. Aus Kosten- und Performance-Gründen besitzt ein TPM keinen eigenen Kryptoprozessor, sondern
übergibt den Schlüssel an einen externen Prozessor oder an Software. Letzteres ist bei Vistas
Bitlocker-System der Fall, das schließlich auf möglichst vielen Rechnern laufen soll und daher
keine Spezialhardware voraussetzen will.
Ein Schlüssel "in Freiheit" ist ein willkommener Angriffspunkt, und dem versucht man beim
typischen TPM-Einsatz in DRM-Systemen mittels "Secure Boot" zuvor zu kommen: Ein vertrauenswürdiger
Teil des BIOS wird beim Start des Rechners zuerst ausgeführt und bildet eine Hash-Summe über sich
selbst und das eigentliche BIOS. Die Hash-Summe wird einem PCR "vorgeführt". Anschließend wird ein
Hash über Teile der Hardwarekonfiguration gebildet, dieser wieder dem gleichen PCR vorgeführt, dann
über den Master Boot Record (MBR), den Bootmanager und das Betriebssystem. So kann garantiert
werden, dass nur ein vertrauenswürdiges Betriebssystem den geheimen Schlüssel erhalten kann. "
Vertrauenswürdig" heißt hier: Mit der richtigen Hash-Summe, was analog zu einer gültigen digitalen
Signatur eines zertifizierten Herstellers zu verstehen ist.
An dieser Stelle steckt ein Denkfehler, der seit Beginn der kontroversen Diskussionen um
TCPA/TPM notorisch wiederholt wird: Die beglaubigte Urheberschaft einer Software garantiert nicht
deren Sicherheit, nur ihren Ursprung. Wie gefährlich die Ignoranz gegenüber diesem Unterschied ist,
zeigte sich deutlich bei Active-X-Controls, bei denen gültige Zertifikate als Garant für Sicherheit
stehen sollten. Sicherheits-Guru Bruce Schneier schrieb in seinem Buch "Secrets and Lies"
sinngemäß: Active-X ist, als würde man alle Einbrecher zwingen, Namensschilder zu tragen, und dafür
dann sofort alle Türschlösser abmontieren.
Wenn es also gelingt, in das "vertrauenswürdige" Betriebssystem einzudringen (und das gelang
bisher immer), dann kommt man prinzipiell auch an den geheimen Schlüssel aus dem TPM heran. Es ist
also ein falsches Marketing-Versprechen, zu behaupten, der Schlüssel sei "nicht auslesbar" in
Hardware versteckt. Das gilt nämlich nur so lange, wie man nicht mit ihm arbeitet!
Bei Vista gibt es nach Aussagen eines Microsoft-Mitarbeiters kein Secure Boot, was sich mit den
Angaben in entsprechenden Technet-Dokumenten [1] deckt: Unter anderem werden der sichere BIOS-Teil
(CRTM, Core Root of Trust Measurement), das BIOS, Hardware-Erweiterungen, der MBR, der
NTFS-Boot-Sektor und der NTFS-Boot-Block sowie der Bootmanager überprüft. Erst wenn all diese
Komponenten zusammen den korrekten Hash-Wert liefern, rückt das TPM den Schlüssel heraus, und das
chiffrierte Bitlocker-Dateisystem kann gelesen werden.
Eine Überprüfung des Betriebssystems selbst oder gar von Applikationen wäre nicht sinnvoll, da
man nach jedem Patch das Bitlocker-Dateisystem nicht mehr ansprechen könnte (nur über den
Recovery-Schlüssel, siehe unten).
Gegenüber dem bisherigen chiffrierten Dateisystem EFS, bei dem der Schlüssel oft im Klartext auf
der Platte zu finden war, ist Bitlocker natürlich ein deutlicher Gewinn bei fast gleichem Komfort.
Doch wie sicher ist Bitlocker wirklich? Zur Beurteilung nehmen wir das gefährlichste Szenario an:
Ein gesichertes Notebook mit firmenkritischen Daten wird gestohlen und soll ausgewertet werden.
Da die Auswertung der Daten in diesem Fall nicht routinemäßig geschehen kann, lohnt sich auch
etwas Handarbeit. So werden die Angreifer natürlich versuchen, an den zur Laufzeit im RAM
untergebrachten Arbeitsschlüssel heranzukommen. Auch wenn derzeit nicht klar ist, wie das geschehen
wird – daran, dass es möglich ist, dürfte kaum jemand zweifeln, zumal der Angreifer das Gerät in
der Hand hat und ihm alle Möglichkeiten des Zugriffs offenstehen.
Noch kritischer könnte jedoch eine zweite Möglichkeit werden. Die oben erwähnten Hashalgorithmen
sind bekannt (oder werden es früher oder später), und vielleicht sind bis auf den sicheren
BIOS-Teil alle Daten, über die gehasht wird, ebenso bekannt. Vermutlich lässt sich der CRTM aber
auch auslesen, oder zumindest kann man mit geringem Aufwand der erzeugte Hash-Wert belauscht
werden. Dann aber lassen sich alle Hash-Summen, die dem PCR vorgeführt werden, im Prinzip auch "
manuell" bereit stellen und der geheime Schlüssel so extrahieren. Der Schutz gegen diesen Angriff
wären wieder die beim Booten einzugebende PIN oder ein gesonderter USB-Stick – doch dann bringt
Bitlocker keine Vorteile mehr.
Beide Angriffe wären effektiv zu verhindern, wenn TPMs einen eingebauten AES-Kryptoprozessor und
ein schnelles I/O-Interface hätten. Der primäre Einsatzzweck von TPMs schien aber eher DRM zu sein,
was ein ganz anderes Nutzungskonzept ist. Für den Transport wirklich kritischer Daten per Notebook
sind wohl Festplatten und Dateisysteme mit externen Schlüsseln (und solidem kryptografischem
Konzept) die bessere Wahl, weil mit zunehmender Verbreitung von Vista und Bitlocker die Angriffe
routinierter werden dürften.
Selbstredend lässt sich ein laufendes Vista-System über das Netz angreifen, auch wenn dies
zunächst schwerer fallen wird als bei älteren WindowsReleases. Der Schutz vor solchen Angriffen ist
nicht Aufgabe eines chiffrierten Dateisystems.
Nichts gibt es geschenkt, und so tritt auch bei Bitlocker das typische Problem auf, das schon
bei TPM/TCPA diskutiert wurde: Wenn sich auch nur eine Hash-Summe während des Boot-Vorgangs ändert,
kommt der Anwender nicht mehr an sein chiffriertes Dateisystem heran. Dies kann durch eine Änderung
der Hardware verursacht werden oder durch ein Update des Bootmanagers. Selbst die Nutzung einer
Bitlocker-Festplatte auf einem anderen Notebook mit TPM ist nicht möglich.
An diesen Fall wurde vorsorglich gedacht. Optional kann beim Einrichten des Dateisystems ein
Ersatzschlüssel (Recovery Key) vom Administrator erzeugt und im Active Directory untergebracht
werden. Die Beschreibung in "Bitlocker Drive Encryption" [1] lässt darauf schließen, dass es sich
hier um simples Secret Splitting handeln könnte, das heißt um das Zerlegen des Generalschlüssels in
zwei unabhängige Teile, deren XOR-Kombination den Schlüssel ergibt. Ein Teil wäre dann lokal
ungeschützt auf dem Rechner verfügbar, der andere bildet den Recovery Key. Dies wäre ein sicheres
Verfahren, obwohl Murphy dafür sorgen wird, dass der Crash genau dann geschieht, wenn die Daten
dringend benötigt werden und der Administrator nicht verfügbar ist. Nur über den Recovery Key ist
ein Transfer des ganzen Systems auf andere Rechner möglich.
Auf einem Vista-System mit Bitlocker wird man nicht nachträglich den MBR modifizieren dürfen, um
optional Linux zu booten. Ebenso kann das Bitlocker-System nicht von einer Linux-Live-CD aus
gemounted werden, was oft die letzte Rettung bei Problemen darstellt. Auch wenn der Chiffriermodus
von Bitlocker (siehe."AES-CBC + Elephant diffuser" [2]) in freier Software nachimplementiert wird –
den Schlüssel im TPM kann diese nicht extrahieren. Nicht zuletzt lässt sich durch Umklappen eines
nicht benutzten Bits etwa im MBR ein besonders perfider Denial-of-Service-Angriff durchführen: Die
Ursache für das Problem dürfte in den wenigsten Fällen erkannt werden. Diese Modifikation ist kein
Problem mit einer Live-CD und entsprechender (einfacher) Software, kurzzeitigen physischen Zugriff
zum Rechner vorausgesetzt.
Zusammenfassend lässt sich sagen, dass Bitlocker zwar gegen "normale" Hacker hilft, doch
vermutlich nicht gegen etwas professionellere Angreifer, gegen die es eigentlich schützen soll.
Halbsicher Surfen mit IE7
Kaum eine andere Windows-Applikation machte mit Angriffsmöglichkeiten mehr von sich reden als
der Internet Explorer. Damit soll unter Vista weit gehend Schluss sein, wenn man den Entwicklern
glaubt. Es gibt jetzt drei verschiedene "Prioritäten" von Prozessen unter Vista, vereinfacht
gesagt: verschiedene Zugriffsrechte. Der IE läuft in der niedrigsten Klasse, und ein gehackter IE
(was dank aktiven Codes auf Webseiten immer möglich sein wird) kann so keinen Schaden mehr
anrichten. Das ist erst einmal das richtige Konzept.
Etwas seltsam muten allerdings die Details an. Weil unter Windows Prozesse über Messages
kommunizieren, ist es dem IE nicht erlaubt, höher priorisierten Prozessen (wie zum Beispiel
normalen Benutzerprozessen) eine Nachricht zu senden. Man könnte so nicht einmal einen Link im
Clipboard ablegen. Deswegen gibt es für diese Prozesse einen "Broker", der je nach Konfiguration
entscheidet, welche Messages gesendet werden dürfen und welche nicht. Die prinzipiell beschränkte
Intelligenz bei der Konfiguration und der Funktion dieses Brokers werden natürlich als lohnende
Angriffsziele erscheinen. Auch ist nicht klar, ob der Firefox eine andere Broker-Konfiguration
benötigt als der IE.
Zum Zweiten ist ein Vergleich mit der aus Hochsicherheitsbereichen bekannten "
Multi-Level-Security" (MLS) interessant (siehe etwa "Linux von der NSA?" [4], wo dieses Konzept für
SE-Linux erläutert wird). Dort ist es genau umgekehrt: Der höher priorisierte Prozess darf dem
niedrigeren keine Nachricht senden. Hintergrund ist, dass sonst sensible Daten in ungeschützten
Bereichen abgelegt werden können. Der niedrigere Prozess darf dem höheren zwar Nachrichten senden,
kann aber keine Aktionen auslösen. Der fehlende Unterschied zwischen Aktion und Nachricht scheint
(allgemein bei Windows) das Problem zu sein.
Unter Vista sieht die Folge der Umkehrung des MLS-Prinzips beispielsweise so aus: Da
Nutzerprozesse dem IE offenbar ohne Kontrolle Nachrichten senden dürfen, könnte ein gehackter
Nutzerprozess den IE beliebig missbrauchen, etwa zum automatischen Ausfüllen von Webformularen.
Ein Vergleich zu UNIX/Linux bietet sich hier an: Dort kann man problemlos einen Browser unter
der Identität eines gesonderten Nutzers starten, dessen Heimatverzeichnis keine relevanten Daten
enthält und dessen Zugriffsrechte stark reduziert sind. Insbesondere hat dieser Nutzer keine
Schreibberechtigung auf fremde Verzeichnisse. Diese Art der Nutzung ist nicht ganz so komfortabel
wie das Surfen unter eigener Identität, doch die Sandbox wird durch vom Betriebssystem vorgegebene
Rechte erzeugt und ist unabhängig davon, um welche Applikation und welche Art Nachrichten es sich
handelt. Ohne ein analoges Sandbox-System dürften immer wieder neue, effektive Angriffe auf die
Sicherheit bei der Nutzung des IE entwickelt werden.
Es bleibt zu konstatieren, dass – allen Fortschritten in der Vista-Sicherheit zum Trotz –
Angreifer sich natürlich kaum von Aero-Effekten beeindrucken lassen, sondern gezielt die
schwächsten Stellen suchen und attackieren werden. Je komplizierter ein System ist, desto eher
werden sie Erfolg haben.
Lesen Sie mehr zum Thema
