Vor ein paar Tagen habe ich mal wieder einen Hinweis zu einer XSS-Lücke verschickt. Mein Beispiel war die Injektion eines Bildes, mit einem JavaScript-Alert, also das übliche. Die Antwort kam sehr schnell:

Ich werde den Fehler natürlich umgehend an unser Technikteam in der *** Zentrale weiterleiten, aber ob und wann dort die Ressourcen zugeteilt werden um diesen Fehler zu beheben…

Den, den ich da angeschrieben habe, war nicht das Hotel um die Ecke oder ein Shop mit fünf Artikeln im System, es ist eine sehr bekannte Publikation die sich mit dem Thema IT-Sicherheit beschäftigt, also musste ich einfach noch einmal Antworten:

ich muss gestehen, Sie haben mich mit Ihrer Antwort verblüfft.

Bei einer Publikation die sich primär dem Thema IT-Sicherheit zuwendet, hatte ich nicht erwartet, dass es bei der Fehlerbehebung um das “ob” geht. :O)

Die Lücke ist nicht schwer zu finden, das heißt: Jedes Scriptkiddie kann sich als großer Hacker aufspielen, um an der Reputation von *** zu kratzen.

Der Cookie-Flag HttpOnly ist nicht gesetzt, weshalb der Session-Cookie per XSS ausgelesen werden kann. Die Session-ID ist nicht an die IP-Adresse des Benutzers gebunden. Das Fehlen dieser beiden Sicherungen, macht es einem Angreifer sehr leicht, per XSS in einen Benutzeraccount einzubrechen.

Das Session-Handling ist komplett fehlerhaft. Beim Übergang von http zu https wird die Session nicht gewechselt, was das Login per https (wegen der fehlenden IP-Bindung) ad absurdum führt. Es fehlt natürlich auch der Cookie-Flag Secure.

Die gleiche XSS-Lücke findet sich auch in den folgenden Seiten:
***.de
***.de
***.de
***.de
***.de

Am nächsten Tag war die XSS-Lücke dann schon gefixt, also hat jemand sehr schnell die “Ressourcen zugeteilt”. Aber die anderen Probleme bestehen weiterhin und es ist so gut wie sicher, dass es in der Seite irgendwo weitere XSS-Lücken gibt.

Das Login, wie es sein sollte per https:

Das Editieren im Benutzeraccount sollte aber auf gar keinen Fall unverschlüsselt erfolgen. Hier der Request bei der Änderung des Passwortes:

Das “Technikteam” weiß nicht so recht warum https verwendet wird. Sie haben wohl mal gehört dass man dieses komische SSL für Logins benutzen sollte, aber warum das gut sein soll? “Keine Ahnung, schadet ja nicht.” Anders ist es nicht zu erklären, warum es nur beim Login eine Verschlüsselung gibt.

Warum wird denn die Kommunikation zwischen Server und Client verschlüsselt?

Ohne Verschlüsselung sind Web-Daten für jeden, der Zugang zum entsprechenden Netz hat, als Klartext lesbar. Mit der zunehmenden Verbreitung von Funkverbindungen, die etwa an WLAN-Hotspots häufig unverschlüsselt ablaufen, nimmt die Bedeutung von HTTPS zu, da hiermit die Inhalte unabhängig vom Netz verschlüsselt werden.

Besser könnte ich es nicht in Worte fassen, deshalb als Zitat aus Wikipedia.
Quelle: http://de.wikipedia.org/wiki/Https

Die Cookie-Flags HttpOnly und Secure werden für den entscheidenden Session-Cookie nicht gesetzt:

Der gesetzte HttpOnly-Flag würde dafür sorgen, dass der Inhalt der Cookies nicht per JavaScript (XSS) ausgelesen werden kann. Liebes “Technikteam”, dies macht ein Angreifer natürlich NICHT per alert(document.cookie), sondern so, dass das Opfer dies nicht bemerkt.

Der gesetzte Secure-Flag würde dafür sorgen, dass Cookies nur per https übertragen werden. Auch ein Man-in-the-middle könnte die Cookies nicht im Klartext lesen, womit diese unbrauchbar wären.

Das was das “Technikteam” da gebastelt hat, ist so unsagbar schlecht, dass in der “Zentrale” sofort einige Stellen neu besetzt werden müssten.


Wie man nur mit einer Session-ID bewaffnet in ein Benutzerkonto einbricht zeigt dies kurze Video:

Das Formular nimmt die Session-ID auf, generiert eine URL inkl. Cross-Site Scripting, welche an die anfällige Website geschickt wird. Die Injektion setzt einfach den Cookie für die Session-ID und leitet dann zur Profilseite des Opfers weiter, sehr einfach, deshalb sieht man in dem Video auch nicht viel. :O)

Die XSS-Lücke in Bebo ist nicht neu, die Verantwortlichen kümmert’s nur nicht, wohl weil es Benutzer sind, die nicht direkt Geld bezahlen.
http://xssed.com/mirror/67289/

