Wenige Meinungsverschiedenheiten gibt es über folgende These: Der Webbrowser gehört zur Topkategorie von Applikationen, wenn es um Sicherheit geht. Wie aber ist die Sicherheit der einzelnen Produkte zu bewerten? Gibt es ein besonders empfehlenswertes Produkt?

Leider gibt es weder wissenschaftliche Modelle noch technische Guidelines, welche die zentrale Frage seriös beantworten: Welches Risiko geht ein User in Realworld Szenarien mit verschiedenen Browsern ein? Es bleibt nur eine zurückhaltende Interpretation einzelner Indizien.

Verletzlichkeiten

Für Aufsehen hat kürzlich eine von Bit9 veröffentlichte “Dirty Dozen” Apps List gesorgt. Die Daten stammen aus der Datenbank des U.S. National Institute of Standards and Technology (NIST). Webbrowser sind in der Hitparade prominent platziert:

1. Google Chrome (76 reported vulnerabilities)
2. Apple Safari (60)
5. Mozilla Firefox (51)
8. Microsoft Internet Explorer (32)

Um eine Vergleichsmöglichkeiten zu gewinnen, habe ich die Verletzlichkeiten der 2009 aktuellen Browserversionen bei Secunia nachgeschlagen. Das ergibt für die drei am weitesten verbreiteten Produkte folgende Zahlen für die relevanten Verletzlichkeiten (moderately, highly und extremely critical):

Google Chrome (5.x 6.x 7.x):   12
Firefox 3.6:   9
IE 8.x:    8

Die publizierten Verletzlichkeiten bilden ein relevantes Indiz. Sie verweisen auf Probleme mit der Codequalität. Vermutlich ist bei Microsoft die Codequalität etwas höher, als die Zahlen auf den ersten Blick vermuten lassen, denn die Aufdeckungsrate von Verletzlichkeiten dürfte beim Marktführer erheblich höher sein. Google hat aus guten Gründen Security bei Features und Produktion von Anfang an hoch gewichtet, in der Praxis scheint aber die Qualität unter der hastigen Entwicklungspace zu leiden. Sollte sich der Aufwärtstrend fortsetzten und Chrome auch mal wie Firefox auf 20% Marktanteil kommen, entfällt der momentane Nischenschutz: Der Angriffsdruck dürfte die Rate der aufgedeckten Verletzlichkeiten steigen lassen.

Die Secunia Zahlen müssen mit Vorsicht interpretiert werden. Sie repräsentieren nicht einzelne Verletzlichkeiten, sondern jeweils ganze Bündel davon.

Patching und Security Features

Verschiedene Browser repräsentieren unterschiedliche Patchingphilosophien: Internet Explorer mit berechenbarem Monatsrhythmus, Firefox mit Hochfrequenz, Google verdeckt. Ganz generell kann nicht von der Überlegenheit eines Modells gesprochen werden. Das hängt vom Anwendungsfall ab. Generell kann den Herstellern attestiert werden, dass sie das Problem ernst nehmen und besser im Griff haben, als beispielsweise Adobe mit seinen Produkten.

Hier kann keine ausführliche Analyse der Security Features geleistet werden. Der Trend geht in die richtige Richtung. Die Infrastruktur des Betriebssystems wird besser genutzt (DEP, ASLR, Integrity Levels, Prozess per Tab). Der Browser wird vom System durch Sandboxing entkoppelt.
Zudem bringen die Browser Mechanismen mit, um üble Sites zu identifizieren, Downloads zu sichern und CrossSiteScripting zu erschweren.

Zusammenfassend

… lässt sich feststellen:

1. Das Qualitätsniveau der führenden Browser ist nicht befriedigend (aber noch problematischer sind einzelne Plugins und die Qualität zahlreicher Websites).

2. Alle drei führenden Produkte bewegen sich in der gleichen Security-Bandbreite.

3. Security ist bei den Browserentwicklern momentan etwas an den Rand gerückt – alles dreht sich um Speed und HTML 5 Kompatibilität.

