Donnerstag, 7. Juni 2012


Topthema

Donnerstag, 21. Februar 2008 | Topthema

About Security #144: Schwachstellensuche: Allgemeine Infos sammeln

(Link zum Artikel: http://www.entwickler.de/php/kolumnen/041569)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

Webanwendungen enthalten, wie alle anderen Programme auch, mehr oder weniger viele Schwachstellen, von denen viele schon in vorherigen Folgen von About Security vorgestellt wurden, z.B. XSS, CSRF, SQL-Injection, ... . Die entscheidenden Fragen sind: Welche Schwachstellen gibt es und wo befinden sie sich? Ab dieser Folge geht es um die Suche nach Schwachstellen in Webanwendungen, sowohl manuell als auch durch Schwachstellen-Scanner.

Manuelle oder automatische Suche?

Die einzigen wesentlichen Unterschiede zwischen einer manuellen Suche und der Arbeitsweise eines Schwachstellen-Scanners sind die menschliche Intuition und die Unerm�dlichkeit des Rechners: Ein Schwachstellen-Scanner nutzt mehr oder weniger dieselben Arbeitsweisen wie ein Mensch, kann aber Schwachstellen nur aufgrund vorgegebener Regeln erkennen, w�hrend ein Mensch auch vollkommen neue Schwachstellen finden kann. Daf�r erm�det der Rechner nicht so schnell wie ein Mensch. Im Folgenden wird die manuelle Suche nach Schwachstellen beschrieben und mit der typischen Arbeitsweise eines Schwachstellen-Scanners verglichen. Bei sich bietender Gelegenheit wird auch auf m�gliche maschinelle Unterst�tzung bei der manuellen Suche hingewiesen.

Wie findet man Schwachstellen prinzipiell?

Die Antwort auf diese Frage ist eigentlich ganz einfach: Entweder, man pr�ft den Quellcode auf Programmierfehler, die zu einer Schwachstelle f�hren, d.h. im Wesentlichen fehlende oder unzureichende Pr�fungen von Eingabewerten. Oder man gibt f�r alle in der Webanwendung verwendeten Parameter m�gliche Angriffsmuster ein und schaut, was passiert. Nat�rlich kann man auch beide Ans�tze kombinieren. Hier soll es haupts�chlich um die Analyse vorhandener Webanwendungen gehen, und zwar der Vollst�ndigkeit halber von Anfang an.

Schritt 1: Informationen sammeln

Am Anfang jedes Angriffs und jeder Suche nach Schwachstellen steht das Sammeln von Informationen �ber die anzugreifende bzw. zu testende Webanwendung. Beim Test der eigenen Anwendung k�nnte man darauf verzichten, weil man die entsprechenden Informationen schon besitzt. Trotzdem lohnt es sich, diesen Schritt zumindest theoretisch nachzuvollziehen. Aus dem einfachen Grund, weil ein Angreifer so anfangen w�rde und man dadurch erf�hrt, was der Angreifer auch erfahren w�rde � obwohl er es vielleicht eigentlich gar nicht sollte.

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

Gesucht werden die Informationen haupts�chlich an 4 Stellen:

  • Kommentare im HTML-Code
  • Sensitive Informationen im HTML-Code
  • Fehlermeldungen der Webanwendung
  • Fehlermeldungen des Webservers und HTTP-Responses
Schritt 1a: Den Aufbau der Webanwendung ermitteln

Zuerst m�ssen alle verwendeten Ressourcen und Parameter ermittelt werden. Dazu k�nnen entweder Webcrawler wie z.B. wget genutzt oder alle Seiten manuell durchgegangen werden. Da bei der automatisierten Suche unter Umst�nden sehr viele Dubletten gefunden werden, ist eine manuelle Suche bei nicht zu gro�en Websites oft zielf�hrender. Dabei gewinnt man gleich einen �berblick �ber die Anwendung, den man sich ansonsten aus dem Crawler-Ergebnis erst erarbeiten m�sste. Der Nachteil der manuellen Suche ist, dass ein �bersehener Link dazu f�hrt, dass die Seiten hinter diesem Link nicht erfasst und dadurch sp�ter auch nicht untersucht werden.

Das Vorgehen bei der manuellen Suche ist nahliegend: Ausgehend von der Startseite werden alle Links zu weiteren Seiten angeklickt und dabei die erreichbaren Seiten und die �bergebenen Parameter dokumentiert. W�hrend die GET-Parameter direkt in dem URL gelesen werden k�nnen, m�ssen die POST-Parameter und Cookies �ber einen Webproxy wie z.B. Paros sichtbar gemacht werden.

About Security: Die komplette Serie

Nutzt die Anwendung verschiedene Benutzerrollen, z.B. f�r G�ste, normale Benutzer und Administratoren, f�ngt man mit der niedrigsten Rolle an und arbeitet sich dann bis zur h�chsten durch.

Ein Schwachstellen-Scanner arbeitet �hnlich: Entweder werden die Seiten von einem Webcrawler durchsucht, oder die Aktionen eines Testbenutzers werden �ber einen Proxy aufgezeichnet. Der Nachteil bei der Aufzeichnung �ber einen Proxy ist derselbe wie bei einer manuellen Suche: Nur die tats�chlich durchgef�hrten Aktionen werden erfasst. Wird eine Aktion beim Test vergessen oder absichtlich ausgelassen, werden die zugeh�rigen HTTP-Requests nicht erfasst und dementsprechend die aufgerufene Seite und zugeh�rige Folgeseiten sp�ter auch nicht gepr�ft.

Die n�chsten manuellen Schritte �berspringt ein Schwachstellen-Scanner im Allgemeinen. Stattdessen beginnt er gleich damit, alle erfassten Seiten und Parameter der Reihe nach zu testen. Die meisten Scanner besitzen daf�r eine mehr oder weniger gro�e Datenbank mit bekannten Exploits, die sie durchprobieren k�nnen. Alternativ k�nnen sie auch eine Reihe typischer falscher Werte an die Webanwendung senden und deren Reaktion auswerten (Fuzzing). Au�erdem wird z.B. gepr�ft, ob unauthorisierte Zugriffe auf vertrauliche Informationen, z.B. Konfigurationsdateien, m�glich sind.

In der n�chsten Folge geht es um die Auswertung der gesammelten Informationen.

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