Windows 10 ist noch gar nicht richtig bei den Anwendern angekommen, da gibt es schon die ersten Vorträge auf den Sicherheitskonferenzen zu Microsofts neuestem Betriebssystem. Dabei stellt sich die Frage: Ist das neue OS womöglich gefährlich oder wohl eher gefährdet?

Im Artikel über die Sicherheit von C# 6.0 [1] hatte ich bereits darauf hingewiesen, dass Windows 10 und alles, was dazu gehört, bisher zwar nicht auf den Sicherheitskonferenzen behandelt wurde, die ersten Vorträge aber bereits für die Black Hat USA im August angekündigt waren. Schauen wir uns also einmal an, was es an Microsofts neuestem Betriebssystem auszusetzen gibt. Oder gibt es vielleicht sogar was zu loben?

Vortrag 1: Wie sicher ist die neue Systemarchitektur?

Alex Ionescu hat sich auf der Black Hat USA mit der Sicherheit der neuen Systemarchitektur von Win­dows 10 beschäftigt [2]. Microsoft setzt in Win­dows 10 und Windows Server 2016 stark auf „Vir­tuali­zation Based Security“ (VBS). Diese besteht aus mehreren Features:

• „Device Guard“ erlaubt es, genau zu kontrollieren, was ausgeführt werden darf, angefangen bei Power­Shell-Skripten über User Mode DLLs und Anwendungen zu den Kernel-Mode-Treibern.

• „Credential Guard“ erlaubt die Speicherung von kryptografischen Geheimnissen, die normalerweise der „Local Security Authority“ (LSA) gehören, in Speicherbereichen, die von niemandem auf dem Rechner gelesen werden können, unabhängig von dessen Benutzerrechten und sogar Hardwarezugriff auf den Speicher.

• „Guarded Fabric“ schützt virtuelle Maschinen vor bösartigen Hostadministratoren und Schadsoftware auf dem Host:

  • vTPM (Virtual TPM) erlaubt den Einsatz von BitLocker auf Virtual Machines und sorgt dafür, dass Daten stets verschlüsselt sind.

  • Shielded VMs verwenden vTPM und weitere Sicherheitsfeatures, um den Speicher der virtuellen Maschine für den Host unsichtbar zu machen.

Zum Zeitpunkt von Alex Ionescus Vortrag waren diese Features nur wenig dokumentiert, inzwischen hat sich die Lage etwas verbessert. Auch Alex Ionescu hat in seinem Vortrag nichts Neues zu den wenigen bisher veröffentlichten Blogbeiträgen etc. zu diesen Themen beigetragen, sondern sich auf deren gemeinsame Grundlagen konzentriert: Alle diese neuen Features bauen auf den gleichen internen Änderungen an Microsofts Hypervisor Hyper-V und dem NT-Kernel auf, dem so genannten Virtual Secure Mode (VSM).

Der Virtual Secure Mode

Los ging es mit einem Überblick über den VSM. Der Hypervisor verbindet mit jedem Virtual Processor (VP) ein Virtual Trust Level (VTL). Davon sind bisher zwei definiert, die Architektur unterstützt allerdings mehr. Je höher der Wert, desto privilegierter ist das VTL: VTL 0 ist die „Normal World“, VTL 1 ist die „Secure World“. Der Hypervisor nutzt Enhanced Page Tables (EPT) für die Speicherverwaltung, die ebenfalls mit einem VTL verknüpft sind. Der Zugriff von VTL 0 auf Seiten mit VTL 1 kann kontrolliert werden. Mittels „Blocking + R“ können kryptografische Geheimnisse verborgen werden (Credential Guard), mittels „Blocking + RX“ (oder + RWX) kann die Ausführung oder Änderung von Code verhindert werden (Device Guard), und mittels „Blocking + W“ können Änderungen an mit VTL 1 gemeinsam genutzten ausführbaren Seiten verhindert werden.

Der Hypervisor selbst implementiert dabei keinen Code und keine Logik zur Implementierung der VBS-Features. Das reduziert seine Komplexität und damit auch seine Angriffsfläche.

