InnoSetup und Trojaner-Heuristiken

[Bernhard Geyer]

Zitat:

Zitat von Gausi (Beitrag 1463904)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1463897)

Vermutlich weil du eine Virenverseuchte Datei hochlädst...

Öhm, wenn ein Upload-Formular für die Analyse von Malware mit der Option "Fälschlicherweise als Malware erkannt, bitte prüfen" keine Dateien zulässt, die fälschlicherweise als Malware erkannt werden, dann ist das Konzept etwas kaputt. ;-)

Ich glaube dein Sarkasmus-Detektor ist kaputt ...

[Assarbad]

Moinsen,

als altgedienter AV-Mensch (auch wenn ich seit einem reichlichen Jahr nicht mehr dabei bin), wollte ich mal ein paar Dinge einwerfen.

Zitat:

Zitat von Gausi (Beitrag 1463884)

Ich habe für meinen mp3-Player mit InnoSetup einen Installer gebaut. Dieser wird seit gestern(?) vom Windows Defender als "Trojan:Win32/Ludicrouz.C" erkannt. "False Positives" sind ja nichts neues, und grade bei Delphi kommt das immer wieder mal vor (z.B. auch mit den Indy-Komponenten). Etwas blöd ist, dass es diesmal der Windows Defender ist, der sehr weit verbreitet sein dürfte. Außerdem ist blöd, dass das Microsoft-Formular zur Malware-Analyse den Upload verweigert ("Upload failed, please try again"), und mir somit eine Meldung dieses Fehlers (erstmal) nicht möglich ist (verschiedene Browser probiert, verschiedene OS probiert, verschiedene Varianten probiert, z.B. auch zip mit Passwort wie im Formular angegeben, ...).

Also, bei Microsoft könntest du Glück haben, weil die eigentlich immer recht gut dabei sind Fehlalarme auszumerzen.

Zitat:

Zitat von Gausi (Beitrag 1463884)

Dann habe ich mir gedacht: Gut, veränderst du halt das Setup ein bisschen - vielleicht reicht das ja, um die Heuristik dann nicht mehr zu triggern. Interessanterweise hat das beim ersten Versuch geklappt. Ich habe im InnoSetup-Script die Zeile

Code:

#define MyAppPublisher "Daniel Gaußmann"

ausgetauscht durch

Code:

#define MyAppPublisher "Daniel Gausi Gaußmann"

Das hat tatsächlich gereicht, um den Windows Defender stumm zu schalten :shock:. Laut VirusTotal ist eine McAfee-Variante damit immer noch nicht zufrieden, aber das soll mir egal sein.

Hmm, kleiner Reality Check (und ja, als FLOSS-Entwickler, oder "ISV" wie man dann bezeichnet wird, wobei das auch kommerzielle einschließt), haste damit ein Problem.

Erkennungen (detections) verbreiten sich innerhalb der Industrie - leider rasend schnell.

Auf VT hochladen ist auch nicht die geilste Idee, weil dort im Hintergrund Analysetools für alle AVler bereitstehen (ich habe noch Zugriff) und sowas selbst geflaggt werden könnte, denn auch Malwareautoren machen genau das (allerdings sind viele davon auf eigene Dienste "im Darknet" umgeschwenkt, welche - wie VT - die Kommandozeilenscanner o.ä. der jeweiligen AVs benutzen).

Einerlei, Erkennungen verbreiten sich, egal ob Fehlalarm oder echt bösartig. Und das Problem ist, während sich mit VT und anderen Initiativen durchaus was herausgebildet hat, um innerhalb der Industrie Erkennungen zu teilen, gibt es keinerlei Möglichkeit allen Herstellern von AVs gleichzeitig die Meldung zukommen zu lassen, daß man Opfer eines Fehlalarms war.

Hier hilft aus meiner Sicht mittelfristig nur eine Regulierung durch die Politik, denn einige sehen sich geradezu als Internet-Sheriffs.

Das Problem ist, daß Einspruch seitens der jeweiligen Autoren von - an sich - harmlosen Programmen nicht vorgesehen ist. Und da keiner für die Fehlalarme zur Verantwortung gezogen wird und bspw. die fälschliche Erkennung zu keinen negativen Folgen (außer bei AV-Test und Konsorten) führt, wird lieber "über-erkannt".

Man kann also nur auf gesellschaftlicher Ebene einfordern, daß sich auch AV-Hersteller für von ihnen zu verantwortende Rufschädigung geradestehen müssen.

Zitat:

Zitat von Gausi (Beitrag 1463884)

Jetzt kann ich nachvollziehen, dass eine Malware-Heuristik bei einer nicht signierten Exe Alarm schlägt, wenn als Publisher z.B. "Microsoft" eingetragen ist.

Zwei Punkte:

1. Zumindest für FLOSS ist signieren billig. Wahlweise certum.pl oder SignPath.
2. Signaturen sind schon seit Jahren - kein Scherz! - durchgekaut. Es wurde ja schon mehrfach Malware gefunden die durch gestohlene oder "abhanden gekommene" Zertifikate signiert worden war. Von den Preimage-Angriffen aus MD5-Zeiten wollen wir mal ganz schweigen. Aus diesem Grunde wurde ja SHA-1 auch abgekündigt, weil zumindest mathematisch gewisse Schwächen ruchbar geworden waren.