Das heisst nicht, dass Internet Explorer 9 oder Firefox 4 weniger sicher als die Vorgängerversionen sein werden. Es besteht aber das Risiko, dass die weiten neu codierten Teile (GPU Acceleration etc.) erneut von unangenehm vielen Verletzlichkeiten gespickt sein könnten. 2011 zu beobachten.

Auch wer sich etwas intensiver mit IT-Sicherheit beschäftigt, erlebt immer wieder mal eine Überraschung. Zum Beispiel diese: Aus dem Webbrowser heraus werden keineswegs nur die seit Jahren diskutierten Cookies auf der Maschine deponiert. Cookies erlauben das nützliche Speichern von Parametern über Web-Sessions hinweg. Und damit auch die Identifikation von Userverhalten und Identitätsmerkmalen. Wer das nicht möchte, kann die Einstellungen seines Browsers enger stellen oder von Zeit zu Zeit die Cookies löschen, auch wenn damit ein paar gewohnte Website-Defaults verschütt gehen.

Nun hat kürzlich heise.de auf einen Beitrag von Kate McKinley hingewiesen. Die richtet den Scheinwerfer auf die Local Shared Objects von Flash Player. Diese werden auf Macs, XP oder Vista (1)  abgelegt und entgehen wohl der Aufmerksamkeit der meisten User. Diese Objekte sind nicht geheim, aber problematisch. Laut einer Entwickler-Site können bequemer als per Cookie Daten abgelegt werden. Als User kann man über den Settings Manager auf der Webseite “Flash Player Help“ die Einträge ansehen und die Speicherzuteilung ändern.

Pikant: Wer in den Objekten herumstochert findet etwa auch ein File mPathyUserData.sol – in einem Folder Namens www.heise.de….

(1) C:\Users\xyz\AppData\Roaming\Macromedia\Flash Player

Adobe hat in den letzten Monaten Schritte in Richtung von mehr Code Quality und periodischem Patching gemacht. Die Ansätze des Konzerns bleiben aber ziemlich unübersichtlich.

Es beginnt bei den Produkteinstanzen. Auch manchen Profis dürfte kaum klar sein, wie sich bei Flash das Plugin zum Player verhält. Erst ein gründliches Studium des Dokuments “Adobe® Flash® Player 10 Administration Guide” klärt diese und weitere Fragen. Der Flash Player wird “normalerweise” (Adobe) als Plugin installiert. Dieses gibt es in zwei Formen – als Browserplugin für Firefox und Verwandte sowie als ActiveX für den Internet Explorer. Es gibt den Flash Player auch als standalone Produkt, der ist aber eher für Entwickler gedacht. Weil bei Adobe Dokumenten immer von Flash Player die Rede ist, bleibt häufig offen, was nun genau gemeint ist.

Der Flash Player ist das wohl wichtigste Plugin für Multimedia-Content auf dem Web. Die entsprechenden Verletzlichkeiten sind aufgrund der weiten Verbreitung ziemlich relevant und sollten leicht zu patchen sein.

Updaten periodisch…

Der Flash Player hat eine periodische Versionsprüfung installiert, die beim Installieren auf 30 Tage gesetzt ist. Dieser Default ist wenig tauglich, weil User bei grassierenden Exploits wochenlang nichtsahnend mit einem veralteten Plugin weitersurfen.

Sucht der User unter Programmen oder unter Plugins ein Interface für die Konfiguration des Flash Player, läuft er ins Leere. Wer unter der Hilfe des Acrobat Readers via Updates zu den ‘ Adobe Updater Preferences’ vorstösst, findet keine Spur von Flash.

Für Flash hat sich Adobe einen Weg über den Webserver ausgedacht. Auf der Seite Flash Player Help finden sich die Links zum Settings Manager und dessen einzelnen Reitern. Unter Global Notification Settings lässt sich dann zumindest die Prüf-Periode von 30 auf 7 Tage reduzieren.

Lokale Settings via einen Konzernwebsite verstellen, das ist in Sachen Sicherheit wie Usability einigermassen fragewürdig. Adobe sieht sich denn auch genötigt, die User-Verwirrung mit folgender Bild… sorry: Toolunterschrift zu klären: “Note: The Settings Manager that you see above is not an image; it is the actual Settings Manager.”

