Angst vor Binärdateien: Ja. Angst vor ASCII-Dateien: Nein. Marc Ruef | 07.09.2009 Kommt es zur Diskussion sicherer Einstellungen für Web- und Mailproxies, befolgen mittlerweile die meisten Administratoren und Sicherheitsverantwortlichen die gleiche Strategie: Binäre Dateien sind meistens gefährlich, Klartextdaten eher weniger. Das will heissen, dass man in erster Linie Dateien mit Erweiterungen wie EXE, DLL, OCX, SCR blockieren will. Alles andere kann ja nicht so gefährlich sein, da man es ja nicht effektiv ausführen kann. Meines Erachtens ein grosses Missverständnis, das sich am besten am Beispiel von Visual Basic Script, es wird mit VBS abgekürzt, illustrieren lässt. Hierbei handelt es sich um eine erweiterte Skript-Sprache, welche von Microsoft auf der Basis des klassischen Visual Basic (VB) eingeführt wurde. Personen aus dem Unix-Umfeld dichten Windows immerwieder an, dass sich auf der Kommandozeile mittels Batch-Skripten nur sehr rudimentäre Dinge automatisieren lassen. Und in der Tat ist die Mächtigkeit der BAT-Dateien nicht mit derjenigen von Bash-Skripten vergleichbar. Die Stapelverarbeitung aus dem Hause Microsoft kommt mit unkomfortablen Kontrollstrukturen und fehlenden Schnittstellen zu externen Daten und Anwendungen daher. Um dieser Einschränkung entgegenzuwirken wurde VBS eingeführt. Sodann lassen sich auf altbekannte und aus heutiger Sicht nicht selten archaisch erscheinende Konstrukte und Paradigmen von VB6 zurückgreifen. Ein VBS-Skript wird in einem herkömmlichen Texteditor erstellt und vorzugsweise mittels cscript.exe über die Eingabeaufforderung ausgeführt. Eine Kompilierung und damit das Anlegen und Ausführen einer Binärdatei ist dabei nicht erforderlich. Stattdessen wird das Skript interpretiert, wodurch es nicht per se gewissen Sicherheitseinschränkungen unterworfen ist. Mit VBS können jedoch auch rudimentäre grafische Objekte generiert und auf andere Schnittstellen zugegriffenw erden. Das nachfolgende Snipplet greift beispielsweise auf Outlook zu, zählt die ungelesenen Nachrichten in der Inbox und gibt diese mit einer Messagebox aus: codeSet otl = createobject("outlook.application") Set session = otl.getnamespace("mapi") session.logon Set inbox = session.getdefaultfolder(6) c = 0 For Each m In inbox.items If m.unread = True Then c = c + 1 MsgBox "New message: " & m.Subject End If Next session.logoff s = "s" If c = 1 Then s = "" Msgbox "You have " & c & " unread message" & s/code Die Gefahr von VBS-Skripten liegt effektiv darin, dass sich komplexe Anwendungen auf Windows-Systemen ausführen lassen, ohne diese kompilieren zu müssen. Entsprechend kann im Internet jemand ein VBS-Skript zum Download anbieten, welches aufg Grund des Dateninhalts niemals mit hoher Verlässlichkeit durch einen Proxy als solches erkennt werden kann. Es könnte ja einfach in einer Tabelle in einem simplen HTML-Dokument eingebettet sein. Der interne Benutzer legt eine Datei namens outlook.vbs an und generiert sich mit Copy&Paste das gewünschte Tool. Der Webproxy konnte nirgends eine VBS-Dateierweiterung feststellen und der Download von HTML-Inhalten ist ebenso legitim. Dies wird spätestens dann zum Beispiel, wenn über diesen Weg korrupter Programmcode an den etablierten Sicherheitsmechanismen vorbeischleust werden kann (siehe hierzu ebenfalls das spread project (http://www.computec.ch/projekte/spread)). Mit VBS lassen sich nämlich ohne Umstände Viren und Würmer entwickeln, die in Bezug auf ihre Mächtigkeit korruptem Programmcode in anderen Sprachen in (fast) nichts nachstehen (selbst der direkte Zugriff auf Speicherbereiche ist durch API-Calls möglich). VBS-Skripten kann man eigentlich nur Herr werden, indem man auf potentiell gefährdeten Windows-Systemen die Ausführung derer bzw. des Interpreters verhindert. Dies lässt sich mit NTFS-Permissions bzw. mit Group Policies durchsetzen. Doch nur die wenigsten Firmen sind mir bekannt, die sich darum bemühen. VBS wird belächelt. Ich wünsche mir für alle gutgläubigen Administratoren, dass man zum Schluss nicht aus Verlegenheit lachen muss, während man seinen Schreibtisch räumt.