Übrigens müssen die Catalog-Dateien bei Treibern genau aus diesem Grund von MS gegengezeichnet werden (früher nannte es sich Cross-Signing und stand nur zur Verfügung nachdem die WHQL-Tests durchlaufen wurden, jetzt gibt es auch die abgeschwächte Variante des Attestation Signing). Kurzum Microsoft sieht deine Treiber bevor sie dein Kunde zu Gesicht bekommt. Hat Vorteile. Bspw. bekommt man als Hersteller auch Zugriff auf die Minidumps von BSODs die der eigene Treiber mutmaßlich zu verantworten hatte.

Zitat:

Zitat von Gausi (Beitrag 1463884)

Sowas ist "verdächtig", völlig klar. Aber wenn ich einen unbekannten Hobby-Entwickler durch einen anderen ersetze, sollte das doch keinen Unterschied machen, oder? Ich halte Antiviren-Software ja tendenziell eher für Schlangenöl, aber so blöd kann das ja nicht sein ...:?

AV-Software ist nicht Schlangenöl. Zumindest nicht jede. Aber ja, im Grunde ist es so, daß Heuristiken halt immer mehr "fangen" als sie prinzipiell sollen. Nachjustieren kann man ja immernoch :zwinker: ... ich habe selber Heuristiken für die Mini-Engine gebastelt, die ich für SWF-Dateien geschrieben hatte. Bei anderen Heuristiken war ich nur lesend unterwegs, da das als (u.a.) Engine-Entwickler nicht gerade meine Hauptaufgabe war.

Und da die Heuristiken auch noch schnell sein sollen - und die AV-Engines ohnehin - werden auch gern Abkürzungen genommen. Jede Menge!

Und da - wie oben geschrieben - keiner für Fehlalarme zur Verantwortung gezogen werden, es sei denn die treten ausgerechnet bei einem der, meiner Meinung nach extrem verzerrten, AV-Tests auch (z.B. von AV-Test, AV Comparatives, VB100).

Kombiniert man das zu einem Gesamtbild, erklärt sich einem Betrachter von außen recht schnell, warum es so läuft wie's läuft.

Signaturen (AuthentiCode) haben nicht viel gebracht und Packern wollte man hiermit begegnen. In Sachen "saubere" Dateien wurde auf der VB2013 das hier vorgestellt. Auf meine explizite Nachfrage an Mark, bekam ich die Antwort, daß das nur für die dicken Haie im Becken sei (Adobe, Google, Microsoft, so die Größenordnung) und ein Zugang für ISVs, insbesondere FLOSS-Autoren nicht angedacht sei.

Zitat:

Zitat von Gausi (Beitrag 1463884)

Dann ist mir aufgefallen, dass die neue Version (mit dem längeren Publisher-String) ein paar Bytes kleiner ist als die alte. Beim Blick in die beiden Binaries (z.B. mit HxD) sieht man, dass dieser (und andere) Strings mit einer konstanten Länge (Unicode-String, aufgefüllt mit Leerzeichen) in der Datei zu finden sind - da ändert sich die Dateigröße also nicht.

Du weißt sicher wie Kompressionsalgorithmen funzen, oder? Das sollte also keine Überraschung sein.

Zitat:

Zitat von Gausi (Beitrag 1463884)

Relativ am Ende (größenordnungsmäßig die letzten 10%) des Installers findet sich dann ein Teil mit größeren Binär-Unterschieden. Die Teile sind dabei echt verschieden, nicht einfach nur um ein paar Bytes verschoben, beginnend mit "Inno Setup Setup Data" (als AnsiString). Ich nehme mal an, dass in diesem Teil die Setup-Daten nochmal(?) in komprimierter(?) Form vorliegen, und dass der längere String in Kombination mit den anderen Strings insgesamt besser komprimiert werden kann. Weiter kann ich mir vorstellen, dass in diesem anderen "Bytehaufen" dann keine Muster mehr vorkommen, die auch in besagtem Trojaner vorkommen.

Mit InnoSetup habe ich mich noch nie beschäftigt. Aber das war doch FLOSS, oder? Schau doch in die Quellen. Meiner Erinnerung nach gibt es auch eine Menge Werkzeuge die das entpacken und dechiffrieren können (also das Skript usw.).

Zitat:

Zitat von Gausi (Beitrag 1463884)

Jetzt ist es natürlich etwas komisch bzw. verdächtig, wenn ich schreibe "Ich hab da nur einen String ausgetauscht", und ein misstrauischer Anwender dann mal ein Diff macht und weitaus mehr Unterschiede findet. :stupid:

Kompressionsalgorithmen ...

Zitat:

Zitat von Gausi (Beitrag 1463884)

Hat damit jemand schon Erfahrung gesammelt, bzw. weiß, warum sich dieser letzte Teil im Installer so deutlich unterscheidet, wenn man nur eine String-Konstante ändert?

Ich würde auf folgende Unterschiede tippen:

• Reine Daten: Hashes, Zeitstempel ...
• Skript (was eventuell auch nochmal anhand deiner geänderten Ressource diese Änderung reflektiert)

Zitat:

Zitat von Gausi (Beitrag 1463884)

Beide Varianten als Download, falls sich das jemand ansehen möchte:
"Mit" Trojaner
"Ohne" Trojaner

Also im 010 sieht's so aus:

Anhang 52464

Code:

Result,Address A,Size A,Address B,Size B
Match,0h,BBE08h,0h,BBE08h
Difference,BBE08h,5h,BBE08h,5h
Match,BBE0Dh,13h,BBE0Dh,13h
Difference,BBE20h,4h,BBE20h,4h
Match,BBE24h,18Ch,BBE24h,18Ch
Difference,BBFB0h,15h,BBFB0h,15h
Match,BBFC5h,754900h,BBFC5h,754900h
Difference,8108C5h,Dh,8108C5h,Dh
Match,8108D2h,68h,8108D2h,68h
Difference,81093Ah,55B1h,81093Ah,55B8h
Match,815EEBh,B2625h,815EF2h,B2625h

... mit dem hier:

Code:

#!/usr/bin/env python3
import sys 

def main(*args):
    for fname in args:
        print("Datei %s" % (fname))
        with open(fname) as f:
            md_dict = {}
            for line in f:
                tk = line.strip().split(",")
                assert len(tk) == 5
                if tk[0] in {"Result"}:
                    continue
                curr = [int(x.strip("h"), 16) for x in tk[1:]]
                tpname = tk[0]
                if tpname not in md_dict:
                    md_dict[tpname] = []
                md_dict[tpname].append((curr[1], curr[3],))
            for k, v in md_dict.items():
                first, second = sum([x[0] for x in v]), sum([x[1] for x in v]) 
                print("{:10}:   {:10} vs. {:10}".format(k, first, second))

if __name__ == "__main__":
    main(*sys.argv[1:])

... bekommen wir folgende Ausgabe (ok.exe/bad.exe ... in der Reihenfolge):

Code:

$ ./compare.py Compare.csv 
Datei Compare.csv
Match     :      9187124 vs.    9187124
Difference:        21980 vs.      21987

Das ist ein schon recht kleiner Unterschied, oder?

Fazit:

• Gesellschaftlichen Druck aufbauen. Ziel muß es sein, daß auch AV-Hersteller für von ihnen begangene Rufschädigungen zur Rechenschaft gezogen werden [1]. Erst ab dem Zeitpunkt wird sich etwas bewegen, so daß auch für ISVs/Einzelautoren die Möglichkeit geschaffen wird über ein Formular alle Hersteller gleichzeitig über einen Fehlalarm zu unterrichten. Klar gibt's da Mißbrauchspotential. Aber die Rufschädigungen wenn etwas harmloses als bösartig erkannt wird, sind auch nicht ohne ...
• Kunden/Anwender auf das Treiben der AV-Hersteller hinweisen und ggf. bitten diese auch zu kontaktieren.

[1] Bei meiner Zwischenstation bei Lavasoft in Göteborg habe ich gelernt, daß eigentlich mehrfach wöchentlich Unterlassungsaufforderungen (cease & desist letters) ankamen, wenn sich einer der Adware-Hersteller auf den Schlips getreten fühlte. Bei AV-Herstellern war das bis vor ein paar Jahren alles immer recht schwarzweiß, bis man anfing Potenziell unerwünschte Anwendungen (PUA) auch mit aufzunehmen. Da stellt sich dann halt die Frage ob der seit anderthalb Jahrzehnten gepatchte Exploit nun wirklich noch gefährlich ist, oder das Tutorial zu Window-Hooks mit einem Tastaturhook nicht brandgefährlich (die entpackte Variante davon mußte ich erst unlängst entfernen, weil ja nicht nur diese eine URI bei Google Safe Browsing gesperrt wird, sondern die komplette Domain mit allen Subdomains) ...

[Assarbad]

Zitat:

Zitat von Delphi.Narium (Beitrag 1463906)

Heuristik heißt bei Virenscanner: Wir suchen nach 'ner Ähnlichkeit.

Nee, das bedeutet wir such(t)en nach Indikatoren und ab einer bestimmten Schwelle schlagen wir Alarm, falls zu viele Indikatoren bedenkliche Werte zeigen.

Zitat:

Zitat von Delphi.Narium (Beitrag 1463906)

Sprich: Das ist von außen nicht durchschaubar.

Es ist bedingt durchschaubar, klar. Aber es ist jetzt auch nicht wirklich Zauberwerk ... vieles kann man sich auch allein denken. Beispiele:

• Welcher Compiler wurde benutzte (effektiv das was PEiD macht, AV-Hersteller benutzen bspw. Yara)
• Gibt es eine Signatur?
• Ist die Signatur gültig?
• Vertrauen WIR (als der AV-Hersteller) der Signatur?
• Welche Importe hat die Datei und aus welchen DLLs? (bspw. UNC-Pfade? ... böse!)
• Keine oder wenige Importe? (Laufzeitpacker/Protector oder der Versuch sich einer Analyse/Erkennung zu entziehen)
• Wie ist die Entropie der Datei (Laufzeitentpacker oder nicht ...)?
• Gibt es verdächtige Strings? (ja, das ist exakt das Beispiel von gausi!)
• Wird auf Debugsymbole verwiesen? Deren Pfade können verräterisch sein, siehe vorheriger Punkt ...
• Wie verhält sich die Datei beim emulieren innerhalb der Engine? (Jupp, bei uns steckte da ein echter Emulator drin, denn nur so konnte man bei Laufzeitentpackern und "Schutz"-Programmen ala Themida reingucken)

Zitat:

Zitat von Delphi.Narium (Beitrag 1463906)

Wenn heute eine Datei problemlos durch alle Virenscanner als ok durchgeht, kann morgen schon die gleiche Datei in absolut unveränderter Form nicht mehr durchgehen, einfach, weil in der Heuristik was verändert wurde und nun irgendwas als Treffer interpretiert wird, was gestern noch kein Treffer war.

Sehr richtig!

Zitat:

Zitat von Delphi.Narium (Beitrag 1463906)

Man muss eigentlich immer damit rechnen, dass ein Virenscanner von heute auf morgen bei einer bestimmten Datei zuschlägt oder eben auch nicht mehr zuschlägt.

Letzteres ist aber deutlich unwahrscheinlicher.

Erinnert sich noch jemand? Das war clever, aber jeder in der Industrie wußte, wie's läuft. Manuell war schon vor Jahren Pumpe. Manuelle Analysen von interessanter Malware hat man sich allenfalls noch als PR gegönnt und weil man so der Konkurrenz ne Nase drehen konnte.

Heute läuft vieles über Sandkästen. Gibt's sogar als FLOSS. Einige haben eigene Technologie zu dem Thema, meine ehemalige Firma hat das verschlafen. Bzw. ich weiß mittlerweile daß ein Konkurrent schneller war (der auch bei mir anfragte ob ich nicht Interesse an einem Job hätte). Schon auf der VB2013 war ein richtungsweisendes Paper vorgestellt worden. Diese Erkenntnisse hätte man nutzen und ausbauen können. Stattdessen wurde in dieser Richtung nichts getan und nun lizensiert man es halt von Dritten. Dumm gelaufen.

Eigentlich hatten wir auch sowas wie einen Sandkasten, nämlich die interne Version unseres Befehlszeilenscanners. Der hat jede Menge Extrainfos ausgespuckt, welche dann wiederum weiterverarbeitet werden konnten.

Einerlei, was passiert wenn du eine Datei bei VT hochlädst, ist daß die durch die ganzen AV-Engines durchgejagt wird und auch nochmal in mindestens einer Sandbox läuft. Was anderes machen auch die AV-Hersteller nicht. Nur stark parallelisiert und automatisiert. Da wird dann geclustert und versucht neue Methoden zu finden wie man zu Clustern kommen kann und das in Heuristiken abbilden kann. Da gibt es die wildesten Methoden.

Die haben überall ihre Honigtöpfe aufgestellt oder sehen bspw. anhand der URLs in Email-Kampagnen (Antispam und Antimalware ist nämlich in dieser Hinsicht supi kombinierbar) was gerade abgeht. So werden auch Malwarekampagnen zeitnah aufgedeckt. Aber gegen Spearphishing hilft das natürlich auch nix.

Zitat:

Zitat von Delphi.Narium (Beitrag 1463906)

Irgendwann war die Exe plötzlich virenverseucht (auch wenn man sie mit Delphi neu kompilierte). Ein paar Tage später war sie es dann nicht mehr, dazwischen lagen nur ein paar Updates der Signaturdateien des Virenscanners. Andere Virenscanner befanden die Exe die ganze Zeit über als "völlig unauffällig".

Wobei man dazusagen sollte, daß es in der Tat schon Malware hab, welche die vorkompilierten Objektdateien auf Rechnern mit Delphi (usw.) befiehl und somit die Programme frisch ab Werk verseucht waren. Aber deine Geschichte klingt schon nach Fehlalarm.

[Assarbad]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1463897)

Doch, bei Heuristik schon. Hatten erst vor kurzen den Fall das eine 1/2 Jahre alte DLL immer wieder gelöscht wurde und von immer mehr (gleiche Engine) Scannern angemeckert wurde.
Damit muss man halt mittlerweile leben ...

Nein! Bitte nicht. Ich meine es Ernst. Empört euch! Beschwert euch!

Was AV-Hersteller überhaupt nicht mögen ist negative PR. Und die bekommen sie meistens maximal durch irgendwelche AV-Testveranstaltungen [1] und dort gemachte Fehlalarme. Aber wenn sich wirklich eine Menge von Entwicklern gemeinsam immer wieder über sowas aufregt, kann daraus etwas entstehen, was dazu führt, daß es einen Rechtfertigungsdruck gibt und daß die AV-Hersteller (das wäre meine Mindestforderung) den Betroffenen eine zentrale Anlaufstelle zur Verfügung stellen. Am besten direkt in ihr Programm eingebaut. Sprich: die Verteilung findet über die existierenden Mechanismen statt (bspw. hatte Norman da vor Jahren etwas etabliert) aber der einzelne Hersteller bekommt immer die Fehlalarmmeldungen seiner eigenen Kunden.

