Bei der Recherche zu SQL-Injections (de.wikipedia.org) bin ich gestern über einen sehr sonderbaren Bug gestolpert.

Wenn ein Script per URL Parameter übernimmt, so in der Form script.asp?id=xyz, so kann man unter schlechten Umständen Fehlermeldungen hervorrufen, wenn man an dem xyz etwas rumspielt.

Ich habe auch etwas rumgespielt und plötzlich wurden mir alle Dateien und Unterverzeichnisse in dem Hauptverzeichnis, in dem die index.asp liegt, angezeigt. Das Directory-Listing ist dort eingeschaltet, was per se noch keine schwerwiegende Sicherheitslücke darstellt, da üblicherweise der Server immer die index.asp ausführt und anzeigt. Aber in diesem Fall reichte es aus index.asp?; aufzurufen, um das Verzeichnis auflisten zu lassen.

Da ein Bug selten alleine kommt… In dem Verzeichnis fand ich u.a. auch ein Unterverzeichnis, welches offensichtlich die Administrationsscripte des CMS enthält und darin gibt es eine Datei die die User-Daten, inkl. Passwort im Klartext, dem Finder präsentiert. Also nicht nur dieser, mir bisher unbekannte Semikolon-Bug, sondern auch mal wieder kein Schutz der Scripte vor unberechtigtem Zugriff und Passworte im Klartext – eines meiner Lieblingsthemen – unverschlüsselte Passworte in Datenbanken.

Eben habe ich etwas gegoogelt – dabei stellte ich fest das man alleine durch ?; Fehlermeldungen provozieren kann und da kommt dann auch gerne der Hinweis zu der Tabelle in dem nichts gefunden werden konnte. Hat man einen Tabellennamen so kann man schon wieder weitere Fehlermeldungen provozieren, um noch mehr Informationen zu sammeln und um letztendlich evtl. auch das ganze System zu übernehmen.

Nicht das jemand nun glaubt ich würde auf ASP rumhacken, nur weil es von Microsoft ist. Solche Bugs findet man ganz sicher auch auf PHP- oder Java-Seiten, es gibt ja genügend Coder da draußen, die an die einfachsten Dinge nicht denken…

Mal wieder ein praktisches Beispiel für XSS (de.wikipedia.org), welches nicht nur hypothetisch besteht:

Auf einer WebSite eines Magazins kann man z.B. für Produkte Bewertungen abgeben. Der WebSite-Betreiber meint das diese Bewertungen glaubwürdiger sind wenn nur angemeldete User eine Bewertung abgeben dürfen, was den Herstellern natürlich als sehr seriös daherkommt. Niemand würde hunderte von Accounts anlegen, nur um seine Produkte gut zu bewerten und/oder die des Konkurrenten schlecht… es geht aber sehr viel einfacher – das AAL-Prinzip, Andere Arbeiten Lassen:

<div style="display:none">
<!-- meine Produkte //-->
<img src="http://www.domain.tld/vote/?pid=1111&rate=10" />
<img src="http://www.domain.tld/vote/?pid=1112&rate=10" />
(...)

<!-- Produkte meiner Konkurrenten //-->
<img src="http://www.domain.tld/vote/?pid=6661&rate=1" />
<img src="http://www.domain.tld/vote/?pid=6662&rate=1" />
(...)
</div>


Das Magazin hat auch ein Forum, in dem sich die User unterhalten. In diesem Forum schreibt der Angreifer einen Beitrag der mit einem Link versehen ist und auf der verlinkten WebSite baut er u.a. auch den obigen Code ein. Der Angreifer kann auf diese Weise dafür sorgen das seine Produkte besser bewertet werden und die seiner Konkurrenz schlechter, und das perfide daran, der User der diese Bewertungen abgibt bemerkt nichts davon. Der einzige Haken für den Angreifer ist, das der User angemeldet sein muß um die Bewertungen abgeben zu können.

Dies ist eine Steigerung zum einfachen XSS, es nennt sich CSRF (de.wikipedia.org).

Eine Cross-Site Request Forgery (…) ist ein Angriff auf ein Computersystem, bei dem der Angreifer unberechtigt Daten in einer Webanwendung verändert. Er bedient sich dazu eines Opfers, das ein berechtigter Benutzer der Webanwendung sein muss. Mit technischen Maßnahmen oder zwischenmenschlicher Überredungskunst wird hierzu aus dem Webbrowser des Opfers ohne dessen Wissen und Einverständnis ein kompromittierter HTTP-Request an die Webanwendung abgesetzt. Der Angreifer wählt den Request so, dass bei dessen Aufruf die Webanwendung die vom Angreifer gewünschte Aktion ausführt.

(Quelle: de.wikipedia.org)

Wenn auf der angegriffenen WebSite auch noch einfaches XSS möglich wäre, dann müßte der Angreifer noch nicht einmal eine eigene Seite basteln. Er könnte einen Foreneintrag schreiben, der bei jedem Aufruf automatisch die Bewertungen abgibt. Auf der WebSite des Magazins ist dies aber nicht möglich.


Mit CSRF sind natürlich auch wirklich sicherheitsrelevante Aktionen möglich.

Wenn z.B. im Backend eines Systems das Anlegen eines neues Users, evtl. sogar mit Administrationsrechten, mit nur einer URL möglich ist, dann könnte man dem echten Admin einen entsprechend erweiterten Link schicken… und schon ist man auch Admin…


Und wer hat das praktische Beispiel gefunden? Es war der Erich (erich-kachel.de) dessen Blog ich ja bereits im Zusammenhang mit XSS erwähnte.