Unter Hyper-V wird ein isolierter Bereich, beispielsweise eine Instanz einer virtuellen Maschine, als Partition bezeichnet. Im typischen Hyper-V-Set-up gibt es eine Root-Partition für das Host-OS und eine Child-Partition für das Gast-OS. Vor dem Einsatz des Hyper-V-Managers zum Einrichten einer virtuellen Maschine existiert nur die Root-Partition (siehe dazu auch den Artikel „Wie sicher sind virtuelle Maschinen?“ auf Seite 92 dieser Ausgabe).

Bisher vertraute Hyper-V der Root-Partition vollständig, und die Root-Partition hatte die vollständige Kontrolle über die Child-Partition(en). Mit VMS erzeugt der Hypervisor weiterhin die Root-Partition, startet sie aber in VTL 1. Der Code läuft daher zunächst im Secure Mode, hat damit den vollen Zugriff auf die EPT-Mappings und kann dort Zugriffsbereiche definieren. Danach wechselt der Code zu VTL 0 und wird weiter ausgeführt. Der Hypervisor vertraut der Root-Partition nun nicht mehr implizit.

Rollen sind dazu da, getrennt zu werden

Es wird auch nicht mehr der gesamte Kernel samt Umgebung in die sichere Partition geladen, was nur zu einer signifikant größeren Angriffsfläche führen würde, sondern ein sichereres Ausführungsmodell verwendet:

• Das Secure-Kernel-Mode-(SKM-)Environment läuft im Ring 0 (VTL 1) und enthält einen minimalen Kernel und einige wenige Kernelmodule, aber kein Win32k.sys.

  • Der Kernel ruft den SMART-Kernel oder SK auf (SMART = Secure Mode Application Run Time).

  • Module: skci.dll (stellt Codeintegrität sicher) und cng.sys (die Cryptographic Services).

• Das Isolated-User-Mode-(IUM-)Environment läuft im Ring 3 (VTL 1) und enthält spezielle Prozesse, die „Trustlets“:

  • Trustlets sind untereinander isoliert und erfüllen spezielle Anforderungen an ihre digitalen Signaturen. Abgesehen von den Signaturen kommen im IUM aber die gleichen Binaries wie im Normal-Mode zum Einsatz.

  • Ihnen stehen nur die Systemaufrufe des SKM zur Verfügung, sie haben keinen Zugriff auf CSRSS.

  • Sie können nur für IUM zugelassene DLLs laden.

Alles andere in VTL 0 bleibt, wie es ist, und wird teilweise als High Level OS (HLOS) bezeichnet.

Anforderungen an die Plattform

Das Ganze lässt sich natürlich nur implementieren, wenn die zugrunde liegende Plattform einige Voraussetzungen erfüllt.

Zunächst einmal muss der Bootloader sicher sein, dass auf der Plattform, auf der er läuft, keine bösartige Firmware läuft. Denn diese könnte den Start des Hypervisors modifizieren, und um die Garantien des VSM wäre es geschehen. Secure Boot garantiert, dass die Firmware unverändert ist, und sorgt auch dafür, dass Policies und Einstellungen sicher gespeichert werden können.

Der Hypervisor ist darauf angewiesen, dass die Hardware keinen DMA-Zugriff auf VTL-1-Seiten zulässt. Andernfalls könnte ein VTL-0-Administrator über eine manipulierte Firmware oder einen speziellen oder verwundbaren Treiber auf VTL-1-Speicher zugreifen. IOMMU/VT-d garantieren, dass diese DMA-Zugriffe nicht möglich sind.

Der Hypervisor benötigt einen sicheren Speicherplatz für Maschinengeheimnisse und Schlüssel. Ansonsten könnten persistente Daten wie der Maschinenschlüssel ausgespäht oder manipuliert werden. Das TPM stellt diesen sicheren Speicher zur Verfügung.

VBS kann so konfiguriert werden, dass die Plattform diese Bedingungen erfüllen muss, oder dass fehlende Features durch Workarounds umgangen werden. Der VSM läuft unabhängig von dieser Konfiguration und kann auch einzeln aktiviert werden.

„Hypervisor-based Code Integrity“ (HVCI)

Mit Windows 10 wurde ein neues Modul eingeführt: skci.dll (Secure Kernel Code Integrity) oder HVCI. Dabei handelt es sich um eine funktional identische, einfachere Form der normalen Codeintegritätsbibliothek ci.dll, die aktiviert wird, wenn der Hypervisor aktiviert und Device Guard konfiguriert ist. Die skci.dll ist als Modul ein Teil des SKM.

