Diese Woche wurde an mich wieder mal die Frage heran­ge­tragen, ob es nicht möglich sei, auf einem HTTP– und Mailgateway ausführbare Dateien (Executables) generell zu blocken und nicht bis zum Browser bzw. ins Postfach des Nutzers gelangen zu lassen. Da es in diesem Fall konkret um die Proxy-Software Squid und den Mailserver Postfix geht wäre eine Filterung auf Basis des Dateinamens relativ schnell über entspre­chende ACLs und »header checks« umsetzbar; diese Art der Überprüfung ist aller­dings auch sehr unzuverlässig.

Eine bessere Lösung, die den Inhalt von E-Mail-Anhängen und herunter geladenen Dateien unter­sucht, unab­hängig vom Dateinamen bzw. der Dateiendung, sollte es schon sein. Schön wäre es auch, wenn der Inhalt von (kompri­mierten) Archiven auf das Vorhandensein von ausführ­baren Binärdateien durch­sucht werden könnte. Zudem sollte sich der Aufwand in Grenzen halten um das Gesamtsystem nicht noch komplexer zu machen. Ach ja, die Performance des HTTP-Proxys sollte ebenfalls nicht weiter leiden — immerhin werden hier schon alle Anfragen durch einen Virenscanner — in diesem Fall HAVP in Verbindung mit ClamAV — gejagt.

Moment mal! Der Virenscanner. Sowohl die E-Mails (clamsmtp) als auch der beim Surfen anfal­lende Datenverkehr werden in diesem Fall vom Virenscanner ClamAV auf Schadcode hin unter­sucht. Dabei werden auch sehr gewis­senhaft unter­schied­lichste Archivtypen zerlegt und deren Inhalt geprüft. Wäre es da nicht sinnvoll, man könnte dem Scanner gleich mitteilen generell alle ausführ­baren Dateien als gefährlich einzu­stufen und Alarm zu schlagen?

Leider bringt ClamAV einen solchen Schalter nicht mit. Der Open Source Virenscanner verfügt aber über die Option, neben den offi­zi­ellen Virensignatur-Datenbanken auch selbst defi­nierte Schadcode-Muster bei der Suche nach bösar­tigem Code zu nutzen.

Wie man eigene Signaturen für ClamAV erzeugt verrät das PDF »Creating signa­tures for ClamAV«. Das Dokument beschreibt recht gut, wie man aus entdecktem Schadcode eine Virensignatur erstellen kann. Das inter­es­siert uns im vorlie­genden Fall aber erstmal weniger. Im Abschnitt 3.3.4 finden wir aber die Lösung zu unserem Problem. Das »extended signature format« liefert uns genau die benö­tigten Optionen, damit wir eine »Generalsignatur« für ausführ­baren Programmcode defi­nieren können. Eine solche Signatur hat allgemein den folgenden Aufbau:

MalwareName:TargetType:Offset:HexSignature

“MalwareName« ist der Name unseres »Virus«. Hier sollte man sich für eine Bezeichnung entscheiden, die sofort klar macht, dass es sich nicht unbedingt um eine gefähr­liche Datei handelt. Das zweite Feld »TargetType« ist schon inter­essanter. Hier kann man den Dateityp bestimmen, auf den die Signatur zutreffen soll. Uns inter­es­sieren im konkreten Fall Dateien vom Typ »Portable Executable, both 32– and 64-bit«, TargetType ist also »1«.

Die nächsten beiden Felder defi­nieren eine Binärsignatur und an welcher Stelle in der Datei diese Signatur erwartet wird. Windows-Executables zeichnen sich durch eine typische Zeichenfolge am Anfang der Datei aus. Daher wählen wir als Offset »0« um deutlich zu machen, das die aufge­führte Signatur am Anfang der Datei zu finden sein muss.

Kennt man den Binärcode von ausführ­baren Dateien unter Windows nicht auswendig (ich bin mir auch nicht sicher, ob ich so Leute kennen will g) greift man unter UNIX-Systemen zum Tool hexdump und wirft damit schnell einen Blick in eine .exe-Datei:

$ hexdump putty.exe | head -1
0000000 5a4d 0090 0003 0000 0004 0000 ffff 0000

“5a4d« ist der gesuchte Fingerabdruck. Die Signatur für ClamAV sähe demnach wie folgt aus:

Executable.Not.Allowed:1:0:5a4d??

Die beiden Fragezeichen (»??«) sind ein Hinweis, dass es nach der vorhe­rigen Sequenz noch weitere Bytes in der Datei gibt.

Damit wäre die Virensignatur fertig, jetzt muss sie nur noch ClamAV bekannt gemacht werden damit dieser auch über die neue Bedrohung Bescheid weiß. ClamAV sucht nach Virensignatur-Dateien im konfi­gu­rierten Datenbank-Verzeichnis — meist /var/lib/clamav. Ein Blick in die ClamAV-Konfiguration (clamav.conf) bringt hier aber Gewissheit. Damit also der Virenscanner unseren neuen Virus in seine Suchmusterdatenbank aufnimmt speichern wir die oben genannte Zeile in einer Datei mit der Endung ».ndb«:

$ echo 'Executable.Not.Allowed:1:0:5a4d??' > /var/lib/clamav/notallowed.ndb

Fertig. Zur Sicherheit sollte man nun alle Prozesse, die auf ClamAV zurück­greifen neu starten (z.B. HAVP, clamsmtp und clamd). ClamAV und die darauf basie­renden Tools (clamscan, clamd, libclamav, clamsmtp, etc.) nutzen ab sofort die zusätz­liche Signatur und werden Windows-Executables (darunter fallen neben .exe auch .dll, .sys und .drv) als Virus erkennen. Ein kurzer Test mit clamscan zeigt uns dies auch:

$ clamscan putty.exe
putty.exe: Executable.Not.Allowed.UNOFFICIAL FOUND
$ clamscan wnaspi32.zip
wnaspi32.zip: Executable.Not.Allowed.UNOFFICIAL FOUND
$ clamscan wnaspi32.dll
wnaspi32.dll: Executable.Not.Allowed.UNOFFICIAL FOUND

HAVP und clamsmtp bringen nun eine entspre­chende Fehlermeldung oder verweigern die Annahme der Mail — und das ohne großen Mehraufwand in der Konfiguration oder verschlech­terter Leistung.

---

PS: Wer sich jetzt auf Grund der Überschrift fragt was dieser Artikel mit dem in RFC3514 beschrie­benen »evil bit« zu tun hat, den muss ich leider enttäu­schen. Die Antwort lautet nämlich ‘ziemlich wenig’. :-)

Zumal das hier beschriebene Verfahren in der Praxis wirklich funk­tio­niert und dabei mehr Sicherheit bringt als die Auswertung des »security bit« in IPv4-Headern — der Vorschlag hat sich leider nie so richtig durchgesetzt. ;-)