Beiträge von hakre

  • Individuelle Artikel auf der Blogseiten

    Probiere mal mit einer Oder-Verknüpfung (statt Und):

    PHP
    if( is_home() || is_paged() )

    damit würde dann allerdings auf allen seiten (!) mit listungen nach modifziert statt nach angelegt soriert werden. Ausrufezeichen nur für den Fall, dass Du das genau _nicht_ willst.

  • Gibts ne Lücke?

    Der Fix in patchset 8495 von #6871 greift nicht bei Angriffen, die Dateien in das Plugin Verzeichniss einschleusen. Genau diesen Fall beschreibt der Bericht in Sebbis Blog. Zitat: "SK2/sk2_plugins/sk2_referrer_check_plugin_02092008.cache", es wird also trotz dem "Fix" weiter munter injected.

    Dies steht im Widerspruch zur Aussage von codestyling, dass die "Unsichtbarkeit eingeschleuster Plugins [...] behoben worden [sei]".

    Im Gegenteil, die Sichtbarkeit von allen aktiven Plugins stellt die Pluginseite gar nicht da, die Routine zum auslesen aller Plugins setzt beim Dateisystem an (und zwar unvollständig), beim Einladen der Plugins wiederum wird eine andere Routine verwendet, die direkt auf den Optionen aufbaut.

    Ferner hat dies nichts mit einem bestimmten Plugin zu tun (ich denke auch hier liegt codestyling daneben) sondern lediglich damit, das der Schadcode in ein bereits bestehendes Plugin Verzeichnis injeziert werden muss, um den Fix aus #6871 zu übergehen.

  • Gibts ne Lücke?

    Ja, dass sieht ganz so aus. Ich bin noch nicht ganz durch (dort sind noch weitere Forum Posts verlinkt) aber es sieht ganz so aus, dass (auch in WP 2.7) Dateien von Remote aus auf den Server hochgeladen und ausgeführt werden können.

    Das Ziel scheint das Plugin-Verzeichnis zu sein. Empfehlenswert dürfte sein, nach der (sauberen) Installation der eigenen Plugins, das Verzeichnis auf Schreibgeschützt zu setzen. Den PHP Errorlog beobachten, ob hier versucht wird Dateien anzulegen.

    Bei WordPress genrell empfehlenswert ist der Betrieb mit Suhosin. Das ist eine PHP Erweiterung die bei einigen Problemen, die aus veraltetem PHP Code resultieren, helfen kann (nicht muss!). Es ist generell empfehlenswert, bei PHP Anwendungen mit alter Codebasis (u.a. auch bei WordPress der Fall) diese nur unter Suhosin zu betreiben. Daran lässt sich meiner Meinung auch ein Hoster messen: Ob er Suhosin mit anbietet (besser) oder nicht (nicht besser).

    Anmerkung:

    Ein Problem scheint zu sein, dass Wordpress nicht alle aktivierten Plugins anzeigt. Der Angreifer hat sich hier zu Nutze gemacht, dass Plugins in Unterverzeichnisse von bereits bestehenden Plugins kopiert werden können und Wordpress diese _nicht_ als aktiv Anzeigt. Der Admin ist also Blind. Da sollte der WordPress Kern nachgebessert werden, so dass wenigstens sämtliche aktive Plugins gelistet werden.

    Anmerkung 2:

    Die Lücke gibts, sie ist bekannt:
    #6871 (Plugins without headers don't show in the plugins page, keeping some exploits hidden) ? WordPress Trac (seit 10 Monaten publik)
    #5564 (Non Plugin Files Cab Be Easily Included In Current Plugins using database Manipulation) ? WordPress Trac (seit 14 Monaten publik)

    Die Frage ist nur, wie ein sinnvoller Schutz davor in WordPress aussehen kann. Natürlich wäre es schön, wenn hier auf verschiedene Ebenen was laufen würde (zB. bevor überhaupt eine Datei durch einen Angreifer mit WordPress auf den Server hochgeladen werden wird) allerdings sollte zumindest für den Admin die möglichkeit bestehen, die aktuelle Konfiguration im Backend einsehen zu können.

  • Passwörter übernehmen

    Wordpress verschlüsselt keine Passwörter sondern es werden sog. Hasches gebildet (eben dieses MD5). Das Funktioniert so:


    1. Wird ein neuer User angelegt, so wird die Passwortvorgabe genommen und ein Hash davon gebildet.
    2. Dieser Hash wird in der Datenbank hinterlegt.
    3. Logt sich nun ein User ein, so wird die Passworteingabe genommen, auch wieder ein Hash davon gebildet und dieser dann mit dem Hash in der Datenbank abgeglichen.

    Sollen nun für die User sich die Passwörter nicht ändern, so müssen entweder das alte und das neue Programm auf identische Art und Weise bilden. Zwar nutzen beide Probramme MD5 allerdings verwenden sie vielleicht unterschiedliche "Salts" und somit könnte es trotz MD5 nicht klappen.

    Die Frage, wie WordPress das nun macht kann man im Quellcode des Programmes herausbekommen. Hier gibt es unterschiedliche Arten bei den WordPress Versionen. Um welche WordPress Version gehts den hier?

  • Doppelcontent

    Doppelter Content wird als Problem masslos überschätzt. In der Regel lohnt die Mühe nicht sich damit zu beschäftigen.

    Viele der Prüftools bauen allerdings auf die Angst der User vor "Suchmaschienen Problemen" und lassen dann mit der ganz, ganz schlimmen Diagnose "doppelter Content" (Hui! Das ja hart!) den User im Regen stehen.

    Wenn es sich hier um ein ernstes Problem handeln sollte, bitte immer mit angeben, wie doppelter Content ermittelt wurde (Methodik, Tools etc.) und auch natürlich der Blog. Viele der Fragen lassen sich nicht pauschal beantworten und per Plugin per-se auflösen.

  • Videos einbinden

    Die Datei mittels einem Link verlinken. Jede Datei, die Du auf deinen Server hochlädst hat eine eigene Adresse in Form einer URL. Diese Adresse verwendest Du entwerde direkt (einfach einfügen) oder Du nutzt sie als ein Link und kannst dabei noch einen Titel verwenden.