Weitere Parameter sind unter Windows nicht etwa in der Registry – sondern in einer proprietären Location qua File mit dem Namen mms.cfg abgelegt. Hier kann Autoupdate beschränkt und konfiguriert werden. Dazu mehr im bereits erwähnten “Administration Guide”. Das Hantieren mit Parameterfiles ist, wie der Titel des Guides sagt, nichts für EndanwenderInnen.

…oder von Hand

Aufgrund der mangelhaft implementierten Automatismen wählen updatewillige User wohl oder übel erst mal den Weg zum Versions-Check mit dem Titel “Version test for Adobe Flash Player”. StudentInnen der Web-Usability können sich hier den Kopf darüber zerbrechen, warum ein Weltkonzern hier dem Anwender das manuelle Nachschlagen überlässt, ob die identifizierte Version auch die neueste ist. Stand der Technik wäre hier eine Diskrepanzmeldung mit dem Angebot zum Download. Immerhin ist im Text ein Link zum Adobe Flash Player Download Center eingebettet.

Während Microsoft die grösste Patchingbaustelle mit einem ziemlich konsistenten Modell bewirtschaftet, kann auf dem zweitgrössten Bauplatz bei Adobe davon keine Rede sein. Die Firma konstatiert mit berechtigtem Stolz: “Flash Player is installed on 98% percent of the world’s desktop computers”. Wie viele davon sind wohl auf dem neusten Stand?

LINKS:

Adobe Flash Player 10 Administration Guide:
http://www.adobe.com/devnet/flashplayer/articles/flash_player_admin_guide.html

Versionscheck
http://kb2.adobe.com/cps/155/tn_15507.html

Installieren / Updaten:
http://get.adobe.com/flashplayer/

Settings Manager:
http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager.html

Browsing Security  10

In den letzten Jahren ist das Thema Sicherheit bei allen Browser-Designern die Prioritätenliste hochgerutscht. Mit verschiedenen Strategien versuchen sie, den User von den Folgen abzuschirmen, die ein Besuch behackter Websites haben kann.

Objekte separieren 

Die Separierung auf Ebene verschiedener Webseiten geschieht zunehmend dadurch, dass jeder Browser-Tab in einem eigenen Prozess des Betriebssystems untergebracht wird. Code einer üblen Webseite kann nicht in andere Prozesse hineingreifen und diese kompromittieren. Prozess-Separierung ist daran, bei allen relevanten Browsern zum Standard zu werden.

Neu wird diese Logik nun auch auf die einzelne Webpage übertragen. Konsequent zu Ende gedacht, muss eine Webpage durch den Browser in einzelne Objekte gegliedert und jedes einer separaten angemessenen Politik unterworfen werden. Das heisst nicht anderes als die Grundstruktur eines Betriebssystems im Browser zu reproduzieren: Ein unabhängiger Kernel kontrolliert die Policies, welche den Spielraum der einzelnen Komponenten und der Interaktion untereinander reguliert. Eine konsistene Implementierung dieser Idee ist noch Zukunftsmusik, es liegt aber ein Prototyp aus dem Forschungskontext vor (1).

Browser vom Betriebssystem entkoppeln

Im Browser kann gelegentlich etwas schief gehen. Das kann aufgrund von Verletzlichkeiten von Browser oder Plugin, durch Unachtsames Klicken des Users oder raffinierte Interaktionen auf dem Website passieren. Wenn der Browser out of Control geraten ist, soll ein Übergreifen auf das System tunlichst vermieden werden. Am weitesten gehen hier die Entwickler des Internet Explorer, die unter Vista einen Protected Mode etablieren, der Virtualisierungsaspekte und besonders tiefe Privilegien für den Browser implementiert.

Filtern und checken

Eine dritte Strategie besteht darin, Filter gegen Phising oder Cross Site Scripting einzubauen und verdächtige Sites gegen eine Blacklist zu checken. Das geschieht etwa beim Firefox durch einen Griff auf Blacklists, die von Google gepflegt werden.

