Archive for the ‘Sicherheit’ Category

Inoffizielles Sicherheitsupdate für easyLink

Thursday, July 23rd, 2009

Seit mehreren Wochen ist nun bekannt, dass in verschiedenen Versionen von easyLink gravierende Sicherheitslücken vorhanden sind. Wie die Firma Mountaingrafix mit ihren Kunden im Forum umspringt, lasse ich an dieser Stelle besser unkommentiert. Ein Update steht von offizieller Seite anscheinend noch immer nicht zur Verfügung; im Forum gibt es zwar ein paar “dringende Sofortmaßnahmen”, diese bringen jedoch zahlreiche Nebenwirkungen mit sich.

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.]

Sicherheitslücken in easyLink 2.6

Monday, July 20th, 2009

Einer meiner Kunden rief mich besorgt an und teilte mir mit, dass es Sicherheitslücken in einem seiner Link-Kataloge gebe. Nach dem Gespräch schickte er mir noch ein Video zu, das das Ausmaß der Lücken demonstrieren sollte: es zeigte einen leicht bedienbaren Exploit, der anscheinend nach Eingabe einer URL private Daten wie E-Mail-Adressen und Kontonummern aus einem Web-Katalog auslas.

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.]

Einbruch in die Fedora-Server?

Tuesday, August 19th, 2008

Seit einigen Tagen sind verschiedene Server der kostenlosen Linux-Distribution Fedora nicht mehr erreichbar, auch das Software-Update funktioniert nicht mehr. Sämtliche Server werden derzeit komplett neu eingerichtet, und Paul Frields, seines Zeichens Projektleiter von Fedora, rät, vorerst keine Updates oder neue Pakete zu installieren [1].

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

Pöse Hacker

Saturday, September 10th, 2005

Das kam Mittwoch bzw. Donnerstag per Mail:

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…

Munteres Kartentauschen

Thursday, May 5th, 2005

Eben war ich bei der Bank, wollte mal wieder Kontoauszüge holen. Portemonnaie auf, Karte raus und ab in den passenden Automaten der schon gierig “Karte einschieben” meldete und die Karte gierig verschlang. Das Warten auf die Kontoauszüge beginnt, wird jedoch abrupt beendet als der Automat provokant meldet: “Karte einschieben”. Doch es half alles nichts, kein Rütteln, kein Schütteln, kein Treten, der massive Automat ließ sich nicht dazu überreden, die Karte wieder her zu geben. Die Bank hatte schon lange geschlossen, eine Telefonnummer ließ sich auch nicht finden. Toll gemacht, Raiffeisenbank Overath-Rösrath.

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 ;)

Großes Sicherheitsloch im wBB

Wednesday, February 23rd, 2005

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.