Browsing Security  3

Eine wasserdichte Bewertung der Sicherheit von Webbrowsern ist kaum realisierbar. Ideal wäre ein gross angelegter Test in repräsentativen Real World Umgebungen. Da würden nicht nur die Qualität des Browsers, sondern auch die Bedienerfreundlichkeit der Security-Features und der reale Angriffsdruck unter dem Strich in eine Impact-Statistik einfliessen. Das erscheint als kaum realisierbares Vorhaben. Bleibt also nur das willkürliche Mixen zufälliger Argumente übrig? Nützlich im Hinblick auf eine sachliche Diskussion erscheint, sich zuerst über sinnvolle Kriterien Gedanken zu machen und dann deren Operationalisierung offenzulegen. So kann immerhin die sicherheitsmässige Qualität eines Produkts eingeschätzt werden.

Ein erstes Kriterium ist die Verletzlichkeitsrate, die über die Zahl der relevanten Verletzlichkeiten und den Patchingbedarf Auskunft gibt. Die Qualität der Patchingmechanismen entscheiden zweitens darüber, wie kurz die Exposition einer Verletzlichkeit gehalten werden kann. Browser Security Features sollen ein Eindringen von Malware und oder Datenklau auf Applikationsebene verhindern. Die Unterstützung von OS Security Features härtet das Gesamtsystem. Eine vernünftige Out of the Box Konfiguration hilft vor allem selbstadministrierenden Endanwendern.

Ist ein Set von vernünftig wirkenden Kriterien gefunden, stellt sich die Frage, wie jedes Kriterium in konkrete Fragestellungen umzusetzen und dann und auf das empirische Material anzuwenden ist. Da bestehen viele Möglichkeiten. Im folgenden werden provisorische, summarische und diskussionswürdige Einschätzungen von Firefox 3 und IE 7 vorgenommen.

Verletzlichkeitsrate
Als Indikator für die securityrelevante Codequalität nehmen wir die 2008 bekannt gewordenen kritischen Verletzlichkeiten, dokumentiert in den Advisories von Secunia. Betrachtet werden Advisories mit der Einstufung moderat, hoch oder extrem kritisch. Darin werden die einzelnen Verletzlichkeiten gezählt. IE7 kommt 2008 auf 22, der Mitte Juni veröffentlichte Firefox 3.x auf 25. Auf ein Jahr hochgerechnet macht das für IE 22 und für Firefox 43 Verletzlichkeiten. Dass die Zahlen beim Firefox trotzt geringerem Angriffsdruck erheblich höher sind, kann einerseits auf Probleme mit der Codequalität deuten und andererseits auch auf die Offenheit des Quellcodes zurückgeführt werden. Auch IE kann nicht wirklich glänzen. In Sachen Verletzlichkeitsrate kriegt Firefox das Rating UNBEFRIEDIGEND und IE ein BEFRIEDIGEND.

Patchen / Exposition
Die beiden Produkte weisen unterschiedliche Patching Mechanismen auf. Das ergibt erhebliche Unterschiede im Hinblick auf die betriebliche Handhabung, die an anderer Stelle detaillierter besprochen werden müssen. Firefox hat einen konfigurierbaren standalone Updatemechanismus. Nach Bedarf wird gepatcht, meist in Forme eines neuen Releases. IE ist ins Windows Update eingebunden und patcht dementsprechend nach Termin, abgesehen von Sondersituationen. 2008 haben beide Produkte alle kritischen Verletzlichkeiten gepatcht und erhalten beide das Rating GUT.

Browser Security Features
Beide Browser machen durch ihre Ausstattung deutlich, dass Security ein wichtiges Problem und anerkanntes Anliegen ist. Grundlegende Mechanismen wie sind vorhanden. Die anspruchsvolle Cross Site Scripting Prävention ist erst in Ansätzen entwickelt. Die Implementierung mancher Features involviert den User mit Warnungen und Entscheidungen – da ist noch nicht das Optimum erreicht. Beide bekommen das Rating BEFRIEDIGEND.

Unterstützung OS Security Features
Leute, die einigermassen sicher browsen wollen, wählen das entsprechende solideste Produkt in einer Betriebssystem-Familie. Bei Windows ist das Vista. Gegenüber von Windows XP bietet Vista zusätzliche Security-Features, die von einem Webbrowser unterstützt werden sollten.
Integrity Levels für Prozesse und Objekte verhindern unter Vista einen Zugriff niederwertiger Prozesse auf höher eingestufte Entitäten. Wird von IE angemessen (low) genutzt, Firefox läuft unter dem Standardlevel.
Address Space Layout Randomization (ASLR) lädt Systemkomponenten in zufällige Speicheradressen und erschwert ein Ausnutzen von Buffer Overflows. Von beiden Browsern genutzt.
Applikations-Virtualisierung leitet Schreibvorgänge unter Vista in Files und Registry Keys in virtuelle Locations um. Nur von IE unterstützt.
Data Execution Prevention (DEP) wurde bereits unter XP entwickelt. Mit DEP können Speicherbereiche als Daten markiert werden, die nicht ausgeführt werden dürfen. Bei Firefox ON, bei Internet Explorer OFF (muss manuell aktiviert werden)

