Einleitung

„Hier sitz ich nun, ich armer Tor, und bin so schlau als wie zuvor!“ Zumindest fühle ich mich so. Es ist anscheinend doch nicht einfach, all die Dinge, die man im Laufe der Zeit gelernt hat, sinnvoll auf Papier zu bringen, so dass andere Leute sie verstehen und anwenden können. Aller Anfang ist schwer.

In diesem Text – meinem ersten Text über einen Bereich der IT-Security – möchte ich auf die grundlegenden Aspekte der Sicherheit von Windows NT eingehen, aber auch kurz die Möglichkeiten der NetBIOS-Penetration beschreiben. Ursprünglich sollte dieser Text gemäß dem Titel „Mit dem Browser in den Server“ lediglich darauf abzielen, einige der schweren Bugs des Internet Information Server (IIS) von Microsoft erläutern, welche mit einem üblichen Browser wie Internet Explorer oder Netscape Communicator und daher plattform-unabhängig ausgenutzt werden können.

Auch andere Fakten wie Buffer Overflows im IIS sollen in diesem Text kurz genannt sein, der Focus bleibt aber auf den Browser-Bugs.
Ich finde sie nämlich viel eleganter :-)

Fangen wir also ganz von vorne an...

1. IIS finden

Das „Super-Buch: Windows NT 4“ beschreibt den IIS als einen „einfach zu verwaltenden, aber auch nicht besonders leistungsfähigen WWW-Server“. Das mag im Vergleich zu anderen Webservern wie etwa Apache durchaus richtig sein. Dennoch hat Microsoft in den neueren Versionen (4.0 und 5.0) schon einige Verbesserungen eingebaut, wie z.B. die Darstellung dynamischer Webseiten durch Active Server Pages (.asp).

Einen IIS kann man auf mehrere Arten erkennen. Am einfachsten ist es wohl, wenn die Default-Webseiten der Installation noch vorhanden sind und der Standardgruß wie „Willkommen zu IIS 4.0!“ auf dem Bildschirm flackert. Übrigens lohnt sich eine Suche nach dieser Phrase in den gängigen Suchmaschinen, wenn man einen möglichst frisch installierten und deswegen eventuell ungepatchten IIS finden will.

Eine andere Möglichkeit, um den Webserver eines Rechners zu bestimmen, bietet das ProgrammXenu. Die Hauptfunktion von Xenu ist allerdings die Anzeige aller durch HTML-Seiten gelinkten Dateien auf dem Server, was die Suche nach Schwachstellen ungemein erleichtern kann.
 

2. Bugs

Das große Problem von IIS und Microsoft im Allgemeinen wohl auch sind die zahlreichen Bugs. Hat man den „Microsoft Security Bulletin“-Newsletter abonniert, erhält man im Schnitt alle drei Tage einen Hinweis, sich doch bitte einen neuen Patch herunterzuladen. Außerdem sollen sogenannte Service Packs dafür sorgen, dass IIS sicher bleibt. Die auftretenden Bugs können in mehrere Arten unterteilt werden:

a) „Mit dem Browser in den Server“

+.htr-Bug

Ein Angreifer kann den Quellcode von .asp, .asa, .ini und üblichen Skriptdateien erfahren, wenn er an die Adresse der entsprechenden Datei die Endung „+.htr“ anhängt. Hierdurch wird IIS vorgetäuscht, dass es sich bei der Datei um eine wirkliche .htr handelt. Die Anfrage wird somit an ism.dll weitergegeben, welche die Datei natürlich nicht ausführen kann und stattdessen den Quellcode ausgibt.

Beispiel: www.server.de/test.asa+.htr
Betroffen sind IIS 4.0 und 5.0.
 

::$DATA-Bug

Ein Angreifer kann den Quellcode von .asp und einigen anderen Dateien erfahren, wenn er an die Adresse der entsprechenden Datei die Endung „::$DATA“.

Beispiel: www.server.de/test.asp::$DATA
Betroffen sind IIS 1.0 bis 4.0
 

Perl-Bug
Ein Angreifer kann den Pfad des Verzeichnisses erfahren, in welchem sich die Webseiten des Servers befinden, wenn er im Verzeichnis /scripts nach einem nicht-existenten Perl-Skript fragt. Wenn der Server darauf eingestellt ist, Perl-Scripts auszuführen, produziert Perl eine Fehlermeldung, da es die Datei ja nicht findet. In der Meldung findet man auch den Pfad des Webverzeichnisses.