FAZIT. Beim Einsatz avancierter Schutztechniken hat momentan Microsoft die Nase vorn – was nicht heisst, dass Browsen mit dem Internet Explorer darum sicherer ist. Nur schon aufgrund der grossen Verbreitung steht der IE tiefer im Sumpf und weiter draussen im Regen als die Konkurrenz. Darum muss mehr Aufwand getrieben werden, um den AnwenderInnen einen vergleichbaren Schutz zu liefern. IE8 bringt nochmals substantielle Security Verbesserungen. Das ändert aber am grossen Bild nichts: Firefox und Internet Explorer sind valable Alternativen, die in Sachen Browsing Security in der gleichen Liga spielen.

Die Trends der Separierung und Virtualisierung dürften sich vertiefen. Letzendes brauchen wir Browser, die wir auf Wunsch voll virtualisiert betreiben können. Das erspart dann das heute nötige Anwerfen einer virtuellen Maschine.

ABBILDUNG: Mehrere Tabs werden durch IE8 und Chrome in mehreren Prozessen separiert, Firefox hält alle im gleichen Prozess

1) Das Gazelle Browser Projekt

Browsing Security  9

Letzte Woche haben wir in einer Diskussionsrunde zum Thema Browsing Probleme und Lösungsansätze auch über die Möglichkeiten gesprochen, unter Windows Browser sicherer zu machen. Da kommen Plugins und Parametersettings in Frage.

Gewisse Optimierungen gegenüber dem Default-Zustand der Browser sind möglich. Allerdings erscheint Zurückhaltung angebracht. Wenn überhaupt Verbesserungen in Sachen Sicherheit zu erreichen sind, müssen bei Plugins Sekundärrisiken und Pflegeaufwand in Betracht gezogen werden. Grundsätzlich bieten die hier betrachteten Firefox 3.x und Internet Explorer 7.x einen robuste Grundausstattung, die nur selektiv ergänzt oder verändert werden sollte.

JavaScript

JavaScript ist an vielen DriveBy Infektionen beteiligt. Idealerweise sollte man es für alle ausserbetrieblichen Sites wegschalten. Das führt aber zu erheblichen Funktionseinschränkungen und Problemen. Ein siteweises Verwalten des Scripting kann für Poweruser sinnvoll sein, Standardusern aber kaum zugemutet werden.

Firefox: Das Plugin NoScript warnt vor Scripts und erlaubt, für Sites Scripting zuzulassen oder zu blocken.

IE: Unter Internet Options / Security kann für jede Zone ein Custom Level für das Active Scripting gesetzt werden. Der Default für die Zone Internet ist enabled. Wer das auf disabled setzt, muss Websites mit erwünschtem Scripting in eine andere Zone eintragen, zum Beispiel in Trusted.

Firefox mit NoScript ist für Endanwender einfacher zu handhaben. Das Zonenmodell von Internet Explorer bietet out of the Box sinnvolle Settings und kann auch zentral mit Policies verwaltet werden – für Endanwender, die Site für Site Scripts zulassen wollen, ist es umständlicher und weniger granular.

Managed Code

Beide Browser bevorzugen ihre offensichtlich naheliegenden Code-Umgebungen mit einer Politik der offenen Tür. Beim Firefox ist out of the Box Java zugelassen, beim Internet Explorer .NET. In betrieblichen Umgebungen mit erhöhten Sicherheitsanforderungen sollte geprüft werden, ob das wirklich benötigt wird.

Zertifikatsprüfung

Mit Version 3 behandelt auch Firefox hausgemachte Zertifikate als nicht vertrauenswürdig und bringt wie Internet Explorer bei entsprechenden HTTPS Verbindungen eine Warnung. Heise kritisiert allerdings die stiefmütterliche Markierung von Standard SSL-Zertifikaten gegenüber hiEnd EV-SSL. Schwerer ins Gewicht fällt allerdings, dass Firefox die Revocation List von Zertifikatsstellen nicht immer verarbeiten kann.

