Personal Firewalls

Der CCC Ulm und der Chaostreff Bad Waldsee haben alle gängigen Personal Firewalls daraufhin getestet, ob das versprochene Mehr an Sicherheit erreicht wird. Das Ergebnis verwundert einen Experten nicht, ist aber für den Laien erstaunlich.

Einführung

Personal Firewalls gehören zu den Mitteln, mit denen der moderne Windows-User den zahlreichen Gefahren des Internets (beispielsweise Würmer, Spyware oder trojanische Pferde) zu begegnen gedenkt. Es handelt sich dabei um Programmpakete, die eine Reihe von Funktionen bündeln, um dadurch sowohl eingehenden wie auch ausgehenden Datenverkehr gezielt zulassen oder unterbinden zu können. Die wesentlichen Funktionen sind:

  • Filtern auf Adressen/Ports: Abhängig von IP-Adresse und Port werden Pakete zugelassen oder verworfen.
  • Filtern auf Anwendungen: Abhängig von Pfad und/oder Prüfsumme (das wird bei den einzelnen Personal Firewalls unterschiedlich gehandhabt) dürfen Anwendungen Verbindungen nach außen aufbauen oder Verbindungen von außen annehmen.

Zusätzlich versuchen manche Personal Firewalls das Starten von Programmen durch andere Programme zu kontrollieren. Dazu werden anscheinend Aufrufe von CreateProcess() bzw. WinExec() abgefangen. Daneben enthalten viele Personal Firewalls noch weitere lustige Features, die den Benutzer schützen sollen. Dazu gehört beispielsweise das Droppen von ICMP-Paketen, um den Rechner vor Angreifern zu verstecken, oder das Sperren der Kommunikation mit einer IP-Adresse, wenn Pakete mit dieser Source-IP als Angriff erkannt wurden.

Wir haben insgesamt sieben Personal Firewalls in Bezug auf ihre Funktionsfähigkeit und ihren Spaßfaktor für Angreifer untersucht. Die Ergebnisse wurden im Dezember bei einem ChaosSeminar in Ulm gezeigt.

Getestet wurden:

  • Kerio Personal Firewall 4.1.2
  • Norman Personal Firewall 1.42
  • Agnitum Outpost Firewall Pro 2.5
  • Sygate Personal Firewall Pro 5.5
  • Tiny Firewall 6.0
  • Zone Labs ZoneAlarm Pro 5.5
  • Symantec Norton Personal Firewall 2005

Zur Realisierung der genannten Funktionen haben die meisten Personal Firewalls einen dreigeteilten Aufbau:

  • ein oder mehrere Kernel-Treiber, zum Filtern im Kernelspace
  • ein oder mehrere Dienste zur Steuerung der Treiber (laufen mit SYSTEM-Rechten)
  • GUI zur Konfiguration (läuft mit Userrechten)

Das GUI lässt sich bei jeder Personal Firewall durch ein Passwort schützen, so dass nicht unbefugt Änderungen vorgenommen werden können. Leider ist dieser Schutz bei keinem der Programme Default. Die Anzahl der installierten Treiber und Dienste variiert sehr stark von Personal Firewall zu Personal Firewall. Um einen Überblick über die installierten Dateien, Treiber und Dienste zu erhalten, wurde die Installation der einzelnen Personal Firewalls mit InCtrl5 protokolliert.

Kerio Norman Outpost Sygate Tiny ZoneAlarm Norton
Registry-Schlüssel 477 64 315 277 1694 189 3556
Registry-Werte 705 246 1036 743 2283 499 5934
Verzeichnisse 12 23 15 8 32 8 34
Dateien 61 109 222 61 382 74 417
Treiber 1 2 2+n 5 8 1 8
Dienste 1 1 1 1 5 1 8

Der Eintrag "2+n" bei den Outpost-Treibern bedeutet, dass neben den Basistreibern eine variable Anzahl von Modulen für Filteraufgaben installiert wird.

Für alle Tests wurden die Default-Einstellungen verwendet, da wir bei Sicherheitssoftware (und solcher, die es werden will) voraussetzen, dass sie mit sicheren Defaults installiert wird.