Es gab vor Jahren mal eine Initiative von einem kleinen ISV (der Autor von PECompact), der eine "Hall of Shame" für die ganzen Fehlalarme etablieren wollte. Leider ist das Projekt eingeschlafen.

Einerlei: als Entwickler von Software sind wir in einer speziellen Position. Wir sind gleichzeitig Anwender von AV-Software und Betroffene bei Fehlalarmen und zusätzlich sind unsere Anwender meistens auch die Anwender von anderen AV-Herstellern und dort Betroffene. Mit dieser Argumentation und den schwachen Argumenten der AV-Industrie sollte sich etwas machen lassen.

[1] Die halte ich komplett für Schiebung mittlerweile. Ich sag nur AMTSO. Der Grundstein wurde damals auf Einladung von Friðrik in Reykjavík gelegt (2010/2011?). Ich war 2017, glaub ich, in Innsbruck bei einer Tagung dabei und bin seitdem etwas desillusioniert in Sachen AV-Tests. Zwar pochten einige der Tester durchaus auf gewisse Verfahrensweisen, aber erstens machen sich einige Tester durch Geldfluß von den AV-Herstellern abhängig und außerdem saßen da mehrere Dutzend AV-Mitarbeiter und vielleicht ein Dutzend Tester.

[Assarbad]

Zitat:

Zitat von dummzeuch (Beitrag 1463903)

Zitat:

Zitat von Delphi.Narium (Beitrag 1463889)

Frei nach dem Motto:

Erstellprozess des Setups starten.
Upps: Virusalarm
Erstellprozess des Setups starten.
Kein Virusverdacht.

Also genau das, was die Virenprogrammierer auch machen, die allerdings vermutlich automatisiert und mit vielen Virenscannern.

Damit liegst du (leider) nicht so weit daneben. Bei VT hochladen war auch eine Weile Usus. Aber mittlerweile haben die Malwareautoren ihre eigenen Dienstleister. Man darf ja nicht vergessen, daß das nicht mehr die VXer aus den 1990ern und frühen 2000ern sind, die zeigen wollen was sie technisch so auf Lager haben, sondern daß es sich um eine im wahrsten Wortsinne organisierte Schattenwirtschaft handelt. Und unsere Geheimdienste mischen da mit, wie man spätestens nach Snowdens Enthüllungen auch ganz sicher weiß.

Übrigens: auch Zeitstempel (auch die von Signaturen, oder von den Datensätzen die zu den Debugsymbolen gehören oder der Zeitstempel im PE-Header - der allerdings nicht bei Delphi) sind Indikatoren bei den Heuristiken :zwinker:

Frisch erstelltes Programm bei dem andere Indikatoren knapp unter der Schwelle für die Erkennung bleiben? Oh?! Frisch erstellt! Bingo ... Hauptgewinn für den Entwickler! :mrgreen:

[Assarbad]

Zitat:

Zitat von himitsu (Beitrag 1463908)

Wenn sich die Länge eines Strings in der EXE verändert, dann verschieben dich auch andere nachfolgende Dinge und Referenzen darauf müssen dann ebenfalls angepasst werden usw.

Wobei bei Setupprogrammen meist ein Stub mit angehängten Daten (Overlay) zum Einsatz kommt. Will heißen die Unterschiede dürften sich meist aus der Kompression und Metadaten ergeben, sofern der Rest gleich ist.

Zitat:

Zitat von himitsu (Beitrag 1463908)

Am "Einfachsten" ist es ja immernoch dem betreffenen Antivierenhersteller seinen False-Positive zu melden und die Viren-Signatur bzw. die Heuristik dementsprechend verbessern zu lassen, anstatt selbst so lange zumzufummeln, bis "aktuell" bei einem selbst das Problem "weg" ist.

Ich hoffe die Lektüre meiner obigen Ausführungen hat dabei geholfen den rosa Feenstaub von deiner Brille zu putzen :mrgreen:

Also erstens ist es meistens nicht gerade wenig Aufwand es einem Hersteller zu melden, sofern man das entsprechende Formular findet (und dieses auch funktioniert und man dutzendfach CAPTCHAs gelöst hat oder daran gescheitert ist). Aber während dieser Zeit tickt bereits die Uhr. Erstens wird der AV-Hersteller dem du den Fehlalarm meldest nicht einfach die Erkennung rausnehmen, sondern das wird einem anderen Prozeß zugeführt und nur in Ausnahmefällen guckt da mal ein Mensch drauf. Und bis dahin kann auch schonmal ne Woche oder zwei vergehen. Ach ja, macht dein AV-Hersteller auf der Formularseite ein Versprechen, man würde sich bei erfolgter Nachanalyse zurückmelden? Nicht? Tscha ... shit happens.