Werden die „Strong Code Guarantees“ aktiviert, ist der Kernel nicht mehr in der Lage, „Kernel Mode Executable Page Tables“ anzulegen. Ist der VSM aktiviert, kann nur das SKM EPT-Einträge als ausführbar markieren. Und dieses markiert einen EPT-Eintrag nur dann als ausführbar, wenn die HVCI bestätigt, dass die Codeseite entsprechend den Signaturregeln signiert wurde.

Sind die „Hard Code Guarantees“ aktiviert, können auch keine User Mode PTE ausgeführt werden. Das Ausführen von Prozessen und Laden von DLLs ist erst möglich, nachdem die HVCI sie erfolgreich geprüft hat.

Auf einem System mit Secure Boot, mit TPPM, IOMMU, SLAT und aktiviertem Hypervisor mit aktivierten „Hard Code Guarantees“ ist es unmöglich, unsignierten Code auszuführen.

Los geht’s – einmal starten, bitte

Der VSM ist ein eingebautes Feature des Hyper-V-5.0+-Hypervisors. Beim Start wird zuerst der Bootloader von Hyper-V, hvloader.efi, gestartet, danach der Hypervisor. Ist dieser aktiv und initialisiert, wird der restliche Boot-Vorgang unter der Root-Partition ausgeführt. Als Nächstes wird vom Bootloader winload.efi der Start des Secure-Kernels vorbereitet. Der Bootloader ist dabei unter anderem für die Erzeugung und Sicherung des Identification-Key (IDK) und des Local-Key (LKEY) zuständig, die von Credential Guard und vTPM verwendet werden. Zusammen mit dem Secure-Kernel securekernel.exe selbst werden auch dessen Dependencies geladen, insbesondere skci.dll und cng.sys.

Der Secure-Kernel initialisiert dann VTL 1 und stellt die IUM-Funktionen bereit. All das wird über die VSM-Boot-Policy konfiguriert.

Alex Ionescu hat im Vortrag noch viele weitere Informationen zu SKM, IUM und Trustlets geliefert, für die hier kein Platz ist.

Alex Ionescus Fazit

Kommen wir zu Alex Ionescus Einschätzung, ob IUM/VSM sicher ist. Kurz formuliert: Ja. Länger begründet: Es scheint keine Designfehler zu geben, die Separierung von Privilegien, Rollen, Fähigkeiten ist gut gewählt, die Angriffsfläche stark limitiert. Es gibt aber einen Haken: Die VSM-Sicherheit hängt von der Sicherheit der Plattform ab, fehlen die Hardwarevoraussetzungen, müssen sie emuliert oder darauf verzichtet werden, was natürlich zu Lasten der Sicherheit geht – worauf Alex Ionescu dann noch genauer eingegangen ist. Und es gibt auch einige Verbesserungsvorschläge, von denen ich einen hier noch kommentieren möchte:

„Microsoft should at the very least make HVCI (skci.dll) verify its own integrity. ci.dll does this, and is additionally protected by peauth.sys, PatchGuard, and Warbird.“

Die DLL, die die Integrität des Codes prüft, wird selbst nicht geprüft? Weder von sich noch von einem anderen Prozess? Das klingt für mich schon wie ein Designfehler. Vor allem, wenn die „alte“ Integritätsprüfung-DLL das tut und zusätzlich noch anderweitig gesichert ist. Da sollte Microsoft in der Tat nachbessern.

Aber kommen wir zum nächsten Vortrag, ebenfalls von der Black Hat USA 2015:

Vortrag 2: Lässt sich die „Control Flow Guard“ (CFG) umgehen?

Yunhai Zhang hat untersucht, ob, und wenn ja wie, sich die in [1] bereits vorgestellte Mitigation „Control Flow Guard“ (CFG) umgehen lässt. CFG erweitert den Code bei jedem indirekten Aufruf um eine Prüfung, ob die Zieladresse eine beim Kompilieren als gültig erkannte Adresse ist. So soll verhindert werden, dass ein Angreifer den Kontrollfluss manipuliert.

