WP gehackt mit "WSO 2.1 Web Shell by oRb"

Hallo,

mein WP wurde offenbar mit dem "Pharma-Hack" - WSO 2.1 Web Shell by oRb gehackt.

Ich bin durch Zufall drauf gekommen dank dem Update auf WP 3.5. Ich update grundsätzlich immer sofort alle Plugins, Themes (ich habe keine kostenlosen Themes im Einsatz, sondern welche von TF) und WP selbst aktualisiere ich - gottseidank - nie über das Dashboard, sondern via FTP, sonst hätte ich gestern gar nicht rausgefunden, dass sich im Root von WP eine Datei w.php befindet mit dem Inhalt:

<?php
/* WSO 2.1 (Web Shell by oRb) */
$auth_pass = "86a5e06b8e4dceae46df86e4e7bbcd92"; //root 
$color = "#df5";
$default_action = 'FilesMan';
@define('SELF_PATH', __FILE__);

usw. es folgt dann ein langer Schwanz an kryptischem Code.

Google spuckt dann diesen o.g. Hack aus.
Ich hab folgende gute Infos dazu gefunden:

http://www.rudolfmaduro.com/2010/10/30/wor…b-shell-by-orb/

und vor allem wird im folgenden genau erklärt, wie der Hack funktioniert, sich auswirkt und wie man WP überprüft - sehr perfide und nur für Suchmaschinen sichtbar :-(

Ich hab dann mal meine Server-Access-Logs angeschaut von meinem Hoster und darin sind zig Einträge wie (wenn man darin nach "feed" sucht):

107.20.14.57 - - [18/Dec/2012:02:12:07 +0100] "GET /feed/ HTTP/1.1" 302 - "-" "feedzirra http://github.com/pauldix/feedzirra/tree/master"

198.58.103.102 - - [18/Dec/2012:02:21:39 +0100] "GET /feed HTTP/1.1" 302 - "-" "Superfeedr bot/2.0 http://superfeedr.com - Please get in touch if we are polling too hard."

usw.

Wenn man die Kommentare hier so durchliest, können die infizierten Dateien überall vorkommen - also bei mir war es (hoffentlich nur) die "w.php" im Root von WP, bei anderen sind offenbar Pluginordner infiziert.

Ich hab dann meinen Webhoster kontaktiert, aber dem ist dieser Hack nicht bekannt und meint nur, er wäre da überfragt und er "überprüfe" mal meinen Webspace. Offenbar läuft da bei ihnen laut der Server-Access-Log die Kaspersky Internet Security.

Laut dem o.g. Artikel hab ich dann die dort gelisteten Datenbankeinträge gesucht - aber in keiner wp-options meines Blognetzwerks was davon gefunden :(

Ich komme da ohnehin nicht mit, wie da jemand eine Datei ins Rootverzeichnis schmuggeln kann - mein technisches Verständnis hält sich da auch sehr in Grenzen :???:, zumal ich zahlreiche Sicherheitsmechanismen aufgrund aktiv hab:

• ich habe keinen Benutzer "admin", das war das erste, was ich bei der frischen WP-Installation gelöscht habe
• mein wp-admin und meine wp-config.php sind via .htaccess geschützt
• meine wp-config.php liegt eine Verzeichnisebene höher als die WP-Installation
• mein SQL-Präfix ist nicht "wp_"
• ich habe Better WP Security netzwerkweit aktiviert
• ich habe Limit Login Attempts und Antivirus aktiv
• meine Passwörter für SQL, FTP und WP-Login sind ziemlich lang und bestehen aus Zahlen & Buchstaben
• ich update Plugins und auch WP sofort, wenn es ein Update gibt

Uff, ich glaube, mehr kann ich fast nicht tun ...
Trotzdem kommt dieser Hack bei mir rein ...

Ich bekomme via "Limit Login Attemps" auch täglich Mails, dass sich ein Benutzer "admin" versucht einzuloggen - gut, den gibt es bei mir nicht ... aber naja ...

Da ich wie im Artikel beschrieben kaum selbst im Quellcode sehen kann, ob, wie, was gehackt worden ist, sondern das offenbar nur für Suchmaschinen sichtbar ist, bin ich jetzt ziemlich verunsichert, ob ich alles "erwischt" hab zur Bereinigung, was ich noch wie absichern kann, wie ich den Hack wirklich komplett loswerden kann.

Tjaaaa, WP neu aufsetzen :mrgreen:, klar, aber: erstmal hab ich ein ziemlich großes Blognetzwerk mit 4 Sites, uff, da kommt Arbeit zusammen. Und was noch übler ist: ich kann ja nicht sagen, seit wann es gehackt worden ist. Sicherlich macht mein Backup-Plugin alle 3 Tage eine Datenbanksicherung ... aber wenn ich es zurückspiele, kann es ja noch durchaus sein, siehe Artikel, dass darin weiterhin übler Code drin ist - so, welches sollte ich dann zurückspielen ...

Merkwürdig finde ich nur, dass sich zum Thema "WSO 2.1 Web Shell by oRb" so gut wie keine deutschen Artikel finden - und meine Seite ist so dermaßen uninteressant für Google, weil alles noch erst in den Anfängen steckt ... wie die dann "zu mir" kommen, ist schleierhaft.

Hat jemand auch schon Erfahrung mit diesem Hack?
Wie kann ich ihn wirklich komplett und wirkungsvoll eliminieren?
Gibt es irgendwie ein Tool, Plugin, wie man die Datenbank "viren-/malware"-checken kann, bzgl. dieses Hacks? Meine Kenntnisse in Sachen SQL/PhpMyAdmin halten sich sehr in Grenzen.

Bin jetzt überfragt, wie ich dem wieder Herr werden könnte ... Habt ihr Profis Tipps, Ideen, Anregungen?

Danke !!!

P.S.
Ich habe gerade herausgefunden, dass dieser Hack wohl unter dem Stichwort "Pharma Hack" auch in Deutschland bekannter ist als unter "WSO 2.1 Web Shell by oRb":

https://www.google.de/search?q=%22ph…-a&channel=fflb

Jo danke, aber so weit war ich auch schon ;-)

Ich hab da mal recherchier ... 8-)