Ob die Validierung der Zertifikate hinreichend ist oder ob zB die SSL Blacklist Extension für Firefox eingesetzt werden soll, kann in Umgebungen mit erhöhten Sicherheitsanforderungen angesehen werden. Für den Standardbetrieb drängen sich keine Zusatzmassnahmen auf.

Werbeblocker

Das Blocken von Werbung oder zumindest gewisser Teile ist aus Sicherheitsgründen erwünscht, wenn Code mit unbestimmter Qualität von Drittquellen ins Browserfenster eingeblendet wird.

Firefox: Das Plugin Adblock Plus hat in Sachen Funktionalität einen guten Ruf (die Qualität ist schwierig einzuschätzen).

Internet Explorer blockt PopUps (wenn das am Initialisieren zugelassen wurde).

Phishing, Malware Sites

Beide Browser kommen mit Anti-Phising Mechanismen. Firefox greift auf eine Google-Datenbank zu, Internet Explorer auf Microsoft-Listen.

Statt Plugins zu installieren erscheint es sinnvoller, einen Virenschutz mit effizientem Site-Blocker zu betreiben.

Browsing Security 8

Laborumgebungen sind spannend – manchmal spannender als den IT-Verantwortlichen lieb ist. Hier wirkt noch eine Hau-Ruck PC Kultur aus den neunziger Jahren des letzten Jahrhunderts nach. Hintergrund dafür bildet die Produktestruktur.

Da stehen sehr teuer Laborgeräte, die einen PC als Mitbringsel und Steuerkonsole benötigen. Die Produzenten haben vielleicht vor zehn Jahren eine Umstellung auf Windows95 vollzogen. Die Mehrheit der Steuersoftware wurde aber nie spezifikationskonform auf die zeitgenössische Windows-Plattform migriert.

Als Folge laufen viele Rechner mit veralteten Windows- und in einzelnen Fällen sogar mit DOS Versionen. Das alles wäre kein Problem, wenn dieses Rechner-Museum im Schutzraum betrieben würde. Nun ist es aber häufig so, dass Technologie aus den neunziger Jahren ans Internet des neuen Jahrtausends angehängt wird. Damit werden natürlich minimalste Qualitätsanforderungen unterlaufen und es dürfen ein paar good Practices in Erinnerung gerufen werden, die unter Fachleuten kaum umstritten sind.

• Auf Laborrechner und Server gehören weder Webbrowsing noch andere persönliche Internet-Aktivitäten
• Systeme, die in Sachen Betriebssystem und anderen Schutzmassnahmen nicht dem Stand der Technik entsprechen, müssen vom Internet isoliert betrieben werden.

An der ETH Zürich gehört letzteres zum Minimalstandard: “Geräte, die an das Netzwerk der ETH Zürich angeschlossen werden, müssen gegen bekannte Verletzlichkeiten geschützt sein.” Anders gesagt: nicht mehr unterstützte und nicht mehr patchbare Betriebssystem dürfen nicht ans Netz gehängt werden.

Dass User in einem Lab browsen wollen, ist legitim. Das sollte aber auf einer separaten Plattform geschehen.

Browsing Security 7

Menschen bewerten Alltagsrisiken intuitiv. Da wundert es wenig, dass auch die Vertrauenswürdigkeit von Websites primär anhand des look and feel bewertet werden. Eine Studie hat gezeigt, dass so 90% der TeilnehmerInnen getäuscht werden konnten. In der hier besprochene Studie liessen sich gar 97% der TeilnehmerInnen per Mail zum Besuch einer Webpage verleiten.

Manche digitalen Objekte lassen nicht oder nicht eindeutig erkennen, was Urheber und Absichten sind. Da treten ohne weiteres auch IT-Profis und Security-Spezialisten in die Pfütze. Das zeigt, dass IT-Sicherheit nicht wirklich den Endanwendern überantwortet werden kann.

Das sehen auch die Browser-Entwickler so und bauen Warnmechanismen ein, die zwar nicht generell gegen Malware, aber vor Phishing-Websites warnen. Firefox greift auf eine Datenbank von Google, Internet Explorer auf Daten von Microsoft zurück. Eine Studie hat untersucht, wie die AnwenderInnen auf die entsprechenden Warnungen regieren (1). Sie kommt zum Schluss, dass passive Warnungen mit Einfärben des Links oder einem kleinen Icon kaum etwas nützen.

