SOS - Google-Suchergebnis leitet auf Scamming-Webseite um

[fusch]

Liebes Forum,

ich hoffe, jemand von Euch kennt das Phänomen und weiß, wie es zu lösen ist:

Wenn ich über die Google- oder Bing-Suche auf die Webseite […] gehe, werde ich zu einer bösartigen Scamming-Website umgeleitet.
Rufe ich die Domain direkt auf […] passiert das nicht.

Da ich gerade im Urlaub bin (warum passiert das eigentlich immer in dieser einen Woche im August??), habe ich nur eine rudimentäre technische Ausstattung dabei und auch nicht alle Passwörter griffbereit. Ich komme ins Backend, habe aber keine Möglichkeit per SSH zuzugreifen oder in den Manager zu gelangen. Auch auf die Zugangsdaten des Providers habe ich gerade keinen Zugriff.

Danke für Eure Antworten schon mal im Voraus.

Liebe Grüße
Hella

P.S.: Auch für den […] und den […], die in der gleichen Contao-Installation liegen, tritt dieses Phänomen auf. Es ist also naheliegend, dass tatsächlich Contao gehackt wurde.

[mlweb]

Muss ja nicht Contao sein. Könnte auch der Account beim Provider sein.

Edit: Die Installationen sind auf dem aktuellen Stand?

[lbableck]

Wenn der Referrer google.com ist kommt folgendes als Antwort vom Server zurück

Da Contao-typische Header bei der Antwort fehlen, gehe ich davon aus, dass das nicht über Contao, sondern eher über bspw. .htaccess oder die Serverkonfiguration kommt. Genauer kann man das von außen aber nicht sagen.

[fusch]

Danke Ihr beiden, das ist schon mal ein guter Hinweis. Der Provider konnte nichts finden. Wir versuchen es jetzt mal mit einem Backup und hoffen, dass das ausreicht.

[cch]

Wir haben das gleiche Problem, wie oben beschrieben.

Kann das wirtklich mit Contao zusammenhängen?

Auf welchem Webhoster liegen die betroffenen Websites? Bei uns ist es All-inkl.com

Wäre großartig, wenn jemand weiß, was zu tun ist.

Viele Grüße -
cch

[Spooky]

Da Contao-typische Header bei der Antwort fehlen, gehe ich davon aus, dass das nicht über Contao, sondern eher über bspw. .htaccess oder die Serverkonfiguration kommt. Genauer kann man das von außen aber nicht sagen.

Auch bei einem Request ohne Referrer kommt die Antwort vom nginx - vermutlich ist daher entweder nginx direkt im Einsatz - oder als Reverse Proxy. Der Schadcode selbst kann also nach wie vor in den PHP Dateien selbst sein.

[Spooky]

@fusch @cch evt. hattet ihr in diesen Installationen in der Vergangenheit (oder auch jetzt noch) kein kernel.secret (secret Parameter über die parameters.yml oder APP_SECRET Umgebungsvariable)?

[tab]

Vielleicht mal in die index.php reinschauen. Eventuell ist da die (bedingte) Weiterleitung drin. Ist aber nur ein Schuss in den nicht mal blauen, sondern eher bewölkten Himmel. In jedem Fall muss geklärt werden, durch welches Einfallstor die Hacker reingekommen sind. Sonst kann es ja jederzeit wieder passieren.

[tab]

Auf welchem Webhoster liegen die betroffenen Websites? Bei uns ist es All-inkl.com

Bei @fusch ist es jedenfalls nicht All-Inkl. Der Hoster ist eh kein Geheimnis, nachdem die Domains bekannt sind . Ein Kunde von mir hat dort auch sein Webhostingpaket. Die drei Websites habe ich schon überprüft und sie sind (noch?) nicht betroffen. Die haben auch alle ein "secret" in der parameters.yml.

[cch]

o.k. in unserer parameters.yml steht auch eine Secret-Zeile ... reicht das wohl aus?