Und in dem jeweiligen Prozeß wird wahrscheinlich dein Programm nicht nur den Analysewerkzeugen rund um VT zugeführt, aber auch. Und wenn derweil andere AV-Hersteller schon bei deinem Hersteller die Erkennung - pardon, den Fehlalarm - "abgeguckt" haben, haste schwuppdiwupp nen Teufelskreis. Hersteller A guckt bei B ab und C wiederum bei A und B. Und jetzt kommst du "Würstchen" und willst denen erzählen deine Software sei harmlos?! Und jetzt kommst du "Würstchen" und willst denen erzählen deine Software sei harmlos?! Das spielst du jetzt mit fünf, sechs dutzend AV-Herstellern durch ... :mrgreen:

Ich hab das selber mit WinDirStat durch. Und zwar in zwei Richtungen. Einmal wollte ich eine trojanisierte Variante in Erkennung aufnehmen lassen. Das ging recht flott, auch da ich durch unser Virenlabor halt Zugang zu anderen Kanälen hatte als der Endanwender oder betroffene Softwareentwickler. Ein anderes Mal wurde leider fälschlich ein harmloses Kompilat erkannt.

Ach ja, es gibt natürlich Premiumdienste wie diesen hier oder diesen hier, mit denen du mittelbar jene bezahlst, die für die Fehlalarme verantwortlich sind, aber nicht zur Verantwortung gezogen werden.

[Gausi]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1463941)

Ich glaube dein Sarkasmus-Detektor ist kaputt ...

Ja, der leidet in letzter Zeit ein wenig und muss mal wieder nachjustiert werden. Ich hatte deinen Kommentar tatsächlich ernst genommen ... :oops:

Zitat:

Zitat von Assarbad (Beitrag 1463952)

als altgedienter AV-Mensch (auch wenn ich seit einem reichlichen Jahr nicht mehr dabei bin), wollte ich mal ein paar Dinge einwerfen.

Wow, tausend Dank! Das ist ne Menge Input.:thumb:

Vor allem die Hintergründe zu VT und Co. Ein ungutes Bauchgefühl hatte ich eh bei dem Ansatz "so lange kleine Änderungen probieren, bis es passt." Das hat sich dann bestätigt, und ich werde das bleiben lassen, bzw. nur in Ausnahmefällen machen.

Generell sind mir Fehlalarme bei den ganzen AV-Herstellern egal in dem Sinne, dass ich da keine Arbeit reinstecke, um die von meiner Seite zu beheben. Dafür ist mein Nutzerkreis zu klein, und die Schnittmenge zu Nutzern von Antivirus-Produkt-XY dürfte eher ein-, maximal zweistellig sein. Beim Windows Defender sieht das etwas anders aus, daher habe ich mich an der Stelle mal oberflächlich damit beschäftigt.

Zum Begriff Schlangenöl: Ich bin da nicht so fanatisch wie z.B. fefe. Problematisch sehe bei AV-Software, dass sie unter Umständen bei einigen Usern ein (falsches) Gefühl der Sicherheit erzeugt, und im Ernstfall dann doch nicht hilft. Bei Sicherheits-Komplett-Paketen, die dann auch TLS-Verbindungen aufbrechen, werde ich aber wirklich skeptisch.
Ein Virenscanner, der im Hintergrund läuft, ist schon sinnvoll denke ich. Ich bin da auch sehr dankbar, dass MS sowas bei Windows integriert hat, und dass deren Defender relativ unauffällig arbeitet. Und nicht regelmäßig Popups produziert wie "Alles OK, ich mache einen super Job!" und "Bitte hier klicken zum Kauf der Vollversion".

[himitsu]

Zitat:

Also, bei Microsoft könntest du Glück haben, weil die eigentlich immer recht gut dabei sind Fehlalarme auszumerzen.

Klar, die haben auch ein berechtigtes Interesse daran, dass ein eigenes Programm nicht das eigene OS unbenutzbar macht. :stupid:

Den Anderen ist es wohl eher mehr egal, hauptsache "sicher".
Wobei, viele der AV-Programmhersteller nutzen doch keine eigene Signaturen und verwenden die von wo anders,
aber ich hätte dann eigentlich auch erwartet, dass es dort dann auch einfacher wird, wenn sich nur Einer oder eine Gruppe um die Befüllung/Bereinigung/Reparatur kümmern, anstatt jder Hersteller selbst.


Zum Glück hatte ich selber noch nicht so große Probleme und die zwei/drei mal, war das Problem zwei Stunden bis paar Tage Später weg, nachdem ich den Fals-Positive hochgeladen hatte.


Nur ein paar Neuerungen von Microsoft nerven, denn standardmäßig ist jetzt "Löschen" voreingestellt, statt den Kunden zu warnen nerven.
Und dann diesee neue coole Funktion, wo ich grade wieder den Namen vergessen hab, da wird beim "ersten" Start die EXE ungefragt/heimlich in die Cloud hochgeladen, für x sekunden blockiert/verzögert und dann geperrt, oder wenn die Cloud nicht schnell genug reagiert nach 10 oder 30 Sekunden erst gestartet.


[EDIT] OK, war zu einfach der Name: "block at first sight" :freak:
https://www.tenforums.com/tutorials/...dows-10-a.html
https://docs.microsoft.com/de-de/win...nder-antivirus

Hatte ein Programm auf dem Server kompiliert, via RDP her geholt und wollte es lokal testen ... erst gefühlt ewig warten und dann der Sperrbildschrirm.

