Alibaba Singapore Attacken [SOLVED]

[Ralph]

Haha, was denn nuh los ... der Apple Bot attackiert nun auch noch!
Könnte es sein dass Angreifer hierbei die Crawler Infrastrukturen von Google, Bing ... usw. einsetzen um diese Art von Attacken auszuführen?
Wäre mit relativ wenig Auwand über registrierte SiteMaps machbar, die Sitemaps verweisen auf interne PHP Scripts die redirects auf externe Ziele dynamisch generieren z.b. Ziel Domains aus einem Array laden.

Code: Select all

$domainname = array("domain1.tld", "domain2.tld", "domain3.tld");
$target = wp-login.php // bzw. (malwarescript.php)
header("Location: http://$domainname/$target");

Es wird sicherlich noch etwas komplexer sein, als hier im Beispiel
$domainname und $target könnten tausende Domains und Scriptziele beinhalten, wobei dann der Crawler die Arbeit für die Angreifer übernimmt und zwar pausenlos und ohne Ende ... wenn dabei nun bei allen möglichen search engines Sitemaps hochgeladen wurden die mit hunderten oder tausenden Sitemap VPS verbunden sind, könnte daraus ein nettes unstoppable Spektakel entstehen.

Ich kann mir nicht vorstellen dass all diese Crawler kompromittiert wurden und von Angreifern als "Zombie Scanner" kontrolliert werden.

[blickgerecht]

Moin!

Sind das sicher deren Bots? Also die machen viel Traffic, keine Frage. Aber aus den vorher genannten IPs, könnten es da auch Google Cloud Dienste sein? Dass dort jmd. VPS oder so anmietet, wie bei AWS oder Microsoft, und darüber Attacken fährt, bis die Sperre kommt?

[Ralph]

Moin!

Sind das sicher deren Bots? Also die machen viel Traffic, keine Frage. Aber aus den vorher genannten IPs, könnten es da auch Google Cloud Dienste sein? Dass dort jmd. VPS oder so anmietet, wie bei AWS oder Microsoft, und darüber Attacken fährt, bis die Sperre kommt?

Ja. das sind 100% deren Crawler die wohl irgendwie ausgetrickst werden um Last Attacken zu produzieren bzw. um Services zu überlasten z.b. Fail2ban währenddessen die Ziel Systeme schwächeln und angreifbar werden. Alibaba, AWS u.a auch KI Infrastrukturen haben ja sehr wahrscheinlich auch eigene Crawler am Start die nicht zwingend eine UA Kennung verwenden müssen ... wie gesagt, ich kann mir nicht vorstellen dass all diese Anbieter kompromittiert wurden.

[tab-kh]

Hast du schon versucht, das irgendwie bei Google zu melden? Kann ja nicht in deren Interesse sein, wenn man sie vom Netz nehmen muss.

[Ralph]

Hast du schon versucht, das irgendwie bei Google zu melden? Kann ja nicht in deren Interesse sein, wenn man sie vom Netz nehmen muss.

Das wird vermutlich wenig nützen, wenn es tatsächlich über diesen Weg ausgeführt wird, müssten die Anbieter alle eingereichten sitemaps auf Gültigkeit prüfen. Durch die vorangegangenen Mega data breaches könnten solche Aktionen selbst mit alten verwaisten Zugängen für Google & Co. leicht umgesetzt werden ... es wäre eine langwierige und komplizierte Aktion ... oder alle Crawler müssten so konfiguriert werden um bei redirects sofort zu stoppen, bei header location kaum möglich (aber protokollierbar).
Dieser Umweg über Crawler ist simpel aber effektiv, zum einen können per Zufall tatsächlich vorhandene malware scripts mehrfach anonym ausgeführt werden die dann eine Kompromittierung zur Folge hätten oder halt eben Last Attacken bis die Ziele keine Resourcen mehr haben um zuverlässig funktionieren zu können.

[tab-kh]

Wenn sie nicht gesperrt werden wollen, dann müssen sie sich halt was einfallen lassen. Ich hätte da jedenfalls keine Skrupel, weil ich auf Google nicht angewiesen bin. Bei Kunden mag es verständlicherweise anders aussehen. Wie gehst du dagegen vor? Alle URLs auf den Kundenseiten mit Malware-URLs sperren? Wenn sie von Google abhängig sind, kann man ja die Bots schlecht komplett aussperren.

Wenn auch andere Crawler außer Google auf die entsprechenden URLs zugreifen und du die begründete Vermutung hast, dass die Sitemaps die Ursache sind - eingereicht oder von der Website ausgespielt - dann müssen die Kunden diese entweder überprüfen (lassen) oder ansonsten ohne Crawler auskommen oder einen anderen Hostinganbieter zuspammen lassen. Die Überprüfung muss im Zweifel sowohl die gesamte Website als auch die Sitemap umfassen, im Prinzip müssen betroffene Websites als gehackt betrachtet werden (oder etwas freundlicher als kompromittiert ), was sie definitiv auch sind. Ist ja kein Zustand so.