Zusammenfassendes Rating bei OS Security Features: Firefox BEFRIEDIGEND, IE GUT.

Out of the Box Konfiguration
Die ist keine eigentliches Security-Feature, wird hier aber einfach aufgrund der praktischen Bedeutung beleuchtet. Viele Endanwender und auch manche Administratoren übernehmen diese Seetings mit geringen Änderungen. Bei Firefox kann ein Vorbehalt angebracht werden, dass Java enabled ist. Die Grundkonfiguration der beiden Browser ist vernünftig und das Rating GUT.

Zusammenfassung

Eine summarische Bewertung der einzelnen Kriterien führt zu einem erfreulichen Schluss. Die beiden betrachteten Browser bieten einen passablen Securitystandard und zeigen sich sicherheitsmässig im gleichen Band. Im Hinblick auf eine Wahl können also funktionale, ergonomische und betriebliche Aspekte in den Vordergrund rücken. Damit kommen eine ganze Reihe weiterer Gesichtspunkte ins Spiel wie: Erweiterbarkeit, Usability, Transparenz (auf Ebene Engineering und Source Code), Kompatibilität oder Handhabbarkeit in zentral gemangten Umgebungen (Deployment von Patches und Policies). Bei sicherheitsmässiger Gleichwertigkeit kann also die Frage ins Zentrum rücken, welcher Browser bei geringstem Aufwand den besten Nutzen abwirft.
Aussagen von der Art „X ist sicherer als Y“ lassen sich in dieser Allgemeinheit kaum begründen. Wichtiger als die Wahl des einen oder anderen Produkts ist, die aktuellste Version mit allen Patches zu verwenden. Und eine Reihe von weiteren Elementen zu beachten, die beim (un)sicheren Browsen involviert sind.

Diskussion

Einen Entwurf dieses Materials habe ich einigen Windows Experten vorgelegt, die mehrere kritische Punkte in die Diskussion einbringen:

• Praxisnähe: Zwei Kollegen haben grossen Wert darauf gelegt, dass eine Beschäftigung mit dem grossen Thema „Browsing Security“ praxisrelevante Ergebnisse hervorbringen soll. Es wird die Frage aufgeworfen, wie weit konzeptionelle Arbeiten dazu dienlich oder nötig sind.
• Kriterienset: Im grossen Ganzen wird das Top Down Vorgehen zur Browserbewertung als sinnvoll und das vorgeschlagene Kriterienset als nützliches Ausgangsmaterial bewertet.
• Verletzlichkeiten / Codequalität. Ein kritischer Einwand bezieht sich auf den Vorschlag, die Verletzlichkeiten einfach unter dem Titel Codequalität abzuhandeln. Das halte ich für teilweise berechtigt und habe das Kriterium nun als Verletzlichkeitsrate statt dem ursprünglichen Code Quality gefasst.
• Ebenfalls mit dem Thema Codequalität befasst sich ein schriftlicher Kommentar, der sich auch mit der Weiterentwicklung der Untersuchungsmethodik beschäftigt: „Bezüglich Code Qualität kann natürlich extrem in die Tiefe gegangen werden, wobei meines Erachtens nicht direkt von der Anzahl aufgedeckten Verletzlichkeiten auf die Code Qualität verlässlich Rückschlüsse gezogen werden können – viel mehr müssen da weitgreifende Aspekte wie das QA Program von MS und Code Audit Vorgänge auf den offenen Source Code von Firefox etc. mit einbezogen werden.“ Dabei ist wahrscheinlich vor allem „die Reaktionszeit vom Auftreten bis zur Patchverfügbarkeit und die Dauer bis dieser die End-Anwender erreicht hat, massgebend und relevant.“ Bei der Code Beurteilung muss unterschieden werden: „Geht es nur um Qualität im Bezug auf die Sicherheit oder soll z.B. die Stabilität/Zuverlässigkeit generell bewertet werden. Diese Faktoren werden dann sicherlich im Aufbau des konkreten Fragenkataloges definiert, wären aber vieleicht schon vorgängig sinnvoll grob abzustecken.“
• Betrieblich: Ein Admin, der den Usern weitere Browser über Applikations-Virtualisierung anbietet, nennt betriebliche Gründe für seinen Einsatz von Internet Explorer:
  „- schnelle Patchreaktion von Microsoft (Zero-Day Kriterium)
  - automatisches Patchen ohne admin-Rechte dank WSUS
  - granulare und vollständige Konfiguration und Kontrolle mit GPOs
  - Automatisches Deployment“