Warnungen müssen auffällig sein und den Arbeitsfluss unterbrechen. In 79% Prozent der Fälle werden solche Warnungen von den Benutzern beachtet. Beim Firefox haben die Testpersonen deutlich besser verstanden, vor welchen Alternativen sie standen, als beim Internet Explorer. IE unterlegt nur eine spezielle Webpage, während Firfox die Arbeitsfläche hinter der Warnung abdunkelt, wie das Windows Vista beim Wechsel in den Admin-Modus bie User Account Control macht. In beiden Fällen eine angemessene Art, den User auf ein Not Business As Usual aufmerksam zu machen.

Es gibt auch beim generellen Design von Warnungen Verbesserungspotential. Dass Browser, Betriebssystem oder Virenschutz mit je eigener Gestaltung und kryptischen Formulierungen auftreten, ist Endanwendern eigentlich nicht zuzumuten.

1) Egelman, Cranor,Hong: You’ve been warned: an empirical study of the effectiveness of web browser phishing warnings.

Browsing Security  6

Gerade mal sechs Minuten brauchte ein Team des Instituts für Internet-Sicherheit an der Fachhochschule Gelsenkirchen, um ein paar hundert Websites auf eine ungepatchte Verletzlichkeit abzusuchen. Das Resultat: Ein Viertel der Webserver hatte drei Tage nach der Publikation den entsprechenden Patch nicht aufgespielt und war unmittelbar angreifbar.

Das untersuchte Produkt Typo3 ist ein Content Management System. Es handelt sich also um professionell betreute Webauftritte von Firmen und Institutionen. Entsprechend waren nach kurzer Zeit Websites von Innenminister Schäuble oder des Fussballclubs Schalke04 behackt.

Der Vorfall wirft ein Schlaglicht auf die ungenügende Qualität vieler Webserver auch im professionell gemanagten Segment. Webserver sind aktiv der Öffentlichkeit angebotene Ressourcen und die Betreiber sollten im eigenen Interesse verhindern, zu Plattformen des Datenklaus und der Malwaredistribution zu werden.

Unverzichtbar ist ein konsistentes Patch-Management für alle Serverkomponenten. Der Faktor Zeit ist bei direkt vom Netz zugreifbaren Server Services viel kritischer als bei abgeschotteten Arbeitsplatzrechnern. Kritische Patches sollten innerhalb von Stunden installiert sein.

Zudem sollten sich die Verantwortlichen an traditionelle Good Practices des Servermanagement erinnern: Wöchentlich die Logs und andere Systemparameter anzusehen, das erscheint bei Webservern keineswegs übertrieben. Auch die Konfiguration und insbesondere die aktiven Features und Services sollten periodisch gecheckt werden.

Im Rahmen von Test oder Projekte rasch Webserver oder Webinstanzen hochzufahren, ist durchaus OK. Sie sollten nach Gebrauch einfach wider weggeknipst werden. Gerade in Hochschulumgebungen bilden verwaiste Webinstanzen einen Kristallisationspunkt von Unannehmlichkeiten aller Art.

Browsing Security 5

Angriffe über den Webbrowser kommen treten in vielen Gestalten aus und basieren teilweise auf raffinierten Techniken. So können auch Webserver zur Verbreitung von Malware eingesetzt werden, ohne dass sie vollständig unter Kontrolle gebracht werden müssen. Die fast unausweichliche Verbreitung des Scripting und die nicht nachvollziehbare Qualität des Contents in Web 2.0 Netzen haben zu einer Diffusion der Browsing Risiken geführt. Anders als vor einigen Jahren, genügt es nicht mehr, dubiosen Websites auszuweichen.

Basierend auf Vorschlägen von Rolf Gartmann (SWITCH) werden hier einige Angriffsszenarien skizziert (1). Das Konzept setzt pragmatisch auf einer handlungsorientierten Ebene an. Wir unterscheiden den absichtlichen Download von Kollateralschäden beim gewöhnlichen Browsen.

