Vista und Viren – Wie sicher ist das Betriebssystem?

Das neue Betriebssystem von Microsoft wird als Produkt positioniert, das höchste Sicherheit gewährleistet. Offiziell veröffentlicht wird Vista am 30. Januar 2007, die Frage ist jedoch, ob das angekündigte Sicherheitsniveau auch tatsächlich gehalten werden kann. Was genau bieten die Funktionen, die die Sicherheit der Anwender gewährleisten sollen? Und machen sie das wirklich? Werden mit Vista alle anderen Antivirus-Programme überflüssig? Auf diese Fragen wollen wir einige Antworten geben.

Es ist überaus erfreulich, dass der Hersteller des am weitesten verbreiteten PC-Betriebssystems ernsthaft über die Sicherheit der Anwender nachgedacht hat. Wer Vista installiert, kann zumindest davon ausgehen, dass die Entwickler seriöse Arbeit bei der Integration von Schutzmechanismen geleistet haben – und dies auch weiterhin tun werden. Allerdings sind die zum gegenwärtigen Zeitpunkt umgesetzten Schutzfunktionen von Vista nicht ausreichend, um – ohne sich in Schwierigkeiten zu bringen – auf zusätzliche Schutzprodukte verzichten zu können (siehe hierzu auch den Artikel „Sicherheit von Microsoft: ein Schritt in eine neue Welt?“ von Natalya Kaspersky).

Die wichtigsten Neuerungen im Sicherheitssystem von Vista bestehen in einem Feature zur Abgrenzung der Benutzerrechte mit der Bezeichnung User Account Control (UAC), dem Kernelschutzsystem PatchGuard und verschiedenen Sicherheitsfunktionen des Internet Explorer 7. Auf weniger umfangreiche Schutzfunktionen, wie Address Space Layer Randomization (ASLR), Network Access Protection, Windows Service Hardening und den Schutz vor Buffer Overflows werden wir nicht eingehen. Auch ergänzende Komponenten wie die integrierte Firewall und das Antispy-Programm Windows Defender werden wir nicht betrachten, denn hierbei handelt es sich eigentlich um typische Dritt-Lösungen, die man nur im Vergleich mit ähnlichen Produkten anderer Hersteller beurteilen kann.

User Account Control (UAC) – Benutzerkontenschutz

User Account Control ist ein Feature zur Kontrolle der Benutzerrechte, das auf Beschränkungen der User-Befugnisse basiert:

  1. Jeder beliebige zum System gehörende Benutzer (inklusive dem Administrator) verfügt über minimale Rechte entsprechend der Zugangs-Kontroll-Liste „Standardbenutzer“.
  2. Die Zugangs-Kontroll-Liste „Standardbenutzer“ wurde gegenüber vorhergehenden Windows-Versionen um einige Vollmachten erweitert.
  3. Versucht eine vom Benutzer geöffnete Anwendung eine Aktion auszuführen, die nicht in dieser Liste enthalten ist, verlangt das System eine Bestätigung durch den Benutzer (wenn dieser den Status „Administrator“ hat) oder die Eingabe des Administrator-Passworts (wenn es sich um einen „Standardanwender“ handelt).

Nicht in der Vollmachtenliste für den „Standardbenutzer“ enthalten sind unter anderem die folgenden Aktionen: Installation von Anwendungen und Treibern, Hinzufügen von Dateien in den Systemverzeichnissen sowie Änderungen in der Systemkonfiguration.

Jeder Entwickler von Lösungen zum Schutz vor Schadcodes befand sich schon einmal in der Situation, in der eine im System vollzogene Aktion verdächtig erschien, aber nicht klar war, ob und inwiefern sie tatsächlich schädlich ist. Je nach den Begleitumständen kann so eine Aktion schädlich sein und muss verboten werden, unter anderen Umständen aber kann es sich um eine völlig legale Aktion einer Anwendung handeln. Solche Situationen sind nicht selten, denn es gibt eine Vielzahl von normalen Programmen, die – unter Schutzaspekten betrachtet – potentiell verdächtige Aktionen ausführen. Wird nun jede einzelne dieser Aktionen von einem Informationsfenster mit der Bitte um Bestätigung oder gar um Passworteingabe begleitet, so ist der Anwender bald genervt und deaktiviert vielleicht sogar den Schutzmechanismus.

So gesehen kann ich UAC nicht als ernstzunehmenden Schutz vor Schadprogrammen anerkennen. Eine Funktion, die an den Nerven des Anwenders zerrt, wird mit großer Wahrscheinlichkeit abgeschaltet werden. Oder aber der Nutzer erlaubt die fragliche Aktion, ohne den Inhalt der Mitteilung überhaupt zu beachten.

Trotzdem bietet UAC zweifellos ein zusätzliches Sicherheitsniveau für Anwender mit Administrator-Rechten. Vor allem, wenn eine Anwendung keine umfangreichen Privilegien verlangt – denn dann wird sie auch im Administrator-Modus mit minimalen Rechten ausgeführt. Eine in einer derartigen Anwendung entdeckte Verwundbarkeit ist weit weniger kritisch als eine Verwundbarkeit in einer „hoch privilegierten“ Anwendung.

Es gibt noch einen weiteren Punkt zugunsten von UAC: Es existieren einige Viren, die sich selbst mit einer Warnmitteilung der Firewall oder eines anderen Schutzsystems ankündigen und im entsprechenden Fenster dann auf das Feld „klicken“, das die Aktion zulässt. Dabei erscheint das Fenster nur ganz kurz auf dem Bildschirm. Microsoft hat mit Secure Desktop einen Schutz vor dieser Bedrohung geschaffen: Ein Fenster, in dem um eine Erweiterung der Privilegien ersucht wird, kann nur vom Anwender bearbeitet werden.

Man sollte aber bedenken, dass jeglicher Schutzmechanismus umgangen werden kann, daher sind die Vorteile, die diese neue „Schutzschicht“ mit sich bringt, auch nur bedingt wirksam und – wie die Praxis zeigt – zeitlich begrenzt. Einige recht gefährliche Ideen zur Umgehung von UAC liegen förmlich auf der Hand, die wir hier aber nicht diskutieren werden, um das Wettrüsten nicht auch noch zu verschärfen.

Der Kernelschutz von Vista

1. PatchGuard

Der Kernel von Vista soll – nur bei 64-Bit-Versionen – vor Modifikationen geschützt sein, was im Hinblick auf die immer größere Verbreitung von Rootkits auf Kernelebene wichtig ist.

Ein Rootkit auf Kernelebene ist ein Schadprogramm, das seine Anwesenheit im System durch eine Modifikation des Kernels verbirgt oder das Verbergen über verschiedene Utilities ermöglicht.

PatchGuard enthält eine Funktion, die Veränderungen in den Diensttabellen, den Deskriptoren des Kernel überwacht. Auf den ersten Blick scheint es, als wären damit alle Probleme mit sich verbergenden Trojanern auf einen Schlag gelöst. Allerdings kann PatchGuard kaum als ein wesentlicher Schutz vor Rootkits angesehen werden, denn das System ist schon vom Prinzip her verwundbar – vor allem wegen der genau beschriebenen Methoden zur Deaktivierung des Schutzes. Doch die größte Verwundbarkeit von PatchGuard liegt in der Architektur des Features: Der Schutzcode wird auf demselben Level ausgeführt wie die geschützte Software und auch der Code vor dem geschützt werden soll. Ein solcher Schutz hat dieselben Rechte wie potentielle Angreifer und kann auf irgendeine Weise umgangen oder deaktiviert werden. Techniken zur Ausnutzung und Deaktivierung von PatchGuard sind bereits bekannt.

Wenn PatchGuard schon vor Rootkits, die den Kernel modifizieren, einen nur äußerst zweifelhafter Schutz bietet, so sei noch zu bedenken, dass auch andere Typen von Rootkits existieren, bei denen eine solche Art von Schutzmechanismus ohnehin machtlos ist. Das Monitoring von PatchGuard bezieht sich auf statische Strukturen des Kernel mit vorher bekannten Inhalten (SST, IDT, GDT), doch PatchGuard kann weder dynamische Strukturen noch alles andere, was sich außerhalb der Kernelebene befindet, überwachen. Ein Beispiel für Rootkits, deren Funktion auf Modifikationen dynamischer Strukturen basiert, ist das FU-Rootkit. Auf Virtualisierungs-Techniken basierende Rootkits sind tiefer in der Kernelebene verankert und daher außer Reichweite von PatchGuard.

Die prinzipielle Verwundbarkeit von PatchGuard besteht darin, dass es auf der gleichen Ebene arbeitet, die es schützen soll. Wenn es also einem Schadprogramm gelingen sollte, seinen Treiber zu installieren, so ist es auch in der Lage, PatchGuard auszuschalten. Vorausgesetzt natürlich, dass der Ort der entsprechenden Überwachung bekannt ist – doch wie wir schon seit langem wissen, hat „verbergen“ wenig mit „sichern“ zu tun.

Ein unbestrittener Nutzen des Kernelschutzes vor Modifikationen besteht darin, dass legale Software den Kernel nicht zu ihren Zwecken modifizieren kann, was sich positiv auf die Stabilität und allgemeine Sicherheit des Systems auswirkt.

Das Bestreben von Microsoft, die Stabilität des Systems insgesamt zu erhöhen, hat zu einigen Nebenwirkungen geführt: Da allen Anwendungen der Zugang zum Kernel verwehrt wird, verhindert Microsoft, dass die IT-Sicherheitsunternehmen alle in ihren Produkten enthaltenen Funktionen zum Einsatz bringen können. Das hat zur Folge, dass zum jetzigen Zeitpunkt unter Windows Vista nicht alle Schutz-Features der Antivirus-Hersteller verwendet werden können. Dabei geht es nicht nur um den Schutz vor Rootkits, denn auch proaktive Technologien zum Schutz vor unbekannten Bedrohungen werden in Mitleidenschaft gezogen. Damit befinden sich die Virenschreiber nun in einer besseren Situation: Denn PatchGuard kann von einem Rootkit problemlos ausgeschaltet werden.

Im Zusammenhang mit dem Kernelschutz von Vista sei nochmals betont, dass sowohl PatchGuard als auch die Überprüfung der Treiber-Signaturen nur für 64-Bit-Rechner verfügbar sind. Es wird wohl noch einige Zeit vergehen, bis diese auch für 32-Bit-Systeme verbreitet sind. In Vista x86 gibt es keinen speziellen Schutz vor Rootkits.

2. Mandatory Kernel Mode und Driver Signing

Die zweite Komponente des Kernelschutzes von Windows Vista für 64-Bit-Versionen besteht in der Forderung nach digitalen Signaturen für jedes beliebige Modul oder jeden Treiber auf Kernelebene.

Vorgesehen sind verschiedene Methoden zur Deaktivierung der Signaturüberprüfung, unter anderem auch zur Erleichterung der Entwicklung und des Testlaufs von Treibern. Da sich nun die Frage stellt, wie Treiber-Entwickler vorgehen sollen, zumal es nicht möglich ist eine elektronische Signatur für jedes Build vor dem Testlauf zu erfragen – wurden verschiedene Methoden zur Deaktivierung der Signaturüberprüfung vorgesehen:

  1. das Hinzufügen eines Systemdebuggers
  2. eine Auswahl im Menü des Bootmodus ohne Kontrolle der Treiber (unter anderem über die Modifikation der boot.ini)
  3. Aktivierung von Testsignaturen in der Sicherheitskonfiguration des Unterstützungsmodus. Ein entsprechendes Tool zur Erstellung von Testsignaturen wird bereitgestellt

Diese drei dokumentierten Methoden zur Deaktivierung des Schutzes schaffen für sich genommen schon ausreichend Raum für Experimente. Doch darüber hinaus ist natürlich auch die Suche nach entsprechenden Verwundbarkeiten in vollem Gange. Vor einem halben Jahr präsentierte Joanna Rutkowska ihre Version eines Exploits, in Vista RC2 wurde die entsprechende Schwachstelle beseitigt, ein Präzedenzfall wurde damit allerdings bereits geschaffen.

Eine Vielzahl von Methoden zur Umgehung der Signatur-Pflicht ist zu erwarten: Die Nutzung der dokumentierten Deaktivierungsarten, die Entwicklung von Exploits, das Zulassen von Privilegien auf Kernelebene ohne Treiber und die Ausnutzung des signierten Treibers eines legalen Produkts (ähnlich wie auch Komponenten von Tools zur Wiederherstellung von Passwörtern in verschiedenen Viren zum Raub vertraulicher Informationen ausgenutzt werden).

Und wieder kommen wir zu dem Urteil: Sicherlich schützt die beschriebene Funktion das Betriebssystem vor Schadcode, aber nicht derart effektiv, wie vom Hersteller bekräftigt wird, und ganz sicher kann auch in diesem Kontext von einem absoluten Schutz des Betriebssystems keine Rede sein.

Schutzfunktionen des Internet Explorer 7

Die Schutzfunktionen des Internet Explorer 7 sollen den Anwender – in der Theorie – vor Exploits auf Websiten und der folgenden Ausführung von Schadcodes oder der Installation eines Trojaners schützen.

  1. Im geschützten Modus (Protected Mode) wird der Browser mit sehr geringen Systemrechten ausgeführt, was den Zugriff auf das Dateisystem, die Registry und andere Bereiche einschränkt.

Der geschützte Modus kann vom Benutzer für jede Zone einzeln aktiviert oder deaktiviert werden. In der Standardeinstellung ist er für die vertrauenswürdigen Knoten (in der Trusted Zone) deaktiviert. Darüber hinaus stellt Microsoft ein Protected Mode API zur Erstellung von Verwaltungskomponenten zur Verfügung, die zum geschützten Modus kompatibel sind1. Hierbei handelt es sich um eine völlig neue Funktion, die bisher noch nicht in der Praxis erprobt wurde, was sie mit hoher Wahrscheinlichkeit äußerst verwundbar macht.

  1. ActiveX Opt-in, eine Funktion, die alle ActiveX-Controls grundsätzlich verbietet, es sei denn sie werden vom Benutzer explizit zugelassen.

Es ist unklar, worin hier der Vorteil liegen soll, denn die Möglichkeit der Abschaltung von ActiveX bestand im IE schon immer, mit dem einzigen Unterschied, dass die Abschaltung im IE7 nun grundsätzlich vorgegeben ist. Die Erfahrung mit früheren Versionen des IE zeigt allerdings, dass der Benutzer nicht dazu neigt, ActiveX abzuschalten und damit etwa auch Flash-Animationen auf Webseiten nicht sehen zu können. Oder er fügt sich in sein Schicksal und nimmt die ständig während eines solchen Films auftauchenden Fenster des Schutzsystems in Kauf. Man kommt also zu dem Schluss, dass die Benutzerfreundlichkeit des IE7 stark gelitten hat. (Und die Ausführung unbekannter ActiveX-Elemente kann nach wie vor zugelassen werden.)

  1. Die Funktion Cross-Domain Scripting Attack Protection soll das Interagieren von Scripten zwischen verschiedenen Domains verhindern und den Benutzer auf diese Weise vor Phishing-Attacken schützen.

Dazu sei angemerkt, dass Phishing-Attacken, die Cross-Domain Scripting nutzen, einen nur sehr geringen Anteil der uns bekannten Angriffe ausmachen.

Der IE7 enthält neben den hier aufgeführten drei Funktionen noch eine Reihe weiterer Sicherheitsverbesserungen, wie den Phishing Filter und den Security Status Bar.

Worin liegen die Unzulänglichkeiten?

Nehmen wir einmal eine fiktive, abstrakte Firewall als einfachstes Beispiel für einen Barrieren-Schutz. Es ist klar, dass es sich hierbei um eine „kluge“ Firewall handelt, die nicht nur auf Grund von Listen erlaubter und verbotener Programme funktioniert, sondern auch die Ereignisse im System mit einbezieht. Versucht ein Programm, Informationen ins Netz zu übermitteln, so stellt das eine Bedrohung der Sicherheit dar. Die Firewall kann nun auf zwei Arten reagieren: a) die Aktion wird in Übereinstimmung mit der Sicherheits-Policy (die eventuell vom Benutzer selbst konfiguriert wurde) verboten, oder b) der Anwender wird um Erlaubnis gefragt. Im ersten Fall werden unweigerlich auch legale Programme blockiert, was durchaus ein gewisses Ärgernis darstellt. Der Benutzer muss nun herausfinden, aus welchem Grund das Programm nicht funktioniert und es dann auf die weiße Liste der Firewall setzen. Im zweiten Fall öffnen sich zwangsläufig viele Fenster, auf die der User dann reagieren muss. Welches der beiden Übel das geringere ist, vermag man kaum zu sagen.

Ist es bei einer Firewall, die die Aktivitäten der Anwendungen verfolgt, noch möglich, die Anzahl der störenden Warnmitteilungen durch den Ausbau der weißen Liste mit der Zeit zu verringern, so ist dies mit einem allgemeinen Schutz nicht machbar. Die Bedrohungen sind unberechenbar und vielfältiger Natur, und die darauf folgende Reaktion sollte nicht starr sein, ansonsten landen wir bei Variante a) und aufgezwungenen Beschränkungen. Wenn die Reaktion allerdings nicht starr ist, so wird sie reizbar.

Sicherheit auf der Grundlage von Beschränkungen bedeutet Sicherheit auf Kosten der Benutzerfreundlichkeit.

Schutz vor Viren unter Vista?

In Vista für 64-Bit-Versionen wird es besonders für jene Trojaner eng, die Treiber und Modifikationen des Kernels nutzen – allerdings nur, bis sie diese Beschränkungen eines Tages umgehen. Die erwähnte Gruppe von Trojanern ist vergleichsweise klein und macht einen Anteil von weniger als 5% an der Gesamtanzahl aller Windows-Viren aus. Vista für die momentan am weitesten verbreitete 32-Bit-Plattform enthält keine Funktion zum Schutz des Kernels und damit auch keinen Schutz vor dieser Art von Trojanern.

Das Feature User Account Control ist ein von der Plattform unabhängiger Bestandteil von Vista. „Bedingt beeinträchtigt“ wird davon ein merklicher Prozentsatz von Trojanern, deren Aktivität Rechte auf Administrator-Ebene erfordert (wie etwa das Recht zur Erstellung von Dateien im Systemverzeichnis, zur Modifikation der Registry, zur Konfiguration des Autobootens usw.). „Bedingt beeinträchtigt“ zum einen, weil man UAC – wie oben gezeigt – nicht als ernstzunehmenden Schutz vor Viren betrachten sollte, zum anderen, weil es für ein Schadprogramm immer die Möglichkeit gibt, auch unter noch so stark eingeschränkten Rahmenbedingungen Schaden anzurichten. Würmer, die sich in Peer-to-Peer-Netzen ausbreiten, vollziehen beispielsweise keine illegalen Aktionen, sie erstellen einfach eine Kopie ihrer selbst in den Verzeichnissen, die zum Dateiaustausch verwendet werden. Ein Beispiel für einen – trotz seiner konzeptionellen Einfachheit – überaus gefährlichen Virus ist der Aufsehen erregende Gpcode, der die Dokumente des Benutzers verschlüsselt und anschließend Lösegeld für die Dechiffrierung fordert.

Wie der Schutz des IE7 sich auf Viren auswirkt, die sich über Websites verbreiten, ist schwer vorherzusagen. Höchstwahrscheinlich gar nicht – zumindest auf lange Sicht. Insbesondere wenn man in Betracht zieht, dass kaum jemand Lust dazu hat, mit einem Browser zu arbeiten, der alles verbietet.

Fazit: Ist Vista sicher?

Ist Vista also sicher, so wie es die Produktwerbung glauben machen will? Ja, zweifelsohne ist Vista sicherer als die vorhergehenden Systeme von Microsoft. Ein System, in dem alles, bis auf den Zugriff auf bestimmte Sites, verboten ist, kann auch als absolut unantastbar angesehen werden.

Allerdings sind für die Mehrzahl der Benutzer einschneidende Beschränkungen, die das System geradezu steril erscheinen lassen, unannehmbar, ebenso wie ständige Bestätigungsanfragen oder Aufforderungen zur Passworteingabe für Aktionen, die vom System als „potentiell gefährlich“ eingestuft werden. Und genau das ist der Punkt, an dem sich das „fast völlig sichere“ System in ein „zunehmend verwundbares“ verkehrt.

Außerdem sollte man bedenken, dass der Mensch das schwächste Glied in jedem beliebigen Sicherheitssystem darstellt. E-Mail-Würmer sind noch nicht ausgerottet und verbreiten sich nach wie vor, ungeachtet der zahlreichen Warnungen von Sicherheitsexperten, verdächtige Anhänge in elektronischen Nachrichten auf keinen Fall zu öffnen. Wenn derartige Warnungen die Mehrzahl der User nicht davon abhalten, E-Mail-Anhänge zu öffnen, warum sollten sie dann anders mit Warnmitteilungen des Sicherheitssystems verfahren, das sie zum Beispiel auffordert, das Administrator-Passwort einzugeben? Und der Benutzer tendiert – wie schon vorher angeführt – dazu, ein Schutzsystem, das ihn mit einer Unmenge von Fenstern belästigt, abzuschalten.

Erschwerend kommt hinzu, dass – gerade auf Grund der Popularität von Microsoft – die gesamte Welt der Computer-Kriminalität sich auf die Suche nach einer Schwachstelle im System machen wird. Wir – als unverbesserliche Optimisten – berücksichtigen dabei nicht einmal, wie sich Microsoft vom Standpunkt der Sicherheit aus innerhalb vieler Jahre der breiten Anwendung bewährt hat. Die Sache ist die, dass die Anzahl und Qualität von Barrieren zum Schutz gegen Hacker keine besonders große Rolle spielen. Vielmehr stacheln sie den Forscherdrang der Online-Kriminellen nur noch weiter an. Was einzig eine Rolle spielt, ist die Tatsache, dass Hacker und Virenschreiber eine Verwundbarkeit suchen werden. Und wenn sie erst einmal angefangen haben zu suchen, werden sie auch fündig.

Philosophische Schlussfolgerung

Ein Sicherheitssystem, das auf irgendetwas anderes als Offenheit gegründet ist, ist immer ein zweischneidiges Schwert. Ein System, dem Beschränkungen zu Grunde liegen, hat immer eine Kehrseite, nämlich die Beschränkungen selbst, die das System zur Benutzung ungeeignet machen können.

Was ist unterm Strich also vorzuziehen? Ein „insgesamt sicheres“ System, das dem Benutzer nicht erlaubt, das zu tun, was er möchte, oder ein unter Umständen verwundbares, aber benutzerfreundliches und den User nicht einschränkendes System, in Verbindung mit einem hoch spezialisierten Service, der sich auf den Schutz vor konkreten Bedrohungen konzentriert?

Freiheit schafft Bedrohungen – Beschränkungen mindern die Flexibilität. Je größer die Beschränkungen sind, desto unangenehmer wird die Verwendung des Systems. Selbst wenn man das ideale Gleichgewicht zwischen Beschränkungen und Benutzerfreundlichkeit finden könnte, gilt es zu bedenken, dass bisher jede Schutzbarriere irgendwann überwunden oder umgangen wurde – vorausgesetzt, hinter der Barriere verbirgt sich etwas Interessantes.

  1. Authentium blog, Microsoft Patchguard
  2. Joanna Rutkowska, “Introducing Stealth Malware Taxonomy”
  3. Joanna Rutkowska, “Subverting Vista Kernel for Fun and Profit”
  4. Windows Vista Security Guide

1Das Protected Mode API (appilcation programming interface) ermöglicht es Software-Herstellern, Erweiterungen und Add-Ons für den Internet Explorer zu entwickeln, die mit dem Dateisystem und der Registry interagieren, während sich der Browser im geschützten Modus befindet.

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.