• Transparenz, Erweiterbarkeit. In der Diskussion wurde nicht ohne Berechtigung vorgeschlagen, Kriterien wie die Transparenz des Source Codes, Erweiterbarkeit oder das Angebot von Plugins als Kriterien aufzunehmen. Die Securityrelevanz dieser und weiterer Elemente (wie Usability, Handhabbarkeit) ist unbestritten. Ich schlage eine Differenzierung vor und würde diese Aspekte in einer zweiten Gruppe von mittelbaren Securitykriterien unterbringen. Elemente wie die Sichtbarkeit des Quellcodes oder die Erweiterbarkeit korrellieren nicht eins zu eins mit Security, sondern in einer ziemlich komplexen Weise, die zu analysieren und diskutieren wäre.

Ich bedanke mich bei Thomas Berchtold, Andreas Jost , Jacques Laville und Thomas Widmann für Diskussion, Kritik und Anregungen.

Browsing Security  2

Wer sich etwas eingehender über Browsing-Risiken Gedanken macht, kommt nicht um einen Blick auf die globale Szenerie herum. Wirtschaftliche, rechtliche und kulturelle Verhältnisse öffnen nicht nur die Spielräume der Cyberkriminalität, sondern bestimmen auch die Vorstellungen, mit denen Endandwender am Netz agieren. Besonderes brisant und interessant ist der diffuse Mediencharakter von Web, Websites und Browsern.

Das Web spannt einen öffentlichen Raum auf, in dem sich für Anbieterinnen und Nachfrager, für Kooperative und Selbstdarstellerinnen völlig neue Möglichkeiten geöffnet haben. Die Zeiten blumiger Verklärung des Cyberspace sind allerding seit den Malware-Pandemien vor einigen Jahren vorbei. Eine zahlenmässig sehr kleine Anzahl Akteure erzeugt einen erheblichen Angriffsdruck. Die negative Effekte prasseln vor allem auf EndanwenderInnen und Kleinfirmen nieder. Kriminelle agieren mit einem geringen Risiko. Das ist auf ungeeignete Regulierung zurückzuführen, wie auf das bloss punktuelle Agieren der Strafverfolgungsbehörden. Die Sicherheit im Cyberspace hat durchaus eine politische Dimension. Es ist dem anhaltenden Pionierzeitalter wie auch dem fehlenden öffentlichen Druck zuzuschreiben, dass Web und Mail nicht als öffentliche Services bewertet und mit Qualitätsstandards geschützt werden. Obama meinte im letzten Sommer: “As president, I’ll make cyber-security the top priority that it should be in the 21st century.” Wir werden sehen, wie sich das entwickelt.

Es wäre verfehlt, die Verantwortung einfach der Politik zuzuschieben. Auch die Internet nahen Branchen machen nicht unbedingt eine gute Figur, wenn es um das Durchsetzen von Standards und Praktiken geht. Teileweise gibt es auch Interessenlagen, die mit der Cyberkriminalität konvergieren – etwa bei der Security-Industrie oder den Netzprovidern. Der Not der Stunde gehorchend haben punktuelle Massnahmen wie das Blacklisting einzelner IP-Nummern Akzeptanz gewonnen. Weiter führen würde eine Selbstverpflichtung der Provider etwa in den OECD Ländern. Wer als Provider minimale Standards nicht einhält, würde einfach keinen Traffic mehr kriegen. Jedenfalls stehen die institutionellen Player in der Pflicht, mehr dafür zu tun, dass der öffentliche Raum des Internets auch für die schwächeren Teilnehmer wieder etwas wohnlicher wird.

Besonders interessant und relevant sind die medialen und kulturellen Aspekte des Internets. Relevant hier deswegen, weil die sie die Vorstellungen und Bilder im Kopf des Anwenders prägen, mit denen er und sie sich ans Navigieren im Internet machen. Unter uns gesagt spielen diese Aspekte auch bei Profis ein erhebliche Rolle. Die Komplexität ist einfach zu gross, um sich bei jedem Blick auf eine Webpage eine detaillierte Vorstellung davon zu machen, was technisch gerade passiert. Enduser sind auf Gedeih und Verderb auf die Widerstandsfähigkeit ihres Systems angewiesen und erinnern sich im besten Fall noch an zwei, drei Faustregeln. Kurz und gut, wir leben mit einer gewissen Überforderung durch die neuen medialen Realitäten.

Mildernd könnte eine mediale Differenzierung wirken. Statt einen einzelnen Browser mit immer mehr Funktionalitäten vollzustopfen, wären verschiedene Typen sinnvoll. Massenmedien Browser mit elementaren Medienformaten, ohne Script und andere aktive Komponenten. Rich Media Browser mit erweiterbaren Medientypen und Downloadfunktionalitäten. Komponenten Container als Browser vor allem für betriebliche Umgebungen, wo nach Lust und Laune ActiveX und Java Applets verteilt werden könne. Entsprechend müssten sich auch Websites mit massenmedialem Anspruch ein elftes Gebot merken: Du sollst dem Besucher keinen lauffähigen Code aufs Auge drücken!

