Browser-Sicherheit: Edge und IE im Vergleich

Warum Microsoft Edge sicherer ist als der Internet Explorer
Kommentare

Cyberkriminelle verbreiten ihre Schadsoftware vor allem über Drive-by-Infektionen. Auf harmlosen Websites eingeschleuster Schadcode nutzt Schwachstellen im Browser oder in dessen Plug-ins aus, um Schadcode auf den Rechnern nichtsahnender Besucher einzuschleusen.

Dabei werden meist mehrere Exploits, also Code zum Ausnutzen von Schwachstellen, nacheinander durchprobiert. So lange, bis der Angriff erfolgreich war oder der Cyberkriminelle sein Pulver verschossen hat. Besonders gefährlich sind dabei die so genannten 0-Day-Exploits, die sich gegen Schwachstellen richten, für die es beim ersten Bekanntwerden der Angriffe noch keine Patches gibt.

Lange Zeit war Java das bevorzugte Einfallstor von Cyberkriminellen, und auch ActiveX Controls wurden nicht verschmäht. Inzwischen hat der Flash Player beiden den Rang abgelaufen.

Werfen wir einmal einen Blick auf die vergangenen drei Jahre: 2013 gab es 21 0-Day-Exploits, 2014 waren es 14 und in 2015 wurden bis zum 26. Oktober 16 entdeckt. Die meisten webbasierten Angriffe richteten sich gegen den Flash Player, gefolgt vom Internet Explorer und Java (Tabelle 1).

tab1_eilers_wd1_16

Tabelle 1: Die Ziele der 0-Day-Exploits der Jahre 2013 bis 2015

0-Day-Exploits werden zuerst meist von darauf spezialisierten Gruppen (hinter denen sehr wahrscheinlich Geheimdienste etc. stehen) für gezielte Angriffe verwendet. Erst nachdem sie dadurch bekannt wurden, werden sie von Cyberkriminellen übernommen und für allgemeine Drive-by-Infektionen eingesetzt.

Wenn 0-Day-Exploits entdeckt werden, beeilen sich die betroffenen Hersteller meist mit der Veröffentlichung eines Patches. Viele der 0-Day-Angriffe auf Microsoft-Produkte wurden sogar erst öffentlich bekannt, nachdem Microsoft die Schwachstelle behoben hatte. Im Security Bulletin gibt es in so einem Fall nur den Hinweis, dass die Schwachstelle bereits für vereinzelte Angriffe ausgenutzt wurde. Erst die Entdecker der Angriffe bringen manchmal Licht ins Dunkel und verraten, wie weit verbreitet die Angriffe waren und gegen wen sie sich richteten. Bereits vor der Veröffentlichung der Patches warnt Microsoft die Benutzer lediglich dann, wenn man befürchtet, dass aus den zielgerichteten, vereinzelten Angriffen auf bestimmte Benutzergruppen allgemeine Drive-by-Infektionen werden, die sich gegen alle Benutzer richten.

0-Day-Exploits sind relativ selten, und Cyberkriminelle begnügen sich meist mit Exploits für schon behobene Schwachstellen. Oft wird aus einem veröffentlichten Patch erst durch Reverse Engineering auf die Schwachstelle geschlossen und danach der Exploit dafür entwickelt. Da Updates vor allem bei Browser-Plug-ins, wenn überhaupt, nur spät installiert werden, finden Cyberkriminelle selbst nach der Veröffentlichung der Patches immer noch genügend Opfer.

Schwachstellen in Browser und Plug-ins vermeiden

Sowohl Browser als auch Plug-ins sind also bevorzugte Einfallstore für Angreifer. Schwachstellen darin müssen also möglichst vermieden und die unvermeidlich dennoch auftauchenden schnellstmöglich behoben werden.

Patchen, Patchen, Patchen

Im Fall des Flash-Players hatte Google mit seinem in Chrome integrierten Flash Player lange Zeit einen Vorteil gegenüber anderen Browsern. Da Adobe Google die Patches immer frühzeitig übergeben hat, war der in Chrome integrierte Flash Player oft schon gepatcht, bevor Adobe die Patches für den normalen Flash Player veröffentlichte. Beim Internet Explorer 10 ist Microsoft diesem Vorbild gefolgt und hat den Flash Player in den Browser integriert, sodass er nicht mehr separat aktualisiert werden muss. Das wurde bei Microsoft Edge beibehalten.