Es gibt praktisch keine Möglichkeit, diesen "Pharma Hack" zu eliminieren, er gräbt sich zu tief in die Wordpress Files als auch in die Datenbank ein.
Ich werde mein Wordpress und meine Datenbank komplett platt machen - auch kein Datenbank-Backup zurückspielen, weil ich nicht weiß, wann diese Infektion stattgefunden hat.

Aber für die, die es auch trifft - [URL="https://www.google.de/search?q=%22ph…iw=1920&bih=881"]und es sind offenbar viele auch deutschsprachiger Wordpress-Seiten --> [/URL], hab ich hier mal kurz zusammengefasst, damit der nächste, der das Problem auch hat, nicht ewig suchen muss.

Was macht der Pharma-Hack und wie kommt er daher und wie wirkt er sich aus [deutsch]?

Englischer Artikel dazu, der ein paar Lösungsansätze bietet

Englischer Artikel, wo sich der Hack einnistet und was er macht

Gedanken von Rechtsanwalt Ferner zum Pharma-Hack in Sachen Image für den Seitenbetreiber

Man selbst sieht also im eigenen Quellcode diese Infektion NICHT!
Sondern er tritt erst zutage, wenn jemand eure Seite bei Google sucht; hier erscheint dann bei Google nicht eure normale, eigene Seitentitel/-beschreibung, sondern die gehackte.

Ihr selbst könnt das herausfinden, indem ihr die Google-Seite aufruft und im Suchfeld eingebt:

inurl:deine-seite.de cheap viagra or cheap cialis

"deine-seite.de" ersetzt du durch deine Domain, die du prüfen willst.

Obwohl auf meiner Seite alles normal erschien und ich nichts gemerkt hatte, trat sie bei Google so zutage, wenn jemand danach gesucht hatte:

Screenshot: http://i48.tinypic.com/244tyqp.jpg

Wie ich überhaupt drauf kam, hab ich im Eingangsposting oben beschrieben.
Das bedeutet für mich, dass ich an meinem Procedere absolut festhalten werde, Wordpress immer nur via FTP manuell zu updaten, will heißen, wie es in der WP-Doku ja schon unter 3. steht, alte WP-Dateien löschen und durch neue ersetzen, damit man auch schon sicher geht, dass auch alle wirklich geupdated werden. Nur so habe ich sehen können, was sich auf einmal in den Wordpress eigenen Ordner eigentlich noch an "fremdem Kram" tummelt - siehe die oben schon erwähnte dubiose Datei "w.php".

Es lohnt auch ein Blick via FTP auf euren Webserver in den Ordner "log" in die "Access-Logfiles" - da tummeln sich dann allerhand miese Zugriffe.

