SOS - Google-Suchergebnis leitet auf Scamming-Webseite um

[Ratatöskr]

Wir haben noch zwei Files gefunden, die ebenfalls kompromittiert erscheinen:
web/share/img.php
web/system/about.php

Ich kann diese Files nicht im Contao Source finden und sie enthalten beide Code-Snippets die sich auf den selben Request beziehen. Interessanterweise liegen diese Files schon seit Mai auf dem Server.

[Spooky]

Evt. hattet ihr bspw. im Mai kein Secret?

[Ratatöskr]

Wir hatten auch im Mai schon ein APP_SECRET in der .env.local, allerdings 32 Zeichen lang und wir hatten es vorher noch nie geändert. War also noch das initiale von Contao 4

[lucina]

Vielleicht mal den Server komplett durchsuchen?

find / -exec grep -l "Don't delete me, thank you! I love you!" {} ;

[cch]

Vielleicht mal den Server komplett durchsuchen?

find / -exec grep -l “Don't delete me, thank you! I love you!” {} ;

Ah, super Sache. Bei mir erscheint bei Eingabe der Zeile allerdings immer "find: missing argument to `-exec'". Könntest Du einem Laien erklären, was ich anders eingeben muss?

Viele Grüße -
cch

[swinde]

Hallo.

Ich hatte gestern auch so einen Fall! In der parameters.yml war definitiv eine secret vorhanden!

Ich habe die Seite über eine Subdomain mit der aktuellen Contaoversion neu installiert und dann die Plugins und das Theme aus der Sicherung eingefügt.
Das ging schneller als die alte Installation nach eingeschleusten Dateien zu durchsuchen!

Steffen Winde

[mlweb]

Ihr müsst alle schauen wie die Sachen eingeschleust worden sind bzw. ob auf dem Server noch etwas verseuchtes vorhanden ist, sonst ist es vorprogrammiert, dass der Angreifer wieder zuschlagen kann. Wenn ein Angreifer einmal Zugriff hatte, baut er sich in der Regel Hintertüren ein um nach einer Säuberung wieder Zugriff zu bekommen. Dann nutzt M.E. auch eine jetzt sichere Contao-Version nichts.

[derRenner]

Bei mir erscheint bei Eingabe der Zeile allerdings immer "find: missing argument to `-exec'".

der -exec-Schalter im find-Befehl benötigt - zumindest bei mir unter Putty - ein Ende gekennzeichnet, also ein '\'.

find / -exec grep -l "Don't delete me, thank you! I love you!" {} \;

wenn du ab einem Verzeichnis prüfen möchtest ... ist ja doch eine sehr lange Prozedur - dann:

find /path/to/my/folder/ -exec grep -l "Don't delete me, thank you! I love you!" {} \;

[Ratatöskr]

Ja, das ist jetzt die Herausforderung, die Backdoor zu finden.
Eine Volltextsuche auf weitere Code-Stellen auf das Kommentar oder auf "nsikun" hat nichts mehr gefunden.
Es gibt allerdings ziemlich viele Möglichkeiten.. eine Dependency könnte von einer "Arbitrary Code Execution"-Sicherheitslücke betroffen sein. Oder es gibt ein Kontaktformular mit Injection-Möglichkeiten.
Oder es ist ein Symfony-Bug der ausgenutzt wird. Allerdings würde ich eher auf eine noch unbekannte Sicherheitslücke bei Contao spekulieren, da es schon in der Vergangenheit "Arbitrary Code Execution"-CVEs gab und auch einige große Contao Seiten betroffen sind.

[ConZens]

Auch bei mir eine infizierte Seite. Die img.php war wie oben beschrieben auch dabei, dann noch eine new.php, news.php und function.php. Laut Google-Konsole wurde die Seite (eigentlich eine kleine regionale deutsche Seite) im letzten Monat übrigens hauptsächlich aus Indonesien und Malaysia besucht. WTF und reichlich Metadaten der verschiedenen Unterseiten verändert. Wie kriegt man den Müll auf die Schnelle wieder aus google entfernt?

[Ratatöskr]