Das Problem der Angriffe über Schwachstellen, für die die bereitstehenden Patches nicht installiert wurden, wird damit deutlich reduziert. Jedenfalls wenn Benutzer die Microsoft-Updates installieren, was aber zumindest häufiger geschehen dürfte als im Fall der Updates für den Flash Player.

Automatische Ausführung war gestern

Angriffe mit 0-Day-Exploits wird man so aber nicht los. Man kann allerdings zumindest verhindern, dass ein 0-Day-Exploit automatisch ausgeführt wird: Wenn ein Plug-in erst nach Zustimmung des Benutzers aktiv wird, sind zumindest keine Angriffe mehr im Hintergrund möglich. Dieses „Click-to-Play“- oder „Click-to-Run“-Verfahren hat zum Beispiel Oracle für sein Java-Plug-in implementiert.

Man sollte den Schutz aber nicht überbewerten. Da die Drive-by-Infektionen meist über eigentlich vertrauenswürdige Websites erfolgen, werden die meisten Benutzer der Ausführung des Plug-ins bedenkenlos zustimmen. Notfalls können Cyberkriminelle mit etwas Social Engineering nachhelfen, frei nach dem Motto Diese Website funktioniert nur richtig, wenn Sie Java/Flash/… erlauben“. Wer wird da schon nein sagen?

Ganz abgesehen davon, dass sich der Schutz durch das „Click-to-Play“ unter Umständen auch durch eine Schwachstelle unterlaufen lässt – wie es zum Beispiel 2015 mindestens drei Monate lang durch eine 0-Day-Schwachstelle in Java möglich war.

Zu Java und Edge komme ich gleich noch, vorher aber kurz ein paar Worte zum Flash Player. Der lässt sich in Edge nur komplett ein- und ausschalten, „Click-to-Play“ gibt es nicht.

Ich empfehle Ihnen, den per Default eingeschalteten Flash Player einfach einmal auszuschalten und einige Zeit ohne ihn zu surfen. Eigentlich braucht man ihn schon längst nicht mehr, mit HTML5 lässt sich das Gleiche viel zukunftssicherer realisieren. Ohne Flash Player surft man deutlich sicherer und vor allem auch schneller. Wenn Sie Flash wirklich benötigen, können Sie den Player problemlos wieder einschalten.

Plug-Ins gibt es nicht mehr

Am einfachsten löst man das Problem der Angriffe über Plug-ins, indem man gar keine installiert. Wo kein Java-Plug-in installiert ist, kann auch kein bösartiges Applet aus seiner Sandbox ausbrechen und den Rechner kompromittieren. Und wo kein ActiveX Control vorhanden ist, kann auch keine Schwachstelle darin ausgenutzt werden.

Da trifft es sich gut, dass Edge weder ActiveX Controls noch die für Angriffe ebenfalls bereits missbrauchten Browser Helper Objects (BHO) unterstützt – beides ziemlich alte und inzwischen relativ unbedeutende Technologien. Und auch Plug-ins werden nicht mehr unterstützt. Vielleicht, weil das für Plug-ins verwendete Netscape Plugin Application Programming Interface (NPAPI) reichlich veraltet ist, weshalb Google es auch aus Chrome verbannt hat. Vielleicht auch deshalb, weil Microsoft genug davon hatte, sich darüber immer wieder neue Schwachstellen einzufangen. Denn Microsoft schreibt dazu selbst:

„Microsoft Edge … does not support any third-party installable plug-ins. This allows us to build a more secure and more reliable browser to make the Web a safer experience for everyone.“

Browser absichern

Der Flash Player ist unter Kontrolle (auch wenn eine „Click-to-Play“-Funktion wünschenswert wäre), Plug-ins gibt es nicht mehr, damit bleibt nur noch der Browser selbst abzusichern. Neben den Plug-ins war auch der Internet Explorer (IE) selbst bei Angreifern sehr beliebt. Was diese sicher gerne auf Edge übertragen werden, wenn dieser den IE ablöst und die Angreifer eine Möglichkeit dafür finden. Microsoft sollte also besser darauf achten, Cyberkriminellen möglichst wenige Gelegenheiten hierfür zu geben.

