Diese Woche im Standpunkt Sicherheit: Die Suche nach Büchern und Bibliotheken, auf dem Server Code ausführendes Cross-Site-Scripting und ein Router manipulierender Trojaner.

Buch gesucht...

Aus gegebenen Anlass habe ich mir Gedanken darüber gemacht, wie/wo ich denn im Allgemeinen überall nach einem Buch suchen würde. Die Antwort darauf ist eigentlich ganz einfach: IT-Bücher stehen im Bücherregal im Büro, alle anderen im Bücherschrank im Wohnzimmer. An anderer Stelle liegen Bücher nur ausnahmsweise: Alle, die ich für ein aktuelles Projekt bereits gebraucht habe und noch einmal brauchen werde, liegen nach Projekten sortiert auf Stapeln auf einem fahrbaren Tisch neben meinem Schreibtisch. Und das aktuell privat gelesene Buch liegt auf einem Tisch im Wohnzimmer. An anderer Stelle brauche ich nach Büchern nicht zu suchen. Und sollte ich wo anders eines finden, würde ich mich doch ziemlich wundern.

... Schadsoftware gefunden

Überträgt man das Ganze auf die IT, wird aus dem einzelnen Buch eine Bibliothek, z.B. eine der Libraries eines Linux-Systems oder der DLLs von Windows. Die werden von den Programmen auch an bestimmten Orten gesucht: Den verschiedenen Bücherregalen entsprechen die Verzeichnisse für die Libraries des Systems und ggf. das Installationsverzeichnis des jeweiligen Programms. Die Verzeichnisse, in denen gesucht wird, werden zu einem Suchpfad, englisch 'search path', zusammengefasst. Enthält der ein vom Benutzer beschreibbares Verzeichnis, kann das unter Umständen eine Schwachstelle sein, die so genannte "untrusted search path vulnerability". Enthält z.B. unter Linux ein mit root-Rechten ausgeführtes Programm einen solchen unsicheren Suchpfad, kann ein Benutzer in ein für ihn beschreibbares Verzeichnis im Suchpfad eine präparierte Bibliothek speichern, über die er dann seinen eigenen Code mit root-Rechten ausführen lassen kann.

Internet Explorer, mal wieder...

Kommen wir nun zum oben erwähnten "gegebenen Anlass": Microsofts Warnung vor Apples Webbrowser Safari. Seit meinem News-Artikel vom 3. Juni wurden dazu weitere Details veröffentlicht. Laut Liu Die Yu ist die Ursache der Schwachstelle die Art, in der der Internet Explorer DLL-Dateien nachlädt: Beim Starten über die Desktop-Verknüpfung werden DLL-Dateien zuerst auf dem Desktop gesucht, bevor das entsprechende Systemverzeichnis durchsucht wird. Mit anderen Worten: Liegt auf dem Desktop eine DLL-Datei mit einem Namen, nach dem der Internet Explorer beim Starten sucht, wird diese Bibliothek geladen und der enthaltene Code ausgeführt. Egal, wieso die Datei da liegt und woher sie überhaupt kommt. Liu Die Yu hat eine Demo-Seite erstellt, die beim Besuch die Bibliothek schannel.dll auf den Desktop speichert. Eigentlich enthält diese Bibliothek den Code für die Nutzung von SSL/TLS. Die Version, die Liu Die Yu über die Demo-Seite einschleust, öffnet stattdessen Notepad.

... oder immer noch?

Diese Schwachstelle ist - mit Verlaub gesagt - eiskalter Kaffee. Nichts gegen Eiskaffee, aber das hier ist wirklich nur kalt gewordener Kaffee. Und zwar von 2006. Damals hat Aviv Raff diese Schwachstelle entdeckt und veröffentlicht: "Internet Explorer 7 - Still Spyware Writers Heaven" vom 1. November 2006 und "IE7 DLL-load hijacking Code Execution Exploit PoC" vom 14. Dezember 2006. Das Ganze ist also eindeutig keine Schwachstelle in Apples Safari, wie es Microsofts Advisory nahe legt. Auch Firefox speichert Dateien per Default auf dem Desktop, fragt den Benutzer aber vorher. Genauso wird es sicher noch mehr Programme geben, die Dateien auf den Schreibtisch speichern. Warum auch nicht? Eigentlich ist ja nichts dabei... solange man danach nicht den Internet Explorer startet und die Datei den Namen einer Bibliothek hat, die der laden möchte. Und das muss ganz eindeutig im Internet Explorer korrigiert werden.

XSS erlaubt Code-Ausführung auf dem Server

Wer jetzt denkt, mit der Überschrift stimmt was nicht, hat leider Unrecht. Normalerweise wird über Cross-Site-Scripting JavaScript-Code auf einem Client eingeschleust. Im Fall einer XSS-Schwachstelle in vBulletin ist das anders. Eigentlich handelt es sich dabei um eine ganz normale Schwachstelle, betroffen ist der Parameter 'redirect' im Skript admincp/index.php. Jessica Hope hat in einem Advisory beschrieben, wie darüber PHP-Code auf dem Server ausgeführt werden kann. Dabei wird ausgenutzt, das vBulletin eval()-Aufrufe verwendet, in die ein Administrator Code einfügen kann. Das Einzige, was für einen erfolgreichen Angriff notwendig ist: Ein Administrator muss einen präparierten Link anklicken. Mit etwas Social Engineering sollte es nicht weiter schwierig sein, das zu erreichen. Was einmal mehr beweist, dass man XSS nicht unterschätzen darf - in Zeiten von Web 2.0 mit seinen Ajax-fähigen Browsern ist da einiges möglich, was man früher für rein theoretische Überlegungen oder überschäumende Phantasie gehalten hätte.

Trojaner konfiguriert Router

Schadsoftware, die Routereinstellungen ändert, ist auch nicht mehr das, was sie vor kurzem noch war: Eine mehr oder weniger theoretische Bedrohung. Oder mit anderen Worten: Was letztes Jahr noch ein Proof-of-Concept war, ist heute schon Wirklichkeit. Brian Krebs von der Washington Post hat berichtet, dass eine neue Version des Trojaners Zlob von einem befallenen Windows-Rechner aus die DNS-Einstellungen gängiger Router ändert. Bisher war dieser Trojaner nur dafür bekannt, die DNS-Einstellungen auf Windows- und OS X-Rechnern zu manipulieren. Die neue Version versucht, über eine integrierte Liste mit Default-Zugangsdaten Zugang zum Router zu erlangen und dann die DNS-Einstellungen zu ändern. Aktuell wird der Trojaner als angeblicher Video-Codec verteilt, andere Verbreitungswege dürften nicht lange auf sich warten lassen. Denn für die Angreifer hat diese Vorgehensweise einen großen Vorteil: Ein einziger befallener Rechner führt im Erfolgsfall dazu, dass alle Rechner aus dem betroffenen lokalen Netz die verfälschten DNS-Einträge nutzen, unabhängig davon, ob sie jemals vom Trojaner befallen wurden oder welches Betriebssystem darauf läuft. Den besten Schutz vor derartigen Angriffen bietet ein gut gewähltes Passwort für den Router. Falls Sie es noch nicht getan haben, ändern Sie das Default-Passwort möglichst bald. Und wählen Sie ein neues Passwort, das nicht über einen Wörterbuchangriff gefunden werden kann. Denn der Schritt von der jetzt verwendeten Liste mit Default-Zugangsdaten zu einem Wörterbuchangriff dürfte bald folgen.

Carsten Eilers