Browsing Security 1 

Das Besuchen (DriveBy) von Websites ist seit längerem der wichtigste Infektionsweg, auf dem Malware in Computer gelangt. Im folgenden sollen die verschiedenen Stufen betrachtet werden, über die der Angriff verlauft. Dabei entsteht ein einfaches Schichtenmodell einer DriveBy Infektion.

Ein Schichtenmodell erleichtert die Risikobeurteilung und zeigt, dass Browsing Security nicht nur den Webbrowser betrifft. Es wird auch sichtbar, dass auf verschiedenen Ebene Abwehr- und Optimierungsmöglichkeiten bestehen.

Der Browser als Eingangsporte kann in ganz unterschiedlichen Szenarien erscheinen. Etwa auch mit Papierbrief, der zum Download eines Programms einlädt. Wir hier von einer Szenario kritischen Verletzlichkeit aus, wie sie bei Internet Explorer oder Firefox immer wieder bekannt werden. Was muss passieren, damit eine noch nicht gepatchte (und allenfalls gar nicht öffentlich bekannte…) Verletzlichkeit ausgenutzt werden kann?

Malware. Gefährliche Malware muss geschrieben und ausgewildert werden. Hier geht die Beliebtheit eines bestimmten Browsers in die Betrachtung ein: für Verletzlichkeiten wenig verbreiteter Browser wird weniger Malware geschrieben.

Kontaktpotential. Wenn nicht umgehend ein Patch bereit liegt muss auf einige Tage hinaus das Kontaktpotential der eigenen Maschinen mit malwarebestückten Websites einschätzt werden. Das Kontaktpotential ist die Überlappung zwischen der Verbreitung der Malware und dem Browsing Horizont der eigenen Maschinen. Der Browsing Horizont wird durch das Verhalten der User und durch allfällige Einschränkungen auf Firewall oder Proxy bestimmt. Üblicherweise entwickelt sich das Kontaktpotential nicht explosionsartig. Es ist wenig wahrscheinlich, dass vielbesuchte Websites behackt und stundenlang Tausende von Maschinen infizieren. Vorherrschendes Muster ist, dass eher marginale Websites über Wochen oder Monate hinweg anfällige Besuchermaschinen anstecken.

Firewall, Proxy. Sie können sowohl das Kontaktpotential durch Blocken von Traffic beschränken

Virenscanner. Der Fall einer öffentlich diskutierten ungepatchten Verletzlichkeiten gehört wohl zu den stärksten Szenen von Virenscannern, weil da mit Hochdruck an Signaturen für sich ausbreitende Exploits gearbeitet wird. Generell darf aber die Wirksamkeit von Virenscannern nicht überschätzt werden – und die Qualitätsunterschiede sind riesig.

Widerstandsfähigkeit, Resilienz. Wir gehen hier ja von der Existenz einer ungepatchten Verletzlichkeit aus. Wenn die Malware auf die Maschine gelangt, können auch Widerstandsmechanismen des Browsers und des Betriebssystems verhindern, dass sie sich installieren kann. Ein Beispiel wäre eine Buffer Overflow, der zwar ausgelöst werden kann, aber wegen Adress-Randomisierung in einer Sackgasse verläuft.

Userintervention. Häufig wird der Download lauffähiger Software vom Browser oder vom Betriebssystem als problematische identifiziert und dem User ein Dialog präsentiert. Stimmt der User dem Install entgegen seinen Interessen zu?

Kompromittierungstiefe. Während unter Adminrechten das ganze System potentiell zugreifbar ist, kann unter Standarduserrechten nur der Userkontext kompromittiert werden. Das ist zwar nicht harmlos (wenn es unentdeckt bleibt) – aber weniger gravierend als eine Kompromittierung des Systems selbst. Ein Löschen des Userkontexts entfernt die Malware; Rootkits können nicht installiert, Virenschutz und Firewalls nicht abgeschaltet werden.

Abschliessend kann festgehalten werden, dass die grosse Masse der Drive By Infektion nicht nach einem Epidemiemuster ablaufen, sonder eher wie das leise Rieseln von Schnee. Es darf auch nicht vergessen werden, dass ein wesentlicher Teil der DriveBy Infektionen (im weiteren Sinn) gar nicht auf einer Verletzlichkeit basieren, sondern auf Social Engineering. Den Usern wird erfolgreich ein Install angeboten.

Das Diagramm zeigt die verschiedenen Schichten, die eine Malware zwischen Produzent und dem Zielsystem durchläuft.