Nachdem sich der "Pharma-Hack" aber auch wahllos in den verschiedensten Plugin-Ordnern einnistet, überlege ich auch künftig manuelle Plugin-Updates via FTP statt dem Automatismus aus dem Dashboard heraus ... mal sehen ...

Ich habe mich die letzten 2 Tage viel eingelesen in diesen Hack und nachdem viel geschrieben haben, wenn sie gemeint hatten, alle in div. Blogs so beschriebenen Dateien, die infiziert sein könnten, zu eliminieren - und sich dann am Ende das Ding doch noch irgendwo "eingegraben" hatte und wieder "re-aktiviert" hatte, sodass dann doch wieder alles beim Alten war, hab ich mich entschlossen, tabula rasa zu machen. Will heißen: Wordpress plattmachen, Datenbank plattmachen und ... back to the roots ... komplett neu starten: frisches Wordpress, leere Datenbank.

Also zur Fehlerbehebung, was ich aus diversen Blogs jetzt zusammengetragen habe an Empfehlungen:

• Screenshots vom Dashboard -> Plugins machen, damit du weißt, welche du installiert/aktiviert hattest
• Webspace plattmachen: Wordpress löschen, Datenbank killen
• keine kostenlosen Themes von sonst woher als dem WP Rep verwenden
• von deinem Theme die neueste Version holen, wenn du z.B. Premiumthemes hast, die öfter geupdated werden
• den kompletten (!) Pluginordner löschen, nichts sichern - da man nicht sicher gehen kann, ob und wo da infizierte Dateien/Code drin liegen. Alle Plugins neu aus dem Rep holen, keine uralten, die nicht mehr geupdated werden.
• ein Datenbank-Update nur in die künftige, neue Installation zurückspielen, wenn du absolut sicher gehen kannst, dass es eine Sicherung ist, die noch nicht infiziert war!
• als Datenbank-Präfix NICHT "wp_" verwenden, ruhig ein kryptisches, das musst du dir eh nicht merken und ist nur für WP wichtig!
• und dann ... start from the scratch :p

Wenn du alles frisch installiert und eingerichtet hast, lass drüberlaufen, bevor du weitermachst:

• Plugin "Theme Authenticity Checker (TAC)
• Plugin "Theme Check"
• Plugin "Antivirus"
• Plugin "Exploit Scanner"
• wichtig: Plugin "Timthumb Vulnerability Scanner"
• Plugin "Sucuri Security - SiteCheck Malware Scanner"