Beabsichtigter Download

Den verschiedenen Varianten des Szenarios Beabsichtigter Download ist eine Intention des Akteurs gemeinsam – absichtsvolles Herunterladen von ausführbarem Code auf das System.

In der Grundvariante lädt der Akteur unsignierte Software, Gadgets oder Plugins auf seinen Rechner, deren Herkunft und Qualität er nicht beurteilen kann. Die Palette reicht von Spielen, Infogadgets, Systemtools bis zu Mediaplayern, PnP-Clients oder vorgebliche AntiVirenSoftware.

Technisch betrachtet ist das ein ganz normaler Software-Installationsvorgang im vorhandenen Möglichkeitenraum des Systems. Unter Adminrechten kann das ganze System, unter Standarduser Rechten der Userkontext mit Anwendungen bestückt und so auch kompromittiert werden. In diesem Szenario müssen bei einem OutOfTheBox System weder Verletzlichkeiten von Betriebssystem oder Browser vorhanden sein – auch Browser Scripting ist nicht involviert.

Weitere Escheinungsformen von beabsichtigtem Download erscheinen in bestimmte Kontexte eingebettet. In einer Social Engineering Variante kann zB eine Software mit (teilweise) falschen Versprechen in einem Forum oder als Werbung erscheinen. Bei einem so angeregten Download kann durchaus von Absicht in Bezug auf das Runterladen und das Eingehen eines Risikos gesprochen werden – auch wenn sich die Absicht nicht auf den Malware-Charakter der Software bezieht.

Ebenfalls von beabsichtigtem Download kann gesprochen werden, wenn beim harmlosen Surfen mit einer PopUp Einladung ein Plugin oder eine Software angeboten wird und der Browser eine Zustimmung verlangt. Angemessener wäre es, hier von toleriertem oder akzeptiertem Download zu sprechen.

Drive By

DriveBy Infektionen entstehen im Vorbeigehen, als unerwünschter Nebeneffekt beim Besuch normaler Websites.

Einbettung des Angriffsvektors in einen malwarefreien Webserver: Mit iFrame wird ein Link zu einem Dritten Server eingebettet, von dem mit Hilfe von JavaScript (oder andern Scripten) die Malware in den Browser des Users gebracht. Dort wird eine Browser- oder Pluginverletzlichkeit ausgenützt. Auch einzelne Varianten von Cross Site Scripting funktionieren ohne Kompromittierung des Webservers.

Website kompromittiert. Wenn ein Website behackt ist, können alle Register der Analyse, Kompromittierung und Datenklau von besuchenden Browsern gespielt werden. Beispiel Click Jacking: Eine Page kann so präpariert werden, dass der User scheinbar auf einen Knopf auf der Page drückt, in Wirklichkeit aber ein Security-Feature seines Browsers ausschaltet. Ins gleiche Kapitel gehört der Fall eines kompromittierten Proxies – der beispielsweise Kontoinformation an Dritte weiterleiten kann.

Medienobjekt kompromittiert. Wenn der Browser oder ein Plugin eine entsprechende Verletzlichkeit aufweisen, kann die mit einem kompromittierten Objekt vom ausgenutzt werden, etwa einem Bild oder Video, das beim Abspielen einen Buffer Overflow ausnutzen kann.

Kompromittiertes Plugin. Es kann ein Objekt auf einer Seite erscheinen, das den Download eines Plugins oder einer ActiveX Komponente anstösst. In Standardsettings wird dabei allerdings die Zustimmung des erfragt - darum muss diese Variante eher als beabsichtigter Download charakterisiert werden.

Diese Varianten gehen vom Browsen auf dem eigenen System aus. Der Vollständigkeit halber ist auf das Browsen auf fremden, kompromittierten Systemen hinzuweisen, etwa in einem Internetcafé. Dort können beispielsweise Userdaten abgerufen werden.

Weitere Unterscheidungen sind möglich und können nur kurz angesprochen werden. Unterschieden werden können DriveBy Infektion die für den User völlig unsichtbar ablaufen und solche, wo in einem Stadium noch eine Zustimmung nötig ist.

