[WP 2.0.1] Sicherheitslücken im Blog-System Wordpress

  • Zitat


    In dem Blog-System Wordpress wurden mehrere Sicherheitslücken entdeckt, die so genanntes Cross Site Scripting (XSS) und die Preisgabe interner Serverinformationen ermöglichen, wie aus einem Advisory einer Gruppe Namens Neo Security Team hervorgeht. Durch eine unzureichende Filterung der Kommentare lässt sich JavaScript-Code in diese einbetten, der nach ihrer Freischaltung auf den Rechnern der Besucher zur Ausführung kommt. Dies ist besonders kritisch bei Wordpress-Installationen, auf denen keine Moderation erfolgt und Kommentare automatisch freigeschaltet werden. Ein unregistrierter Nutzer könnte sich auf diese Weise möglicherweise administrativen Zugang zum Blog verschaffen, wenn die manipulierten Kommentare von einem eingeloggten Administrator gelesen werden.

    Weiterhin lassen sich aufgrund fehlender Sicherheitsabfragen diverse PHP-Skripte von Wordpress direkt aufrufen. Häufig kommt es dabei, wie beispielsweise bei der Datei wp-includes/default-filters.php, zu einer Fehlermeldung, die den vollständigen Pfad der Wordpress-Installation im Dateisystem des Servers enthält. Unter Umständen lassen sich mit dieser Information weitere Angriffe gegen das Blog-System oder den Server realisieren. Darüber hinaus wird in dem Advisory ein frei zugängliches Directory-Listing beim Aufruf des Verzeichnisses wp-includes/ bemängelt, was jedoch als unkritisch eingestuft wird.

    Die Fehler wurden in Wordpress 2.0.1 nachgewiesen. Laut Advisory sind auch alle älteren Versionen davon betroffen. Ein offizieller Patch ist bislang nicht verfügbar, doch in dem Advisory wird zur Behebung der XSS-Lücke empfohlen, die vier Aufrufe der Funktion trim() in der Datei wp-comments-post.php von Wordpress 2.0 durch htmlentities(trim()) zu ersetzen, um die erforderliche Filterung nachzurüsten. Direkt ausführbare PHP-Skripte lassen sich demnach durch ein vorangestelltes if (eregi('Name-des-Skripts-eintragen.php', $_SERVER['PHP_SELF'])) die('You are not allowed to see this page directly'); gegen direkten Aufruf sichern. Bis zum Erscheinen einer gepatchten Version kommt als möglicher Workaround gegen XSS-Angriffe die gewissenhafte Moderation sämtlicher Kommentare infrage.

    http://www.heise.de/newsticker/meldung/70263

    http://neosecurityteam.net/index.php?action=advisories&id=17

    • Anzeige

    Hallo!

    Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

    • ✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
    • ✔️ Deutsche Server & DSGVO-konform
    • ✔️ Persönlicher Support (kein 0815-Ticket-System)

    Mehr erfahren

  • Der Workaround wird ja im Artikel genannt: htmlentities(trim()). Oder eben alle Kommentare erstmal prüfen und dann erst freigeben.

    Das mit den fehlenden htmlentities() halte ich ja für eine dicken Hund. Wer macht denn solche Anfängerfehler.

    Gruß, The Dude

  • Zitat von TheDude

    Der Workaround wird ja im Artikel genannt: htmlentities(trim()). Oder eben alle Kommentare erstmal prüfen und dann erst freigeben.

    Das mit den fehlenden htmlentities() halte ich ja für eine dicken Hund. Wer macht denn solche Anfängerfehler.

    Gruß, The Dude

    bin kein hacker / programmierer. deshalb waere ein genaue anleitung in welcher datei man was genau veraendern muss von vorteil.

  • Zitat von blodvitne

    bin kein hacker / programmierer. deshalb waere ein genaue anleitung in welcher datei man was genau veraendern muss von vorteil.

    Ist doch alles genau beschrieben:

    Zitat von KiNGU

    die vier Aufrufe der Funktion trim() in der Datei wp-comments-post.php von Wordpress 2.0 durch htmlentities(trim()) zu ersetzen

  • Zitat von KiNGU

    Ein offizieller Patch ist bislang nicht verfügbar, doch in dem Advisory wird zur Behebung der XSS-Lücke empfohlen, die vier Aufrufe der Funktion trim() in der Datei wp-comments-post.php von Wordpress 2.0 durch htmlentities(trim()) zu ersetzen, um die erforderliche Filterung nachzurüsten.


    Frage: "Macht der Workaround in der Form wirklich Sinn?" Ich habe leider nicht so die Ahnung davon, im Heise-Forum habe ich allerdings gelesen, dass bei Anwendung der Änderungen keine Links in den Kommentaren mehr möglich sind. Das wiederum wäre natürlich auch nicht so schön.

  • Zitat von web-junkies

    Frage: "Macht der Workaround in der Form wirklich Sinn?" Ich habe leider nicht so die Ahnung davon, im Heise-Forum habe ich allerdings gelesen, dass bei Anwendung der Änderungen keine Links in den Kommentaren mehr möglich sind. Das wiederum wäre natürlich auch nicht so schön.

    Du kannst dann gar nichts mehr mit html designen,

    da steht dann alles im Kommentar so wie Du es im Quelltext siehst,

    nötig...

    ich als Admin darf ein Script ausführen und das ist eine Sicherheitslücke,
    halten die uns Admins für derart doof, dass wir nicht wissen was wir tun?

    lg

  • Zitat von TheDude

    Der Workaround wird ja im Artikel genannt: htmlentities(trim()). Oder eben alle Kommentare erstmal prüfen und dann erst freigeben.

    Das mit den fehlenden htmlentities() halte ich ja für eine dicken Hund. Wer macht denn solche Anfängerfehler.

    Gruß, The Dude

    ist schon ein doofer Anfängerfehler, wenn man in einem Kommentar eine URL anzeigen lassen darf ;);)

    lg

  • Zitat von Monika

    Du kannst dann gar nichts mehr mit html designen,

    da steht dann alles im Kommentar so wie Du es im Quelltext siehst,

    nötig...

    ich als Admin darf ein Script ausführen und das ist eine Sicherheitslücke,
    halten die uns Admins für derart doof, dass wir nicht wissen was wir tun?

    lg

    Es gibt sogar eine noch größer Sicherheitslücke. Der Admin kann per FTP den gesamten WordPress Ordner und über phpmyadmin auch noch die Datenbank löschen. Das sollte drigend gepatcht werden (via Handamputation oder ähnliches).

    ;-)

    Ok, noch mal sachlich: Der von olaf verlinkte Artikel klärt sachlich darüber auf, dass die "Sicherheitslücken" keine sind. Wie schon so oft kann man daraus lernen, dass es nicht hilfreich ist, bei jeder Meldung sofort in Panik zu verfallen

  • Zitat von Monika

    ist schon ein doofer Anfängerfehler, wenn man in einem Kommentar eine URL anzeigen lassen darf ;);)

    lg

    Solange es eine URL ist oder sonst ein bewusst erlaubtes Tag ist ja alles OK. Ich habe aber schon genug Skripte gesehen, die POST-Daten einfach an einen MySQL INSERT weitergeben und dann aus der DB ungeprüft in die HTML Seite ausgeben. Gib mal bei so manchem Gästebuch <!-- in's Formular ein, drück auf submit und schau dir die Seite an ... ;)

  • Zitat von Monika

    Du kannst dann gar nichts mehr mit html designen,

    da steht dann alles im Kommentar so wie Du es im Quelltext siehst,

    nötig...

    ich als Admin darf ein Script ausführen und das ist eine Sicherheitslücke,
    halten die uns Admins für derart doof, dass wir nicht wissen was wir tun?

    lg

    nicht jeder der einen wordpress betreibt ist serveradmin, unixguru und sicherheitsexperte. oder etwa doch?

  • Endgueltiger Patch verfuegbar!

    Jetzt gibt es einen kumulativen Patch, der alle sicherheitsbedenklichen PHP-Files patcht. Der Autor hat seine Website anscheinend selbst damit gepatcht. Habe selbst gerade die im Patch enthaltenen Dateien (18) in meine WordPress 2.0.1 Installation eingespielt, geht einwandfrei!!!

    Der Link zum Patch:

    http://www.stellwag.us/2006/03/02/sic…r-in-wordpress/

    Der direkte Link:

    (Wurde entfernt, da der Autor dies nicht mag :(!)

    LG

    ricci007

    [FONT=Courier New][size=8][COLOR=Gray]wHaT yOu HaCk Is WhAt YoU gEt :cool:[/COLOR][/SIZE][/FONT]

    Einmal editiert, zuletzt von ricci007 (2. März 2006 um 19:42)

  • Patchen erzeugt Umlaut-Probleme!

    die vier Aufrufe der Funktion trim() in der Datei wp-comments-post.php von Wordpress 2.0.1 durch htmlentities(trim()) zu ersetzen, führt dazu, das die Umlaute zerhackt dargestellt werden. Leider hilft dabei das o42-Umlau-Plugin auch nicht mehr...

  • Joa, Problem wurde behoben. Des ging mal schnell :rolleyes:.

    LG

    ricci007

    [FONT=Courier New][size=8][COLOR=Gray]wHaT yOu HaCk Is WhAt YoU gEt :cool:[/COLOR][/SIZE][/FONT]

  • Wenn der Link nicht angegeben werden soll, hier die Korrektur:
    In der wp-comment-post.php muss es so eingegeben werden:
    1. $comment_author = htmlspecialchars(trim($_POST[’author’]));
    2. $comment_author_email = htmlspecialchars(trim($_POST[’email’]));
    3. $comment_author_url = htmlspecialchars(trim($_POST[’url’]));
    4. $comment_content = htmlspecialchars(trim($_POST[’comment’]));

    Patch kann auch bei mir runtergeladen werden!

  • ...ich probier`s nochmal, anscheinend lesen einige den Beitrag nicht von Anfang an!

    Es gibt kein massives Sicherheitsproblem!

    XSS ist nur als eingeloggter Administrator möglich, das ist natürlich völliger Unsinn, da man als eingeloggter Admin so ziemlich alles machen kann.

    Ja, das ist ein Bug. Nein, das ist kein Sicherheitsproblem!

    Einmal editiert, zuletzt von Olaf (2. März 2006 um 22:03)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!