Mittwoch, 6. Oktober 2010


Topthema

Donnerstag, 28. Februar 2008 | Topthema

About Security #145: Schwachstellensuche: Daten auswerten

(Link zum Artikel: http://www.entwickler.de/php/kolumnen/041676)

In About Security #144 wurde beschrieben, wie der Aufbau der auf Schwachstellen zu untersuchenden Webanwendung ermittelt werden kann. In dieser Folge geht es um die Auswertung der dabei gesammelten Daten.

Schritt 1b: Analyse der Webseiten

N E U ! Security aktuell
T�glich aktuelle Security-Infos!

Zuerst werden die gesammelten Seiten eine nach der anderen analysiert. Dazu wird der Code jeder Seite betrachtet und nach n�tzlichen Informationen in Kommentaren gesucht. Das k�nnen z.B. auskommentierte Codeteile in der Programmiersprache der Webanwendung sein, die durch einen falsch gesetzten Tag oder HTML-Kommentar in die ausgegebene Seite gelangt sind. Solche Codefragmente k�nnen Aufschluss �ber den inneren Aufbau der Webanwendung geben oder sogar Informationen �ber die Konfiguration wie Namen von Servern, SQL-Tabellen usw. enthalten. Die HTML-Dateien k�nnen sowohl manuell als auch mit einem Tool wie z.B. grep mithilfe von regul�ren Ausdr�cken durchsucht werden.

Interessant sind besonders folgende Punkte:

  • HTML-Kommentare (<!-- .. -->) enthalten meist nur Hinweise auf Bereiche der Seite, k�nnen aber manchmal auch interessantere Informationen enthalten.
  • Programm-Kommentare (z.B. //, /* .. */, <!--- .. ---> (Coldfusion, leicht mit HTML-Kommentaren zu verwechseln) ) d�rften normalerweise nicht in der ausgegebenen HTML-Seite erscheinen. Tun sie es doch, sind die Chancen gro�, dass sie n�tzliche Informationen enthalten.
  • Versteckte Eingabefelder (<input type='..' hidden>) k�nnen z.B. Tokens zum Schutz vor CSRF-Angriffen oder andere brauchbare Informationen enthalten.
  • SQL-Queries (SELECT .. FROM .., UPDATE .. SET .., INSERT INTO .., DELETE FROM ..) k�nnen au�er in Fehlermeldungen nur durch einen Programmier- oder Konfigurationsfehler in die ausgegebene Seite gelangen. Sie liefern unter Umst�nden Informationen �ber die Datenbankstruktur und den Aufbau der verwendeten Queries.
  • IP-Adressen interner Server
  • Web- oder E-Mail-Adressen, z.B. der Entwickler, die Informationen �ber beteiligte Unternehmen liefern. Vielleicht basiert die Webanwendung ja auf einem bekannten Programm und wurde nur optisch angepasst?
Schritt 1c: Analyse der �bergebenen Parameter

Als N�chstes werden die �bergebenen Parameter untersucht. Was passiert bei falschen Eingaben? Die zur�ckgegebenen Fehlermeldungen, egal ob vom Webserver oder der Webanwendung, k�nnen n�tzliche Informationen liefern. Z.B. kann in einer Fehlermeldung des SQL-Servers die fehlgeschlagene Anweisung samt Server- und Tabellennamen enthalten sein. Auch immer wieder gern gesehen sind unterschiedliche Fehlermeldungen bei einem fehlgeschlagenen Login-Versuch: Liefert die Anwendung unterschiedliche Fehlermeldungen f�r einen falschen Benutzernamen und ein falsches Passwort, kann der Angreifer g�ltige Benutzernamen ermitteln. Gibt es dann auch keinen Schutz gegen Brute-Force-Angriffe, kann das b�se enden. Daher sollten solche Fehlermeldungen neutral formuliert werden, z.B. "Benutzername und Passwort passen nicht zueinander" oder "Benutzername und/oder Passwort sind falsch".

About Security: Die komplette Serie

Entsprechendes gilt f�r alle Fehlermeldungen: Auf produktiv eingesetzten Systemen sollten die nur mitteilen, dass ein Fehler aufgetreten ist. Details sind f�r den Benutzer uninteressant, aber f�r den Angreifer Gold wert. Ebenso sollten auf produktiv eingesetzten Systemen besser keine Kommentare in den ausgegebenen HTML-Seiten enthalten sein. Ein normaler Benutzer sieht sie sowieso nicht, daf�r liefern sie Angreifern unter Umst�nden n�tzliche Informationen. Alternativ k�nnte man nur die Kommentare mit m�glicherweise f�r einen Angreifer n�tzlichen Informationen l�schen. Das bedeutet aber nur unn�tigen Aufwand. Einfacher ist es, alle Kommentare zu l�schen.

Das klingt zwar nach "Security by Obscurity", hat damit aber nur teilweise zu tun. Die Sicherheit h�ngt nicht vom Verbergen der Informationen ab. Die Webanwendung darf keine Schwachstellen enthalten � unabh�ngig davon, ob der Angreifer nun mehr oder weniger Informationen besitzt. Aber man muss es einem Angreifer ja nicht unn�tig leicht machen.

Schritt 2: Weitere Informationen sammeln

Nachdem die offensichtlichen Informationen gesammelt wurden, kann man anfangen, die nicht offensichtlichen zu suchen. Dazu wird im Wesentlichen nach nicht verlinkten Seiten gesucht. Wenn z.B. ein Verzeichnis die verlinkten Dateien gesch�ftsbericht04.pdf, gesch�ftsbericht05.pdf und gesch�ftsbericht06.pdf enth�lt, ist ja vielleicht auch der noch nicht ver�ffentlichte aktuelle als gesch�ftsbericht07.pdf vorhanden.

Die in Schritt 1a aufgebaute Sitemap kann dabei helfen, Muster in den Dateinamen und interessante Verzeichnisse zu finden. Dabei h�ngen die m�gliche Ergebnisse sehr von der untersuchten Anwendung ab. So werden z.B. in einem Buchkatalog, in dem jedes verf�gbare Buch auf einer eigenen Seite beschrieben wird, auf diesen Seiten keine f�r den Angreifer verwertbaren Informationen zu finden sein. Ganz anders sieht es hingegen bei einem Benutzerverzeichnis aus, bei dem die Benutzer nur die vollst�ndigen Profile bestimmter anderer Benutzer sehen d�rfen. Kann dann �ber z.B. benutzer-[lfd.Nr.].html oder benutzer.php?id=[lfd.Nr.] auf beliebige Profile zugegriffen werden, k�nnte der Angreifer dadurch nicht f�r ihn bestimmte Informationen erlangen.

In der n�chsten Folge geht es um das Sammeln von Informationen im Client.

Wenn Sie Fragen oder Themenvorschl�ge haben, k�nnen Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security � �bersicht zum aktuellen Thema "Schwachstellensuche � I. Informationen sammeln"

Kommentare

Folgende Links könnten Sie auch interessieren