Yunhai Zhang hat zunächst den Aufbau und die Implementierung der CFG beschrieben. CFG verwendet die so genannte CFG-Bitmap, um alle gültigen Zieladressen zu verfolgen. Ein gesetztes Bit in der Bitmap signalisiert, dass die zugehörige Adresse zulässig ist. Angriffe können erfolgen über

• Module, die die CFG nicht nutzen:

  • Die Module können ungeschützte indirekte Aufrufe enthalten, deren Ziel überschrieben werden kann, sodass der Kontrollfluss geändert werden kann.

  • Alle Bits der CFG-Bitmap sind gesetzt, sodass jede Adresse in der Textsektion ein gültiges Ziel für einen indirekten Aufruf ist. Ein geschützter Aufruf kann mit einer dieser Adressen überschrieben werden, die dann als gültig angesehen wird.

• JIT erzeugten Code: Der Code kann ebenfalls ungeschützte indirekte Aufrufe enthalten, und alle Bits der CFG-Bitmap sind gesetzt. In Edge ist dies beides in der aktuellen Version nicht mehr der Fall.

• Indirekte Sprünge (Jumps) ändern den Kontrollfluss ebenso wie indirekte Aufrufe, werden aber nicht von der CFG geschützt. Yuki Chen hat auf der SyScan 15 einen entsprechenden Angriff auf den IE 11 unter Windows 8.1 vorgeführt [4]. Der Schutz kann wie bei indirekten Aufrufen erfolgen, im Fall von Edge wurde ein entsprechender Schutz bereits verwendet.

• Überschreiben der Return-Adresse: Dieser Angriff ist seit Langem bekannt und erfolgt zum Beispiel bei einem stackbasierten Pufferüberlauf. Für dessen Abwehr sind andere Mitigations wie GS, SAFESEH und SEHOP zuständig. In bestimmten Fällen ist es trotzdem noch möglich, die Return-Adresse zu überschreiben.

• Gültige API-Funktionen können immer angesprungen werden.

Yunhai Zhang hat eine Möglichkeit gefunden, CFG universell zu umgehen. Dazu wurde die Adresse der Prüffunktion der CFG mit der Adresse einer Funktion überschrieben, deren Ergebnis dem der Prüffunktion nach erfolgreicher Prüfung entspricht. Bevor die Adresse überschrieben werden konnte, musste ihr Speicherplatz von „Read-only“ auf „Writable“ geändert werden.

Die am 22. Januar 2015 an das Microsoft Security Response Center gemeldete Schwachstelle wurde von Microsoft am 30. Januar bestätigt, ein Patch wurde am 10. März veröffentlicht.

Das wird sicher nicht die letzte Möglichkeit zum Umgehen der CFG sein, Mitigations haben es nun mal so an sich, das sie sich mitunter umgehen lassen. Sie sollen einen Angriff ja auch lediglich erschweren, nicht komplett verhindern. Dafür sind immer noch die Patches zur Korrektur der Schwachstellen zuständig.

Kommen wir zum nächsten Vortrag. Der widmet sich im weitesten Sinne einem solchen Patch.

Vortrag 3: Pass the Hash verhindern, Ansatz x

Bei einem „Pass-the-Hash-Angriff“ werden die Hash-Werte eines Passworts aus dem Speicher des Betriebssystems ausgespäht und verwendet, um den Angreifer auf einem anderen System zu authentifizieren. Das ist ein uraltes Problem, an dessen Beseitigung Microsoft genauso lange arbeitet, wie es existiert. Möglich sind diese Angriffe nur, wenn Single Sign-on (SSO) zum Einsatz kommt, sodass der Angreifer seine auf einem System erbeuteten Daten auch auf anderen Systemen verwenden kann. Die einfachste Möglichkeit, Pass-the-Hash-Angriffe zu verhindern, ist also der Verzicht auf SSO. Aber wer will sich schon ständig neu anmelden, nur weil er auf Ressourcen auf einem anderen Rechner zugreifen möchte oder Ähnliches?

In Windows 10 wurde der nächste Versuch gestartet, die Angriffe zumindest teilweise unmöglich zu machen. Und wie gut der gelungen ist, haben Seth Moore und Baris Saydag untersucht und auf der Black Hat USA 2015 demonstriert [5].