Es gibt die Möglichkeit zumindest bei Google über die SEO-Konsole Seiten aus dem Index zu löschen oder zu sperren.
Wenn der Schadcode entfernt wurde, sollten außerdem die Seiten beim nächsten Crawlen 404 zurückliefern und die Einträge aus dem Suchmaschinen-Index wieder entfernt werden.

Interessant ist auch, dass die Indizierungen nur durch Backlinks zustande kommen. Die Sitemap der gehackten Website ist zumindest bei uns nicht kompromittiert

[ConZens]

Uuuihhhh. Laut google Konsole wurden bei meiner Seite über 700.000 neue Scam Seiten indexiert. Ein Großteil der indexierten Seiten bzw. URLs sieht dann so aus: domain.de/?bloedsinniger-text-mit-immer-neuen-varianten und leiten böderweise auf meine Startseite weiter, erzeugen also keinen 404 Fehler. Hat jemand einen Tipp wie ich das angehen kann?

[Spooky]

Uuuihhhh. Laut google Konsole wurden bei meiner Seite über 700.000 neue Scam Seiten indexiert. Ein Großteil der indexierten Seiten bzw. URLs sieht dann so aus: domain.de?bloedsinniger-text-mit-immer-neuen-varianten und leiten böderweise auf meine Startseite weiter, erzeugen also keinen 404 Fehler. Hat jemand einen Tipp wie ich das angehen kann?

In Contao 4.13 kannst du den Canonical Tag aktivieren. Somit würden solche URLs dann nicht mehr indiziert werden.

[ConZens]

Danke Spooky, die Erweiterung habe ich gleich installiert und die Seiten entsprechend angepasst.

BG

[Spooky]

Was meinst du mit Erweiterung?

[ConZens]

Die rel_canonical Erweiterung von Christian Barkowsky. Meine Seite läuft noch mit contao 4.9.

[lex83]

Ich wollte nur mal einbauen, dass auch Wordpress betroffen ist (oder server wo das liegt). Mache selber kein Wordpress, aber sollte das fixen vor wenigen Wochen. Die Weiterleitungen von Google und co. zu scammseiten kommen meist über eine sitemap (auch wenn mehr php und js Daten kompromitiert sind). Also in Contao mal schauen ob in Sitemap-Ordnern eine PHP datei ist die da nicht hingehört.
Ansonsten bleibt leider nur das neuaufsetzen (was ja recht einfach ist) weil ich alleine in Wordpress 30+ scam Datein gefischt habe mit "Don't delete me, thank you! I love you!".

[ConZens]

Uuuihhhh. Laut google Konsole wurden bei meiner Seite über 700.000 neue Scam Seiten indexiert. Ein Großteil der indexierten Seiten bzw. URLs sieht dann so aus: domain.de/?bloedsinniger-text-mit-immer-neuen-varianten und leiten blöderweise auf meine Startseite weiter, erzeugen also keinen 404 Fehler. Hat jemand einen Tipp wie ich das angehen kann?

Nachtrag: mittlerweile sind es (nur noch) ca. 100.000 statt über 700.000 Scamseiten, der Tipp von Spooky mit dem Canonical hat also auf jeden Fall etwas bewirkt.

Gibt es denn vielleicht per htaccess noch eine weitere Möglichkeit?

Ich müsste die gefakten URL-Links auf meine Startseite: https//www.domain.de/?bloedsinniger-text-mit-immer-neuen-varianten alle auf eine 404 Seite weiterleiten, damit da irgendwann mal der Müll komplett aus dem Index verschwindet.

Stichwort ist da ja "Query String". Aber wie kann ich alle https//www.domain.de/?bloedsinniger-text-mit-immer-neuen-varianten URLs auf eine page-not-found Seite weiterleiten?

Weiß jemand Rat?

Vielen Dank schon mal.

[tab]

Ist denn die Ursache überhaupt schon beseitigt, also die gehackte Installation bereinigt?

[ConZens]

Ja, die sollte jetzt save sein.

[Spooky]

Du könntest https://extensions.contao.org/?q=hof...get-parameters nutzen - aber Vorsicht: man sollte es nicht übertreiben damit.

[ConZens]

Hi Spooky,

