Piwik: XSS und etwas CSRF?!

Für einen aktuellen Servercheck habe ich mir auch Piwik (de.piwik.org) angeschaut, eine Webanalyse-Software, ganz ähnlich wie Googles Analytics. Wer Piwik nutzt der hat die Hoheit über die erhobenen Daten, was bei Google nicht der Fall ist, da weiß niemand was die mit den Daten anstellen und wem sie sie geben.

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.

piwik xss seo widget
(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.


Benutzername: admin
Passwort: 123456789
token_auth=c561acea86161390fe8bc97a433c20ad

Plain: 123456789
MD5 Hash: 25f9e794323b453885f5181f1b624d0b

Plain: admin25f9e794323b453885f5181f1b624d0b
MD5 Hash: c561acea86161390fe8bc97a433c20ad


In Piwik steht zwar:

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: (https://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

piwik xss seo widget

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.





4 comments

  1. Ahoi,
    der Eintrag kam von mir :) Der von dir genannte “Fehler” in der Benutzerverwaltung ist allerdings keiner. Wie du an der URL siehst, wird das Modul API dort verwendet. Die API dient genau dem Zweck den du beschrieben hast – nämlich dem Anlegen/Bearbeiten/Löschen von Benutzern. Der Sicherheitshinweis kommt nicht von ungefähr – irgendwie muss die API eine Authentifizierung ermöglichen und das geschieht bei Piwik mit dem token_auth. Letztlich läuft das auf nichts anderes hinaus wie bei jedem anderen System auch, wenn du die Zugangsdaten für deinen Server rausgibst wunder dich nicht, dass jemand was verändert..

    Die persistente XSS-Lücke finde ich allerdings sehr interessant. Werde dem ganzen mal weiter nachgehen und einen Patch bauen.

  2. Wenn du sagst das der Bug doch ein Feature ist, dann frage ich mich warum der token_auth per Suchmaschine gefunden werden kann?! Da ist dann der DAU-Schwarze-Peter wohl bei dem Anwender. ;O)

    Mit der persistenten XSS-Lücke solltest du vorsichtig sein. Wenn die falschen Zeichen injiziert werden, dann lässt sich das Ziel nur noch direkt in der Datenbank löschen und nicht mehr im Piwik-Backend.

    Was mir noch aufgefallen ist:
    Ein http://domain.tld/index.php?language=nix gibt eine Fehlermeldung mit dem Pfad bis zum Root aus.

  3. Japp der “Bug” ist ein Feature :) Das wirst du per Suchmaschine finden können weil irgendein User sein token_auth veröffentlicht hat. Das token_auth wird zudem verwendet, um Widgets zu exportieren (also auf der eigenen Seite einzubinden). Dazu nutzt man aber das token_auth eines Users mit nur View-Berechtigungen und nicht das eines Admins (ansonsten trifft das was du oben geschrieben hast natürlich zu).

    Die persistente XSS-Lücke erklärt sich einfach durch nicht vernüftig escapete (komisches Wort) Zeichen. Man könnte hier evaluieren ob es damit als normaler User möglich ist soviel Code zu injizieren, sodass der Admin beim einloggen einen API-Request absetzt der dem normalen Nutzer Administrationsrechte gibt.

    Edit: Gerade getestet, es geht. Wird noch gefixt bis 1.1.

  4. Siehe zweites Update im Eintrag.

    XSS-Lücken erklären sich immer mit fehlerhafter Filterung.

    Ein nettes Feature in den Zielen noch:
    Unter “Name” nur ein Leerzeichen eingeben, da die zur Verfügung stehenden 50 Zeichen eh nicht sinnvoll genutzt werden können. Die 255 Zeichen zum auslösen des Zieles sollten dann aber ausreichend sein, um z.B. die Google-Suche zu integrieren…

    Ja ja, ich geb ja schon Ruh. ;O)

Comments are closed.