Klassifikation von bösartiger Software und aktuelle Testergebnisse des Virus Test Centers von AntiMalware-Software unter Linux

Klassifikationen von Viren

Da es sich bei einem Großteil der verbreiteten bösartigen Software um Viren handelt, haben sich verschiedene, allgemein akzeptierte Klassifikationen für diese spezielle Art von Malware durchgesetzt. Zum einen kann man Viren nach der Plattform, für den der Virus programmiert wurde und auf dem er lauffähig ist (das heißt, auf dem er sich durch Replikation verbreiten kann), einteilen. Zum anderen werden Viren häufig danach eingeteilt, ob sie verbreitet sind oder ob es sich um seltene, nicht häufig gefundene Viren handelt.

Eine Einteilung in verschiedene Klassen ist sinnvoll, um einen Überblick über die große Masse an verschiedenen Viren zu erlangen und um neu auftauchende Exemplare einordnen zu können. Allerdings lassen sich einige Viren nicht eindeutig zu den beschriebenen Klassen (s.u.) zuordnen. Da anhand dieser Klassifikationen auch die Malware-Datenbanken des Virus-Test-Centers strukturiert sind, werden in den folgenden beiden Unterabschnitten die Klassifikation nach Plattform und nach Verbreitung kurz erläutert.

Klassifikation nach Plattform

Jede Art von programmiertem Computercode ist jeweils nur auf einer bestimmten Plattform lauffähig. Da ein Computervirus jeweils nur auf dieser Plattform ausgeführt werden kann, kann man Viren nach der Plattform, für die der Code geschrieben wurde, unterscheiden:

Klassifikation nach Verbreitung

Eine Aussage, wie hoch die Gefahr ist, sich mit einem bestimmten Virus zu infizieren, kann über die Analyse der Verbreitung von Viren getroffenen werden. Viele Hersteller von Anti-Viren-Software stellen auf ihren Webseiten Übersichten bereit, auf denen sie angeben, welche Viren am meisten verbreitet sind ("Top 10" und ähnliches). Diese Übersichten basieren auf den Daten des jeweiligen Herstellers. Obwohl einige Hersteller von Anti-Malware-Software über eine große Anzahl an Kunden verfügen, sind solche Auflistungen nicht notwendigerweise repräsentativ für die tatsächliche Verbreitung von bestimmten Viren.

Eine allgemein akzeptierte Einteilung von Viren nach ihrer Verbreitung ist die Einteilung von der WildList Organisation ([Wildlist 2003]). Die WildList Organisation teilt Viren in zwei Klassen ein:

Beim Testen von Anti-Malware-Software werden die Viren, die auf der aktuellen WildList stehen, als in-the-wild Viren bezeichnet (abgekürzt ITW). Die restlichen Viren einer Testmenge bezeichnet man als Zoo-Viren, da sie kaum verbreitet sind und sich deshalb - die Analogie zu Tieren aufrechterhaltend - nicht in "freier Wildbahn" sondern in einem "Zoo" befinden.

Lokale Verbreitung, Social Engeneering:

Egal, ob eine Datei durch einen Virus infiziert wurde oder ob sie "Klick mich, ich bin ein Bild von AnnaKournikova!.jpg.vbs" heißt, wird dem Benutzer ein vertrautes, harmloses Objekt vorgespiegelt, das dieser gerne nutzen will. Für Virusscanner ist dies der einfachste Fall, denn die Malware liegt als Datei vor, und das Betriebssystem bietet die Möglichkeit, vor der Ausführung die Datei zu scannen.

Anders sieht es aus, wenn in einem Hoax zum Beispiel die Anleitung zum Löschen der "gefährlichen" Datei mit dem Teddybärsymbol (vom Java-Debugger) immer wieder in einem neuen Format weitergeleitet wird. Dies ist kein maliziöser Programmcode, den ein Virusscanner erkennen sollte, sondern die Dummheit der Nutzer, vor der nur Aufklärung und Rechtevergabe schützt.

Freigaben:

Viele Nutzer geben Platten mit Systemverzeichnissen für das lokale Netzwerk frei und vertrauen darauf, daß niemand böse Absichten hat. Hierbei wird gerne übersehen, daß erstens das Internet ein Netzwerk ist, und zweitens die böse Absicht nicht notwendig ist, um Schaden anzurichten. Wenn Malware die Rechte des Benutzers erlangt hat, dann kann sie alle erreichbaren Dateien löschen oder unbemerkt ändern. Noch schlimmer ist es, wenn ein Wurm Zugriff auf die Konfigurationsdateien nehmen kann, denn so kann dieser nicht nur den Inhalt der Dateien auslesen, sondern auch den Startmechanismus verändern und sich somit zur Ausführung bringen oder Virusscanner abschalten.

Diese Angriffe können theoretisch sehr leicht vermieden werden, indem man Verzeichnisfreigaben auf notwendige Verzeichnisse beschränkt und dort keine ausführbaren Dateien lagert oder anklickt. Dies funktioniert genau so lange, wie alle Nutzer sich daran halten, was der Administrator nur selten sicherstellen kann.

Ein Virusscanner kann gegen derartige Angriffe schützen, aber es ergeben sich einige Einschränkungen. Wichtig ist, daß die Dateien bei jedem Öffnen gescannt werden, denn eine Datei, die nicht für Netzwerkzugriffe gesperrt ist, kann gleichzeitig von einem anderen Nutzer ausgeführt werden. Hier ergibt sich eine Race-Condition; maliziöser Code könnte nach den Öffnen, aber vor dem Ausführen geschrieben werden. Ein Sicherheitsrisiko bleibt also auch bei Nutzung eines Virusscanners bestehen. Besonders On-Demand-Scanner (Überprüfung nach Aufruf) können nicht zuverlässig auf zum Schreiben freigegebenen Verzeichnissen für Sicherheit sorgen, denn zwischen dem Scannen und dem Ausführen einer Datei kann diese wesentlich leichter durch einen Wurm ersetzt werden als bei Verwendung eines On-Access-Scanners (Überprüfung beim Zugriff). Auf keinen Fall dürfen System- oder Konfigurationsdateien mit Schreibzugriff freigegeben sein.

Wechseldatenträger:

Ein verseuchtes System kann eingelegte Datenträger so modifizieren, daß diese eine Kopie der Malware enthalten, welche beim Einlegen oder beim Booten ausgeführt wird. Da Disketten immer weniger benutzt werden, ist diese Art der Verbreitung derzeit wenig bedeutend. Mit der Verbreitung von wiederbeschreibbaren Medien in Form von USB-Sticks und ähnlichen Geräten wird diese Verbreitungsart jedoch neues Potential erhalten. Steckt man ein Wechselmedium an ein laufendes System, so kann ein dort laufender On-Access-Scanner die Schadsoftware vor der Ausführung erkennen, denn es besteht kein prinzipieller Unterschied zu von Benutzern aufgerufenen Dateien.

Ein neu startendes System, das versucht, von einem Medium zu booten, startet meistens ohne aktives AntiMalware-Programm, so daß ein Virus sich verbreiten kann. Hier besteht jedoch für einen Virus die Schwierigkeit, den Start des Betriebssystems zu überleben, und diese Aufgabe wird zunehmend kompliziert, da die Startroutinen heutiger Betriebssysteme recht komplex sind.

Buffer Overflow (zu lange Eingabedaten):

Ist eine Programmeingabe zu lang, so kann die Rücksprungadresse der aufgerufenen Funktion durch einen Wert in der Eingabe ersetzt werden. Dies erlaubt bei Kenntnis über das angegriffene System, mit der Anfrage ein Code-Fragment mitzuschicken, welches beim Verlassen der Funktion angesprungen wird. Dieses Code-Fragment kann zum Beispiel einen Wurm nachladen (Morris- und Ramen-Wurm), bereits den gesamten Wurm enthalten (SQL-Slammer) oder eine Shell für den Angreifer aufrufen. Solch ein Angriff läuft meistens direkt über ein Netzwerk und im Hauptspeicher ab, so daß kein scanbares Objekt im Dateisystem vorliegt (der Hauptspeicher wird höchstens beim Start des Scanners, unter Linux bisher jedoch nicht geprüft). Erst eine nachgeladene Datei könnte erkannt werden, dann ist die Malware jedoch schon aktiv. Man braucht andere Verfahren, um diesen Angriff abzuwenden, zum Beispiel einbruchsvermeidende Systeme (intrusion avoidance systems). Besser ist es jedoch, möglichst sauber programmierte Software zu verwenden.

Auswertung im falschen Kontext:

Eine Anfrage enthält Sonderzeichen oder zusätzliche Angaben, die fälschlicherweise zu einer geänderten Bearbeitung der Anfrage führen.

Beispiel:

GET /cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd

Diese Web-Server Anfrage sorgt dafür, daß in einer Telefonbuchanwendung der Variable "alias" der String

"x<Zeilenende>/bin/cat /etc/passwd"

zugewiesen wird. Wenn die Variable nun ungeschützt verwendet wird, so kann das Zeilenende als Ende des Befehls interpretiert werden, wodurch der Rest zu dem nächsten auszuführenden Befehl wird. Dieser Angriff unterscheidet sich für den Virusscanner nicht von einem Buffer Overflow, auch hier kann er nur dann eingreifen, wenn eine Datei nachgeladen wird.

Unzureichende Prüfung der Zugriffsrechte, Ausnutzung einer Vertrauensstellung:

Eine bekannt unsichere Funktion ist nicht oder nicht an allen Stellen, an denen sie maliziöse Handlungen erlaubt, vor Aufrufen geschützt, oder ein Zugang wird über unsichere Methoden kontrolliert.

Beispiel IFRAME-Exploit: Zitat aus http://www.microsoft.com/technet/security/bulletin/MS99-042.asp:

Beispiel vim: Der Texteditor Vim erlaubte es, für die verschiedensten Aufgaben eigene Funktionen zu schreiben und dabei auf Systemfunktionen zurückzugreifen. Diese Funktionen können auch im Text zugewiesen werden, so daß der Autor eines Textes bei den Lesern die Ausführung beliebigen Codes auslösen kann. Ein Beispiel für einen damit möglichen Wurm kann man unter http://www.securiteam.com/unixfocus/5RP0L0A8US.html nachlesen.

Beispiel Morris-Wurm: Wenn der Morris-Wurm (auch als Internet-Wurm bekannt, 1988) auf einem System aktiv war und bereits zu einem Benutzeraccount Zugang hatte, dann versuchte er, weitere Systeme über die Programme "rexec" oder "rsh" zu erreichen. Vertrauten diese Systeme oder dessen Benutzer dem befallenen System, so konnte der Wurm sich dort zur Ausführung bringen.

Diese Exploits können über die enthaltenen Strings leicht erkannt werden, so lange sie als Datei vorliegen und das Format richtig erkannt wird. Dies kann aber zumindest beim Morris-Wurm erst passieren, wenn die Schadroutine bereits läuft. Zu diesem Zeitpunkt könnten jedoch schon Nutzerdateien gelöscht werden sein. Zudem gibt es auch die Möglichkeit der nichtmaliziösen Nutzung der Schnittstellen, so daß man mit "false positives" rechnen muß, die Erkennung ist also sehr unzuverlässig. Wesentlich besser ist die Vermeidung von Software, die unnötige Funktionen und Schnittstellen anbietet oder auf den nötigen Schnittstellen inhärent unsicher ist.

Das beste Produkt ?

Die erste Frage, die meistens gestellt wird, ist, welches Produkt denn nun das beste sei. Diese Frage wird hier nicht beantwortet werden, denn die Antwort hängt einerseits sehr vom jeweiligen Einsatzbereich ab und setzt andererseits voraus, daß ein Produkt in allen relevanten Aspekten getestet wird. Da der Einsatzbereich von Antimalware-Produkten von Privatanwendern bis zu Großunternehmen (mit Tausenden von Clients) reicht, ist es nicht sinnvoll zu versuchen, allgemeine Aussagen dieser Art zu treffen. Die VTC-Tests beschränken sich auf die Erkennungsrate der Produkte; andere für den Einsatz durchaus relevante Aspekte (wie z. B. Geschwindigkeit, Bedienung, Remote-Administration) werden nicht berücksichtigt. Deshalb ist es auch nicht möglich, im Rahmen der VTC-Tests umfassende Bewertungen der Produkte vorzunehmen. Trotzdem werden auch in VTC-Tests Produkte bewertet, aber ausschließlich nach funktionalen Aspekten.

Die folgende Grafik zeigt, welcher Prozentsatz aller infizierten Dateien von den verschiedenen Produkten als infiziert gemeldet wurde.