gibt es denn keine Möglichkeit das per htaccess zu lösen?

Nachtrag: wegen der 100.000 Scamseiten … die URLs werden ja mittlerweile nicht mehr auf andere Seiten verlinkt, das ist ja behoben. Da habe ich mich falsch ausgedrückt. Es geht mir nur darum, dass die indexierten Seiten mit den angehängten Parametern und den gefakten Metadaten aus den Suchmaschinen verschwinden.

[Spooky]

gibt es denn keine Möglichkeit das per htaccess zu lösen?

Vermutlich schon, also eine RewriteRule auf die Query Parameter.

[ConZens]

Vermutlich schon, also eine RewriteRule auf die Query Parameter.

Ja genau so etwas suche ich. Hab einiges ausprobiert aber irgendwie blicke ich da nicht durch und es funktioniert bisher nichts.

Aber wie müsste der htaccess-Code dafür sein?

https//www.domain.de/?bloedsinniger-text-mit-immer-neuen-varianten ( << davon gibt es dann ca. 100.000 Varianten !)

weiterleiten zu

https//www.domain.de/page-not-found.html

[Schneetiger]

@Ratatöskr,

was ist denn ein sog. Pharmacy Hack? Den Ausdruck habe ich noch nie gehört.

Kann ich irgendwo nachlesen, wie ich die "robots.txt" absichern kann? Ich dachte, die könnten wir mit Contao 4 vernachlässigen oder bin ich da komplett auf dem Holzweg unterwegs?

LG
Schneetiger

[Spooky]

Was willst du in der robots.txt absichern?

[Schneetiger]

@spooky,

war offensichtlich eine blöde Frage, die ich einfach aufgegriffen habe.

Ich habe mich damit schon länger nicht mehr beschäftigt, aber wenn ich das noch richtig im Kopf habe, kann ich solche Sicherheitsprobleme, wie eben geschildert, sicherlich nicht mit einer "robots.txt" lösen. Die Lösungen sind ja bereits genannt worden; bin offensichtlich aktuell nicht davon betroffen :-).

Vergiss die Frage einfach; ich werde mich mal selbst in dieses Thema zur Auffrischung der Kenntnisse einlesen. Jedenfalls danke für die Rückfrage.

LG
Schneetiger

[Spooky]

Über die robots.txt kannst du Google auch mitteilen gewisse Query Parameter - oder alle Parameter - nicht zu indexieren.

[betatester]

Ich habe diesen Thread eben gefunden und ich möchte konstruktiv sagen, dass ich etwas verwundert bin.
Entweder hat Contao keine besonders gute Disclosure Strategie, oder es gibt ein paar nicht zutreffende Gerüchte. Schließlich kam es hier zu Dateimanipulationen, das ist kein Spaß. Da sind Szenarien wie zum Beispiel das Absaugen von (je nach Einsatzzweck möglicherweise auch personenbezogenen) Daten nicht mehr weit entfernt.

Einige erwähnen hier Sicherheitslücken die angeblich bekannt sein sollen und mit dem secret zu tun haben.

Darüber findet sich aber soweit ich sehen kann nichts in den offiziellen Contao Security Quellen, also

weder hier
https://github.com/contao/contao/security

noch hier
https://contao.org/de/sicherheitshinweise

Alle hier offiziell gelisteten Sicherheitslücken würde ich vorsichtig mal eher als "mittel" bezeichnen. Die meisten erfordern zb. einen authentifizierten Backend User. Kann man vermutlich als Ursache bei den hier Betroffenen ausschließen.

Daher möchte ich hier schon nochmal klar fragen:

1) Gibt / Gab es eine Lücke wie sie hier angedeutet wurde in Verbindung mit dem secret?
2) Wenn ja, gibt es dazu eine offizielle Quelle?
3) Wenn ja, was weiß man über den Angriffsvektor?
4) Wenn ja, warum findet sich darüber nichts in den offiziellen Contao Security Quellen?
5) Wenn nein, welche anderen Angriffsvektoren kamen hier bei den Betroffenen in Frage?

[mlweb]