[Ralph]

Die Kunden SiteMaps sind ja OK, ich meinte Fake Sitemaps von externen Angreifer Systemen deren Sites via header dynamisch umgeleitet werden auf externe Ziele (daher z.b. das crawling auf nicht existierende malware files). Ich gehe mal davon aus diese Taktik sollte via SiteMaps funktionieren um Crawler für Angriffe nutzen zu können ... anders kann ich mir die vielen Blacklistings der Crawler Netzwerke nicht erklären ... die werden ausgenutzt um Attacken zu produzieren.
Ich schließe aber nicht aus das eventl. auch eine KI Komponente die von diesen Anbietern eingesetzt wird, außer Kontrolle geraten ist und nuh wie wild Amok läuft

[tab-kh]

Ah, jetzt verstehe ich welchen Angriffsvektor du vermutest. Das wäre böse. Sehr, sehr böse. Aber letztlich dann eben doch die Aufgabe derer, die die Crawler betreiben. Schon aus ureigenem Interesse, sofern sie weiterhin erfolgreich crawlen wollen. Denn das würde in diesem Fall zum einen daran scheitern, dass die Crawler nur noch mit sinnlosen (also nicht von der jeweiligen Suchmaschine vorgesehenen) Seitenaufrufen beschäftigt sind und ihre eigentliche Aufgabe nicht mehr erfüllen. Und zum anderen daran, dass sie eben haufenweise auf Blocklisten landen oder (wie von dir) teilweise manuell geblockt werden.

Was je eh schon per se zum Problem wird mittlerweile. Jede dahergelaufene Firma versucht gerade, das komplette Internet mehrmals am Tag zu crawlen um die Daten in ihre KI zu füttern. Sehr zielführend, denn "garbage in, garbage out". Erst Shodan & Co und jetzt auch noch die Möchtegern-KI-Fritzen. Hält sich bei mir aber noch in Grenzen, meine Seiten sind nicht so interessant, aber OpenAI ist doch schon ein paar Mal aufgeschlagen hier. Zumindest laut User Agent, habe die IPs bisher nicht kontrolliert bei der eher geringen Zahl von Zugriffen, die für die Server keine nennenswerte Last erzeugen. Ob die das wirklich waren, das kann ich ja dann demnächst mit passenden Fragen direkt von ChatGPT erfahren.

[Ralph]

Einige requests scheinen sehr schlicht aufgebaut zu sein ... es wird einfach ein google.com/search?q=XXXX mit an die URL angehängt.
In dem Fall beantwortet Apache auch brav den request also z.b.

Code: Select all

https://community.keyhelp.de/viewforum.php?f=5&https://www.google.com/search?q=community.keyhelp.de

Code: Select all

[14/Sep/2025:14:34:09 +0200] "GET /pagename/ HTTP/1.1" 200 24874 "https://www.google.com/search?q=domainname" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0" 562 25794

Dieser request kam direkt von bc.googleusercontent.com, keine Ahnung ob der Google Bot daraufhin mit anspringt ...
https://www.abuseipdb.com/check/34.174.148.154

Andere requests werden vermutlich über sitemaps gezielt triggered z.b. mit Ziel auf Glückstreffer von malware scripts, die dann verschiedene Crawler aufrufen.
Oder beide Methoden zusammen verursachen irgendwie ein pausenloses Zombie crawling ....

Bei google selbst funktioniert das nicht, da wird direkt ein 404 ausgegeben, bei meiner WP bekomme ich ebenfalls einen 404, ein 200er muß irgendwo mit einem rewrite zusammenhängen ...
https://www.google.com/webhp&https://ww ... google.com

[Ralph]

Sorry, da hab ich nicht richtig hingeschaut ...
Der Teil "https://www.google.com/search?q=domainname" ist als User-Agent angehängt, der request kommt aber aus einer googleuser cloud und (noch) nicht vom Google crawler selbst:

Code: Select all

"GET /pagename/ HTTP/1.1" 200 24874 "https://www.google.com/search?q=domainname"

Das ist dann also doch etwas komplexer aufgebaut ....

[Ralph]

Die Search API wird bereits seit Jahren für Attacken missbraucht, neuerdings wohl bevorzugt über deren eigene Netzwerke ...
Es gibt zwar Limit Beschrränkungen und Abuse detection, aber anscheinend sind deren eigene Cloud IPs davon ausgenommen oder werden toleriert.
Abuse reports sind wenig hilfreich (nutzlos) und werden ignoriert, bleibt also nur ein IP blocking.
https://cloud.google.com/blog/products/ ... ning?hl=en
https://learn.microsoft.com/fr-ca/previ ... g-requests

https://github.com/luminati-io/google-search-api