Date submitted: 17/06/2010
Date published: 18/06/2010

Update: 01.02.2012 – 18:13 Uhr

Der Session-Cookie hat einen HttpOnly-Flag spendiert bekommen:



Noch ein Link passend zum Thema XSS und HttpOnly:
“Apache httpOnly Cookie Disclosure” (fd.the-wildcat.de)


Update: 01.02.2012 – 22:00 Uhr

Wie ich schon erwartete, habe ich eine weitere XSS-Lücke gefunden, aber Dank des HttpOnly-Flags kann nun der Session-Cookie nicht ausgelesen werden.
(Weil es kein Apache ist.)


Update: 07.02.2012 – 10:58 Uhr

Die letzte XSS-Lücke wurde mittlerweile geschlossen, aber es gibt sicher weitere Lücken.

Der Secure-Flag für den Cookie der Session-ID wird noch immer nicht gesetzt und auch das Editieren innerhalb des Benutzerkontos erfolgt noch immer unverschlüsselt.

Hiermit will ich es mal damit bewenden lassen, schließlich kann ich den Verlag nicht zwingen mehr für die Sicherheit seiner Besucher zu tun.

Eine SQL-Fehlermeldung bedeutet nicht, dass es auch eine Möglichkeit für SQL-Injection gibt. Anders herum bedeutet das Fehlen einer Fehlermeldung nicht, dass es keine Lücke gibt. Ein einfacher Test mit and 1=1 und and 1=2 zeigt, ob eine Injektion möglich ist. Wurde eine Lücke identifiziert, prüft man die Anzahl der Tabellenspalten, wobei es auch hier eine hilfreiche Fehlermeldung gibt. Hat man die korrekte Anzahl der Tabellenspalten gefunden, sieht man in der Regel die injizierten Ziffern, die man dann mit den Systemvariablen user(), database(), version() ersetzten kann. Für einen Proof of Concept reicht dies meist aus, um dem Seitenbetreiber die Schwachstelle zu demonstrieren.

In diesem Beispiel sollen die Zugangsdaten ausgelesen werden, daher wird einfach nach ‘pass’ in der Datenbank gesucht. Hier werden die Hochkommata nicht so einfach übernommen, weshalb die Anfrage in Hexcode umgewandelt wird. Es gibt drei Tabellen in denen offensichtlich Passworte gespeichert werden: login, login_secured und users. In der Tabelle login wir nun nach den Bezeichnungen der Tabellenspalten gesucht, um im letzten Schritt die Zugangsdaten auslesen zu können: Das meistbenutzte Passwort ever!

Das Passwort wird hier im Klartext in der Datenbank gespeichert. Meist wird man aber einen Hash (MD5, SHA1) finden, für den man dann noch die Entsprechung, also das Passwort, herausfinden muss. Dank fehlendem Salt und einfachen Passworten, ist auch dies meist relativ schnell erledigt.

Mit den richtigen Werkzeugen lässt sich dies alles auch bewerkstelligen ohne zu verstehen was SQL ist — am Ende fallen nur die Zugangsdaten aus dem Tool.

In dem Beispiel wurden Daten nur ausgelesen, es ist natürlich auch möglich diese zu ändern, zu löschen oder komplett neue Datensätze hinzuzufügen.

Abhängig davon wie ein Angreifer vorgeht, wird der Seitenbetreiber nichts von dem Angriff mitbekommen. Erst wenn tausende von Kundendaten abgeflossen sind, diese missbraucht wurden, Kunden eindeutig feststellen können “Nur Shop-X hat meine Daten.” und sich beschweren, erst dann wird der Seitenbetreiber aufmerksam.

Wie man sieht, ist ein Angriff per SQL-Injection sehr einfach durchzuführen. Auch minderbegabte Scriptkiddies können hier großen Schaden anrichten, weshalb es mich immer wieder wundert, wie ignorant und leichtfertig Seitenbetreiber mit entsprechenden Hinweisen umgehen. Wenn dann mal wirklich eine Reaktion auf eine meiner Hinweise kommt, dann wird auch nur darauf geschaut, dass genau mein Beispiel nicht mehr funktioniert, dass aber an vielen anderen Stellen die gleiche Lücke besteht, wird außer Acht gelassen. Es wird immer nur an den schlimmsten Bugs geflickt und auch nur wenn man befürchten muss, dass dies öffentlich wird.


Ich habe noch immer die Hoffnung, dass es irgendwann eine Stelle gibt, denen man Sicherheitslücken melden kann und die, mit den richtigen Sanktionsmitteln ausgestattet, sich mit dem Seitenbetreiber auseinandersetzen und am Ende dafür sorgen können, dass die Lücke oder die Website geschlossen wird.


Die verfremdeten Screenshots gehören nicht zu dem ignoranten Seitenbetreiber. Es gibt so viel Unrat im Netz, da fand ich schnell eine Seite für mein Beispiel.