Funktionalität mangelhaft

Was den Schutz von Außen betrifft so geht eine Personal Firewall den Weg des Packetfilterns. Der Angriffsvektor ist dabei immer ein Dienst. Wenn dieser anfällig gegen gezielte Protokollverletzungen wie z.B. Buffer Overflows ist, kann sich ein Angreifer damit Zugang zum System verschaffen. Die Personal Firewall soll das verhindern, in dem sie den eingehenden Verkehr scannt und u.A. Verbindungsversuche zu diesem Dienst unterbindet. Da jede Personal Firewall Software ist, und Software nun mal Fehler haben kann, weil sie von Menschen gemacht wird, hat man das Risiko damit effektiv nur verlagert. Jetzt ist es die Personal Firewall, die angegriffen werden kann. Wenn man den nicht benötigten Dienst aber einfach abschaltet, besteht dieser Angriffsvektor nicht mehr. Das Betriebssystem wirft die Pakete weg, weil auf dem angegebenen Port kein Dienst lauscht. Der einzige Angriffsvektor bleibt hierbei das Betriebssystem. Und wenn das einen Fehler im Protokoll Stack hat, dann hilft auch keine Personal Firewall mehr.

Eigentlich sollte Microsoft seine Betriebssysteme ohne aktivierte Dienste ausliefern. Aus irgendwelchen Gründen ist das aber nicht der Fall, so dass sich Würmer wie z.B. Sasser verbreiten konnten. Man kann aber manuell nachhelfen. Hierzu gibt es entweder ein Batch-Skrit von Torsten Mann oder ein GUI Programm von Volker Birk, die beide das selbe tun: sie machen Änderungen in der Windows Registry, so dass die Dienste beim Booten nicht gestartet werden.

Die Funktionalität des Packetfilters für eingehenden Verkehr ist also für die meisten Anwender nutzlos, weil es bessere und einfachere Möglichkeiten gibt. Was die Kontrolle des ausgehenden Datenverkehrs betrifft, haben wir gezeigt, dass keine Personal Firewall ihr Versprechen halten kann.

Wenn ein Programm versucht, Daten ins Internet zu senden, kontrolliert der Applikationsfilter, ob es das darf. Wurde das noch nicht bestimmt, wird üblicherweise der Benutzer gefragt. Das Windows Nachrichtensystem erlaubt es aber jedem Programm, beliebe Benutzeraktionen zu simulieren. Der Autoclicker nützt das aus, in dem er im Hintergrund wartet, bis das Fenster der Personal Firewall auf geht um dann schnell die nötigen "Sicherheitseinstellungen" vorzunehmen und auf OK zu "klicken". Effektiv bedeutet das, dass so bald der Benutzer gefragt wird, jedes beliebige Programm ins Internet verbinden darf. Es bedeutet auch, dass eine Personal Firewall effektiv nicht vorhanden ist, so bald sie der Benutzer ohne Passwort konfigurieren darf,

Doch es kommt noch schlimmer. Es war uns mit allen Personal Firewalls möglich, mit Hilfe der wwwsh einen Rechner remote zu kontrollieren. Die wwwsh ist ein trojanisches Pferd, das mit Hilfe von Fensternachrichten einen Browser fern steuert und somit Daten an der Personal Firewall vorbei in und aus dem System schleusen kann. Die Proof­of-Concept Implementierung verwendet ein sichtbares Browserfenster, damit man sehen kann, was passiert. Es ist aber mit Hilfe von MessageHooks möglich zu verhindern, dass das Browserfenster die Nachricht zum sich Zeichnen erhält und somit unsichtbar bleibt. Mehr dazu steht im Artikel "Windows Nachrichtensystem" in dieser Datenschleuder.

Wie oben bereits erwähnt, verhindern manche Personal Firewalls das Starten anderer Applikationen durch die Filterung von Bibliotheksaufrufen. Das tun sie, weil schon mehrere Methoden bekannt wurden, wie man sie mit Hilfe von Wirtsprogrammen umgehen kann. Die Filterung der Bibliotheksaufrufe bietet aber keinen Schutz. So verwendet die wwwsh den "Start->Ausführen" Dialog um dort "iexplore.exe" einzutragen und auf OK zu "klicken".