[COLOR=#ff0000]
Achtung: diese Scanner haben NICHT meinen Pharma-Hack entdeckt!!!![/COLOR]

Bevor du weiter loslegst, informiere dich über das Thema Sicherheit mit WP. Hier ein paar gute Quellen:

• [size=10]Why You Should Never Search For Free WordPress Themes[/SIZE]
• 10 Schritte zum Schutz des Admin-Bereich[size=10]s[/SIZE]
• Auslagern von wp-content
  Ich habe meine wp-content eine Ebene höher, außerhalb der WP-Installation!
• wp-config schützen
• Wordpress-Blog absichern
• Tipps zur Sicherheit von Wordpress
• Wordpress-Security: best practices and free&premium plugins
• Initiative: mehr Sicherheit für Wordpress durch den "Admin"-Schutz

Also:

• den Benutzer "admin" gleich zu Beginn löschen und deinen eigenen, neuen anlegen; den Benutzernamen, mit dem du dich anmeldest, nicht als Nutzernamen im Frontend führen ("Spitzname")!
• sicheres, langes Passwort aus Buchstaben, Zahlen
• nicht das gleiche Passwort für FTP, mySQL-Datenbank und den Wordpress-Login verwenden
• WP und alle Plugins immer regelmäßig updaten
• regelmäßige Theme-, Datenbankupdates
• wp-config, wp-admin etc. mit .htaccess absichern (steht in den eben verlinkten, gut beschriebenen Artikeln)
• wp-config nicht im WP-Verzeichnis lassen
• installiere Sicherheitsplugins wie Bulletproof-Security

Zitat

Why is .htaccess Website Security So Much Better Than Any Other Type of Website Security?
The answer is very simple - .htaccess files are processed first before any other code on your website. In other words, hackers malicious scripts are stopped by BulletProof Security .htaccess files before those scripts even have a chance to reach the php coding in WordPress.

• und installiere und aktiviere netzwerkweit Sicherheitsplugins wie
  
  
  • Better WP Security
  • WP Security Scan
  • Antivirus
  • Limit Login Attempts

  
  

Gerade "Limit Login Attempts" leistet mir gute Dienste - täglich kommen Benachrichtigungsmails, dass wieder versucht worden ist, sich auf meinen Seiten mit "admin" anzumelden. Daher ist es so immens wichtig, den Benutzer "admin" gleich zu Anfang einer WP-Installation zu eliminieren.

Die Liste der Sicherheitsvorkehrungen ließe sich sicherlich weiter verlängern ... einfach mal in den eben verlinkten, sehr hilfreichen Artikeln stöbern für verschiedene Lösungsansätze.

Wo ist die Sicherheitslücke?

Aber am wichtigsten ist natürlich, bevor man also wieder von vorne loslegt, vorher rauszufinden - in der infizierten Umgebung -, wo die Sicherheitslücke war/ist, damit man sie nicht wieder in einer neuen Installation produziert.

In meinem persönlichen Fall meine ich herausgefunden zu haben, dass es womöglich die bekannte Timthumb-Schwachstelle war; und zwar in einem alten Theme, das ich auf einem Blog innerhalb meines Netzwerks auf einer Seite noch installiert habe, die schon seit Monaten im Wartungsmodus ist, weil ich erst meine anderen Websites im Netzwerk bearbeiten wollte und diese nicht so wichtig war - fatal, wie sich herausgestellt hat, wenn man sich dann nicht weiter um das dort installierte Theme kümmert!

Ich habe dann durch das Plugin "Timthumb Vulnerability Scanner" dies herausgefunden für gerade dieses alte Theme. Kann sein, dass sich der Hack dadurch eingeschleust hat, vielleicht auch noch durch andere Lücken, die mir grade nicht bekannt sind: ich hatte vorher nicht den wp-admin-Bereich mit .htacess abgesichert gehabt und meine wp-config lag nicht außerhalb des WP-Verzeichnisses eine Ebene höher ... zum Beispiel.
Fazit: in meiner neuen Installation scanne ich erst einmal wie eben beschrieben, die neuen Themes für mein Blognetzwerk durch.

Offenbar vernachlässigt man die Sicherheit oft im "Blogalltag" - aber gemessen an der Zeit, wo ich jetzt drüber sitze und sitzen werde, alles von Null wieder aufzubauen, ist es ein Klacks, sich vorher über Sicherheit mit WP zu informieren und entsprechende Vorkehrungen zu treffen, zu installieren, einzurichten. Aber man wächst ja mit seinen Aufgaben und Fehlern ;-)

Bereinigung der infizierten Domain bei Google

