Wordpress gehackt, alles gelöscht trotzdem Abuse-Hinweise

Hast du auch mal die Datenbank nach Schadcode durchsucht?

Vielleicht kann es sein das ein crontab von PHP im userspace angelegt wurde, dieser wurde dann nur in Plesk aufgelistet.

Nur so als Idee.

Solange es verschiedene Passwörter sind, wäre es ja eher unwahrscheinlich das der "Plesk User" zusätzlich kompromittiert wurde.

Sorry liebe Leute. Da regen sich Leute auf die m E. von den Systemen die Sie betreuen keine Ahnung haben. Es wird für eine Business kritische Webseite auf ein shared Hosting Angebot gesetzt und als CMS Wordpress. Bei wem es bis jetzt noch nicht geklingelt hat der sollte den Job wechseln

Zitat von monotron

Ja, dass Problem ist aber, bist du im CCP, kannst du einfach auf "Autologin Web" klicken und bist im Plesk, ohne dein Plesk-Passwort einzugeben. Anders ist es im Plesk, da kannst du dich direkt einloggen, aber ohne Zugriff auf das CCP.

Das spielt doch keine Rolle.. Ist nur meine Vermutung.

Je nach Plesk Konfiguration kann der PHP-User eine User-Cron Datei im Hosting ablegen. (Fiel mir bei /bin/psa/chrootsh in der Email ein)

Also je nach Plesk (Habe kein Hosting bei Netcup, keine ahnung) brauchst du für die Plesk-Aufgaben keinen einzigen Login, sondern kannst eine "~/.crontab oder so" Datei anlegen. bzw. auch ein "crontab -e" in der Shell.. Das sieht man dann als Aufgabe/Plan im Pleskpanel

Also bräuchte man für die Aufgaben im Plesk Panel garkeinen Login, sondern lediglich ein ausführbares PHP Script im Userspace was durch einen Wordpress Hack erfolgt.

Die Hackerbots sinds so intelligent, das sie eine Shell erkennen und PHP nutzen und sich immer quer kopieren, entwerder der Cron das Script, oder das Script den Cron..

Zitat von Ganzjahresgriller

Sorry liebe Leute. Da regen sich Leute auf die m E. von den Systemen die Sie betreuen keine Ahnung haben. Es wird für eine Business kritische Webseite auf ein shared Hosting Angebot gesetzt und als CMS Wordpress. Bei wem es bis jetzt noch nicht geklingelt hat der sollte den Job wechseln

Nein! Eine Firmenseite die unter WordPress läuft und dann nicht mal nen Dedicated Server, selbst für kleine Läden die kaum Geld in Webdesign oder Hosting stecken können - du hast Recht. Das ist ein Verbrechen an der Menschheit. Wir schicken in Zukunft alle Kunden nur noch zu den ganz teuren Hostern im Managed Tarif und bauen die Seite mit Typo3. Dann können wir wenigstens für jede Änderung und Update kräftig abkassieren, weil da kaum jemand durchsteigt.

Mit diesem Post bestätigts Du einfach meine Meinung von Dir und Deinen Kentnissen

Zitat von Schupp

Je nach Plesk Konfiguration kann der PHP-User eine User-Cron Datei im Hosting ablegen. (Fiel mir bei /bin/psa/chrootsh in der Email ein)

Also je nach Plesk (Habe kein Hosting bei Netcup, keine ahnung) brauchst du für die Plesk-Aufgaben keinen einzigen Login, sondern kannst eine "~/.crontab oder so" Datei anlegen. bzw. auch ein "crontab -e" in der Shell.. Das sieht man dann als Aufgabe/Plan im Pleskpanel

Also bräuchte man für die Aufgaben im Plesk Panel garkeinen Login, sondern lediglich ein ausführbares PHP Script im Userspace was durch einen Wordpress Hack erfolgt.

Du hast leider teilweise recht!

Über eine .crontab Datei klappt es zwar nicht, egal an welchem Ort. Aber führt man über den Webbenutzer den crontab Befehl aus (z.B. mittels exec() über PHP), kann man alle Cronjobs ersetzen und die tauchen dann auch in Plesk auf! Soeben erfolgreich bei einem Webhosting-Paket getestet, die neuen Cronjobs werden tatsächlich ausgeführt. Ich hätte nicht gedacht, dass Plesk das erlaubt. Damit sind z.B. Limits für die Anzahl der Cronjobs doch komplett hinfällig?

Ich muss meine vorherige Aussage somit korrigieren:

Zitat

Ein Cronjob im Plesk-Panel, bei einem Webhosting-Paket? Gar nicht, sofern der Server nicht als ganzes kompromittiert wurde, was sehr unwahrscheinlich ist.

Es ist doch möglich! Meine Aussage war falsch. Sorry für die Verwirrung monotron

Dennoch, Passwörter ändern und Geräte auf Schadcode testen, schadet in so einem Fall nie.

Zitat von KB19

Sorry für die Verwirrung

äh, eher danke für die verwirrung. das finde ich jedenfalls gut zu wissen.

kann es sein, dass das nur bei webhostings >2000 funktioniert?