Die Informationen gehen base64 kodiert als Teil von URL's aus dem Zielsystem raus. Die Antwort kommt als HTML Dokument mit einem Meta-Refresh auf eine neue URL, die wiederum base64 kodierte Informationen enthält. Der Browser surft die neue Seite an und zeigt die URL in der GUI, so dass die wwwsh sie auslesen kann und somit an die Informationen kommt. Das Funktionsprinzip der wwwsh ist es, regelmäßig eine URL zu pollen, bis im Antwortteil ein Befehl mit kommt. Dieser Befehl wird lokal ausgeführt und dessen Standardausgabe in die URL kodiert und zurück gesendet. Damit umgeht man sämtliche Firewalls, weil eigentlich alle http auf Port 80 zu lassen.

Jeder Windows Rechner, auf dem der lokale Benutzer mit einem Browser surfen darf, kann remote kontrolliert werden. Egal, ob eine Personal Firewall läuft, oder nicht. Alle Versprechen von Herstellern von Sicherheitssoftware sind falsch. Es bleibt dem Benutzer nichts anderes übrig, als aufzupassen, welche Software er lokal ausführt. Wie er das am besten macht, war Thema des letzten ChaosSeminars in Ulm.

Zu guter letzt bleiben noch so Kleinigkeiten wie das Verstecken des Rechners durch ICMP Blocking. Jeder, sich mit TCP/IP auskennt weiß, dass es technisch nicht möglich ist, einen Teilnehmer in einem IP Netzwerk zu verstecken. Falls der Teilnehmer nicht existieren würde, müsste bei einem "ICMP Ping" der Router davor ein "ICMP Host unreachable" schicken. Wenn keine Antwort kommt dann deutet das auf eine Firewall hin, die filtert. Damit weiß man auch, dass das Ziel existiert.

Keine der versprochenen Features von Personal Firewalls haben also einen Nutzen für den normalen Benutzer der Zielgruppe. Doch es kommt noch schlimmer. Manche Features bietet zusätzliche Angriffsvektoren. Es gibt also Angriffe, die sind nicht möglich, obwohl eine Personal Firewall installiert ist, sondern weil ein Personal Firewall installiert ist.

Zusätzliche Angriffsvektoren

Viele Personal Firewalls bieten sog. Intrusion Detection Systeme (IDS) an. Dabei handelt es sich um eine Heuristik, die versucht, Angriffe zu erkennen. Von unseren Testkandidaten boten Outpost, Sygate, ZoneAlarm und Norton dieses Feature. Die Art der Heuristik schwankt sehr von Hersteller zu Hersteller. Bei der Norton Personal Firewall beispielsweise zählt bereits ein IP-Paket, das auf einem bekanntermaßen von trojanischen Pferden verwendeten Ports ankommt, als "Hacker Angriff". Derartige "Angriffe" führen im Normalfall dazu, dass der gesamte ein- und ausgehende Datenverkehr zur Source-IP dieses Pakets temporär gesperrt wird. Die Sperrdauer ist bei allen oben genannten Programmen konfigurierbar, wobei der Defaultwert bis zu 30 Minuten (bei Norton) beträgt. Da die Source-Address trivial zu spoofen ist und längst nicht jeder Router Pakete mit gespoofter Source-Address verwirft, bieten sich hier interessante Möglichkeiten zum Ärgern von Personal Firewall-Anwendern. Beispielsweise könnte man die IP-Adressen der Nameserver eines Netblock-Owners verwenden, um so einem User gezielt die Nameserver "weg zuschießen". So haben sie für eine gewisse Zeit nur noch per IP-Adresse Internet was effektiv einem Denial Of Service für die meisten Benutzer gleich kommt.