Das sieht zwar aussagekräftig aus, man sollte sich jedoch nicht davon täuschen lassen, denn die Aussagekraft dieser Grafik ist eher gering. Z. B. wäre es schlichtweg falsch, hieraus eine Rangliste der besten Produkte zu erstellen (leider findet man solch oberflächliche Bewertungen oft). Es lassen sich höchstens eingeschränkte Aussagen treffen, z. B. das die Erkennungsrate von OAV deutlich schlechter ist als die aller anderen Produkte.

Einer der Gründe, warum diese Zahlen nicht ausreichend sind, liegt in der unterschiedlich guten Erkennung der verschiedenen Virenarten. Während einige Produkte z. B. File-Viren sehr gut erkennen aber mit Skript-Viren Probleme haben, sind andere überall mittelmäßig. Es gibt auch Produkte, die nur bestimmte Virenarten erkennen können, dies jedoch sehr präzise. Somit lassen sich die Gesamtergebnisse nicht unbedingt vergleichen. Und für ein konkreten Einsatz ist es wichtig zu wissen, daß ein Produkt in den für diesen Zweck wichtigen Bereichen gut funktioniert.

Wie man sieht, zeigen FPR, FSE und CMD (die intern alle die gleiche Scan-Engine verwenden) deutliche Schwächen bei der Erkennung von Skript-Viren, während RAV eher Probleme mit File-Viren hat (und dabei über 700 Viren nicht erkennt).

Erkennung von ITW-Viren und nicht-replizierender Malware

Viel bedeutender ist jedoch, wie weit verbreitet die nicht erkannten Viren sind. Auch wenn ein Produkt insgesamt 99,9% aller Dateien erkennt, kann es trotzdem unbrauchbar sein, falls sich unter den nicht erkannten Dateien viele In-The-Wild-Viren befinden. Deshalb werden In-The-Wild-Viren in separaten Datenbanken getestet. Während z. B. 100 nicht gefundene Dateien in einer (riesigen) Zoo-Datenbank kaum einen Unterschied machen, ist dies in einer In-The-Wild-Datenbank nicht akzeptabel.

Insgesamt ergibt sich hier ein ganz anderes Bild als bei der vorhergehenden Betrachtung. Im Gegensatz zu den Zoo-Datenbanken ist hier bei FPR, FSE und CMD die Erkennung der Skript-Viren sogar besser als die der File-Viren (wobei allerdings die unterschiedliche Größe der Datenbanken berücksichtigt werden muß). Bereits die relativ geringe Anzahl nicht erkannter Dateien in den ITW-Datenbanken ist ähnlich schwerwiegend einzustufen wie die Schwächen von RAV auf den Zoo-Datenbanken.

Wieder anders sieht es aus, wenn man die nicht-replizierende Malware betrachtet.

Hier schaffen es nur AVK und SCN, akzeptable Erkennungsraten zu erzielen.

Falschmeldungen und Erkennung von Malware in komprimierten Dateien

Für den Praxiseinsatz ist es nicht nur wichtig, das ein Produkt möglichst jede Malware erkennt, sondern auch, das keine "sauberen" Dateien als Malware klassifiziert werden. Auch wenn es nicht möglich ist, dies repräsentativ zu testen, kann bereits ein Stichprobentest ausreichen, um Produktschwächen zu offenbaren. Dazu wurden vor allem Word und Excel-Dokumente verwendet, die harmlose Makros enthalten.

Wie man sieht, gibt es zumindest im Makroviren-Bereich bei vielen Produkten deutliche Probleme, zwischen schädlichen und harmlosen Makros zu unterscheiden. Lediglich SCN bietet hierbei eine zufriedenstellende Leistung. OAV hat zwar ebenfalls ein gutes Ergebnis, das allerdings angesichts der unzureichenden Erkennung von Makro-Viren nicht zu hoch bewertet werden darf.

Letztlich ist nicht unwichtig, wie gut die Produkte Malware in komprimierten Dateien, Mailbox-Archiven und anderen Kodierungen erkennen können. Dies wird wegen des großen Aufwands nur für wenige Kompressionsformate getestet (Zip, Arj, Cab, Lha, Rar1.5, Rar2.0, Rar3.0). Da die vollständigen Ergebnisse für diesen Beitrag viel zu umfangreich sind, wird hier nur gezeigt, welche Formate von den getesteten Produkten unterstützt werden (auch wenn diese Unterstützung nicht ganz zuverlässig ist):