Channel Security

Nach dem Sammeln von Informationen auf dem Server (siehe About Security #144) und deren Auswertung (siehe About Security #145) geht es diesmal zuerst weiter um die Suche nach nicht offensichtlichen Informationen auf dem Server und danach um die Untersuchung des Clients.

Interessante Informationen können auch in nicht verlinkten, separaten Verzeichnissen liegen. Vielleicht gibt es ja ein ungeschütztes Verzeichnis test/ mit einer noch nicht ausgereiften Testversion der Anwendung, oder ein Verzeichnis admin/ mit einer Administrationsoberfläche. Oft sind auch nicht benötigte Beispielanwendungen oder nicht benötigte Bibliotheken der verwendeten Entwicklungsumgebung und Ähnliches noch auf dem Webserver gespeichert. Auch diese Seiten können Schwachstellen enthalten oder unnötige Informationen preisgeben.

Ebenfalls in diesem Schritt kann nach weiteren Diensten auf dem zu untersuchenden Server gesucht werden: Gibt es einen SSH-Zugang, läuft auf einem anderen Port des Webservers eine Administrationsanwendung usw., kurz: Ein Portscan ist fällig. Dazu eignet sich z.B. Nmap.

Findet man bei der Analyse der eigenen Webanwendung in diesem Schritt irgendetwas, hat man wahrscheinlich vorher einen Fehler gemacht. Und der sollte dann gleich korrigiert werden: Nicht benötigte Dienste werden deaktiviert und der Webserver so konfiguriert, dass nur die gewünschten Seiten ausgeliefert werden. Ebenso ist es nun an der Zeit, einen eventuell fehlenden Zugriffsschutz für sensitive Teile der Anwendung, wie z.B. den Administrationsbereich, nachzurüsten bzw. zu aktivieren. Nicht benötigte Komponenten müssen gelöscht oder mit einem Zugriffsschutz versehen werden. Es wäre doch ärgerlich, wenn die eigene Anwendung absolut sicher ist und dann ein Angreifer eine Schwachstelle in einer unbenutzten, veralteten Bibliothek ausnutzt, um die Kontrolle über den Server zu übernehmen. Ein gutes Tool, um nach bekannten Schwachstellen zu suchen, ist Nikto.

Schritt 3: Untersuchung des Clients

Bei der Untersuchung des Clients gibt es große Unterschiede zwischen klassischen, statischen Websites und den dynamischen (AJAX-)Anwendungen des Web 2.0. AJAX-Anwendungen haben im Gegensatz zu statischen Webseiten interne Zustände, die ihr Verhalten beeinflussen. Die Reihenfolge der Benutzerinteraktionen hat Auswirkungen auf den Ablauf des JavaScript-Codes, dazu kommen u.U. automatische Requests zur Aktualisierung von z.B. Aktienkursen oder Wetterdaten. Hinzu kommen Änderungen während der Laufzeit: Serverantworten enthalten neuen JavaScript-Code, der das Verhalten der Seite ändern kann. Doch bevor die sich daraus ergebenden Probleme betrachtet werden, wird die Untersuchung der statischen Seiten beschrieben.

Schritt 3a: Untersuchung statischer Seiten

Bei der Untersuchung statischer Seiten richtet sich das Interesse primär darauf, weitere Hinweise für den Angriff auf die Webanwendung zu erlangen. Im Wesentlichen geht es dabei um Beschränkungen der Benutzereingaben: Wenn die Eingaben bereits auf dem Client geprüft oder auf bestimmte Werte beschränkt werden, findet ja vielleicht auf dem Server keine weitere Prüfung mehr statt. Da der Angreifer den Client beliebig manipulieren oder sogar simulieren kann, kann er auch die an den Server gesendeten Parameter beliebig manipulieren und damit Schaden anrichten.

Der erste Blick gilt Eingaben wie Text- oder Auswahlfeldern, Radio-Buttons und Select-Tags. Sind Textlängen begrenzt, welche Werte stehen bei Auswahlfeldern, Radio-Buttons und Select-Tags zur Verfügung? Danach geht es darum, diese Werte zu manipulieren und die Reaktion der Webanwendung auszuwerten. Dazu stehen drei Möglichkeiten zur Verfügung: Per GET übertragene Parameter können direkt in dem URL manipuliert werden. POST-Parameter können entweder vor dem Senden in der lokal gespeicherten Seite geändert oder nach dem Senden "on the fly" über einen Proxy wie Paros oder ein Tool wie die Firefox-Erweiterung Firebug manipuliert werden. Bei einer Änderung in der gespeicherten Seite müssen ggf. relative Links in der Seite in passende absolute umgewandelt werden.

Ein (zugegeben etwas konstruiertes) Beispiel: In einem Webshop wird die Anzahl der gewünschten Artikel über ein Drop-Down-Menü ausgewählt, das Werte von 0 bis 10 vorgibt. Was passiert, wenn für diesen Parameter ein negativer Wert übertragen wird? Eventuell findet auf dem Server keine weitere Prüfung statt, weil ja nur Werte von 0 bis 10 ausgewählt werden können. Wird dann der Rechnungsbetrag nach dem Muster "Anzahl * Preis in der Datenbank" berechnet, würde eine negative Anzahl zu einem negativen Rechnungsbetrag bzw. einer Verminderung des Gesamtbetrags führen.

Falls die Länge eines freien Textfeldes begrenzt ist, könnte ein längerer Wert für den betreffenden Parameter auf dem Server zu einem Pufferüberlauf führen, sofern dort keine Prüfung des Wertes erfolgt.

Während sich die Schwachstellensuche bisher auf den Server und auf die vom Benutzer im Client zumindest in bestimmten Grenzen manipulierbaren Parameter konzentriert hat, geht es in der nächsten regulären Folge u.a. um die Werte in versteckten Feldern. Davor gibt es in der nächsten Woche den schon traditionellen Bericht über Neuigkeiten von der CeBIT.

Carsten Eilers

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

• About Security #144: Schwachstellensuche: Allgemeine Infos sammeln
• About Security #145: Schwachstellensuche: Daten auswerten
• About Security #146: Schwachstellensuche: Infos im Client sammeln
• About Security #147: Schwachstellensuche: AJAX-Clients (1)
• About Security #148: Schwachstellensuche: AJAX-Clients (2)