Wir haben jetzt die Datei autoload.php unter /vendor als befallen ausgemacht. Da steht ne Menge Mist drin. Diesen entfernt, läuft die Sache bei Google und Co. wieder.

Es bleibt die Frage, wie diese Datei gehackt werden konnte. Das wäre ja sehr wichtig, dieses Lücke zu schließen.

Viele Grüße -
cch

[Spooky]

o.k. in unserer parameters.yml steht auch eine Secret-Zeile ... reicht das wohl aus?

Es bleibt die Frage, wie diese Datei gehackt werden konnte. Das wäre ja sehr wichtig, dieses Lücke zu schließen.

Wenn kein secret in der parameters.yml und kein APP_SECRET in der .env.local eingetragen ist oder war, dann war die Installation auf jeden Fall angreifbar - zumindest bis vor einem der letzten Contao Security Releases.

[cch]

Kann ich das denn im Nachhinein richten?

In der parameters.yml steht wie gesagt eine solche Zeile. Wie komme ich denn an die .env.local? (Bin da nicht so bewandert, kann ich da auch per FTP ran oder wie prüfe ich das?)

Danke für die Hilfe hier!

[Spooky]

Wenn ein secret gesetzt war, dann wurde diese Sicherheitslücke vermutlich nicht ausgenutzt - es sei denn das secret war den Angreifern bekannt.

[Spooky]

@fusch wenn es Contao Security Releases gibt, müsst ihr immer sofort aktualisieren. Eure Contao Installation scheint nicht auf dem Neuesten Stand zu sein.

[cch]

Wenn ein secret gesetzt war, dann wurde diese Sicherheitslücke vermutlich nicht ausgenutzt - es sei denn das secret war den Angreifern bekannt.

Wie kann ich denn jetzt ein Secret richtig sowohl in der parameters.yml, als auch in der .env.local setzen?

Viele Grüße -
cch

[Spooky]

Beides brauchst du nicht. Nur eines von beiden. Oder auf die neueste Contao Version aktualisieren - aber das solltet ihr in jedem Fall machen.

[cch]

Ich wollte nur noch einmal zurückmelden. Bei uns ist eine zweite Website betroffen. Auf dieser war in der .env.local entsprechende Sicherheitsmaßnahme gesetzt.

Auf der heute zu erst erwähnten Website war entsprecehnde Maßnahme in der parameters.yml umgesetzt.

D.h. daran kann es m.E. nicht liegen.

Viele Grüße -
cch

[mlweb]

@cch
Es gibt m.E. viele Möglichkeiten wie so etwas passieren kann. Es muss ja nicht an der Contao-Installation selbst liegen.
Mögliche Ursachen z.B.:

• infizierte lokale Rechner
• Zugriff über FTP (ohne Verschlüsselung)
• gehackte Passwörter aller Art (Contao, Provider, FTP/SFTP)
• Weitergabe von Zugangsdaten über einen nicht sicheren Weg (z.B. E-Mail)
• gehacktes Mail-Postfach mit entsprechend gemailten Passwörtern
• kompromittierte andere Installation auf dem Webspace (z.B. Wordpress oder Joomla ...)

Ihr müsst die Ursache analysieren, alles andere ist m.E. lesen im Kaffeesatz.

Welche Contao-Version ist bei Euch konkret im Einsatz?

[cch]

Welche Contao-Version ist bei Euch konkret im Einsatz?

Eben noch (bei Befall) die 4.13.23 und jetzt die ganz aktuelle 4.13.28

[mlweb]

Damit war die Contao-Version nicht auf dem aktuellen Stand, als der Befall entstanden ist.
Die veröffentlichte Sicherheitslücke könnte also ausgenutzt worden sein.

[mlweb]

Ändern ausnahmslos aller Passwörter und Kontrolle aller Rechner die Zugang zur einer Installation auf Eurem Webspace haben, sollte selbstverständlich sein - unabhängig davon, was im Endeffekt die Ursache ist.