[COLOR=#b22222]Da ich so schnell jetzt ein neues, leeres WP/Datenbank nicht aus dem Boden stampfen kann, habe ich erst einmal versucht, meine Domain bei Google wieder "sauber" zu bekommen.

Mit dem Pharma-Hack infiziert live bei Google sieht das so aus - obwohl die Seitenbeschreibung auf meiner WP-Seite dies NICHT so anzeigt/eingegeben ist!!

Screenshot: [/COLOR][COLOR=#0000ff]http://i48.tinypic.com/244tyqp.jpg[/COLOR][COLOR=#b22222]

[/COLOR]

1. [COLOR=#b22222]Ich habe dann erstmal auf dem Server bei meinem Webhoster via FTP (Filezilla) außerhalb von Wordpress einen neuen leeren Ordner erstellt[/COLOR]
2. [COLOR=#b22222]In den Confixx-Einstellungen unter "Domains" habe ich diese infizierte Domain nun nicht mehr auf das WP-Verzeichnis zeigen lassen ([/COLOR][COLOR=#0000ff]Info[/COLOR][COLOR=#b22222]), sondern auf diesen neuen leeren Ordner außerhalb der (infizierten) WP-Installation[/COLOR]
3. [COLOR=#b22222]Ich erstellte eine neue index.html-Datei - pro forma erstmal nur mit einem kurzen Body-Text von wegen "... wird gerade überarbeitet" - und WICHTIG: habe die Metatags dort wie gewünscht eingetragen. Dafür gibt's, wenn's brennt, bei Google etliche [/COLOR][COLOR=#0000ff]Metatag-Generatoren[/COLOR][COLOR=#b22222]. Diese dann in den "head"-Bereich der index.html eintragen, mit FTP auf den Server in den leeren Ordner hochladen.[/COLOR]
4. [COLOR=#b22222]Dann bin ich auf dieses [/COLOR][COLOR=#0000ff]Google-Formular[/COLOR][COLOR=#b22222] gegangen, um meine Seite neu "einzureichen", in der Hoffnung, dass sie möglichst schnell von Google gecrawlt wird, um dieses infizierte Suchergebnis zu eliminieren.
   [/COLOR][COLOR=#b22222]Übrigens: in den [/COLOR][COLOR=#0000ff]Webmastertools von Google[/COLOR][COLOR=#b22222] war diese Seite nicht gekennzeichnet von wegen dass Google dort Malware gefunden hätte![/COLOR]
5. [COLOR=#b22222]Abwarten und hoffen :smile: [/COLOR]

Und welch Wunder ... genau 1 Tag später sieht es, wenn ich nach meiner Seite bei Google suche, endlich wieder so aus:

Screenshot: http://i50.tinypic.com/j59irq.jpg

Damit ist zumindest "öffentlich" bei Google nichts mehr vom Hack zu sehen. Bleibt also "nur" noch WP neu aufzusetzen mit einer leeren frischen Datenbank, geänderten Passwörtern für all dies und den o.g. Sicherheitsvorkehrungen.

Auf ein Neues, Weltuntergang und persönliche WP-Apokalypse überstanden ... Prosit neues Wordpress, Prosit Neujahr! :cool:

P.S.
Falls ich was übersehen habe in Sachen Sicherheit, bin jederzeit für weitere Tipps offen.

Nachtrag:

und was mache ich nun mit Wordpress?

• Von der infizierten Installation mache ich mir von jedem Blog des Netzwerks vom Backend aus Screenshots: alle Plugin-Einstellungen, aktive Plugins, Theme-Options, WP eigene Settings etc., damit später das Einrichten in der neuen WP-Installation schneller geht.
• Da ich nicht weiß, wann von meinen 3-tägigen Datenbank-Backups die Infektion stattgefunden hat und welche Backup-Datei ich zurückspielen kann, fange ich wieder bei Null an. Bei großen, umfangreichen Seiten (die meine aber nicht sind) müsste man sich evtl. was anderes einfallen lassen - das übersteigt aber mein technisches Verständnis.
• Ich öffne jeden Artikel im Backend in der HTML-Ansicht (!!!) des Artikel- bzw. Seiten-Editors und mit copy&paste kopiere ich den kompletten Inhalt in ein leeres Notepad++-Dokument (oder andere HTML-Editor), speichere das unter dem Artikeltitel lokal ab.
• Genauso verfahre ich mit allen Seiten: aus der HTML-Ansicht des Editors rauskopieren in leeres Dokment, speichern unter Seitentitel, damit man es später leichter findet zum Reinkopieren in die neue WP-Installation in eine neue leere Seite.
  [COLOR=#ff0000]Hintergrund: durch das copy&paste aus der [/COLOR][COLOR=#40e0d0]HTML-Ansicht des WP-Editors[/COLOR][COLOR=#ff0000] im Backend heraus, habe ich auch alle CSS-Styles, Quicktags, Shortcodes, die ich so verwendet habe, gleich in der Kopie mit drin und brauche später in eine leere Artikelseite das nur 1:1 wieder reinkopieren, evtl. Bilder(pfade) anpassen, Bilder hochladen - fertig. [/COLOR]

[COLOR=#ff0000]

[/COLOR][COLOR=#000000]In diesem Sinne ... frohe Weihnachten euch allen :-D
Birgit[/COLOR][COLOR=#ff0000]
[/COLOR]

Das erledigen die Security Plugins - siehe oben - ganz gut:

http://wordpress.org/extend/plugins…ty/screenshots/

listet einem das gnadenlos auf. Ich habe aber trotzdem jetzt noch zusätzlich http://wordpress.org/extend/plugins/bulletproof-security/ installiert, weil für mich der Ansatz hier sehr schlüssig erscheint:

Zitat

Why is .htaccess Website Security So Much Better Than Any Other Type of Website Security?

The answer is very simple - .htaccess files are processed first before any other code on your website. In other words, hackers malicious scripts are stopped by BulletProof Security .htaccess files before those scripts even have a chance to reach the php coding in WordPress. BulletProof Security uses .htaccess website security files, which are specific to Apache Linux Servers. Please read the FAQ page for Server compatibility questions.