Ich habe wieder in einer sehr populären Website verschiedene Sicherheitslücken gefunden und den Betreiber darauf hingewiesen. Ok, meinen Hinweis habe ich erst gestern verschickt und er hat heute schon reagiert, aber aus dem was er geändert hat, kann ich nur schließen — er hat das Problem nicht verstanden.


Beim Login wird die Session nicht an die IP-Adresse des Besuchers gebunden, wodurch jeder Zugang zu dem Account bekommen kann, der die Session-ID kennt. Die fehlende IP-Bindung an die Session ist für sich alleine genommen schon eine Sicherheitslücke — aber noch nicht sehr kritisch, sofern man (unrealistisch) davon ausgeht dass es keine weiteren Lücken gibt.

Leider finden sich auch Lücken zu Cross-Site Scripting (de.wikipedia.org) in der Seite, was im Zusammenspiel mit der Anfälligkeit für Session Hijacking (de.wikipedia.org) zu einer schwerwiegenden Sicherheitslücke wird.


Mit JavaScript ist es auch möglich einen bestehenden Cookie zu überschreiben. Gibt es in einer Website eine XSS-Lücke, so können auch die Cookies überschrieben werden, auf die der Browser laut Same Origin Policy (de.wikipedia.org) gar keinen Zugriff hat.

Ein Angreifer verteilt den Link zu seiner präparierten Seite, in der per unsichtbarem Iframe die anfällige Unterseite aufgerufen wird. Ist ein Opfer in der Website angemeldet so wird ein weiterer Cookie geschrieben. Der Angreifer richtet sein Script so ab, dass er nur dann eine Meldung bekommt wenn dieser zusätzliche Cookie gefunden wurde. Und da er die abgefangene Session-ID gleich in seine eigene Session übernehmen kann, kann er sich automatisch in den fremden Account einloggen.


Wenn es beispielsweise um SQL-Injection geht, da verstehen mittlerweile auch die die sich weniger mit der Sicherheit von Websites beschäftigen, dass es gefährlich werden könnte. Ein Angreifer kann dabei nicht nur Informationen aus einer Datenbank auslesen, sondern auch editieren, neu einfügen oder löschen.

Nach wie vor wird Cross-Site Scripting unterschätzt, was wohl der Grund dafür ist, dass es noch immer sehr einfach und schnell möglich ist entsprechende Lücken zu finden. Auch der Betreiber der populären Website scheint XSS nicht zu verstehen und nur an die üblichen Beispiele (Verunstaltung: “Hacked by Scriptkiddie”) zu denken.

Gestern konnte in den Input-Feldern noch
"><script>alert(123)</script>
ausgeführt werden, heute noch immer
">Nur Text nach dem Input-Tag.
aber auch
" onmouseover=alert(123) "

Erwartungsgemäß wurde wieder am Textarea gar nichts geändert, dieser HTML-Tag wird sehr sehr häufig vergessen, wenn es um Eingabefilterung geht — warum auch immer?! Dort ist weiterhin die Injektion von
</textarea><script>alert(123)</script>
möglich.


An dem Handling mit der Session wurde noch nichts geändert. Es ist Sonntag! <g>


Vielleicht wird sich in den nächsten Tagen jemand um das Fixen der Lücken kümmern, der mehr Kompetenz mitbringt, als die Wochenendaushilfe.

Die Website gehört zu den Kandidaten bei denen es mir wieder sehr schwer fällt den Betreiber nicht zu nennen, denn durch die Bekanntheit der Seite gibt es sehr viele mögliche Opfer.


Update: 16.08.2010 – 16:42 Uhr

Die Aushilfe hat Verstärkung bekommen. Jetzt werden alle Felder, auch das Textarea, korrekt gefiltert, wodurch kein XSS mehr möglich ist. Nun fehlen noch Maßnahmen gegen Session Hijacking.

Vorgestern las ich von einem neuen (?) Shopsystem:
“E-Commerce System Zeuscart – eine Alternative für Magento?” (t3n.de)

