Bis ein Sicherheitsupdate seitens Mountaingrafix erscheint, wird man sich wohl noch einige Zeit gedulden müssen. Herr Schoppengerd schreibt im Forum: “leider hat bei uns momentan leider niemand Zeit sich um die Version wirklich zu kümmern.”

Um die Nutzer von easyLink 2 nicht im Regen stehen zu lassen, habe ich daher nach bestem Wissen und Gewissen ein inoffizielles Sicherheitsupdate erstellt. Da es potenziellen Angreifern hilfreiche Informationen über die Lücken liefern könnte, werde ich es jedoch nicht öffentlich anbieten.

Betroffene easyLink-Besitzer können es kostenlos per E-Mail an sicherheitsupdate@naggel.com anfordern.

[Nachtrag 28.07.09: Mittlerweile stellt der Hersteller für die neueste Version ein Update zur Verfügung, das auf meinen Änderungen beruht. Benutzern älterer Versionen wird empfohlen, die Änderungen manuell anhand meiner Anleitung durchzuführen.]

Das stank natürlich nach XSS, SQLi und mehr, und nach einiger Recherche im Code fand ich auch einige Sicherheitslücken, die das Ausspähen dieser Daten ermöglichten. Natürlich habe ich umgehend Fehlerkorrekturen erstellt und bei allen meinen betroffenen Kunden installiert!

Zitat meines Kunden: “Vielen Dank für die super schnelle Fehlerbehebung! Ich bin froh, dass Sie den Support für mein Portal leisten!”.

Danke, das hört man gerne :-)

[Nachtrag 28.07.09: Mittlerweile stellt der Hersteller für die neueste Version ein Update zur Verfügung, das auf meinen Änderungen beruht. Benutzern älterer Versionen wird empfohlen, die Änderungen manuell anhand meiner Anleitung durchzuführen.]

Dies legt den Schluss nahe, dass in die Fedora-Server womöglich eingebrochen wurde. Mit einer Neuinstallation würde man sicher stellen, dass dem Angreifer keine Hintertür offen bleibt. Man kann nur hoffen, dass sich diese Befürchtung nicht bewahrheitet, und vor allem, dass keine Software-Pakete modifiziert wurden.

Das Fedora-Infrastruktur-Team ist derzeit fleißig dabei, die bestehende Infrastruktur wieder flott zu kriegen [2] [3]. Heute verschickten sie eine Mail in der sie jeden mit Zugriff auf einen der Fedora-Server auffordern, sein Passwort zu ändern.

Tom Callaway, einer der Fedora-Admins, teilte mir mit, dass die im Account-System gespeicherten Passwörter als MD5-Prüfsumme mit Salt gespeichert werden. Es besteht daher keine Gefahr, dass ein etwaiger Angreifer aus womöglich geklauten Hashs Rückschlüsse auf euer Passwort ziehen kann. Es ist ihm auch nicht möglich, sich mit diesem Hash Zugang zu einem anderen System oder einer Seite zu verschaffen, bei der ihr das selbe Passwort benutzt habt. Mit einem geklauten Hash dieser Art ist ausschließlich der Zugriff auf euren Fedora-Account möglich, daher bitte trotzdem, auch im eigenen Interesse, umgehend euer Passwort ändern.

[1] http://redhat.com/archives/fedora-announce-list/2008-August/msg00008.html
[2] http://redhat.com/archives/fedora-announce-list/2008-August/msg00009.html
[3] http://redhat.com/archives/fedora-announce-list/2008-August/msg00011.html

Hey man.I am just learning bout exploits,injections and stuff.I am a
moderator in a site (hackits) and found out bout your exploit in the Burning
Board forum.The “‘X OR userid = ‘1″.
I ‘ve done this in the site where i am mod and saw that the only thing that
got to do was that the user X’ OR userid = ‘5012 had the avatar of the user
1.NOthing more (except of the fact that the forumcookiehash value was the
same between the 2 users).How is it that i can login (maybe change the
password????) with the user 1???
Please respond.I am not a scriptkiddy triyng to find only known exploits,but
i am only in the beginning… :(

Hi,
I’m a web administrator for a WBB (2.3.3) board, and I’m trying to replicate the exploit shown below on a 2.2.1:
http://securitytracker.com/alerts/2005/Mar/1013351.html
For some reason it’s not working and I was wondering if you could help me out.
I modified my cookie as stated below:
wbb2_userid = 1 web.forum.wbb.example
Could you please help me? I’m trying to understand more about the board by exploiting it, if that makes sense.
Thanks!

Mittlerweile gibt es offenbar Interesse an der Sicherheitslücke im wBB, die ich im Februar bekannt machte, ohne jedoch einen funktionieren Exploit mitzuliefern. Tz, Leute gibt’s…

Naja, werde ich die netten Damen und Herren dort mal am Freitag Morgen besuchen…

Weiterhin kam heute ein Brief von der Free Software Foundation Europe mit den PINs für meine “Fellowship Card”, diese wird bald in einem seperaten Brief ankommen. Mal schauen, welche Karte zuerst den Weg zu mir findet, Wetten darauf werden ab sofort akzeptiert.

Nachtrag 06.05.2005: Die Bankkarte hat mit einem Vorsprung von rund 60 Minuten knapp gewonnen ;)

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.