[Birden]

Ist vielleicht in der .htaccess ein Eintrag der da nicht hingehört aber mitgeschleppt wurde?

[cch]

Großer Mist!

Habe mich daran gehalten und nach der Bereinigung des Schadcodes, Contao-Updates (auf jetzt 4.13.28) durchgeführt. Dann die Passwörter zum Webhoster und zu allen FTP-Zugängen und zum CM geändert.

Jetzt, nach ein paar Stunden, ist die eine Website wieder betroffen - Links auf Suchergebnis-Seiten (Google, Bing) werden auf Scam-Website weitergeleitet. (Bei direkter Eingabe der Webadresse geschieht das nicht.)

Was hab ich übersehen? Wer kann helfen?

Viele Grüße -
cch

[Spooky]

Poste mal die URL zur Seite.

[cch]

Poste mal die URL zur Seite.

www.lebensraum-diakonie.de

[cch]

Diesmal wurde der Schadcode in der vendor/composer/autoload_real.php eingeschleust.

Dort hab ich ihn erstmal wieder rausgenommen.

Bis zum nächsten Mal

[mlweb]

Alle Rechner auf Schadcode überprüft, die Zugang zur Installation haben und ggf. vorrübergehend alle Nutzer gesperrt (außer Deinem Zugang)?
Was gibt es noch für andere ggf. auch alte Installationen in dem Paket beim Provider?

[Spooky]

Diesmal wurde der Schadcode in der vendor/composer/autoload_real.php eingeschleust.

Dort hab ich ihn erstmal wieder rausgenommen.

Bis zum nächsten Mal

Ihr müsst auch prüfen, ob irgendwelche zusätzlichen PHP Dateien eingeschleust wurden. Im Speziellen in beliebigen Locations im public/ bzw. web/ Ordner (auch unter Symlinks von dort).

[fusch]

Danke für die Unterstützung hier!
Das secret ist jetzt eingetragen, das Update folgt.

Liebe Grüße
Hella

[Spooky]

Hm, wo habt ihr das Secret eingetragen? Weil die Installation ist noch immer angreifbar.

[ph!L]

Ich habe das Problem heute auch entdeckt, bei einer Contao 4.4.57 (ja, ich weiß, ist alt).

Bei uns war es die vendor/symphony/symphony.php

Bildschirmfoto 2023-08-01 um 15.44.28.png

Wie kann ich bei einer 4.4 die Security mit dem Secret nun herstellen, bis wir auf eine aktuelle Version wechseln können?

[Spooky]

Wie kann ich bei einer 4.4 die Security mit dem Secret nun herstellen, bis wir auf eine aktuelle Version wechseln können?

In der parameters.yml den secret Parameter eintragen (am besten 32 Zeichen), danach den Symfony Application Cache neu aufbauen.

[ph!L]

In der parameters.yml den secret Parameter eintragen (am besten 32 Zeichen), danach den Symfony Application Cache neu aufbauen.

Den Secret kenne ich natürlich aus aktuelleren Versionen, aber da ist er seit Installation selbst drin. Kann ich mir den einfach selbst ausdenken/generieren?

[Spooky]

Ja, mit einem beliebigen (ausreichend guten) Passwort-Generator. Alternativ kannst du die parameters.yml auch löschen und dann über das Install Tool neu anlegen lassen.

[ph!L]

Danke, hat funktioniert.

Für alle anderen: das .yml File verträgt nur Leerzeichen statt Tabs ;-)

Ich beobachte das Thema mal weiter und schaue, ob der Befall aufhört. Alle relevanten Passwörter, mit denen Zugriff auf den Webserver möglich wäre habe ich ebenfalls geändert.

[tab]

Nachdem sich der Schadcode offenbar in unterschiedlichen Dateien befinden kann, vielleicht auch in mehreren, wäre es vielleicht eine Idee, vorsichtshalber auch noch den Opcode- und Composer-Cache zu löschen und die Composer-Abhängigkeiten neu installieren zu lassen im Contao-Manager.