Beispiel: www.server.de/scripts/no-such-file.pl
(Can't open perl script "C:\InetPub\scripts\no-such-file.pl": No such file or directory)

Betroffen sind anscheinend alle Versionen bis auf IIS 5.0
 

%20.pl-Bug
Ein Angreifer kann Inhalte etwaiger Passwortdateien von CGI-Skripts, die im einfachen Textformat gespeichert werden, herausfinden, wenn er an die Adresse der entsprechenden Datei die Endung „%20.pl“ anhängt. Auch hier liegt der Fehler wieder bei Perl, da es die Datei nicht verarbeiten kann.

Beispiel: www.server.de/scripts/passwd.txt%20.pl

Betroffen sind anscheinend ebenfalls alle Versionen bis auf IIS 5.0
 

UNICODE-Bug
Dieser Bug hat in der letzten Zeit für viel Aufregung im Hause Microsoft gesorgt. Er ermöglicht das Navigieren in sämtlichen Ordnern des Servers sowie das Ausführen von Programmen im Rahmen des Benutzers IUSR_machinename, falls ein ausführbares Verzeichnis (/scripts, /msadc, etc.) vorhanden ist.
Das Navigieren mittels der Zeichenkette ../ wird bei diesem Bug ausgenutzt, nachdem die Slashes mithilfe von UNICODE-Zeichen dargestellt werden.
Besonders nützlich erweist sich hier der NT-Kommandointerpreter cmd.exe, dem ein Angreifer über die URL Befehle erteilen kann.

Beispiele:
www.server.de/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir
www.server.de/scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir

Beide URLs liefern die Inhalte des Webordners. Einen Blick in andere Ordner wie /winnt kann man mit folgender URL werfen:
http://www.server.de/scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir+..\..\winnt\

Betroffen sind IIS 4.0 und 5.0
 

b) Buffer Overflows

In Sachen Buffer Overflows hat sich vor allem das Team von eEye eine goldene Nase verdient. Ihre Exploits ermöglichen einem Angreifer z.B. den Transfer von Programmen von seinem eigenen Server auf den Zielrechner.

Betroffen sind IIS 4.0 mit den Service Packs 3 bis 5 bei iishack bzw. IIS 4.0 mit Service Pack 6 bei iishack1.5.

Wie oben schon erwähnt, möchte ich diese Möglichkeiten eines Angriffs nicht genauer erläutern. Hierüber sind schon genug Texte verfasst worden bzw. sind die Seiten von eEye mehr als ausführlich.

c) NetBIOS-Penetration

NetBIOS (Network Basic Input Output System) ist ein recht altes Protokoll, welches schon die Kommunikation zwischen MS-DOS-Rechnern unterstützte. Es benutzt die Ports 137 bis 139 und besteht aus weniger als 20 Befehlen, die für den Datenaustausch sorgen. NetBEUI (NetBIOS Extended User Interface) heißt sein „Nachfolger“, dieser ist mit NetBIOS aber nahezu identisch, nachdem er auf dieselben Befehle zurückgreift.
Wenn das nb-Protokoll auf einem Rechner aktiviert ist, so kann man mithilfe des DOS-Befehls nbtstat –A [IP] herausfinden, ob Ordner oder Drucker auf dem Rechner freigegeben sind. nbtstat gibt einen Table aus, auf dem der Name des Rechners (vgl. IUSR_machinename !) und eingeloggte Benutzer aufgeführt werden:

       NetBIOS Remote Machine Name Table

   Name               Type         Status
---------------------------------------------
A-5            <00>  UNIQUE      Registered
BUSTER         <00>  GROUP       Registered
A-5            <03>  UNIQUE      Registered
A-5            <20>  UNIQUE      Registered
BUSTER         <1E>  GROUP       Registered

MAC Address = 44-45-53-54-00-00

Auf freigegebene Daten kann man zugreifen, wenn in dieser Tabelle der Wert <20> auftaucht. Ein Angreifer würde nun versuchen, diese Share entweder mit den net-Befehlen oder ganz einfach mit dem Befehl \\IP im bekannten Feld „Ausführen“ an seinen Rechner zu binden.

Eine Möglichkeit, ein Netzwerk auf nb-Schwachstellen zu untersuchen, bietet das Programm nbtscan von Alla Bezroutchko. Es ist aber leider genauso schnell wie ungenau, übersieht es doch oft einige Rechner mit Freigaben.

Freigaben werden oft durch Passwörter geschützt. Bei Windows 9x / ME-Rechnern kann ein Angreifer diese Hürde jedoch schnell überwinden, da nb nach der Eingabe des Share-Passworts nur dessen erstes Byte auf Richtigkeit überprüft und man diesen Bug mit einem modifizierten Samba-Clienten, der eben nur das erste Byte des Passworts sendet, ausnutzen kann. Der Quellcode zur Modifikation ist hier zu finden.
 

3. Schlusswort

In der Hoffnung, ein paar interessante Dinge gesagt und ein paar lernwilligen Leuten geholfen zu haben, sitze ich hier erkältet vor meinem Computer und kann es kaum erwarten, endlich den letzten Punkt unter diesen Text zu setzen.
Bevor ich das tue, möchte ich aber noch die Leute grüßen, die mit mir in den Weiten des Internet stets neue Grenzen überschreiten :-)
Besonders erwähnt seien AzZ, bl&ckboxx, [ Convex ], fiction, Mr. Hudes, Lightning, Mescalin und tuvok.

Nicht nur in Hinsicht auf diesen Text, sondern in jeder Situation haben mir meine Freundin Anne, AzZ und tuvok geholfen. Danke hierfür. Ihr seid spitze!

Wenn jemand Fragen oder Anmerkungen zu diesem Text hat, kann er mir gerne mailen oder im Forum 15941 | Hacking vorbeischauen.

Bis dahin,

...try the error...
…  [ Coneo ]  ...