Altlasten über Bord …

Zunächst einmal hat Microsoft gründlich ausgemistet und alle Altlasten, die man ohnehin längst nicht mehr braucht, über Bord geworfen. Wie zum Beispiel Plug-ins und ActiveX-Controls, aber noch vieles mehr. Zum Beispiel die „Document Modes“, die in der Vergangenheit bereits für einige Schwachstellen sorgten. Aus Sicherheitssicht hat dieses Ausmisten zwei Vorteile:

  1. Was nicht da ist, kann auch nicht angegriffen werden
  2. Alter Code, der womöglich noch aus der Zeit vor der Einführung des Security Development Lifecycle stammt, enthält erfahrungsgemäß viel mehr Schwachstellen als neu entwickelter Code, bei dessen Entwurf und Implementierung „Sicherheit“ groß geschrieben wurde.

Edges Rendering Engine EdgeHTML ist ein Fork der Rendering Engine Trident des IE, MSHTML. Aus MSHTML wurden mehr als 220 000 Zeilen Code, sechs „Document Modes“ und mehr als 300 APIs entfernt, um eine Ausgangsbasis für EdgeHTML zu erhalten. Dort sind mehr als 300 000 Zeilen Code und 49 neue Features hinzugekommen, und es gab mehr als 4 200 „Interop Fixes“, also Verbesserungen im Zusammenspiel der Komponenten.

Microsoft Passport und SmartScreen

Bei Edge wurde schon im Entwurfsstadium die Sicherheit berücksichtigt. Zum Beispiel durch die Unterstützung von Microsoft Passport [1], um Phishing-Angriffe ins Leere laufen zu lassen – wo es keine Klartextpasswörter gibt, gibt es auch nichts abzuphishen. Um Phishing-Angriffe auf normale Zugangsdaten zu erschweren, wird auf Microsofts Reputationssystem SmartScreen gesetzt, das den Aufruf von Phishing-Seiten verhindert. Die gleiche Technologie wird auch eingesetzt, um Social-Engineering-Angriffe zur Installation von Schadsoftware abzuwehren.

HTTPS-Zertifikate sicherer machen

HTTPS-Zertifikate, die zwar von einer vertrauenswürdigen CA stammen, aber nicht vom Domaininhaber autorisiert wurden, sollen mithilfe von Microsofts Certificate Reputation erkannt werden. Microsoft sammelt über Telemetriedaten Informationen über die für eine Website gültigen Zertifikate. Taucht ein gültiges Zertifikat auf, das von einer anderen als der üblichen CA ausgestellt wurde, wird überprüft, ob es sich um ein legitimes Zertifikat oder einen Angriff handelt. Im Fall eines Angriffs erfolgt eine Warnung. Zusätzlich zu den gesammelten Telemetriedaten können auch die Betreiber der Websites zur Certificate Reputation beitragen, indem sie über die Bing Webmaster Tools die erkannten Zertifikate kontrollieren und ggf. korrigieren.

Das von Chrome, Firefox und Opera verwendete Public Key Pinning, mit dem die HTTPS-Zertifikate an die jeweilige Domain „angeheftet“ werden, wird von Edge bisher nicht unterstützt, ist aber „Under Consideration“. Ab Anfang 2016 wird Edge die als unsicher geltende und von der IETF seit Februar 2015 für TLS verbotene RC4-Verschlüsselung nicht mehr unterstützen.

Websicherheitsstandards unterstützen

Edges Rendering Engine EdgeHTML unterstützt sowohl die Content Security Policy (CSP) zur Abwehr von XSS-Angriffen als auch HTTP Strict Transport Security (HSTS) zur Abwehr von SSL-Stripping-Angriffen.

Über die CSP kann der Server Inline-Skripte verbieten und über eine Whitelist festlegen, ob überhaupt und wenn ja von wo Skripte geladen werden dürfen. Das Gleiche gilt sinngemäß auch für Frames, Bilder, Multimediadateien, Plug-ins, Stylesheets (CSS-Dateien) und Schriften. Außerdem kann festgelegt werden, mit welchen Servern der Browser über XMLHttpRequests, WebSockets und Server-sent Events kommunizieren darf. Ob auch die erweiterte CSP Level 2 implementiert wird, steht noch in den Sternen.