Die Lösung des Problems lautet „Gewaltenteilung“, ähnlich wie es in Staaten üblich ist. Die kann man auf ein modernes Betriebssystem übertragen:

• Administratoren sind die Legislative, sie legen fest, wer was tun darf.

• Kernel, Systemdienste und Treiber sind die Exekutive, die die Anweisungen der Benutzer(-prozesse) im Rahmen der von den Administratoren vergebenen Rechte ausführen.

• Die Trusted Computing Base (TCB) ist die Judikative, die dafür sorgt, dass sich alle an die Regeln halten.

Ein sicheres Betriebssystem muss gezwungenermaßen eine Trennung zwischen diesen Faktoren vorsehen. Weder Administratoren (die bösartig sein können, Fehler machen oder Opfer eines Angriffs werden können) noch Kernel, Systemdienste und Treiber (die alle kompromittiert werden können) kann vollständig vertraut werden.

Bisherige Lösungen des Problems sind Authenticode/Kernel Mode Code Signing (KMCS), Protected Process (PP)/Protected Process Light (PPL) und Patch Guard, die alle auf ihre Weise einen Teil des Problems lösen, aber alle die gleiche Einschränkung teilen: Sie sind Softwarelösungen. Sicherer und daher vorzuziehen wäre eine Hardwarelösung.

Wo könnte man Geheimnisse so sicher speichern und verarbeiten, dass nicht einmal der Administrator und Kernel sie ausspähen können? Der Kernel läuft im Ring 0, also müssten die Geheimnisse darunter gespeichert werden. Was lange nicht möglich war, da es darunter nichts gab. Das hat sich mit dem manchmal auch als Ring -1 bezeichneten Hypervisor geändert: Der kann Daten speichern und verarbeiten, auf die selbst Ring 0 keinen Zugriff hat. Womit wir bei den schon von Alex Ionescu beschriebenen Änderungen an der Systemarchitektur landen.

Seth Moore und Baris Saydag haben zunächst beschrieben, wie die Geheimnisse, insbesondere Creden­tials, vor Windows 10 gespeichert wurden. Danach ging es um die Speicherung der Credentials unter Windows 10, wo der schon oben erwähnte Credential Guard für ihre Speicherung und Schutz verantwortlich ist.

Dessen Beschreibung von Seth Moore und Baris Saydag ist naturgemäß deutlich ausführlicher als die von Alex Ionescu, bei dem der Credential Guard nur ein Teil der gesamten zu untersuchenden Architektur war.

Ihr Fazit: Entsprechende Hardware vorausgesetzt können die Benutzer sicher sein, dass selbst die am höchsten privilegierte Schadsoftware keine Möglichkeit hat, die Credentials auszuspähen. Ein Angreifer, der einen Rechner kompromittiert hat, kann darauf also keine Credentials erbeuten, mit denen er weiter ins lokale Netz vordringen kann.

Vortrag 4: Ein neuer Angriff über SMBv2

Jonathan Brossard und Hormazd Billimoria haben auf der Black Hat USA 2015 einen neuen Angriff über SMBv2 vorgestellt, der auch Windows 10 und Spartan (inzwischen in Edge umbenannt) betrifft [6]. Während SMB-basierte Angriffe sich bisher auf das lokale Netz beschränkten, konnten sie darüber aus dem Internet heraus Rechner kompromittieren.

Wird in einer HTML-Seite eine Ressource, zum Beispiel ein Bild, über einen file://-URL von einem Server im Internet eingebunden, senden Internet Explorer und Edge beim Request die Credentials des Benutzers mit. Der Benutzername wird als Klartext gesendet, Windows Logon Credentials oder Active Directory Network Credentials als NTLMv2-Hash.