weil in obiger abuse-mail X-Cron-Env: <SHELL=/opt/psa/bin/chrootsh> steht und

/opt/ in unserem WH2000SE beispielsweise nicht angelegt ist und auch kein crontab-binary existiert.

plesk standalone scheint ja /opt/ anzulegen [z.b. für php etc.].

Zitat von Olivetti

kann es sein, dass das nur bei webhostings >2000 funktioniert?

weil in obiger abuse-mail X-Cron-Env: <SHELL=/opt/psa/bin/chrootsh> steht und

/opt/ in unserem WH2000SE beispielsweise nicht angelegt ist und auch kein crontab-binary existiert.

plesk standalone scheint ja /opt/ anzulegen [z.b. für php etc.].

Das funktioniert über SSH im Chroot nicht. Das musst Du schon über PHP und den Webserver aufrufen

<?php

/*
// Ersetze Cronjobs mit einer eigenen Datei
$command = "/bin/bash -c 'crontab /var/www/vhosts/hostingXXXXX.YYYYY.netcup.net/tmp/cronjobs.txt' 2>&1";
$output = $result_code = null;

exec($command, $output, $result_code);
var_dump($output, $result_code);
*/

// Liste aktuell hinterlegte Cronjobs auf
$command = "/bin/bash -c 'crontab -l' 2>&1";
$output = $result_code = null;

exec($command, $output, $result_code);
var_dump($output, $result_code);

Zitat von KB19

Das funktioniert über SSH im Chroot nicht. Das musst Du schon über PHP und den Webserver aufrufen

Also ideal für einen Wordpress-Hacker.

Zitat von KB19

$command = "/bin/bash -c 'crontab -l' 2>&1";

hier ist kein crontab weit und breit -> error 500 beim exec(…)

welches webhosting testest du damit?

Zitat von Olivetti

hier ist kein crontab weit und breit -> error 500 beim exec(…)

Bei exec() erhält man normalerweise aber keinen Error 500, wenn der Befehl fehlschlägt. Ich tippe auf eine andere Ursache

Ist exec bei Dir vielleicht in disable_functions enthalten? Was steht im Errorlog? Oder alternativ einmal das am Anfang einfügen:

error_reporting(-1);
ini_set('display_errors', 1);

(Nur schnell am Handy getippt, ungetestet!)

Zitat von Olivetti

welches webhosting testest du damit?

Das war auf einem ncLabs (C2P) Tarif. Ich kann es am Abend aber gerne auch noch auf einem anderen WH testen. (500 P2P oder Spezial Mini)

korrektur: wenn der exec fehlert, dann bringt der nachfolgende var_dump den error 500.

ich schreibs jetzt in ein file, dann steht im file entweder nichts (crontab -l) oder der korrekte user (gegenprobe mit whoami).

du rufst ja auch nur bash -c 'crontab -l' auf, also müsste irgendwo bei dir im filesystem ein crontab rumlungern.

hier habe ich 2 WH2000 und jeweils kein crontab.

<?php

//$command = "/bin/bash -c 'crontab -l' 2>&1 >>tmp.log";
$command = "/bin/bash -c 'whoami' 2>&1 >>tmp.log";
 $output = $retval = null;

var_dump($command, $output, $retval);
    exec($command, $output, $retval)
//var_dump($command, $output, $retval);

?>

Olivetti Ups, da fehlt jeweils ein Semikolon nach dem exec(). Das war ein Copy-Paste-Fehler, weil ich da im Forenbeitrag nochmals umgebaut habe. Ist nun in meinem ursprünglichen Beitrag korrigiert.

haha, ja ich hab's selber übersehen, obwohl ich's oben 'g'scheit' formatiert hab'.

string(40) "/bin/bash -c 'crontab -l' 2>&1 >>tmp.log" array(1) { [0]=> string(28) "no crontab for hostingxxx" } int(1)

Also gibt es den Befehl doch

no crontab for hostingxxx ist eindeutig eine Ausgabe des crontab Befehls. Es gibt halt keine Cronjobs für diesen User, spricht: Leere Crontab-Datei.

es ist ja nicht nur, daß es keine crontab (job file) gibt, es muss ja irgendwo als crontab-binary ausgeführt werden.

das ist schon wirklich seltsam. also woher kommt das?

irgendwo muss wohl noch ein suchpfad im web-(php) angehängt werden oder web-/bin/ ist ein anderes /bin/, als shell-/bin/, mit entsprechend integriertem crontab.

und wenn ich jetzt crontab jobs.txt ausführen würde, werden dann die bisherigen plesk-jobs gelöscht oder wird ergänzt?

ich bin gerade ziemlich unentzückt!

Zitat von Olivetti

das ist schon wirklich seltsam. woher kommt das?

Ich kann Dir nicht ganz folgen?

Zitat von Olivetti

und wenn ich jetzt crontab jobs.txt ausführen würde, werden dann die bisherigen plesk-jobs gelöscht oder wird ergänzt?

Bei mir wurden sie ersetzt. Die Datei muss natürlich ein korrektes Format enthalten, sonst schlägt es fehl.