Großes Sicherheitsloch im wBB

In allen aktuellen wBB-Versionen gab es bis vorgestern ein großes Sicherheitsleck, durch das man sich Administratorrechte verschaffen konnte. Im Woltlab-Supportforum fragte jemand nach Informationen, ich habe ihm geantwortet; der Beitrag wurde innerhalb weniger Minuten geschlossen und kurze Zeit später entfernt. Bei Woltlab hält man also anscheinend nichts von Full Disclosure, schade…

Das Problem war, dass Werte aus $_COOKIE ungeprüft an die Datenbank geschickt wurden. Bei Woltlab ist man anscheinend davon ausgegangen, dass nur Werte in $_POST und $_GET validiert werden müssen, da ich auf einen ähnlichen Fehler der sich auf $_SERVER bezog bereits vor über 2 Jahren hingewiesen habe. Damals war es möglich, sich mit Hilfe von manipulierter UserAgents Administratorrechte zu verschaffen.

Dank dem nun bekannt gewordenen Loch war dies lange Zeit über Cookies möglich, die man von Hand bearbeitete. Schauen wir uns mal die Datei /acp/lib/session.php an:

Dort findet sich in Zeile 88 der Aufruf $wbbuserdata = getwbbuserdata($_COOKIE[$cookieprefix.’userid’], “userid”, 1);, das Cookie ‘userid’ wird an die Funktion getwbbuserdata (aus der Datei /acp/inc/functions.php) übergeben. Betrachtet man diese genauer, so findet man einen Fehler, der einfach vermeidbar ist und auf keinen Fall hätte auftreten dürfen – ohne den Entwicklern zu nahe treten zu wollen, aber dies war wirklich wie auch der oben genannte ein peinlicher Anfängerfehler.

Die Funktion getwbbuserdata($id, […]) sendet in den Zeilen 1406 bis 1411 folgende Datenbankabfrage: $wbbuserdata = $db->query_first(“SELECT u.* […] FROM bb”.$n.”_users u […] WHERE u.userid=’$id'”); Und hier das ungeheuerliche, die Variable $id erhält den ungeprüften Wert aus dem Cookie! Solche und ähnliche Fehler findet man des öftern im Internet, meist von weniger erfahrenen Programmierern verursacht. Er ist jedoch oft nicht ausnutzbar, da Werte aus Cookies bei vielen Hostern über die gpc_magic_quotes automatisch in nicht für SQL-Injections ausnutzbare Werte konvertiert werden. Dem ist man sich bei Woltlab jedoch bewusst gewesen, schließlich deaktiviert und umgeht man diese Funktion in den Zeilen 33 bis 38 der global.php. Man sollte daher eigentlich wissen, wie man mit solchen Werten aus $_SERVER und $_COOKIE verfahren sollte.

Doch zurück zur aktuellen Sicherheitslücke, und wie man diese ausnutzen kann. Wie oben gezeigt, wird also der Wert des ‘userid’-Cookies ungeprüft an die Datenbank abgesendet. Ändert man nun diesen Wert von beispielsweise “5” (Benutzer Nr. 5) in “X’ OR userid = ‘1″, so lautet die neue WHERE-Bedingung: WHERE u.userid=’X’ OR userid = ‘1’. Die Funktion getwbbuserdata() gibt in diesem Fall den Benutzer mit der ID 1 zurück, und dies ist standardmäßig der Administrator. Eine schlimme Sicherheitslücke!

Zusätzlich wird auch das Cookie ‘lastvisit’ nicht validiert, eine weitere Lücke.

Mit der oben beschriebenen Lücke ist es mir gelungen, auf einer unveränderten wBB-Installation Administratorrechte zu erlangen. Einen genauen Lösungsweg dafür werde ich nicht nennen, allerdings sollte dies für php- und SQL-bewandte Leute kein Problem darstellen. Die obigen Informationen sollen nicht als Anleitung zur Erschleichung von Dienstleistungen oder Datenmissbrauch betrachtet werden, sondern als Hinweis, sich mit der Sicherheit benutzter Software auseinander zu setzen. Sollte jemand weitere Fragen haben, immer her damit.

Nachtrag: Seit dem 02. März gibt es auch bei SecurityTracker näheres über den Fehler zu erfahren.

2 Responses to “Großes Sicherheitsloch im wBB”

  1. Jan says:

    Hallo,
    ich empfinde das Verhalten von Woltlab als eine ziemliche Frechheit. Warum soll der Kunde nicht wissen, wo genau der Fehler ist? Schließlich benutzt er ja das Produkt und hat ein Recht darauf zu erfahren, wie es um die Sicherheit bei der Anwendung steht. Dann halte ich die Löschung des Beitrags im Forum für ein unangemessenes Verhalten. Die Verantwortlichen könnten doch zumindest eine kurze Stellungnahme dazu abgeben und im Zweifelsfall für eine Richtigstellung des Sachverhalts sorgen. Jedenfalls nicht direkt löschen.
    Danke für die Aufklärung
    Jan

  2. helga says:

    Der Kunde hat erfahren, wo der Fehler liegt, siehe auch Update in der session.php.
    Ich finde es genauso nicht richtig, wenn dort dann noch beschrieben wird, wie man diese Sicherheitslücke ausnutzen kann. Das würde keinem Softwarehersteller gefallen ! Das Verhalten seitens Woltlab finde ich daher angemessen.

Leave a Reply