Um die Antwort vorweg zu nehmen: Nein!


Wenn ich eine neue Seite besuche dann kann ich nicht anderes, da muss ich einfach mal irgendwo ein '">xss eingeben… :O)

Weiteres reflexives Cross-Site Scripting findet sich noch auf den folgenden Seiten: Passwort vergessen, Suche, Registrierung und Login.

Es gibt aber auch die Möglichkeit persistent eigenen Code im Shop zu speichern. Eine Seite die zum Pagemanagement aus dem Backend gehört kann von nicht angemeldeten Besuchern des Shops aufgerufen werden. Auf der Seite können bestehende Einträge editiert, gelöscht und neue hinzugefügt werden.


Seiten aus dem Backend die für jeden Besucher aufrufbar sind, und nicht nur für Shopadmins, gibt es noch weitere:

• Ausgabe der phpinfo()-Seite.
• Export aller Produktdaten im Excel-, XML-, CSV- oder TAB-Format.
• Export aller Kundendaten im Excel-, XML-, CSV- oder TAB-Format.
• Löschen der Aktivitäten des Admins, die in einer Tabelle gelistet werden.
• Anzeige der letzten Bestellungen der Kunden, inkl. Name und E-Mail-Adresse.

Nach der Registrierung im Demoshop testete ich auch die Passwort-vergessen-Funktion und wunderte mich gar nicht mehr, dass das von mir vergebene Passwort in der E-Mail stand. Dafür gibt es zwei mögliche Gründe: Entweder wird das Passwort direkt im Klartext in der Datenbank gespeichert oder es wird so kodiert, dass es wieder dekodiert werden kann.

Ich habe mir die Software runtergeladen und kurz in den Quellcode reingeschaut. Die Passworte werden per base64_encode() kodiert und nicht per MD5 oder SHA1 gehasht. Das bedeutet dass alle Passworte die in der Datenbank stehen per base64_decode() dekodiert, also in Klartext umgewandelt werden können.

Hier ein Beispiel für das Kodieren und Dekodieren:


Und hier kann man dies online ausprobieren: “Base64 Kodierer / Base64 Generator” (php-einfach.de)


Und, natürlich fand ich auch noch an vielen Ecken Cross-Site Request Forgery.

Würde dies in eine Seite als unsichtbares Iframe eingebaut und der Shopadmin besucht die Seite während er eingeloggt ist, bekommt er einen weiteren Admin ins System gepflanzt:
http://domain.tld/admin/
?do=subadminmgt&action=insert
[POST]
subadminname=adminb
&subadminpassword=123456
&subadminemail=adminb%40domain.tld
&insert=Add


Noch ein paar Infos für die die sich diese Software anschauen möchten:

Backend: http://ajdemos.com/demo/zeuscart/v3/admin/
User Name: demoadmin
Password: demo123

Frontend: http://ajdemos.com/demo/zeuscart/v3/
User Name: demouser@domainname.com
Password: demouser

Download: http://www.zeuscart.com/download/Zeuscart3.zip


Ich bin sicher dass es noch weitere Schwachstellen gibt, beispielsweise zu SQL-Injection, aber die gefundenen Lücken sind schon vollkommen ausreichend, um die Nutzung abzulehnen. Wer nun noch ernsthaft überlegt dieses Stück Schrott einsetzen zu wollen — dem ist nicht mehr zu helfen.

Vielleicht ist dies auch nur Teil einer Studie, so nach dem Motto: “Wie schrottig darf eine Software sein, bis sie niemand mehr benutzen mag?” ;O)


Eigentlich schreibe ich ja nicht so kritisch über eine Software, aber dieses Teil ist so schlecht und hat so viele Schwachstellen, dass man nicht davon ausgehen kann, dass die Entwickler (immerhin schon Version 3) auf diese noch nie hingewiesen wurden. Eine Google-Recherche nach “Zeuscart” förderte nur Testinstallationen oder bereits gehackte Shops zutage