Das sollte eigentlich nur im lokalen Netz passieren. Aus dem Hashwert lässt sich mit etwas Rechenaufwand (maximal zwei Tage und fünf Stunden für ein acht Zeichen langes Passwort aus dem Zeichenvorrat [a-zA-Z!@#$%&]) das Passwort ermitteln. Im Test wurde das Passwort Vn4@2Bpt mit Hashcat in der vorgegebenen Zeit ermittelt.

Um mit den so erbeuteten Credentials etwas anfangen zu können, muss die Verbindung zwischen dem Server des Angreifers und dem Rechner des Opfers zu einem Rechner im lokalen Netz des Opfers weitergeleitet werden. Jonathan Brossard und Hormazd Billimoria haben über die Weiterleitung zu einem Exchange-Server die Kontrolle über den E-Mail-Account des Opfers erlangt.

Außer dem IE/Edge sind auch alle anderen Windows-Clients angreifbar, die file://- oder \\-URLs akzeptieren.

Eine Lösung für das Problem gibt es noch nicht. Als Workaround sollte SMB-Verkehr ins Internet sowohl in der Netzwerkfirewall als auch in der Windows-Firewall blockiert werden.

Außerdem erschweren längere und komplexere Passwörter das Brechen des Hash-Werts. Und Packet Signing für SMB verhindert einfache SMB-Relaying-Angriffe (aber nicht das Ausspähen der Credentials).

Vortrag 5: Die Angriffsfläche von Edge

Mark Vincent Yason hat auf der Black Hat USA 2015 einen Überblick über die Angriffsfläche von Edge und seine Widerstandsfähigkeit gegeben [7]. Dieser Vortrag war bereits Thema im Artikel über die Sicherheit von Edge [8].

Nach der Konferenz ist bekanntlich vor der Konferenz. In diesem Fall gab es auf der Black Hat Europe 2015 vom 10. bis 13. November 2015 die nächsten Vorträge mit Bezug zu Windows 10.

Vortrag 6: BitLocker aushebeln

Ian Haken hat auf der Black Hat Europe 2015 gezeigt, wie sich die Festplattenverschlüsselung von BitLocker aushebeln lässt [9]. Dazu müssen drei Voraussetzungen erfüllt sein:

• BitLocker ist aktiviert, es gibt aber keine Pre-Boot-Authentifizierung. Der Angreifer kann die Maschine bis zum Log-in-Bildschirm booten.

• Die Maschine gehört zu einer Domäne, und ein autorisierter Domänenbenutzer hat sich vorher bei der Maschine eingeloggt.

• Der Angreifer kennt den zugehörigen Benutzernamen (den er zum Beispiel aus belauschtem Netzwerkverkehr erfährt).

Der Angreifer kann eine Schwachstelle in der Authentifizierung nutzen, um sich Zugriff auf die Maschine zu verschaffen.

Dazu benötigt er einen gefälschten Domaincontroller, bei dem das Passwort des anzugreifenden Benutzer(namen)s als abgelaufen markiert ist. Der Angreifer muss sich dann mit diesem ihm bekannten Passwort bei der Maschine als deren Benutzer anmelden. Da das Passwort als abgelaufen gilt, wird er aufgefordert, ein neues Passwort zu setzen.

Das Log-in schlägt immer noch fehl, da das Maschinenpasswort dem gefälschten Domaincontroller nicht bekannt ist. Im lokalen Credential-Cache wird aber trotzdem das neu gesetzte Passwort gespeichert.

Wird die Maschine danach vom Netzwerk getrennt, kann der Angreifer sich mit dem neuen Passwort lokal anmelden, denn es stimmt mit dem im Cache überein. Danach hat der Angreifer Zugriff auf alle Daten des Benutzers und kann sie nach Belieben ausspähen, aber auch Schadsoftware auf dem Rechner installieren.

Ian Haken hat den Angriff unter allen Windows-Versionen seit Vista (das mit dem BitLocker eingeführt wurde, also Vista, 7, 8 und 10) erfolgreich getestet. Die Schwachstelle wurde von Microsoft inzwischen behoben.

Vortrag 7: Edge mit integriertem Flash Player – ist das denn sicher?

Der Flash Player ist seit einiger Zeit mal wieder das Einfallstor Nummer eins für Cyberkriminelle, soweit es die Drive-by-Infektionen betrifft, und über die wird heutzutage die meiste Schadsoftware verbreitet. 2015 gab es bisher sechzehn 0-Day Exploits, und acht davon waren für den Flash Player [10].

In Edge gibt es keine Plug-ins mehr [8], das wäre die ideale Gelegenheit gewesen, diese veraltete und gefährliche Technologie loszuwerden. Stattdessen hat Microsoft das genaue Gegenteil getan: Der Flash Player ist nicht länger ein Plug-in, das man löschen kann, sondern wie schon im Internet Explorer ab Version 10 fester Bestandteil des Browsers.

Wenn der Flash Player nun aber einmal fester Bestandteil von Edge (und IE 10/11) ist, ist er denn wenigstens sicher? Zumindest sicherer als das Plug-in? Dieser Frage ist Francisco Falcon auf der Black Hat Europe 2015 nachgegangen [11].

Der integrierte Flash Player profitiert von der neu eingeführten Mitigation Control Flow Guard (CFG), die eine Manipulation des Kontrollflusses erschweren soll. Um herauszufinden, ob das funktioniert, hat sich Francisco Falcon eine Schwachstelle im Flash Player angesehen und geprüft, ob ein Angriff darüber von der CFG gestoppt wird.

Der herkömmliche Exploit wird in der Tat von der CFG gestoppt. Aber lässt sich vielleicht einer entwickeln, der den Schutz unterläuft? Dazu hat Francisco Falcon nach einem indirekten Aufruf gesucht, der nicht von der CFG erfasst wird, weil er beim Kompilieren noch nicht vorhanden war – und ist im Flash-JIT-Compiler fündig geworden (ein bekanntes Problem, s. o.). Und in der Tat lässt sich die CFG mithilfe des JIT-Compilers unterlaufen, was natürlich eine Schwachstelle ist, die Microsoft prompt behoben hat. Der Flash-JIT-Compiler lässt sich nicht mehr missbrauchen, um die CFG zu unterlaufen, und wurde darüber hinaus weiter gehärtet.

Was zur Frage führt, ob außer über die Manipulation des Kontrollflusses noch andere Möglichkeiten bestehen, die Kontrolle über den Rechner zu übernehmen – was tatsächlich der Fall ist.

Über so genannte „Data-only“-Angriffe konnte sich Francisco Falcon ohne die eigentlich nötige Autorisierung Zugriff auf Kamera und Mikrofon verschaffen und die Sandbox mit der SWF-Datei von der eingeschränkten „Remote“-Sandbox in eine privilegierte „Local Trusted“-Sandbox aufwerten. Dazu musste er „nur“ das SecuritySettings-Objekt des Flash Players manipulieren.

Außerdem war es ihm möglich, beliebige Befehle ohne das Einschleusen von Shellcode oder Return-oriented Programming auszuführen. Dazu missbrauchte er einen vorhandenen WinExec()-Aufruf, in den er eigene Befehle einfügte.

Die „Data-only“-Angriffe haben gezeigt, dass es trotz aller Mitigations weiterhin möglich ist, Schaden anzurichten. Aber die Mitigations sollen ja auch lediglich spezielle Angriffe erschweren, CFG zum Beispiel Manipulationen des Kontrollflusses. Für die ausgeführten „Data-only“-Angriffe gibt es gar keine Mitigations.

Diese Angriffe sind auch unabhängig davon, ob der Flash Player als Plug-in oder als fester Bestandteil des Browsers ausgeführt wird. Der integrierte Flash Player ist in diesem Fall also zwar nicht sicherer, aber auch nicht unsicherer als die Plug-in-Version – die wiederum nicht von der CFG geschützt wird, sodass dort schon der einfache Exploit funktioniert.

Fazit

Bisher sieht es für Windows 10 auf den Sicherheitskonferenzen sehr gut aus. Die neue Systemarchitektur macht einen sehr guten Eindruck, die Mitigations funktionieren im erwarteten Rahmen, neu entdeckte Schwachstellen werden wie meist schnell behoben.

Ob sich die neue Architektur auf Dauer bewährt, bleibt natürlich abzuwarten. Cyberkriminelle und die Hintermänner der Advanced Persistant Threats fangen ja erst an, sich mit Windows 10 zu beschäftigen. Aber Alex Ionescus Vortrag hat doch recht deutlich gezeigt, dass Microsoft sich um diesen Punkt wirklich Gedanken gemacht und eine durchdachte Lösung herausgebracht hat.

Wenn man einmal davon absieht, dass der Integritätsprüfer selbst nicht geprüft wird. Aber das lässt sich ja noch ändern.