In der folgenden Tabelle sind die Angriffsszenarien mit wichtigen Eigenschaften aufgelistet:

Zusammenfassung

Wenn sich User entscheiden, dubiose Software auf einem System zu installieren, können das weder Browser noch Betriebssystem verhindern. Besonders übel wirkt sich aus, dass zu diesem Zweck ja meist unter Adminrechten hantiert wird – allfällige Malware kann das leicht das ganze System infizieren. Der User ist ganz vom Retter der letzten Hoffnung abhängig, vom Virenschutz.

DriveBy Infektionen sind auf Scripts und Verletzlichkeiten angewiesen. Die Webprovider haben den BesucherInnen mit der zunehmenden Verwendung von JavaScript einen Bärendienst erwiesen. Scripting lässt kaum mehr generell wegknipsen. Leichter, wenn auch nicht leicht, lassen sich die Verletzlichkeiten von Browser und Plugins durch Patchen bekämpfen.

Wir danken Rolf Gartmann wie auch Dominique Aeschbacher, Fabio Consani und Wolfgang Lierz für Input und Diskussion.

Browsing Security 4

Wenn Malware auf via Browser auf einem Windows-Rechner landet, hat das meistens mit dem wackligen Zustand des Webbroswers zu tun. Hunderte von Millionen Web Enthusiasten leben nach dem Motto: Weder patchen noch upgraden.

Das belegt eine Studie des TIK/ETH vom letzten Sommer, auf die wir gerne nochmals die Aufmerksamkeit lenken (1). Sie postuliert mit Recht das Konzept des „most secure browser“. Darunter wird ganz einfach die neueste Version mit den neuesten Patches verstanden. Die Forscher haben anhand der Daten von Google Webservern herausgefunden, dass beim Internet Explorer (IE) nur 52% und beim Firefox 92% die neueste Version verwenden. Die Lücke ist natürlich nicht gleichzusetzen mit Verletzlichkeiten, denn etwa auch IE6 wird ja weiterhin mit Patches versorgt. Die Lücke ist aber identisch mit “not most secure browser”. Die Autoren betonen, dass die Browser bezüglich Sicherheit Fortschritte gemacht haben und widerstandsfähiger geworden sind.

Zur Patching Aktualität verweist die Studie auf Zahlen von Secunia, die auf eher sicherheitsbewussten Umgebungen basieren. Danach waren im letzten Mai 4,4% der IE7 und 8.1% der Firefox Installationen unter Windows nicht mit den neuesten Patches versehen. Weil IE den Patchinggrad einem Webserver gegenüber nicht offenlegt, konnten die Forscher nur zu andern Browsern eigene Zahlen erheben. Sie identifizierten 16.7% ungepatchte Firefoxes (über alle Betriebssysteme).

Die Studie rechnet weltweit mit über 600 Millionen “not most secure browser” Versionen, was 45% entspricht. Sogar wenn gepatchte IE6 separat betrachtet würden ist klar: Es gibt weltweit einen riesigen Pool von verletzlichen Maschinen, welche den etwa Aufbau von Botnetzen und den Massenversand von Spam ziemlich leicht machen.

Eine Analyse von Symantec zum Conficker-Wurm legt nahe, dass dieser Pool vor allem aus XP Schwarzkopien in den Emerging Markets besteht. Doch auch hierzulande sind nicht einmal betriebliche Umgebungen perfekt gepatcht. Und sogar bevorteilte Populationen wie die Studis sind wohl mit 10-20% suboptimalen Webbrowsern unterwegs. Eine Studie mit Daten von Hochschulservern wäre interessant. Die Hauptfolgerung der Autoren wirkt aber auch ohne weitere Zahlen ziemlich plausibel: “Always use the most recent version of the installed software and instantly apply the latest patches.”

(1) Frei Stefan, Dübendorfer Thomas, Ollmann Gunther, May Martin: Understanding the Web browser threat: Examination of vulnerable online Web browser populations and the “insecurity iceberg” . DOWNLOAD.