Über HSTS kann eine Website festlegen, dass sie für einen gewählten Zeitraum nur über HTTPS aufgerufen werden darf. Wird die Website mindestens einmal ungestört aufgerufen, wird der Schutz aktiv. Versucht später ein MitM HTTPS- durch HTTP-Links zu ersetzen, verhindert der Browser den Angriff (sofern der Schutzzeitraum noch nicht abgelaufen ist). Zusätzlich zur manuellen Absicherung durch die Server gibt es eine Preload-Liste mit Websites, von denen bekannt ist, dass sie nur HTTPS verwenden. Auf diese Site kann generell nicht über HTTP zugegriffen werden. Selbst dann nicht, wenn ein MitM den HSTS-Header beim ersten Besuch ausfiltern würde.

Und da wir gerade bei Standards sind: Edge unterstützt außerdem die aktuelle Working Draft des Web Cryptography API.

Gegen Angriffe abhärten

Die DOM-Repräsentation im Speicher wurde gegen Angriffe gehärtet. Da Edge eine App ist, wird er in einer Sandbox ausgeführt. Ein möglicher Angreifer erhält also selbst im Erfolgsfall keinen Zugriff auf das System, sondern bleibt in der Sandbox eingesperrt. Jedenfalls solange er nicht über eine entsprechende Schwachstelle aus der Sandbox ausbrechen kann.

Auf 64-Bit-Systemen ist Edge ein 64-Bit-Prozess und profitiert so von den auf diesen Systemen verbesserten Schutzmaßnahmen, insbesondere bei der Address Space Layout Randomization (ASLR). Auch alle anderen aktuellen Mitigations wie der in Edge erstmals zum Einsatz kommende Memory Garbage Collector (MemGC) und die Control Flow Guard (CFG) kommen zum Einsatz.

Der MemGC versucht, Use-after-Free-Schwachstellen zu verhindern, indem die Speicherfreigabe automatisiert wird. Erst, wenn es keine Referenzen auf einen Speicherbreich mehr gibt, wird er freigegeben. Die CFG soll die Manipulation des Kontrollflusses erschweren, sodass der Angreifer darüber nicht die Kontrolle über den Browser übernehmen kann. Ein Angreifer dürfte angesichts dieser Vielzahl von Mitigations einige Probleme haben, eine Speicherverletzung zur Ausführung von Code auszunutzen.

Überblick über die Angriffsfläche von Edge

Mark Vincent Yason vom IBMs X-Force Advanced Research Team hat auf der Black Hat USA 2015 einen Überblick über die Angriffsfläche von Edge und seine Widerstandsfähigkeit gegeben.

Dazu hat er sich zunächst einen Überblick über die Unterschiede zwischen MSHTML und EdgeHTML verschafft. Danach hat er alle Stellen gesucht, an denen ein Angreifer Zugriff auf Edge erhält, zum Beispiel beim Rendern der HTML-Daten, bei der Anzeige von Multimediainhalten, Flash- oder PDF-Dateien etc. Wie zu erwarten war, bringen die neuen Funktionen auch neue Angriffspunkte mit sich.

Nachdem die Angriffspunkte bekannt waren, hat Mark Yason sich die Exploit-Mitigations vorgenommen. Für die allgemeinen Mitigations sind in der Vergangenheit immer wieder Möglichkeiten gefunden wurden, den Schutz zu unterlaufen. Was seitens Microsoft im Allgemeinen zu einer Verbesserung der betreffenden Mitigation geführt hat – beides ist normal. Mitigations erschweren Angriffe nur, sie können sie aber nicht verhindern. Und wenn sie umgangen werden können, sind das Schwachstellen, die natürlich möglichst behoben werden.

Für den in Edge erstmals eingesetzten MemGC sind bisher keine Umgehungsmöglichkeiten bekannt, ebensowenig für seinen Vorläufer Memory Protection. Der wurde aber bereits ausgenutzt, um ASLR zu unterlaufen. Als Fazit bleibt, dass die Mitigations die Exploit-Entwicklung schwieriger und damit teurer machen. Teilweise wird die Ausnutzung von Schwachstellen sogar unmöglich sein.