Zuerst einmal - soweit ich sehe hat hier keiner der Betroffenen geschrieben, ob als Angriffsvektor eindeutig Contao identifiziert wurde. Die Ursache kann also alles mögliche gewesen sein (z.B. auch ein ausgelesener FTP-Zugang). Das fehlende Secret kann es jedenfalls nur gewesen sein, wenn zum Zeitpunkt des Angriffs keins existiert hat. Das konnte ja kaum einer eindeutig beantworten.

Die Sicherheitslücke mit dem Secret war auch keine Sicherheitslücke in Contao, sondern eine in Symfony, wird also nicht von Contao "gemanagt" sondern von Symfony. Bei normalen Installation wurde das Secret in Contao 4 in ausreichender Länge über das Installtool gesetzt. Contao ist als im Normallfall von dieser Symfony-Sicherheitslücke nicht betroffen gewesen. Wenn aber jemand das Secret z.B. bei einem Umzug gelöscht hat, dann wäre so etwas ausnutzbar gewesen. Contao hat mit einem Update zusätzlich versucht das Ausnutzen dieser Symfony-Sicherheitslücke noch besser zu verhindern.

[betatester]

Vielen Dank für Deine Einschätzung!
Wenngleich ich der Meinung bin, dass eine Erwähnung des Themas bei den Security Agenden sicher nicht geschadet hätte, auch wenn es keine direkte Contao Lücke ist.

Ein anderes Thema das ich bei meinen Recherchen gefunden habe, ist von letztem Jahr
https://kb.prohacktive.io/de/index.p...CVE-2022-26265

Hat mit 9,8 eine durchaus knackige CVE Bewertung. "Remote Code Execution" liest man nie gerne.

Hier gibt es auch den einen oder anderen Proof
https://github.com/redteamsecurity2023/CVE-2022-26265

Finde ich ebenfalls nicht auf den Contao Security Info Seiten.
Hier kann ich selbst den Angriffsweg aber nicht nachvollziehen (jedenfalls nicht auf die Schnelle), bei meinen Contao Installationen scheint /api/server/config nicht erreichbar zu sein. Somit also auch ein Beispiel wo es interessant wäre mehr darüber zu lesen.

[Spooky]

Wir haben das auch bei Symfony gemeldet - Symfony hat es aber nicht als Lücke gesehen, daher gibt es dafür auch kein CVE.

[mlweb]

Ich kenne keine Contao Managed Edition V 1.5.0. Kann aber an mir liegen.

[betatester]

Ich kenne keine Contao Managed Edition V 1.5.0. Kann aber an mir liegen.

Yep, die Versionsangabe hat mich auch sehr gewundert.

[mlweb]

@Spooky Die Antwort bezieht sich auf das Secret oder?

[lbableck]

Ich kenne keine Contao Managed Edition V 1.5.0. Kann aber an mir liegen.

Damit ist der Contao Manager 1.5.0 gemeint.

Hier kann ich selbst den Angriffsweg aber nicht nachvollziehen (jedenfalls nicht auf die Schnelle), bei meinen Contao Installationen scheint /api/server/config nicht erreichbar zu sein. Somit also auch ein Beispiel wo es interessant wäre mehr darüber zu lesen.

Die URL lautet /contao-manager.phar.php/api/server/config.
Siehe auch https://web.archive.org/web/20220321...lityDetails.md

[betatester]

Danke für die Info. Bestätigt mich in der Strategie, die manager phar nicht einfach so online rumliegen zu lassen, wenn sie nicht benötigt wird.

[Spooky]

@Spooky Die Antwort bezieht sich auf das Secret oder?

Es bezieht sich auf die "Lücke" die entsteht, wenn kein oder nur ein unsicheres Secret vorhanden ist, ja.

[lbableck]

Bestätigt mich in der Strategie, die manager phar nicht einfach so online rumliegen zu lassen, wenn sie nicht benötigt wird.

In dem Fall muss man zwar sowieso im CM angemeldet sein, daher find ich die 9.8 auch recht hoch angesetzt, aber schaden wirds nicht zumindest HTTP Auth noch vorm CM zu haben.

[zonky]

Blogpost "Contao richtig absichern"

https://pdir.de/news/contao-richtig-...-erhoehen.html