[Delphi.Narium]

Zitat:

Zitat von Assarbad (Beitrag 1463954)

Zitat:

Zitat von Delphi.Narium (Beitrag 1463906)

Heuristik heißt bei Virenscanner: Wir suchen nach 'ner Ähnlichkeit.

Nee, das bedeutet wir such(t)en nach Indikatoren und ab einer bestimmten Schwelle schlagen wir Alarm, falls zu viele Indikatoren bedenkliche Werte zeigen.

Naja, und reicht die Menge der Indikatoren, dann böse ;-)
Für mich ist das eine Ähnlichkeit, vielleicht auf 'ner anderen Ebene, als bei Meier und Maier, aber es gibt halt eine bestimmte Menge an (algorithmischen) Übereinstimmungen.

Zitat:

Zitat von Assarbad (Beitrag 1463954)

Zitat:

Zitat von Delphi.Narium (Beitrag 1463906)

Sprich: Das ist von außen nicht durchschaubar.

Es ist bedingt durchschaubar, klar. Aber es ist jetzt auch nicht wirklich Zauberwerk ... vieles kann man sich auch allein denken. Beispiele:

• Welcher Compiler wurde benutzte (effektiv das was PEiD macht, AV-Hersteller benutzen bspw. Yara)
• Gibt es eine Signatur?
• Ist die Signatur gültig?
• Vertrauen WIR (als der AV-Hersteller) der Signatur?
• Welche Importe hat die Datei und aus welchen DLLs? (bspw. UNC-Pfade? ... böse!)
• Keine oder wenige Importe? (Laufzeitpacker/Protector oder der Versuch sich einer Analyse/Erkennung zu entziehen)
• Wie ist die Entropie der Datei (Laufzeitentpacker oder nicht ...)?
• Gibt es verdächtige Strings? (ja, das ist exakt das Beispiel von gausi!)
• Wird auf Debugsymbole verwiesen? Deren Pfade können verräterisch sein, siehe vorheriger Punkt ...
• Wie verhält sich die Datei beim emulieren innerhalb der Engine? (Jupp, bei uns steckte da ein echter Emulator drin, denn nur so konnte man bei Laufzeitentpackern und "Schutz"-Programmen ala Themida reingucken)

Dafür brauch' ich aber deutlich mehr "NauHau", als ich so vom Normalverbraucher (der z. B. Gausis Programm nutzen möchte) erwarten kann. Und der kriegt ggfls. die Virenscannermeldung um die Ohren gehauen und wird bei (fast) allen(?) Punkten, die Du aufgeführt hast, höchsten mit 'nem "hä" antworten ;-)

Nichtsdestotrotz:

Deine Antworten sind hoch informativ und gegeben auch uns Laien einen kleinen Einblick in die Materie.

Muchas gracias!

[Assarbad]

Zitat:

Zitat von Gausi (Beitrag 1463979)

Zum Begriff Schlangenöl: Ich bin da nicht so fanatisch wie z.B. fefe.

Nehmen wir mal die aktuelle Bedeutung, so wie sie halt auf AV-Software auch angewandt wird.

AVs schützen vor Dingen, die den jeweiligen Herstellern bekannt sind, bzw. durch eine Heuristik erfaßt werden. So weit, so gut. Problem ist nur, daß in der Tat allein schon durch das Parsen von Dateien aller Couleur jede Menge Angriffsfläche frisch entsteht. Guck dir die mehr oder weniger regelmäßigen Schwachstellen in Sachen Archivformate an. Und wenn es dann an die Bearbeitung der gemeldeten Schwachstellen kommt, dann merkt man, daß es auch bei AV-Herstellern kein höheres Problembewußtsein für Schwachstellen gibt als anderswo.

Die Kritik ist also durchaus berechtigt. Im Gegensatz zu den ganzen anderen im obigen Artikel verlinkten Programmen haben die meisten AVs aber durchaus auch eine Schutzwirkung. Daher finde ich den Begriff Schlangenöl - bei aller berechtigter Kritik! - unpassend.

Zitat:

Zitat von Gausi (Beitrag 1463979)

Problematisch sehe bei AV-Software, dass sie unter Umständen bei einigen Usern ein (falsches) Gefühl der Sicherheit erzeugt, und im Ernstfall dann doch nicht hilft.

Das bringt das Hauptproblem schön auf den Punkt. Bzw. es ist Glückssache ob sie hilft. Sprich, sie hilft in - meinetwegen - 98% der Fälle, aber was passiert falls du über die verbleibenden 2% stolperst. In absoluten Zahlen sind die verbleibenden 2% dann ja noch immer extrem viele nicht erkannte Schädlinge.

Leider ist es nicht im Interesse der AV-Hersteller Anwender zu schulen. Das wäre aus meiner Sicht die wirksamste Methode schlechthin. Aber als ehemaliger Admin weiß ich auch, daß die meisten Anwender auch keinen Bock haben geschult zu werden.

Zitat:

Zitat von Gausi (Beitrag 1463979)

Bei Sicherheits-Komplett-Paketen, die dann auch TLS-Verbindungen aufbrechen, werde ich aber wirklich skeptisch.