Theorie gut, und was ist in der Praxis?

In der Theorie ist Edge also sicher. Und wie sieht es in der Praxis aus? Zum jetzigen Zeitpunkt (Ende Oktober) gab es keine Angriffe auf Edge, aber an allen bisherigen Patchdays nach der Veröffentlichung von Windows 10 und damit Edge wurden Security Bulletins für Edge und damit Updates zum Beheben von Schwachstellen veröffentlicht:

  • August (MS15-091, „Critical“): 3 Memory-Corruption-Schwachstellen mit der Möglichkeit, aus der Ferne Code auszuführen (Remote Code Execution, RCE), eine Möglichkeit zum Umgehen der ASLR. Zum Vergleich: In allen noch unterstützten IE-Versionen wurden insgesamt 13 Schwachstellen behoben, die meisten davon RCE-Schwachstellen (MS15-079).
  • September (MS15-095, „Critical“): 4 * Memory Corruption mit Möglichkeiten zur RCE. IE: 17 Schwachstellen, die meisten RCE (MS15-094), zusätzlich ein Bulletin außer der Reihe zum Beheben einer bereits für Angriffe ausgenutzten RCE (MS 15-093).
  • Oktober (MS15-107, „Important“): Möglichkeiten zur Preisgabe von Informationen aus dem Speicher sowie zum Umgehen des XSS-Filters. IE: 14 Schwachstellen, die meisten RCE (MS15- 106).

Das sieht doch sehr gut aus. Vor allem, wenn man bedenkt, wie lange es den IE schon gibt und wie lange darin also schon Schwachstellen behoben werden.

Schutzfunktionen von Edge, IE, Chrome und Firefox

In Tabelle 2 sehen Sie einen Vergleich der Schutzfunktionen von Edge und IE 11 sowie Chrome und Firefox, in Tabelle 3 einen Vergleich der Angriffsflächen von Edge und IE 11.

tab2_eilers_wd1_16

Tabelle 2: Die Mitigations von Edge und IE 11, Chrome und Firefox im Vergleich

Tabelle 3: Die Angriffsfläche von Edge und IE 11 im Vergleich

Tabelle 3: Die Angriffsfläche von Edge und IE 11 im Vergleich

Fazit

Edge ist sicherer als der IE, daran besteht wohl kein Zweifel. Was auch kein Wunder ist, hat man doch reichlich alten Code und alte Funktionen entsorgt, die sicher noch für etliche Schwachstellen im IE sorgen werden. Und da die neuen Funktionen von Anfang an auf Grundlage des Security Development Lifecycle entwickelt wurden, sind sie natürlich sicherer als die, die zumindest teilweise noch vor dessen Einführung entwickelt wurden.

Trend Micro sieht Edge bei der Sicherheit gleichauf mit Chrome, und beide deutlich vor Firefox. Was unter anderem an der fehlenden Sandbox von Firefox und dessen weiterhin vorhandener Unterstützung von Plug-ins liegt. Außerdem fehlt ihm ein JIT-Hardening, und wie bei Chrome gibt es natürlich kein MemGC. Zumindest Letzteres kann sich schnell ändern, wenn Microsoft diese Funktion allgemein verfügbar macht.

Edge ist zwar noch nicht komplett, noch fehlt zum Beispiel die Möglichkeit, Erweiterungen zu installieren. Insofern ist es etwas unfair, ihn mit den voll ausgerüsteten Browsern zu vergleichen. Wenn alle noch geplanten Funktionen implementiert sind, gibt es natürlich neue Angriffspunkte. Aber auch die wird Microsoft bei der Entwicklung berücksichtigt und entsprechend abgesichert haben. Edge dürfte also kaum unsicherer werden, nur weil die noch fehlenden Funktionen nachgeliefert werden.

Links & Literatur

[1] Eilers, Carsten: „Windows 10 und die Sicherheit“, in: Windows Developer 12.2015

Aufmacherbild: Safety concept via Shutterstock / Urheberrecht: Maksim Kabakou

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -