1. AV-Scanner als Schwachstelle
Wie wir in den beiden vorangegangenen Artikeln der Serie aufgezeigt haben, sind AV-Scanner nicht das Allheilmittel gegen Schadsoftware, als das sie gerne dargestellt werden. Vielmehr können die eher mäßigen Erkennungsraten von neuer Schadsoftware und die teilweise gravierenden Schwachstellen in der AV-Software selbst, die Gesamtsicherheit eines Systems erheblich beeinträchtigen.
Aktuell ist bspw. Microsoft Malware Protection Engine von einer kritischen Schwachstelle betroffen, die Millionen von Rechnern weltweit bedroht. Diese Schwachstellen werfen daher zunehmend die Frage auf, ob der Einsatz eines AV-Scanners vielleicht nicht mehr schadet, als dass er nutzt. Ferner stellt sich natürlich auch die Frage, ob ein Virenscanner wirklich so alternativlos ist, oder ob vielleicht auch etwaige, weniger einschneidende Maßnahmen existieren, um sich zu schützen.
Im letzten Beitrag der Serie möchten wir deshalb präventive Maßnahmen und Strategien vorstellen, die nach unserer Auffassung das Risiko vor einer Infektion erheblich reduzieren können. Wir möchten darauf hinweisen, dass diese Maßnahmen in keinem Fall als abschließend zu verstehen sind, sondern eher als Einstieg und Anregung gedacht sind und es gilt, diese Maßnahmen im Einzelfall auf seine persönlichen Bedürfnisse anzupassen.
Hinweis
Gegen die aktuell grassierende Ransomware WannaCry konnten AV-Scanner (auch diesmal) nicht schützen. Wie wir bereits im ersten Teil der Serie aufgezeigt haben, sind insbesondere die Erkennungsraten von neuer Schadsoftware gering bis praktisch nicht vorhanden, weil noch keine passenden Viren-Signaturen bereitstehen und andere Methoden zur Erkennung meist versagen.
- Antiviren-Scanner: Mehr Risiko als Schutz? – Snakeoil Teil1
- Antiviren-Scanner: Nur ein Sicherheitsgefühl? – Snakeoil Teil2
- Alternativen zu Anti-Viren-Software – Snakeoil Teil3
2. AV-Scanner als Stand der Technik
Heutzutage stellen AV-Scanner nach wie vor einen bedeutenden Teil eines IT-Sicherheitskonzepts von Unternehmen und Organisationen dar. Ferner gilt der Einsatz eines AV-Scanners noch immer als Stand der Technik und wird als wichtiger Schutzschild im Kampf gegen Schadsoftware angesehen. Doch dieser weit verbreiteten Einschätzung können wir uns nicht vorbehaltlos anschließen. Denn wie wir in den vorherigen Artikelteilen aufgezeigt haben, besteht die Möglichkeit, dass der Einsatz von AV-Software oftmals zu einer (weiteren) Gefährdung führt. Sei es durch eine Schwachstelle in der Scanner-Software selbst oder bspw. aufgrund der Aushebelung der systemseitig implementierten Sicherheitsmaßnahmen durch die AV-Software, um ihren Scan durchführen zu können.
Bis AV-Scanner den Status »Stand der Technik« einbüßen, dürfte ein IT-Verantwortlicher vermutlich auf deren Einsatz nicht verzichten wollen. Würde er nämlich auf AV-Scanner verzichten, müsste er bspw. in einem Schadensfall etwa seinem Vorgesetzten, der Aufsichtsbehörde, dem Gericht usw. explizit darlegen, weshalb er durch den »Nicht-Einsatz von AV-Software« die Anforderungen des Stands der Technik missachtet hat. Um seinen »Hals« aus der Schlinge zu ziehen, müsste er aufzeigen, dass auch ein Einsatz eines AV-Scanners diesen Vorfall nicht verhindert hätte. Die Beweisführung, ob und wie ein AV-Scanner einen Sicherheitsvorfall verhindert hätte, ist in der Praxis kaum möglich, weshalb immer ein Restrisiko besteht. Aufgrund des mit einem Verzicht des Einsatzes von AV-Software verbundenen Risikos, im Ernstfall umfassend Zeugnis ablegen bzw. einen entsprechenden Beweis führen zu müssen, wird daher die Mehrheit der IT-Verantwortlichen dieses Risiko vermutlich (verständlicherweise) nicht tragen wollen.
Der Einsatz eines AV-Scanners wird daher in der Praxis nach wie vor als »alternativlos« angesehen. Doch diese Sichtweise ist nicht unproblematisch. Denn nicht zuletzt in einem (zunehmend auch gesetzlich vorgeschriebenen) Risikomanagement, gilt es sich mit den (rechtlichen und technischen) Risiken, die mit dem Einsatz von (kommunikationsfreudiger) AV-Software einhergehen, auseinanderzusetzen. Setzt man sich in dieser Analyse offen und ehrlich mit den Risiken des Einsatzes von AV-Software auseinander und prüft die weiteren, zur Verfügung stehenden technischen und organisatorischen Maßnahmen, dürfte schnell deutlich werden, dass der Einsatz von AV-Scannern doch nicht so alternativlos ist, wie er gerne dargestellt wird.
Bevor man sich jedoch mit den jeweiligen Maßnahmen im Detail auseinandersetzt, sollten man sich zunächst mit den beiden am häufigsten vorkommenden Infektionswegen von Schadsoftware auseinandersetzen.
3. Präventive Maßnahmen und Strategien
3.1 Infektionswege
Einer der häufigste Infektionswege ist, dass eine Schadsoftware eine bestehende Sicherheitslücke in bereits installierter Software bzw. dem Betriebssystem ausnutzt. Da zunehmend alles mehr oder weniger mit dem Internet verbunden ist, nimmt das Internet eine zentrale Rolle bei der Verbreitung von Schadsoftware ein.
Ein beliebtes Angriffsziel sind insbesondere Browser und deren Addons, bei denen Angreifer versuchen bestehende Schwachstellen auszunutzen. Gelingt ihnen dieses, sind sie je nach Schwachstelle in der Lage, zusätzlichen Schadcode zu laden, der dann, wenn er ausgeführt wurde anfängt bspw. die Festplatte zu verschlüsseln oder sensible Zugangsdaten von den infizierten Rechnern auszuspähen. Dass Angreifer den Browser zum Verbreiten von Schadsoftware ausnutzen ist kein Zufall. Denn dieser ist der »Schlüssel« zum Internet, mit dem wir sowohl private als auch berufliche Aufgaben erledigen. Ferner bieten Browser ein hervorragendes Angriffsziel, denn sie sind über die Jahre zu einem hochkomplexen Werkzeug geworden, das keiner mehr beherrschen kann.
Im Idealfall werden Schwachstellen in Soft- oder Hardware von IT-Sicherheitsforschern entdeckt, die den Hersteller über die Lücke informieren. Oftmals finden Hersteller auch durch ihre, (falls durchgeführten) Überprüfungen der Soft- / Hardware selbst entsprechende Sicherheitslücken. In diesen beiden Fällen sind sie grundsätzlich in der Lage, die Lücke(n) zu schließen, bevor jemand zu Schaden kommt oder diese Lücke vermehrt in Angriffen ausgenutzt wird. In der Praxis werden Schwachstellen allerdings oftmals auch von Kriminellen oder Geheimdiensten entdeckt. Aufgrund ihrer eigenen Motivationen diese Lücken für ihre Zwecke möglichst lange Zeit ausnutzen zu können, melden sie diese Sicherheitslücken (vielfach) nicht an den Hersteller. Derartige Schwachstellen werden, weil sie dem Hersteller (größtenteils) nicht bekannt sind und diese Lücke damit, weil sie nicht geschlossen wird, praktisch unendlich lange ausgenutzt werden kann, als sog. Zero-Day-Lücke (0-Day) bezeichnet. Laut der Studie »Zero Days, Thousands of Nights« können und werden solche Zero-Day-Lücken deshalb im Durchschnitt sieben Jahre lang erfolgreich ausgenutzt!
Die zweite Möglichkeit einer Infektion besteht darin, dass die Schadsoftware vom Nutzer selbst zur Ausführung gebracht wird, indem er bspw. einen nicht vertrauenswürdigen E-Mail Anhang einfach öffnet.
Eine weitere Möglichkeit sich unfreiwillig mit einer Schadsoftware zu infizieren, ist der Erwerb eines bereits »verwanzten« Produkts. Gerade vor wenigen Tagen wurde bspw. in den HP-Business-Notebooks ein Audio-Treiber gefunden, der alle Tastatureingaben (inkl. Passwörter) vom Nutzer protokolliert. Häufig sind auch Smartphones betroffen, die von Werk aus bspw. über die Schadsoftware Adubs alle privaten Daten eines Android-Geräts sammlen und unbemerkt Apps installieren können.
Die (häufigsten) Infektionswege nochmal zusammengefasst:
- Eine Schadsoftware nutzt eine bestehende Sicherheitslücke aus
- Ein Nutzer installiert sich die Schadsoftware selbst
- Die Schadsoftware ist bereits in Soft- oder Hardware integriert
Angesichts der eher mäßigen Erkennungsraten und gravierenden Sicherheitslücken von AV-Software stellt sich unweigerlich die Frage, ob nicht vielleicht andere, weniger einschneidende Schutzmaßnahmen existieren, um ein System vor dem Befall durch Schadsoftware zu schützen.
3.2 Regelmäßige Updates
Wie auch die durch Google durchgeführte Umfrage von »Sicherheitsexperten« belegt, stellt das regelmäßige Einspielen von (System-) Updates (vermeintlich) eine sehr wichtige Maßnahme gegen bekannte bzw. bekanntgewordene Sicherheitslücken dar. Wie diese Umfrage jedoch auch zeigt, findet diese eigentlich nachvollziehbarste Schutzmaßnahme, bei einem durchschnittlichen Anwender noch immer zu wenig Beachtung. Das hat zur Folge, dass Angreifer meist alte, bekannte Sicherheitslücken in Software ausnutzen, die vom Hersteller eigentlich längst beseitigt wurden.
Gerade weit verbreitete Softwareprodukte wie Betriebssysteme (insbesondere Windows), Internet-Browser (Firefox, Chrome, Safari), Java, Adobe PDF- Reader, Flash oder Microsoft Office sind ein beliebtes Angriffsziel und ein häufiges Einfallstor für Schadsoftware, insbesondere wenn bei ihnen keine aktuellen Patches bzw. Updates eingespielt wurden.
Da auf einem Anwendersystem oftmals eine Vielzahl an unterschiedlichen Softwareprodukten installiert sind, für die in regelmäßigen Abständen Patches bzw. Updates vom jeweiligen Hersteller herausgegeben werden, ist das alleinige Einspielen von regelmäßigen Patches / Updates nur für das jeweilige Betriebssystem noch längst nicht ausreichend. Vielmehr sollten alle auf dem System installierten Anwendungen, Plug-Ins, Browser-Erweiterungen etc. stets auf dem aktuellen Stand sein und gehalten werden. Diese unserer Ansicht nach sehr nachvollziehbare Anforderung stellt einen Anwender in der Praxis jedoch vor nicht unerhebliche Herausforderungen. Zum einen muss er zunächst einmal überhaupt wissen, welche Software eigentlich alles auf seinem PC installiert ist. Ferner muss er für diese Software ständig nach Updates Ausschau halten, zumal nicht jede von ihm installierte Software einen sog. Update-Checker integriert hat.
Bei Windows-Systemen können aber bspw. Tools wie der Personal Software Inspector den Nutzer dabei unterstützen, das Betriebssystem und alle darauf installierten Anwendungen, stets auf aktuellem Stand zu halten. Letztendlich gilt für das Updaten von Software daher eine einfache aber umso bedeutsamere Regel:
Wenn du etwas installiert hast, dann update es auch.
Die Verantwortung regelmäßig (Sicherheits-) Updates einzuspielen, liegt deshalb beim Anwender bzw. Administrator des Systems und kann auch nicht durch den Einsatz etwaiger AV-Software ersetzt bzw. kompensiert werden.
Hinweis
Das träge Updateverhalten von Unternehmen und Privatanwendern sorgt aktuell für die rasche Verbreitung der Ransomware WannaCry. Ein Patch für die Sicherheitslücke wurde bereits vor knapp zwei Monaten von Microsoft zur Verfügung gestellt. Gerade im Unternehmensumfeld ist die verspätete Installation von Sicherheitsupdates hochgradig verantwortungslos.3.3 Systemhärtung / Reduktion auf das Wesentliche
Wie bereits im zweiten Artikel dargestellt, gilt im Bereich der IT-Sicherheit, das durchaus sinnvolle und nachvollziehbare Prinzip von »keep it small and simple« (KISS) zu beachten. Auf die Praxis angewendet bedeutet dieser Grundsatz, dass je weniger Komponenten auf einem System installiert sind, umso weniger potenzielle Schlupflöcher / Einfallstore für Schadsoftware kann es folglich geben.
Dieses in der IT-Sicherheit anerkannte, durchaus nachvollziehbare Prinzip wird jedoch zunehmend von Software-Herstellern und insbesondere von Betriebssystem-Herstellern nicht ausreichend beachtet. Denn standardmäßig werden viele dieser Systeme mit einer Vielzahl an Programmen, Schnittstellen und Diensten ausgeliefert bzw. installiert, die der Anwender jedoch für seine Bedürfnisse eigentlich gar nicht benötigt. Das Installieren von eigentlich nicht benötigten Software-Komponenten steigert jedoch wie aufgezeigt die Komplexität des Systems und vermindert damit gleichzeitig dessen Beherrschbarkeit. Ferner wird durch diese zunehmende Komplexität die nachhaltige Systemabsicherung erschwert.
Um ein System halbwegs sicher zu bekommen bzw. es soweit wie möglich absichern zu können, sollte ein System standardmäßig auf die wirklich essentiellen Funktionen beschränkt sein / werden. Es gilt sich deshalb auf die benötigten Komponenten zu reduzieren. Daher sollte auch nur die Software installiert werden, die der Nutzer zur Erfüllung seiner Aufgaben wirklich benötigt.
Der Ansatz, sich auf das Notwendige zu reduzieren, wird in der Praxis oftmals auch als Härten (engl. hardening) bezeichnet. Das Härten wird insbesondere bei Server-Systemen durchgeführt, die aufgrund ihrer ständigen Erreichbarkeit und ihrer Komplexität aufgrund der installierten Komponenten, meist ein beliebtes Angriffsziel darstellen. Auf einem Desktop-System, einem Smartphone – oder ganz allgemein auf einem »Consumer-System« – lässt sich eine Härtung jedoch oftmals nicht ohne weiteres (ohne tiefe Eingriffe in das jeweilige System vorzunehmen) durchführen. Vielfach lassen sich nämlich systemseitig vorinstallierte Programme nicht ohne weiteres bzw. ohne entsprechende Hilfsmittel löschen. Auch das Abschalten von für die Nutzung eigentlich nicht notwendiger (System-) Dienste, ist bei modernen Betriebssystemen nicht so einfach möglich.
Nach unserer Auffassung sollte man (was wir ja auch bspw. mit unserem Projekt »Your Phone – Your data« aufzeigen wollten), trotz der von den Herstellern vorgenommenen Schutzmaßnahmen auch als Nutzer versuchen, diese Systeme soweit wie möglich zu »entkernen«. Dieses insbesondere deshalb, um selber halbwegs die Übersicht und Kontrolle über diese zu behalten. Daher sollte man auch bei diesen Systemen versuchen, diese soweit wie möglich zu härten, um dadurch die Angriffsfläche für Schadsoftware zu verringern. Dabei sollten insbesondere folgende Aspekte beachtet werden:
- Softwareumfang reduzieren: Um das System zu härten gilt, dass nur die Programme auf dem Rechner verbleiben sollten, die tatsächlich auch benötigt bzw. genutzt werden. So empfiehlt es sich für einen Nutzer oftmals, bspw. das vorinstallierte Java zu deinstallieren, wenn er dieses nicht nutzen will. Dieses Vorgehen reduziert nicht nur die Angriffsfläche auf das System, sondern reduziert auch die Zeit, die die Installation von regelmäßigen, umfangreichen Software-Updates erfordert.
- Schnittstellen deaktivieren: Moderne Rechner oder Smartphones sind mit einer Vielzahl an Schnittstellen / Sensoren wie Wi-Fi, Bluetooth, Kamera, Mikrofon, NFC usw. ausgestattet. Besonders die nicht verwendeten Schnittstellen sollten, da sie durchaus weitere Angriffsvektoren darstellen, systemseitig deaktiviert werden. Idealerweise lassen sich nicht benötigte Schnittstellen wie etwa die Kamera bereits im BIOS eines Systems deaktivieren. Damit sind sie für das (nachträglich gestartete) Betriebssystem nicht mehr erkennbar und damit auch quasi nicht verfügbar.
- Dienste abschalten: Häufig wird durch die Installation von Software ein (Netzwerk-) Dienst bzw. Netzwerk-Port auf dem System geöffnet. Ferner ist es auch denkbar, dass das Betriebssystem durch seine Standardkonfiguration selber, derartige Portöffnungen vornimmt. Kritisch sind diesbezüglich insbesondere jene Dienste, die vom Netzwerk aus (und damit oftmals auch vom Internet) erreichbar sind wie bspw. der in Windows vorhandene SMB-Dienst. Um die Angriffsfläche möglichst gering zu halten, empfiehlt es sich deshalb, derartige Dienste zu deaktivieren oder so zu konfigurieren, dass sie lediglich nur vom eigenen System (localhost) erreichbar sind.
Hinweis
Auch auf dem Blog wurde das Thema »Systemhärtung« bereits in der Artikelserie »Linux härten« vorgestellt.3.4 Stärkung des Sicherheitsbewusstseins
Im Zusammenhang mit AV-Scannern liest und hört man häufig die Aussage
die größte Schwachstelle ist immer der Nutzer.
Dieser Sichtweise können und wollen wir uns nicht vollumfänglich anschließen. Denn erstens sollte man beachten, dass Software nie fehlerfrei sein kann und der Nutzer nicht in der Lage ist, zu evaluieren, welche Fehler die von ihm eingesetzte Software eigentlich alles hat. Software ist deshalb etwas, auf das sich der Nutzer, weil er die Sprache der IT nicht spricht, verlassen bzw. ihr vertrauen muss.
Weil der Nutzer derjenige ist, der (vermeintlich) die IT bedient, ist er logischerweise auch immer derjenige, der mit seinen Handlungen eine Infektion ermöglichen kann. Aber im Gegenzug ist er auch derjenige, der, wenn er umsichtig und selbstreflektiert mit der IT umgeht, eine Infektion durchaus auch verhindern kann, insbesondere wenn ihn eine »fehlerhafte Schutzsoftware« nicht ausreichend schützt.
Doch der umsichtige und selbstreflektierte findet auch schnell seine Grenzen, denn oftmals wird der Nutzer auf perfide Art und Weise getäuscht und zu einer Handlung psychologisch »gezwungen«. So gilt es sich zu vergegenwärtigen, dass Angreifer mit immer ausgefeilteren (psychologischen) Methoden arbeiten, um Anwender über ihre wahren Motive zu täuschen und sie dadurch bspw. zur Ausführung von Dateien zu bewegen. Insbesondere die Technik des sog. Social Engineerings wird von Angreifern immer weiter verfeinert und gilt als äußerst erfolgversprechend. Laut BSI geht dabei das höchste Bedrohungspotenzial z. B. für Industrial Control Systems von »Social Engineering und Phishing« aus.
Als Social Engineering wird eine Vorgehensweise bezeichnet, bei der die vermeintliche »Schwachstelle« Mensch ausgenutzt wird. Der Angriff richtet sich demnach nicht primär gegen einen Computer, sondern gegen dessen (menschlichen) Benutzer. Social Engineering nutzt gezielt menschliche Eigenschaften wie Hilfsbereitschaft, Gutgläubigkeit oder Unsicherheit von Nutzern aus, um dadurch an vertrauliche Informationen zu gelangen oder das Opfer zu bestimmten Aktionen zu bewegen. Mit Hilfe psychologischer Tricks und Beeinflussungstechniken wird deshalb bspw. versucht, den Nutzer dazu zu bewegen, dass er einen schadhaften E-Mail Anhang öffnet oder über eine gefälschte Webseite (Phishing) seine persönlichen Daten preisgibt. Sowohl technische, als auch organisatorische Sicherheitsmaßnahmen lassen sich deshalb verhältnismäßig einfach mittels Social Engineering unterwandern.
Technische Gegenmaßnahmen, die wirksam vor Social Engineering schützen, gibt es bis heute kaum. Wirksamstes Mittel hinsichtlich der Behandlung von mysteriösen E-Mail Anhängen, dürfte daher ein gehöriges Maß an Misstrauen des Nutzers sein. Um ein solches Misstrauen zu schaffen, muss beim Anwender jedoch ein entsprechendes Sicherheitsbewusstseins für den Umgang mit IT geschaffen werden. Es sei jedoch diesbezüglich auch angemerkt, dass gegen geschicktes Social Engineering Aufklärung allerdings auch nur bedingt hilft, wie bspw. Studien der US-Militärakademie West Point gezeigt haben.
Angesichts der immer komplexeren und ausgefeilteren Angriffe, derer sich Nutzer heutzutage ausgesetzt sehen, äußert deshalb auch der IT-Sicherheitsspezialist Bruce Schneier in einem Interview seine Zweifel, ob es überhaupt wirksame, präventive Maßnahmen gegen Social Engineering geben könne…Wie vorstehend dargestellt, stellt daher der Nutzer (der Mensch) einen bedeutenden Teil der Informationssicherheitskette dar. Er ist damit das größte Risiko aber auch eine der wichtigsten Schutzinstanzen im Bereich IT. Aus unserer Sicht ist daher eine gezielte, praxisorientierte, ehrliche und auf die Nutzerinteressen zugeschnittene Aufklärung, die auf »Panikmache« verzichtet, ein essentieller Baustein zur Stärkung des vermeintlich »schwächsten Glieds« in der Kette. Dieses ist insofern essentiell, als dass bis zur Erfüllung der Forderung von Bruce Schneier, Systeme zu entwickeln, bei denen der Nutzer nicht versehentlich einen schadhaften E-Mail Anhang ausführt Realität wird, wohl noch einige Zeit ins Land ziehen wird.
Neben den vorstehend aufgeführten Grundsicherheitsmaßnahmen sollte man für sich bzw. für seine Organisation auch analysieren, ob sich für den Umgang mit IT möglicherweise die nachfolgend dargestellten erweiterten Sicherheitsmechanismen eignen.
4. Erweiterte Sicherheitsmechanismen
Da man sich als Verantwortlicher / Nutzer über die »Unzulänglichkeit« von Hard- und Software im Klaren sein sollte, gilt es sich mit Maßnahmen auseinanderzusetzen, um das Risiko einer Infektion verbunden mit den damit einhergehenden Folgen, soweit wie möglich zu reduzieren. Dabei gilt es sich immer darüber im Klaren zu sein, dass es nie eine »100%ige Sicherheit« beim Einsatz von IT geben kann. Ferner gilt es sich darüber im Klaren zu sein, dass es nicht die »eine für alles passende« Maßnahme geben kann. Vielmehr gilt es sich vor Augen zu führen, dass Informationssicherheit immer ein Bündel an sinnvollen Maßnahmen erfordert, was es umso schwerer macht im Einzelfall zu entscheiden, welche Maßnahmen für mich persönlich, in meinem Fall, nun die richtigen sind. Daher sollen im Nachfolgenden einige von uns als sinnvoll erachteten Maßnahmen vorgestellt werden.
4.1 Schutz gegen 0-Days
Um die Ausnutzung bisher unbekannter (0-Day-) Sicherheitslücken zu erschweren, existieren diverse Sicherheitstechniken wie bspw. die im vorherigen Artikel bereits angesprochene Address Space Layout Randomization (ASLR) oder der Einsatz von sog. Stack Cookies / Canary, die einen Pufferüberlauf (engl. Buffer-Overflow) erschweren sollen. Aber auch Konzepte wie das Application Whitelisting, bei dem eine Art Berechtigungsliste (Whitelist) definiert, welche Anwendungen, wie vom Nutzer ausgeführt werden dürfen, können das Risiko der Ausnutzung von 0-Day-Lücken minimieren.
Erweiterte Kontrollmöglichkeiten bieten darüber hinaus diverse Sicherheitsframeworks, wie AppArmor oder SELinux, die insbesondere in der Linux-Welt bekannt sind und vermehrt eingesetzt werden. Diese Frameworks basieren auf dem sog. Mandatory-Access-Control-Konzept (MAC). Dieses Modell ermöglicht es, den Zugriff auf die unterschiedlichsten (System) Ressourcen feingranular zu steuern. Auf der Basis von Subjekten und Objekten lässt sich damit anhand entsprechender Regeln definieren, ob bspw. der Zugriff einer Software auf einen Prozess, eine Datei oder ein Netzwerkdienst ermöglicht wird, oder der entsprechende Komponente ein Zugriff verwehrt bleibt. Vereinfacht ausgedrückt regelt daher ein solches Modell:
Wer, wie auf welche Ressourcen eines IT-Systems zugreifen darf.
Unterstütze den Blog mit einem Dauerauftrag!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
4.2 Sandbox
Wie bereits in Artikel 1 der Serie dargestellt, verwenden immer mehr AV-Softwareprodukte eine sog. Sandbox, um in dieser potenzielle Schadsoftware ohne Konsequenzen für die übrige Systemsicherheit prüfen zu können. Dieses Sandbox-Prinzip ist grundsätzlich für alle Betriebssysteme interessant. So ermöglicht es eine Sandbox dem Nutzer, Dateien in dieser vom Rest-System »abgeschlossenen Umgebung« auszuführen, ohne prinzipiell negative Auswirkungen auf das eigentliche System fürchten zu müssen.
Sowohl für Windows (Sandboxie), MacOS (App Sandbox), als auch Linux (bubblewrap, Firejail) stehen derartige Sandboxes bereit, die es wie vorstehend beschrieben ermöglichen, Programme isoliert vom restlichen Betriebssystem auszuführen.
Bei all den vorstehend aufgezeigten Sicherheitsmechanismen gilt es sich jedoch immer vor Augen zu führen, dass auch diese keinen hundertprozentigen Schutz vor Schwachstellen bzw. Zero-Day-Lücken bieten können. Jedoch stellen sie eine wichtige Ergänzung dar, um das mit dem Betrieb von vernetzter IT einhergehende Risiko des Befalls durch Schadsoftware erheblich zu reduzieren.
5. Fazit
AV-Scanner gelten bei vielen Ottonormalanwendern noch immer als eines der Hauptschutzmaßnahmen im Kampf gegen Schadsoftware. Gleiches ist auch in Unternehmen und Organisationen zu beobachten, bei denen sich IT-Verantwortliche am Stand der Technik orientieren.
Angesichts der in unserer Artikelserie aufgezeigten Schwächen, eignen sich AV-Scanner nach unserer Auffassung jedoch nur bedingt, um ein System und die darauf befindlichen Daten, nachhaltig vor Schadsoftware zu schützen. Vielmehr sollte diesbezüglich immer auch bedacht werden, dass eine AV-Software selbst, aufgrund der Menge an möglicherweise in ihr schlummernden und noch nicht gefundenen bzw. veröffentlichten Sicherheitslücken, ein Einfallstor für Schadsoftware darstellen kann.
Nach unserer Auffassung ist, wie durch die vorstehenden Ausführungen deutlich werden sollte, AV-Software nicht alternativlos. Denn wie aufgezeigt, existieren durchaus (weitere) sinnvolle Alternativen, um eine adäquate »Sicherheit« zu schaffen.
Autoren:
Über den Autor | Kuketz
In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.
Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
Antiviren-Scanner: Mehr Risiko als Schutz? – Snakeoil Teil1
Antiviren-Scanner: Nur ein Sicherheitsgefühl? – Snakeoil Teil2
Trügerische Sicherheit: Virenscanner-Apps sind schlichtweg überflüssig
F-Droid und App-Alternativen – Android unter Kontrolle Teil3
F-Droid und AFWall+ – Android ohne Google?! Teil4
37 Ergänzungen zu “Alternativen zu Anti-Viren-Software – Snakeoil Teil3”
Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
Woher kommt die Information das AV Software gegen WannaCry nichts genutzt hat?
(Eigene Tests, oder irgendwelche berichte oder nur eine Vermutung weil es so gut zum Thema passen würde?)
Ich weiß zumindest von einer stelle wo AV Software am Freitag deswegen angeschlagen und dass ausführen verhindert hat.
Außerdem ist in einigen detaillierteren Meldung über befallene Systeme davon die rede das dort keinerlei AV Software eingesetzt wurde.
Upload eines Samples bei Virustotal. Erkennungsrate über das Signaturverfahren der AV-Scanner: 0%. Fefe hat sogar einen Screenshot gemacht:
Gegenfrage: Ist dir ein Scanner bekannt, der abseits vom Signaturverfahren, WannaCry über eine andere Erkennungsmethode erkannt hätte? Ich meine bevor die Signaturdatenbanken geupdatet wurden.
Klar. Wer das Update nicht eingespielt hat, den hat es mit hoher Wahrscheinlichkeit erwischt. Ob AV-Software oder nicht, spielte keine Rolle.
Fazit: AV-Scanner konnten uns vor der raschen Ausbreitung also nicht bewahren und werden das auch in Zukunft nicht können. Jetzt wo die Schadcode-Signatur bekannt ist eventuell verlangsamen. Aber da hilft auch ein einfaches Einspielen eines Security-Patches – dafür braucht es keinen AV-Scanner, der zusätzliche Lücken ins System reißt und Millionen von Nutzern in falsche Sicherheit wiegt.
Eine kleine Relativierung: Man sieht im Screenshot, dass es sich beim File, das man hier auf VirusTotal geprüft hat, um ein PDF handelt. Ich vermute deshalb, dass es sich hier nicht um den Trojaner selbst, sondern „nur“ um einen Downloader handelt (via JavaScript im PDF drin). Es ist natürlich schlimm, wenn ein solcher Downloader als völlig unbedenklich taxiert wird, und das unterstreicht sicher die Probleme heutiger AV-Software; es wäre aber trotzdem interessant gewesen, zu diesem frühen Zeitpunkt den Trojaner selbst d.h. das .EXE-File durch VirusTotal scannen zu lassen…
Das ist jedoch ein unrealistisches szenario, da bei immer nur der downloader bzw stager verteilt wird um den eigentlichen schadcode entschlüsselter nur direkt im Ram zu haben.
Jedes kommerzielle oder open-source RAT macht das auch nicht anders.
Daher ist dieses szenario vollkommen unrealistisch, da es dir nichts bringt wenn der AV die finale stage auf der HDD erkennen würde, diese aber nie auf der HDD landet.
Da muss ich widersprechen: Bei einigen mag das so sein, dass man den eigentlichen Schadcode nie auf der Platte sieht, aber sicher nicht bei allen. Beim weitverbreiteten Cerber-Ransomware-Trojaner weiss ich aus erster Hand, dass dieser unter den Filenamen „exe1.exe“ und „exe2.exe“ sehr wohl in der Windows-Temporär-Directory zu finden ist, nachdem der Downloader gelaufen ist.
Aber stimmt schon, sollte Ransomware unter Druck kommen, z.B. weil die Leute vorsichtiger werden, werden sich die Trojaner verbessern, und natürlich steht die Technologie, rein im Speicher zu arbeiten, längst zur Verfügung, was wiederum den hier besprochenen AV-Lösungen weiter den Boden unter den Füssen wegziehen wird.
Ja natürlich gibt es vereinzelt Malware die nicht direkt per dll hooked und die exe ins TMP verzeichnis kopiert. Das ist aber eher als Fail und somit als Ausnahmefall zu betrachten.
Selbst ein unerfahrener Amateur kriegt Shellcode Injection per Powershell hin. Gibts außerdem alles quasi fertig in den Weiten des Internets.
Wenn man sich den Schadcode von WannaCry ansieht ist der gesamte böse Teil des Payloads in einem passwortgeschützten zip Archiv. Somit ist es extrem unwahrscheinlich das irgendein Virenscanner das ganze in den ersten paar Tagen erkannt hat.
Mittlerweile ist natürlich das Passwort und der Hash bekannt.
Jedoch geht das Katz und Mausspiel mit neu verschlüsselten und „obfuscateten“ Code wieder von vorne los und das ist eine Sache von Minuten.
AV-Software macht es sogar noch schlimmer, da sie auf einem System, das mit WannaCry infiziert ist, die Betätigung des Notausschalter verhindert.
Ransomware WannaCry: Sicherheitsexperte findet „Kill-Switch“ – durch Zufall:
https://www.heise.de/newsticker/meldung/Ransomware-WannaCry-Sicherheitsexperte-findet-Kill-Switch-durch-Zufall-3713420.html
Folgendes habe ich ebenfalls in einem anderen Blog gelesen: „Auch scheinen einige Virenschutzprogramme den “Kill Switch” zu deaktivieren – bedeutet: Sie hebeln die als Stop-Anweisung gedachte Funktion aus.“
Hat da einer nähere Informationen zu?
Naja die Malware versucht ja auf die Hardcoded URL zurückzuconnecten. Wenn dies erfolgreich ist schaltet sich die Malware quasi ab. Wenn nun das Antivirenprogramm verhindert, dass die Malware zu dieser URL connected, bleibt der payload aktiv…
Puh, also das ist schon ein großes Fail der AV-Hersteller.. Bin ich froh, dass ich mich unter Windows-Zeiten schon früh von AV-Software verabschiedet habe. Wenn das restliche System stimmt und diverse Schutzmechanismen korrekt umgesetzt werden, kann man darauf gut und gerne verzichten.
Naja das zurückconnecten zu verhindern würd ich jetzt gar nicht als Fail bezeichnen. In der Regel sind Payloads staged. D.h. der vom Exploit ausgeführte Schadcode ist oftmals eine reine Reverseconnection über TCP, HTTPS etc zum Command & Control Server. Von dem wird dann weiterer Schadcode nachgeladen.
Dies in Verbindung mit diversen Obfuscation Techniken umgehen die Detektion von Virenscannern eigentlich immer.
Aus diesem Grund versuchen Virenscanner oft das zurückconnecten generell zu verhindern
Schöner Artikel!
Die heise/ct Redaktion glänzt hingegen mit Inkompetenz: WannaCry & Co.: So schützen Sie sich
Zitat: „Stellen Sie sicher, dass Ihr Virenschutz auf dem aktuellen Stand ist. Zwar fallen auch Virenscanner gelegentlich durch Sicherheitslücken auf, aber ein Verzicht auf Virenschutz ist auch keine Lösung.“
Die heise Redaktion scheint ihre besten Tage auch schon hinter sich zu haben.
Whitelisting oder Sandboxing wird hingegen nicht mal erwähnt.
Was haltet ihr eigentlich von Malwarebytes Anti-Ransomware?
Ist zwar Beta, aber unter Windows gab es mal bei mir einen Fehlalarm. Gut, da hat es auf den Nextcloud/Owncloud Sync Client angeschlagen, vermutlich wegen dem abtasten/scannen der lokalen Dateien.
Anti-Ransomware hatte ich in einer längeren Antwort auch schon erwähnt. Aber die wurde wohl nicht freigeschaltet da es nicht in das Weltbild hier passt.
Deshalb noch was in das Weltbild hier passt, Sophos ändert seine Werbung:
„The NHS is totally protected with Sophos.“ wurde entfernt.
https://www.heise.de/security/meldung/l-f-Sophos-aendert-nach-WannaCry-Angriff-seine-Werbung-3714943.html
Es liegen keine weiteren Kommentare von dir vor, ich muss dich enttäuschen.
Kein Grund unverschämt zu werden, oder?
Vielen Dank für den Artikel. Wirklich mal wieder sehr gut gelungen. Weiter so :)
Mike, was hälst Du vom AV-Ansatz, den Cylance verfolgt?
Vgl.: https://threatvector.cylance.com/en_us/home/cylance-vs-wannacry-wanacrypt0r-2-0.html
Vielen Dank für die Übersichtsartikel!
Was mich ein wenig wundert:
Als weitere Schutzmaßnahme gegen Infektionen ist sicher auch die Virtualisierung des Surf-/Mailsystems noch erwähnenswert. Hier könnte ggf. dann Linux als Guest zum Einsatz kommen – und das Hostsystem mit Win oder OS X wird zumindest weniger exponiert, auch wenn eine Virtualisierung natürlich ebenfalls keine 100%-ige Sicherheit liefern kann. Aber das dürfte ja klar sein.Mit Virtualbox und SSD – und je nach Auslastung mehr RAM – ist das alles sehr gut machbar. Aber diese Überlegungen sind hier im Forum vielleicht zu sehr Basics und daher nicht erwähnt worden.
Linux als Hauptsystem und Windows in die VirtualBox – dann wird ein Schuh draus. ;-)
Sorry Mike, vielleicht sitze ich auf der Leitung, aber die Sache mit dem Schuh verstehe ich nicht.
Ich will doch das – vermeintlich – mehr gefährdete System eher abschotten. Dann würde ich doch das als Host nehmen (Windwos oder OS X) und mit einem gut gehärtetem Linux virtualisiert surfen, mailen etc. Der Host ist dann mein Arbeitssystem, was u.U. Treiberanbindungen an meine Hardware erleichtern kann, o.k., nicht muss, außerdem den Einsatz evtl.von speziell benötigten Programmen, die es nur z.B. für Win, gibt, ermöglicht. Aber über den Host werden keine Verbindungen ins Web erlaubt, weder vom OS noch von Programmen. Wenn man Sicherheitsupdates machen will, erfolgen sie manuell, bei Win z.B. via wget über den Weg Download im Guest –> einspielen auf Host. Natürlich kann man auch auf verschiedenen Maschinen arbeiten und so gleich alles komplett trennen, wer es denn braucht bzw. sich leisten kann. Oder habe ich da was völlig falsch verstanden?
Mike meint das vielleicht etwas anders. Warum sollte man ein Hostsystem einsetzen dem man nicht vertrauen kann?
Das ergibt keinen Sinn -> deshalb Linux oder BSD als Host.
Am Host Sandboxing der wichtigsten Komponenten. Und für alles wo du um Windows nicht rumkommst dann eben die VM.
Du kannst das ja noch weitertreiben indem du Linux und oder Whonix als zusätzliche VM zum Surfen oder Mailen hast. Oder du setzt gleich auf QubesOS ;-)
So ähnlich. Ja! :-)
Also Anonymous und Mike sicherheitstechnisch ist das sicher völlig klar.
Leider ist es nach meiner Erfahrung so, dass durch die Emulation es z.B. in Virtualbox eben doch mit diversen Programmen in der Vergangenheit Probleme gab, v.a. bei Anbindung von Hardware wie Drucker, Scanner etc. Das macht es natürlich mit Win oder OS X als Host leichter. Daher die o.g. Überlegung – aber das ist zugegeben kein Argument zur Sicherheit, worum es ja hier geht.
Diese Aussage finde ich etwas merkwürdig – denn das gibt es doch bereits! Für Windows steht SRP zur Verfügung (das ich in einem Kommentar zu Snakeoil Teil 1 erwähnt hatte), mit dem c’t-Tool Restric’tor ist das auch für Home-Versionen leicht implementierbar.
Programme können dann nur noch im Windows- und im Programme-Ordner ausgeführt werden. Das Ausführen z.B. eines Email-Anhangs oder eines Programms oder Scripts auf einem USB-Stick oder im Download-Ordner wird dagegen für eingeschränkte Benutzer völlig blockiert und ist nur noch mit Admin-Rechten möglich. Am besten sollte man SRP zusammen mit einem eingeschränkten Benutzerkonto einsetzen (und sich nicht nur auf den UAC-Prompt verlassen).
Die oben genannte Forderung ist also schon längst erfüllt, nur noch nicht standardmäßig implementiert. Insofern schade, dass ihr in dem Artikel darauf nicht eingegangen seid.
Stichwort Application Whitelisting – stand im Artikel. SRP in Windows ist eben eine Form der Umsetzung. Den c’t-Restric’tor kenne ich, weiß aber nicht ob der was taugt.
Und Hand aus Herz: Vermutlich wird sich kein Durchschnittsanwender Application-Whitelisting »antun«. Im Firmenumfeld ist das womöglich anders.
Ich hatte SRP seither über die Gruppenrichtlinien realisiert, habe jetzt aber Restrictor seit einiger Zeit getestet, und es scheint sauber implementiert zu sein.
Das ist wohl wahr. Aber ein Durchschnittsanwender wird sich auch nicht Sandboxie oder das Deaktivieren von Diensten antun und wird stattdessen im Zweifel sogar UAC ganz deaktivieren.
Ich denke, du erreichst mit deinem Blog eher Anwender, die sich ernsthaft mit ihrem System beschäftigen und Sicherheit und Privatsphäre ernst nehmen. Für die ist, glaube ich, auch SRP nicht überkandidelt – sofern sie überhaupt noch bei Windows sind und nicht eh schon zu Linux gewechselt haben.
Sehe ich auch so. Meine Prognose bezog sich eher auf die von Schneier getätigte Aussage:
Die Systeme bzw. Maßnahmen mögen vielleicht schon da sein, nur hat ein Durchschnittsnutzer wenig davon – er muss diese ja meist selbst einrichten und pflegen, was aber die wenigsten tun. Daher bleibt die Aussage von Schneier nach meiner Auffassung auch weiterhin aktuell.
Würde Applocker oder notfalls SRP dem Restrictor vorziehen. Würde da nicht der 3rd Party Implementierung eines c’t Redakteurs vertrauen.
Unter Home kann man sich oft mit dem Family Filter behelfen.
Whitelisting ist eines der wenigen Dinge das wircklich hilft.
Wie oben erwähnt, habe ich auch viele Jahre SRP über die Gruppenrichtlinien realisiert und mich dabei an
http://www.mechbgon.com/srp/
orientiert, aber Restrictor scheint seine Aufgabe ordentlich zu machen.
Kann ich nicht beurteilen. Ich hatte nie Home.
Das sehe ich auch so.
Hallo Mike,
danke für die super Übersicht.
Nur noch mal zu meinem Verständnis zum Thema Wahl der Linux-Distro, die ja nicht uninteressant für die Sicherheit sein dürfte:
Warum setzt Du auf Debian? Siehst Du klare Sicherheitsvorteile z.B. gegenüber den Ubuntu-Abkömmlingen von Debian bzw. würdest Du Ubuntu und Co eher misstrauen? Gibt es in der Ubuntu-Familie sicherheitstechnisch klare Unterschiede? Immerhin werden im Privacy-Handbuch ja gerade Xubuntu bzw. Kubuntu favorisiert -allerdings als STS. Und Debian ist tendenziell doch eher LTS, oder? Für Sicherheitupdates doch vermutlich nicht uninteressant.
Hohe Stabilität, breites Softwareangebot, transparenter Umgang mit Schwachstellen und eher konservative Entscheidungen bei der Aufnahme neuer Technologien.
Und wichtig: (X)Ubuntu basiert ja auf Debian. Allerdings bedeutet jede Veränderung an einem bereits bestehenden Package wiederum der Einbau von möglichen Fehlern bezüglich Stabilität und Sicherheit. Daher bleibe ich lieber beim Original, auch wenn die Pakete bzw. die Entwicklung oftmals dem »Trend« hinterher hinken – damit kann ich allerdings sehr gut leben.
Auf dem Desktop greife ich immer zum aktuellen Dabian Stable – derzeit noch Jessie.
Die Frage ist aber Offtopic. Daher möchte ich dies im Zusammenhang mit dem Beitrag auch nicht weiter vertiefen. ;-)
Um auch noch Bruce Schneier zu Wort kommen zu lassen:
WannaCry Ransomware
Your second line of defense is good antivirus software. Sometimes ransomware tricks you into encrypting your own hard drive by clicking on a file attachment that you thought was benign. Antivirus software can often catch your mistake and prevent the malicious software from running. This isn’t perfect, of course, but it’s an important part of any defense.
–Bruce Schneier, Ph.D.
Ich bin bei vielem einer Meinung mit Schneier – hier allerdings mal wieder nicht.
Jetzt ist es so, dass Signaturen vorliegen. Was spricht also gegen den Einsatz eines AV-Programms wie ClamAV, welches passiv auf dem System wartet, um bei Bedarf Dateien zu scannen?
Mir kommen die oben beschriebenen Alternativen etwas mau vor. Sandboxing wird von moderner Malware als Sandbox erkannt und dementsprechend das Verhalten angepasst. Schutzmaßnahmen wie ASLR konnten bereits erfolgreich umgangen werden und Bewusstsein schaffen hilft nichts (siehe Phishing Angriffe).
Im Fall von WannaCry haben AV-Scanner durch die Bank versagt. Was geholfen hat und noch immer tut: (System-)Updates einspielen. Wie auch gestern wieder gesehen erhöhen AV-Scanner die Angriffsfläche eines Systems. Es ist daher fraglich ob du einen AV-Scanner laufen lassen möchtest, der meist schlechte Erkennungsraten hat (siehe Beitrag 1) und die Angriffsfläche durch Sicherheitslücken in der AV-Software selbst (siehe Beitrag 2) nur unnötig erhöht. Your choice!
Sind sie nicht. ;-)
Updates, System-Härtung und insbesondere auch Sandboxing reduzieren im Gesamtpaket die Wahrscheinlichkeit einer Infektion durch eine Sicherheitslücke erheblich. Awarness bzw. Bewusstsein schaffen ist dann der zweite Baustein.
Noch ein ganz wichtiger Punkt, den ich glaube in keinem der 3 Teile gelesen habe, ist die zusätzliche „Verschwendung“ von PC-Ressourcen (CPU+RAM+Akku, Strom). In der nicht allzu alten Vergangenheit gab es da immer wieder mal Szenarien, in denen einige AV-Scanner nicht selten 2/3 der CPU-Last in Anspruch nahmen/nehmen und/oder Systeme fast bis zur Unbenutzbarkeit verlangsamt haben.
Und noch einer hinterher: So wie ich das mitbekommen habe hat „Bitdefender“ zwar WannaCry ebenfalls nicht erkannt, aber -als einzigster AV-Scanner- zumindest eine Infektion verhindert:
https://www.bitdefender.com/news/bitdefender-blocks-worlds-most-aggressive-piece-of-ransomware-with-next-generation-detection-technologies-3289.html