Viel Lärm um nichts
Fehlalarme von Antivirus-Software korrigieren
Wer Software entwickelt und übers Internet verteilt, plagt sich oft mit übergriffigen Virenscannern herum: Die halten selbst harmlose Programme nicht selten für ein Sicherheitsrisiko. Kürzlich waren wir selbst betroffen. Wir hinterfragen das Verhalten an konkreten Beispielen und loten den Spielraum aus, der Entwicklern bleibt.
Mit unserem Bausatz für ein Notfallsystem auf Basis von Windows haben wir jedes Jahr aufs Neue einen Kampf gegen Fehlalarme von Antivirus-Software auszufechten: Einige Programme zum Erweitern des Notfallbetriebssystems und auch dort eingebaute Werkzeuge zum Auslesen von Passwörtern lassen die AV-Software anschlagen – so weit, so erwartbar. Wir untersuchen die Situation jedes Jahr aufs Neue und veröffentlichen auf der Projektseite unser Einschätzung zu jedem einzelnen Programm (siehe ct.de/yfsf).
Vergleichsweise unerwartet traf es uns, als Ende Februar mehrere Leser darauf hinwiesen, dass das zu c’t 6/2023 veröffentlichte Zip-Archiv mit Skripten zum Auslesen von Windows-Lizenzschlüsseln [1] Alarme produziert. Die Skripte und Programme hatten wir intern intensiv mit aktiven Virenscannern getestet. Die Leser berichteten, dass Webbrowser schon beim Download Viren im Archiv meldeten.
Ein Upload des Archivs bei VirusTotal, einer Website, die unter anderem über 60 AV-Scanner konsultiert, zeigte zu diesem Zeitpunkt für zwei enthaltene funktionsgleiche Programme ctbioskey32.exe und ctbioskey64.exe über 20 alarmierende Scanner.
Wenn mehr als eine Handvoll Scanner eine Datei als verseucht identifizieren, ist das meist ein deutliches Zeichen für einen Schädling, noch dazu, wenn es sich um namhafte Scanner handelt. Im Fall der genannten Dateien bleibt das aber schleierhaft, weil wir die Programme selbst übersetzt haben und sie nur zwei dokumentierte, triviale Windows-Funktionen aufrufen.
Wirkfreie Maßnahmen
Natürlich haben wir die veröffentlichten Programme sofort nach den ersten Hinweisen erneut geprüft. In verschiedenen Experimenten haben wir versucht herauszufinden, ob und wie sich die Fehlalarme vermeiden lassen. Das Ziel sollte immer sein, dass kein Scanner auf VirusTotal die Software beargwöhnt. Dazu muss sie nicht nur von den Scannern, die den Dateiinhalt analysieren, als ungefährlich eingeschätzt werden. Auch die Sandboxen, die VirusTotal zur dynamischen Analyse ausführt, sollten zu diesem Schluss kommen.
Unseren ersten Ansatz, den Programmen mit einer Code-Signatur mehr Glaubwürdigkeit zu verschaffen, krönte nur mäßiger Erfolg: Die 32-Bit-Version schätzten weiterhin fünf Scanner als gefährlich ein, die 64-Bit-Version zwei. Nach wie vor hatte keine der Sandboxen an den Programmen etwas auszusetzen. Diese Signatur, die man einer EXE-Datei mit einem speziellen Zertifikat hinzufügt, attestiert ihre Herkunft. Ein solches Zertifikat kostet rund 100 Euro pro Jahr und verlangt eine Identitätsprüfung der kaufenden Person.
Im zweiten Schritt haben wir den Quelltext des Programmes noch genauer angesehen. Es rief in der Originalfassung zwei Funktionen der Windows-Programmierschnittstellen (API) auf: EnumSystemFirmwareTables und GetSystemFirmwareTable. Die Recherche förderte zutage, dass Malware besonders mit der erstgenannten Funktion gern ergründet, ob sie in einer VM läuft oder nicht. Das klang nach einer heißen Spur.
Denkste: Die Programmfassung, die allein mit der zweitgenannten Funktion auskommt, hielten einige Scanner ebenfalls für gefährlich, und zwar sowohl in der 32- als auch der 64-Bit-Version. Auf die zweite Funktion kann das Programm nicht verzichten. Auch sie wird mancherorts mit Malware in Verbindung gebracht, denn sie saugt Informationen aus der Firmware ab. Wir griffen zu einer unschönen, allerdings oft wirksamen Methode: Obfuskation.
Anstatt die Funktion direkt aufzurufen, ließen wir das Programm über die API-Funktionen LoadLibrary und GetProcAddress einen Zeiger auf GetSystemFirmwareTable ermitteln und die Funktion indirekt aufrufen. Obendrein stand der für den Aufruf von GetProcAddress nötige Funktionsname nicht im Klartext im erzeugten Programmcode, sondern verschleiert. So konnte die Dateianalyse der AV-Scanner den Aufruf dieser Funktion nicht erkennen.
Wieder nix: Die Anzahl der Alarme blieb für beide Versionen nahezu gleich. Die Sandboxen reagierten übrigens trotz des ziemlich primitiven Obfuskationsversuchs weiterhin nicht auf unser Progrämmchen. Egal ob wir es VirusTotal in einer signierten oder unsignierten Fassung zur Prüfung vorlegten, änderte sich die Einschätzung nicht: Es blieb immer eine signifikante Anzahl von alarmierenden Scannern.
Es sei noch angemerkt, dass die Anzahl der Alarme über die Zeit variiert. Bei erneutem Hochladen bereits untersuchter Dateien zeigt VirusTotal zunächst bereits vorhandene Testergebnisse an. Die Weboberfläche untersucht eine Datei erneut, wenn man auf „Reanalyse file“ klickt. Ein neuer Upload ist nicht notwendig.
Dass AV-Software Fehlalarme produziert, ist unvermeidbar. Denn letztlich besteht da immer ein Zielkonflikt zwischen den zwei zentralen Aufgaben, einerseits möglichst alle „bösen Dinge“ zu erkennen und andererseits dabei keine „guten“ zu erwischen. Ein perfekter Scanner, der alle Viren entdeckt, ist einfach gebaut: Hält er schlicht alles für einen Virus, liefert er eine hundertprozentige Erkennung, aber auf Kosten einer ebenso so hohen Falsch-Positiv-Rate.
Hersteller justieren deshalb kontinuierlich ihre Stellschrauben, um gute Erkennungsquoten bei möglichst niedriger Falsch-Positiv-Rate zu erzielen. Dabei kann man vier grundsätzliche Mechanismen der Erkennung unterscheiden. Mit möglichst charakteristischen Byte-Folgen – sogenannten Signaturen – erkennt AV-Software bereits bekannte Schädlinge recht zuverlässig, ohne dabei oft danebenzuliegen. Aber eben nur die bekannten.
Um auch Variationen oder sogar neue Schädlinge zu finden, sucht sie in den Dateien nach bekannten Mustern – etwa typische Kombinationen verdächtiger Systemaufrufe. Diese Heuristik ist unscharf und produziert je nach Einstellung mehr oder weniger Fehlalarme. Ähnliches gilt für die Überwachung des Verhaltens – etwa in einer Sandbox oder auch live am lebenden Objekt.
Gerade für Entwickler besonders problematisch ist die Bewertung der Reputation einer Datei, die sich unter anderem daraus speist, wie oft und in welchem Kontext AV-Software diese Datei bereits gesehen hat: Neue, bislang selten gesehene Programme gelten dabei häufig erst mal als grundsätzlich verdächtig. Da braucht es dann nur wenige weitere Indizien, um vorsichtshalber einen Alarm auszulösen. Digitale Signaturen können etwas gegensteuern, verlieren aber angesichts der zunehmenden Flut an signierter Malware zusehends an Wert. Erschwerend hinzu kommt, dass AV-Hersteller auch gelegentlich voneinander abschauen. Halten Konkurrenten gemäß VirusTotal eine Datei für böse, spart man sich schon mal eigene Analysen und übernimmt deren Einschätzung, zumindest bis weitere Erkenntnisse vorliegen.
Und damit hat man noch gar nicht angefangen, über PUA zu reden. Das sind „potenziell unerwünschte Anwendungen“. Diese Kategorie haben die Hersteller ursprünglich eingeführt, um sich gegen die zunehmenden Klagen der Hersteller von Ad- und Spyware abzusichern: Die haben sich teils erfolgreich vor Gericht dagegen gewehrt, dass ihre Software als Trojaner bezeichnet und blockiert wurde. In der Tat ist es oft gar nicht so einfach, eine scharfe Grenze zu ziehen zwischen „böse“ und vom Anwender so akzeptiertem oder sogar gewollten Verhalten. Mit der Deklaration als PUA spielen die AV-Hersteller den Ball zum Anwender zurück, der sie dann optional blockieren oder auch freigeben kann.
Prüfstanderkennung
Als Ultima Ratio, um die Fehlalarme zu vermeiden, bleibt eine Technik: Wir haben die beanstandeten Programme kurzerhand in ein Zip-Archiv verpackt und es mit einem trivialen Passwort geschützt. Das Skript zum Auslesen der Installationsschlüssel entpackt dieses Zip-Archiv, wenn es die Programme aufrufen muss – durch eine Änderung am Skript ist das nur noch in PE-Umgebungen nötig und da läuft standardmäßig kein störender Virenscanner.
Auch unser Bausatz für das Notfall-Windows wendet diesen Trick an: Er enthält ebenfalls ein passwortgeschütztes Zip-Archiv, in dem alle Programme des Bausatzes liegen, die durch Fehlalarme aufgefallen sind. Dieses Archiv entpackt der Bausatz erst, wenn er in einem Verzeichnis loslegt, das der Nutzer im Virenscanner mit einer Ausnahme versehen hat. So konnten wir typische Leseranfragen zu AV-Alarmen massiv reduzieren.
Ähnlich gehen auch einschlägige Software-Autoren vor, die systemnahe Software produzieren und von den Übergriffen der AV-Scanner und den daraus resultierenden Nachfragen mehr als genervt sind. Sehr oft trifft es beispielsweise Nir Sofer und seine nützlichen NirSoft-Programme. Er verpackt sie inzwischen in geschützte Archive und veröffentlicht zusätzlich das Passwort, damit AV-Software die Programme nicht schon direkt beim Herunterladen wegfischt.
So haben erfahrene Nutzer die Möglichkeit, die Programme in ein Verzeichnis zu entpacken und daraus aufzurufen. Das klappt, wenn sie für dieses Verzeichnis in der AV-Software eine Ausnahme definiert haben, die ihr verbietet, es zu überwachen. Denn von der AV-Software als „potentially unwanted application“ (PUA) markierte Programme sind vor allem dann unerwünscht, wenn nicht der Benutzer selbst sie auf den PC gebracht hat, sondern Dritte – etwa ein Schädling oder Einbrecher.
Reporterabenteuer
Wer selbst Software verteilen möchte und dabei die AV-Programme nicht austricksen will, kann versuchen, seine zu Unrecht verdächtigten Programmdateien bei den Anbietern auf eine Whitelist setzen zu lassen. Das allerdings artet in eine Fleißaufgabe aus: Zwar haben viele einen Kommunikationskanal für Anfragen zu „False Positives“ eingerichtet, doch jeder geht hier einen eigenen Weg.
Manche Hersteller nehmen solche Berichte per Mail entgegen, andere per Webformular und wieder andere überhaupt nicht. Die Ironie dabei: Die meisten verlangen ein passwortgeschütztes Archiv mit der betroffenen Datei. Einige Hersteller wie McAfee, die bei VirusTotal gleich mit mehreren Scannern vertreten sind, verlangen für jedes ihrer Produkte einen eigenen, separat übermittelten Report.
Am 8. März erzeugte die von uns signierte ctBiosKey32.exe-Datei noch drei Fehlalarme bei Antiy-AVL, McAfee und Rising. Ihr 64-Bit-Pendant hielt kein Scanner mehr für verdächtig. Wir haben dann bei den drei Anbietern entsprechende Falsch-Positiv-Reports eingereicht und darin, so weit möglich, auf den auf GitHub liegenden Quelltext verwiesen. Signatur und Quelltext sollten hinreichend sein.
Den Report wurden wir bei McAfee nur per Mail los. Es dauerte nicht lang und wir hatten eine automatische Antwort: Die Annahme der Mail wurde von der Gegenstelle mit dem Hinweis auf ein Sicherheitsproblem verweigert. Welches, verriet die Maschinenintelligenz nicht. An einer zweiten Mailadresse nahm McAfee den Report schließlich an.
Rising akzeptiert entsprechende Anfragen nur über ein Web-Formular und bittet darum, das RAR-Archiv nicht mit einem Passwort zu schützen. Das Webformular scheint seit 2014 niemand mehr angefasst zu haben. Das Hochladen der Datei gelang und wir erhielten eine Inquiry-Nummer. Mit der kann man auf der gleichen Seite einsehen, wie es um den Status einer Einreichung bestellt ist.
Bei Antiy Labs stolperten wir gleich beim Besuch der Website über das erste Problem: Ihr Zertifikat war seit fünf Tagen abgelaufen. Wir haben großzügig darüber hinweggesehen und fanden in den Kontaktangaben Hinweise auf eine Mailadresse für einen Report. Dort bat man darum, „PKI Encryption“ zu nutzen – bei näherer Betrachtung des dort bereitgestellten öffentlichen Schlüssels entpuppte sich das als PGP.
Das Ergebnis vermag kaum zu überraschen: Die sorgsam präparierte E-Mail erreichte den Empfänger nicht. Auch hier antwortete geballte maschinelle Intelligenz mit dem Hinweis, dass Nachrichten an diese Adresse nicht zugestellt würden. Da die Firma nicht mal ihr Website-Zertifikat erneuert hat, halten wir weitere Versuche für reine Zeitverschwendung.
Eine Woche nach dem Abschicken der beiden Reports hatte sich die Bewertung von ctBiosKey32.exe bei keinem der Anbieter geändert. Bei Rising hieß es weiterhin, dass die Probe analysiert würde. Von McAfee gab es keine Reaktion bis Redaktionsschluss für diese Ausgabe. Über ct.de/yfsf haben wir den VirusTotal-Bericht verlinkt, über den man auch eine erneute Prüfung veranlassen kann.
Browserkapriolen
Nicht nur ein lokal aktiver Virenscanner greift ein, sondern gern schon Browser vorm Download eventueller Schädlinge: Nachdem uns erste Hinweise zu vermeintlichen Virenfunden im c’t-KeyFinder erreicht hatten, dauert es nicht mehr lang, bis gängige Browser schon vom Download abrieten.
Sowohl Firefox als auch Chrome warnten beim Download-Versuch. Die Technik dahinter stammt von Google und heißt „Google Safe Browsing“. Die Browser können über ein API individuelle URLs online oder über einen lokalen Cache offline auf bekannte Sicherheitsprobleme prüfen (lassen).
Die von Google bereitgestellten Funktionen sollen vor allem vor Phishing-Seiten schützen, aber auch vor vermeintlicher Malware. Für Phishing-URLs bietet Google ein Web-Formular an, um dort falsche Befunde zu melden und die URLs aus der Blacklist entfernen zu lassen. Site-Betreiber müssen damit rechnen, dass das bis zu 24 Stunden dauert. Für den Fall fälschlicherweise als Malware erkannter Downloads bietet der Konzern allerdings keine Meldemöglichkeit an.
Wie genau der Dienst arbeitet und was technisch dahintersteckt, verrät Google nicht. Es gibt aber bei VirusTotal einen Blog-Beitrag vom 10. August 2022, der nahelegt, dass nach der Integration des URL-Scan-Dienstes nun auch die Dateiüberprüfung Teil von VirusTotal geworden ist. Details erfährt man nicht, nur dass sich beide Unternehmen den Selbstverpflichtungen der „Anti-Malware Testing Standards Organization“ (AMTSO) unterwerfen, einem Verband von AV-Firmen.
Der Verband hat sich zwar intensiv mit Falsch-Positiven und der Abgrenzung zu möglicherweise gefährlicher Software befasst, aber weder ist daraus eine gemeinsame Strategie für den Umgang damit entstanden noch ein gemeinsamer Standard, um Falscheinschätzungen zu korrigieren. So müssen betroffene Programmautoren mühsam jeden Anbieter einzeln abklappern und hoffen, dass etwas passiert.
Was die Anbieter mit entsprechenden Einsendungen tun, ist komplett intransparent. Viele fragen nicht einmal Kontaktdaten oder weitere Informationen ab, die beim Einschätzen helfen und eventuelle Rückfragen erlauben. Wir wurden das Gefühl nicht los, dass hier der Aufwand, den ein Betroffener betreiben muss, in keinem Verhältnis zur Aufmerksamkeit steht, die dieser dort erfährt.
Reflexion
Software-Entwickler können sich bei vielen AV-Hersteller registrieren und neue ausführbare Dateien im Vorfeld dort vorlegen, damit die gar nicht erst unter falschen Verdacht geraten. Wie beim Melden von Falsch-Positiven kocht hier jeder Hersteller von Antivirus-Produkten aber sein eigenes Süppchen.
Unterm Strich ist es wirtschaftlicher, sich an den Antivirus-Produkten vorbeizulavieren, etwa indem man fälschlich als unsicher denunzierte Programme versteckt. Die Ironie der Geschichte ist, dass man zu den gleichen Tricks greifen muss, die auch Virenbastler anwenden, um ihre Schädlinge unter die Leute zu bringen.
Falls Entwickler doch den mühsamen Weg gehen wollen, fälschlich als Schädling eingestufte Programme als ungefährlich einstufen zu lassen, finden sie auf GitHub eine seit Jahren gepflegte Liste mit Kontaktmöglichkeiten der AV-Hersteller für solche Fälle (siehe ct.de/yfsf). (ps@ct.de)
Reports auf VirusTotal, GitHub-Liste, ctBiosKey-Quelltext: ct.de/yfsf