Ein weiteres Feature, das manche Personal Firewalls bieten, ist die Überprüfung des Datenverkehrs auf persönliche Daten wie beispielsweise PINs, Passwörter oder Telefonnummern. Dazu hinterlegt man diese Daten in einem zentralen Formular der Personal Firewall, die daraufhin ausgehenden Datenverkehr auf diese Muster prüft und ggf. sperrt. Kerio, ZoneAlarm und Norton implementieren dieses Feature. Im Allgemeinen ist dieses Feature äußerst fragwürdig, denn z.B. bei https Verbindungen kann die Personal Firewall den Verkehr gar nicht scannen. Es genügen aber auch einfache Kodierungen wie rot13 oder base64, um die Personal Firewall zu umgehen. Ein Angreifer wird also immer einen Weg finden, die persönlichen Daten rauszuschleußen. Doch leider ist das Feature nicht nur nutzlos, sondern bringt eine zusätzliche Gefahr: ein Angreifer hat eine Zentrale Anlaufstelle um Kreditkartennummer und Passwörter abzugreifen. Mit Hilfe von Fensternachrichten kann das Programm des Angreifers sich einfach zum Eingabeformular der Personal Firewall "durchklicken" und dort die Angaben auslesen. Das geht nur bei ZoneAlarm nicht, da dort die Daten nur als Sternchen erscheinen. Doch auch hier kann ein Angreifer z.B. die PIN herausfinden. Er lockt das Opfer auf eine Webseite, wo automatisiert URLs geladen werden, die alle vierstelligen Zahlen enthalten. Diejenige URL, die nicht angesurft wird, ist die mit der PIN des Benutzers.

Da alle Personal Firewalls Dienste installieren, die mit SYSTEM-Rechten laufen, bieten sie potenziell Angriffspunkte für Privilege Elevation Attacks. Dienste sollen gemäß den Vorgaben von Microsoft keine Fenster öffnen, aber manche Personal Firewall (Outpost, Sygate, Tiny) ignoriert diese Vorgabe. Welches Programm privilegierte Prozesse mit Fenstern startet, lässt sich z.B. mit dem Visual Studio-Tool Spy++ herausfinden, mit dem man sich die Eigenschaften von Prozessen und Fenstern anzeigen lassen kann. Fenster ermöglichen unter Umständen sog. Shatter Attacks, bei denen man Code in das Fenster schreibt und diesen anschließend über eine Fensternachricht mit geeigneter Callback-Funktion zur Ausführung bringt. Die ursprüngliche, von Foon beschriebene Shatter Attack hat dazu per WMPASTE den Shellcode in ein Edit Control geschrieben und diesen Code dann über eine WMTIMER zur Ausführung gebracht. Zwischenzeitlich wurden noch weitere Methoden beschrieben, um auf diesem Weg Code zur Ausführung zu bringen. Aus Zeitgründen konnten wir allerdings noch nicht weiter untersuchen, welche Personal Firewall tatsächlich für Shatter Attacks anfällig ist. Aber auch ohne Shatter Attacks lassen sich manche Personal Firewalls erfolgreich exploiten. Beispielsweise wurde im Dezember 2004 ein Sicherheitsproblem mit der LiveUpdate-Funktion von Symantec-Produkten gemeldet. Über den Benachrichtigungs-Dialog, der im Fall neuer Updates angezeigt wird, konnte ein lokaler Nutzer sich erhöhte Rechte verschaffen. Aber auch andere Personal Firewalls haben mit der Rechtetrennung so ihre Probleme. Outpost hat ein modulares Filterkonzept. Über einen Dialog kann man Module hinzufügen, die dann zusätzliche Filterfunktionen ausüben können. Anfang 2004 wurde entdeckt, dass dieser Dialog mit SYSTEM-Rechten läuft, so dass man über diesen Dialog eine cmd.exe mit SYSTEM-Rechten starten konnte. Interessant auch die (nicht verifizierte) Stellungnahme von Agnitum zum Problem.