Sei gleich ablehnend. Derlei MitM-Quark gehört auf den Müllhaufen der Geschichte. Das geht überhaupt nicht.

Zitat:

Zitat von himitsu (Beitrag 1463982)

Zum Glück hatte ich selber noch nicht so große Probleme und die zwei/drei mal, war das Problem zwei Stunden bis paar Tage Später weg, nachdem ich den Fals-Positive hochgeladen hatte.

Glückspilz!

Zitat:

Zitat von himitsu (Beitrag 1463982)

Wobei, viele der AV-Programmhersteller nutzen doch keine eigene Signaturen und verwenden die von wo anders,
aber ich hätte dann eigentlich auch erwartet, dass es dort dann auch einfacher wird, wenn sich nur Einer oder eine Gruppe um die Befüllung/Bereinigung/Reparatur kümmern, anstatt jder Hersteller selbst.

Okay, kurzer Exkurs. Signaturen im klassischen Sinne kommen noch immer zum Einsatz. Aber allein durch die schiere Menge täglich frischer Malware, die sich nur in wenigen Bytes unterscheidet, müssen diese baldmöglichst in Heuristiken überführt werden. Das macht man, sobald sich ein Cluster aus verschiedenen Dateien herauskristallisiert. Die Bezeichnung "Signaturen" ist also eigentlich technisch irreführend, aber dennoch gebräuchlich.

Erkennung ergibt sich grob gesagt aus: Engine (Code) + "Signaturen" (Daten).

Meistens sind diese "Signaturen" nur zu jeweils einer Engine kompatibel. Aus Endanwendersicht gibt es also jene AV-Hersteller mit eigener Engine und jene ohne eigene Engine. Letztere bauen - auch wenn das jetzt etwas überspitzt und verkürzt ist - im Prinzip nur eine Benutzeroberfläche um eine existierende AV-Engine. Und ja, es kann sein daß ein solcher Hersteller seine eigenen "Signaturen" anbietet oder zusätzlich zu denen des Herstellers der AV-Engine eigene erstellt und anbietet (dazu gibt's dann Werkzeuge seitens des Herstellers der Engine). Bei VT kann man häufig an der gleichen Namensgebung erkennen ob sich mehrere AV-Produkte eine Engine teilen.

Dann gibt es noch den Spezialfall mehrerer Engines. Meistens sind das dann Hersteller aus der zweiten Kategorie, denn die Engine-Hersteller befinden sich ja in einer natürlichen Konkurrenz zueinander. Meist wird die schnellste Engine vorgeschaltet. Zusätzliche Engines dienen dann der Verifikation. Denn allgemein galt bei uns immer: sobald wir etwas erkennen, geht's nicht mehr um Geschwindigkeit, sondern um Gründlichkeit. Bei mehreren Engines bekäme also die Engine 2 die Datei nochmal vorgelegt und so können dann bspw. Fehlalarme (False Positives) ausgeschlossen werden.

Aber ich kann keine wirklichen Details nennen, da ich da nicht genug Einblick habe (Multi-Engine). Ich würde annehmen, daß der Produkt-Hersteller die eingesetzten Engines selbst bewertet und so quasi den Erkennungen eine Vertrauenswürdigkeit zuordnet und dementsprechend einen Gesamt-Score ermittelt. Also bspw. weiß der dann daß Engine 1 die schnellste ist, also wird die davorgeschnallt. Außerdem ist Engine 1 gut bei - sagen wir mal - Droppern. Hingegen bei PUA ergibt sich eine Diskrepanz zu den Bewertungskriterien von Engine-Hersteller und Produkt-Hersteller. Also werden PUA-Erkennungen von Engine 1 nochmal Engine 2 vorgelegt und dann ggf. "durchgelassen".

Zitat:

Zitat von himitsu (Beitrag 1463982)

Hatte ein Programm auf dem Server kompiliert, via RDP her geholt und wollte es lokal testen ... erst gefühlt ewig warten und dann der Sperrbildschrirm.

Das erhöht natürlich unheimlich die Akzeptanz solche Lösungen :zwinker:

Zitat:

Zitat von Delphi.Narium (Beitrag 1463989)

Zitat:

Zitat von Assarbad (Beitrag 1463954)

Zitat:

Zitat von Delphi.Narium (Beitrag 1463906)

Heuristik heißt bei Virenscanner: Wir suchen nach 'ner Ähnlichkeit.

Nee, das bedeutet wir such(t)en nach Indikatoren und ab einer bestimmten Schwelle schlagen wir Alarm, falls zu viele Indikatoren bedenkliche Werte zeigen.

Naja, und reicht die Menge der Indikatoren, dann böse ;-)
Für mich ist das eine Ähnlichkeit, vielleicht auf 'ner anderen Ebene, als bei Meier und Maier, aber es gibt halt eine bestimmte Menge an (algorithmischen) Übereinstimmungen.

Wahrscheinlich meinen wir das gleiche. Nur bei Ähnlichkeiten frage ich mich immer: ähnlich wozu. Und genau diese Cluster bilden sich ja erst raus, je mehr erkannte Dateien man "sieht".