[Spooky]

Man muss grundsätzlich alle PHP Dateien der gesamten Contao Installation prüfen.

[tab]

Es müssen also zumindest die Hashwerte aller PHP-Dateien überprüft werden? Durchsuchen nach der Domain, auf die da weitergeleitet wird, oder nach dem Referer (Google) wird ja nicht reichen. Durch Löschen des Composer Cache und neu herunterladen dürfte man doch wenigstens zahlenmäßig die meisten PHP-Dateien schon erschlagen haben. Die restlichen wird man wohl zumeist selbst erstellt haben und somit durchschauen müssen. Oder wie sieht die effizienteste, sichere Methode zum Überprüfen aller PHP-Dateien aus? Bisher zum Glück nur eine Frage für alle Fälle. Bis jetzt, klopf auf Holz, habe ich noch keine infizierten Installationen gefunden. Zügiges einspielen von Updates lohnt sich wohl doch. Die heutigen Updates kommen heute auch noch dran.

[ph!L]

Es müssen also zumindest die Hashwerte aller PHP-Dateien überprüft werden? Durchsuchen nach der Domain, auf die da weitergeleitet wird, oder nach dem Referer (Google) wird ja nicht reichen. Durch Löschen des Composer Cache und neu herunterladen dürfte man doch wenigstens zahlenmäßig die meisten PHP-Dateien schon erschlagen haben. Die restlichen wird man wohl zumeist selbst erstellt haben und somit durchschauen müssen. Oder wie sieht die effizienteste, sichere Methode zum Überprüfen aller PHP-Dateien aus? Bisher zum Glück nur eine Frage für alle Fälle. Bis jetzt, klopf auf Holz, habe ich noch keine infizierten Installationen gefunden. Zügiges einspielen von Updates lohnt sich wohl doch. Die heutigen Updates kommen heute auch noch dran.

So wie ich das sehe, betrifft das nicht nur google als Referer, sondern alle Aufrufe mit Referer. Ziemlich clever.

Habe weiter oben einen Screenshot mit einem Beispiel gepostet.

[Ratatöskr]

Guten Morgen,

unsere Agentur ist ebenfalls vom selben Angreifer vom 31.07 betroffen. Wir hatten bereits Ende Juni den selben Schadcode, damals in einer Mail.php Datei.
Deswegen haben wir ein neues APP_SECRET (sogar 64 Zeichen lang + Sonderzeichen) generiert. Das APP_SECRET liegt bei uns in der .env.local Datei, was ja angeblich der sicherste Ort dafür sein soll.
Dennoch wurden wir am 31.07 wieder Opfer desselben Angriffs. Bei uns wurde der Schadcode dieses mal in die autoloader.php Datei injiziert.
Nach dem letzten Angriff hatten wir alle Benutzer-Passwörter resettet, 2FA hinzugefügt, FTP-Zugänge resettet usw. Dennoch ist es dem Angreifer wieder gelungen, seinen Code zu platzieren. Scheinbar sind einige Contao-Installationen davon betroffen, welche ich hier allerdings aus Sicherheitsgründen nicht nennen möchte.
Wir vermuten eine unbekannte Sicherheitslücke im Contao CMS, welche ausgenutzt werden kann, um Schade-PHP-Code zu injizieren.

Der Schadecode beginnt immer mit den folgenden Kommentaren:

//Don't delete me, thank you! I love you! 

Wir haben jetzt nochmal die letzten Updates für Contao 4.13 eingespielt und unsere PHP Version aktualisiert. Hat sonst noch jemand Ideen was man machen könnte?

Vielleicht auch interessant: unser Stage-Environment wurde nicht betroffen, da es via Robots.txt nicht für Suchmaschinen sichtbar ist. Scheinbar hat der Angreifer also unsere Website nur anhand SEO Indizierungen ausgewählt. Eventuell ein so genannter Pharmacy Hack?