Dadurch, dass Personal Firewalls jedes eingehende Paket entgegennehmen und anschauen müssen, entstehen weitere potenzielle Sicherheitslücken, denn der Code, der die Pakete untersucht, kann natürlich Fehler enthalten. Dass dieses Bedrohungsszenario sehr real ist, zeigte sich im März 2004, als der Wurm W32/Witty.worm Systeme angriff, die durch Produkte des Herstellers Internet Security Systems (ISS) "geschützt" waren. Der Wurm nutzte einen Buffer Overflow in einem Analyse-Modul für das ICQ-Protokoll aus. Da dieser Wurm ausschließlich Systeme befiel, die durch eine Personal Firewall "geschützt" waren, kann er als Proof-of-Concept für die Erhöhung der Angriffsfläche durch Personal Firewalls betrachtet werden.

Ärger mit Personal Firewalls

Dadurch, dass eine Personal Firewall ein- und ausgehenden Datenverkehr untersuchen muss, belastet sie natürlich auch noch die Ressourcen des Rechners. Downloadzeiten werden verlängert, die Auslastung des Systems steigt. Das führt so weit, dass beim Betrieb von ZoneAlarm in der Einstellung "unsicheres Netzwerk" ein 400 MHz Pentium II vollständig unbenutzbar wurde. Selbst auf einem 2,3 GHz Athlon kam es zu sekundenlangen Aussetzern, während derer keine Interaktion mit Anwendungen möglich war.

Außerdem nerven Personal Firewalls mit erfolgreichen Abwehrmaßnahmen, denen gar kein Angriff vorausging. Wenn man z.B. von seinem ISP bei der Einwahl eine dynamische Adresse bekommt und diese zuvor einem gehört hat, der einen eDonkey laufen hatte, so bekommt man fälschlicherweise Benachrichtigungen über zur Verfügung stehende Shares. Die Personal Firewall wertet diesen Verbindungsaufbau als versuchten Angriff und meldet das dem Benutzer. Es gibt noch weitere Fälle, in denen Personal Firewalls fälschlicherweise Alarm schlagen. Ein Auflistung gibt es z.B. hier.

Im Allgemeinen machen Personal Firewalls Probleme, weil sie am Windows rumpatchen und somit sein Verhalten verändern. Da man unter Windows üblicherweise Nachrichten wie Ereignisse behandelt, haben es viele Programme mit einem Haufen Race Conditions zu tun. Man hofft einfach, dass die Nachrichten in der üblichen Reihenfolge und innerhalb der üblichen Zeitfenster ankommen. Das ist aber nicht garantiert. Veränderungen am System durch die Personal Firewall können deshalb dazu führen, dass manche Programme nicht mehr funktionieren. Und je mehr die Hersteller von Personal Firewalls versuchen, Windows mit Flicken dicht zu bekommen, desto mehr Programme steigen aus.

Zum Abschluss noch ein besonderer Leckerbissen: Norman. Dieses Stück Bitschrott ist derart br0ken, dass man es nur dann konfigurierbar installieren kann, wenn Windows auf einer einzigen Partition installiert ist. Hat man irgendetwas daran geändert (z.B. %ProgramFiles% auf eine andere Partition gelegt), so werden Änderungen der Konfiguration mit einer Fehlermeldung quittiert. Bei einem Portscan öffnet sich bei Norman ein Dialog, den man mit vier Mausklicks bestätigen muss. Für jeden Port. Aber auch andere Personal Firewalls haben nette Eigenheiten. Verbietet man in Tiny beispielsweise dem Programm mozilla.exe die Kommunikation mit dem Internet, so braucht man es nur in ein anderes Verzeichnis zu kopieren, und schon funktioniert die Kommunikation wieder. Darüber hinaus implementiert Tiny ein eigenes Rechtesystem für Zugriffe auf Dateien und Registry-Einträge, das komplett am regulären Rechtesystem vorbei funktioniert und ist die einzige Personal Firewall im Test bei der in der Default-Einstellung Ports von außen erreichbar waren (u.a. 135/tcp und 445/tcp). Sehr nett ist auch ZoneAlarm, das seine Konfiguration in world-writable Dateien speichert, die es dadurch schützt, dass der Dienst diese Dateien beim Start öffnet und lockt.