Frage:
Die Website wird an den Viagra Store weitergeleitet. Alle üblichen Verdächtigen tauchen nichts auf
Lew
2014-04-25 18:23:24 UTC
view on stackexchange narkive permalink

Ich habe eine Kundenwebsite ( http://changewise.biz), die an einen Viagra-Shop (mywifeishappy.com) weitergeleitet wird. Wir haben alle üblichen Verdächtigen durchgesehen, können jedoch den Schuldigen, der die Umleitung verursacht, nicht finden:

  • Als erstes haben wir alle .htaccess-Dateien überprüft. alles sauber.
  • Checked robots.txt; wieder nichts.
  • Überprüfte alle 522 PHP-Dateien auf schädlichen Code (dies ist eine WordPress-Site, die bei RackSpace ausgeführt wird); Wir haben eine Codezeile mit einem base64decode eines Codes in der Tabelle wp-options der Site gefunden. 76 Instanzen davon, die alle ohne Freude entfernt wurden.
  • Ging zu Google Webmasters, damit Google die Website neu indiziert, falls fehlerhafte Indexdaten über die Website gespeichert sind. Dies kann eine Weile dauern.

Was seltsam ist, ist, dass ich über die direkte URL in meinen Browsern ( http://changewise.biz) auf die Website zugreife sehe es gut. Wenn der Kunde dies in seinen Browsern tut, landet die Site bei Viagra. Und - wenn wir beide Google "changewise" und auf den Link klicken, den Google in seinem SERP zurückgibt, wird die Website zum Viagra-Store weitergeleitet.

Hat jemand eine Idee dazu? Ich habe mit dem technischen Support von RackSpace gesprochen und sie können keine Ideen anbieten. Sie sehen keine anderen Schwachstellen im Hosting-Setup. Der Kunde ist sehr frustriert, genau wie ich.

Haben Sie die DNS-Einträge überprüft?
Ja. Ich habe ViewDNS.info verwendet, um einen ersten Blick darauf zu werfen (ich habe den Domain-Registrar um Zugangsdaten gebeten, um den DNS zu untersuchen. Bisher wurde nur das Problem gemeldet, dass lokale Nameserver keine IP-Adressen (Kleber) zusammen mit NS-Einträgen zurückgeben. Offensichtlich fehlen diese Für jeden der beiden aktuellen Nameserver, die auf RackSpace verweisen, müssen Datensätze hinzugefügt werden.
Siehe auch: http://security.stackexchange.com/questions/39231/how-do-i-deal-with-a-compromised-server.
Haben Sie Ihre .htaccess-Dateien überprüft? Da sie mit einem `.` beginnen, könnten Sie sie auf einem ls vermissen.
Ich habe zahlreiche Kompromisse gesehen, die sehr ähnliche Symptome hatten. Überprüfen Sie, wie bereits erwähnt, Ihre `.htaccess`-Dateien auf Kompromisse. Überprüfen Sie außerdem, welche Apache-Module installiert sind. Ich habe Kompromisse gesehen, die in einem böswilligen Apache-Modul mit unterschiedlichen Namen (z. B. "mod_charset.so") auftreten und dies verursachen.
Vielen Dank für Ihre Vorschläge - sehr geschätzt. Ja, alle .htaccess-Dateien wurden überprüft, auch diejenigen, die sich nicht im Stammverzeichnis befinden. Auch robots.txt überprüft. Sie haben keinen Zugriff auf Apache-Informationen, da dies ein Shared Hosting-Setup ist und wir keinen dedizierten Server haben. Ich kann den Hoster (RackSpace) bitten, dies am Ende zu überprüfen. Sie haben bereits eine Reihe von Scans und Überprüfungen durchgeführt und nichts gefunden.
FWIW, die Weiterleitungszielseite ist mit einem Javascript-Code-Packer / Obfuscator kompromittiert, daher am besten nicht mit dem Browser anzeigen.
Alle: Vielen Dank, dass Sie sich die Zeit genommen haben, um zu antworten. Sie alle hatten großartige Vorschläge, und ich bin den meisten nachgegangen. Die ideale Lösung ist hier "Sucuri". Sie sind ein Sicherheitsgeschäft, das sich auf WordPress-Websites konzentriert, und ihr Scanner hat die Malware identifiziert (und zeigt, dass es sich um den Viagra-Store handelt). Sie haben einen 90-Dollar-Plan für eine Website - was meiner Meinung nach unschlagbar ist. Viel billiger als ein Entwickler, der zwischen 50 und 100 US-Dollar pro Stunde abrechnet und an dieser Art von Problem arbeitet, wenn sich der Service nach ein oder zwei Stunden Zeit bezahlt macht. Deshalb habe ich diesen Service meinem Kunden empfohlen - empha
Sechs antworten:
mcgyver5
2014-04-25 18:56:05 UTC
view on stackexchange narkive permalink

Ich habe festgestellt, dass bei einer Google-Suche der Verweis (www.google.com) aus der Webanforderung zu changewise.biz nicht zur Spam-Site weitergeleitet wird.

Wenn Ich nehme den Referer nicht heraus, ich erhalte die Spam-Site (und nachfolgende Anfragen erhalten sie immer, da sie dann im Browser zwischengespeichert wird).

Ich denke, es handelt sich nicht um fehlerhafte alte Google-Daten, sondern um etwas auf Ihrer Site, die den Referer betrachtet.

Ihre Site liefert die folgende http-Antwort, wenn von google.com verwiesen wird: 

  HTTP/1.1 301 Permanent verschoben Server: Apache / 2.2Inhaltstyp: text / html; charset = iso-8859-1Datum: Fr, 25 Apr 2014 14:10:26 GMTLocation: http://mywifeishappy.com/Connection: Keep-AliveContent-Länge: 305<! DOCTYPE HTML PUBLIC "- // IETF // DTD HTML 2.0 // EN "><html><head><title>301 verschoben Permanently< / title>< / head><body><h1>Moved Permanently< / h1><p>The Dokument <a href = bewegt hat" http://mywifeishappy.com/ ">here< / a>.< / p><hr><address>Apache / 2.2 Server bei www.changewise.biz Hafen 80< / address>< / body>< / html>
+1 für einen guten ersten Schritt. Dann sollte das OP (oder der Client) die Konfiguration der Apache-Dateien (sowie alle .htaccess-Dateien und dergleichen im obersten Ordner der Website-Hierarchie. Und auch die Indexdateien.) Überprüfen, um festzustellen, welche die Umleitung hinzufügt
Ich zweitens die "Konfigurationsdateien überprüfen" auch tiefer in die PHP-Dateien einchecken. PHP kann durch Base64-Codierung und andere Mittel verschleiert werden. Überprüfen Sie die Protokolldateien auf Fehler, die Sie möglicherweise in die richtige Richtung führen. Versuchen Sie, den Index zu "wget", und prüfen Sie, ob er dem entspricht, was er sein soll.
Ich vermute, es gibt eine Weiterleitung in .htaccess
Ja, wie oben erwähnt und in meiner Frage, habe ich als erstes .htaccess - alle - und robots.txt überprüft. Überprüfte auch alle index.php-Dateien. Hat ein GREP mit verschiedenen Optionen während der gesamten Installation durchgeführt und 78 Dateien gefunden, die mit Code infiziert sind, der str_rotate13 und base64_decode ausführt. Ich habe das alles losgeworden.
Steffen Ullrich
2014-04-26 02:47:46 UTC
view on stackexchange narkive permalink

Ich würde vorschlagen, dass Ihr Apache-Prozess selbst eine Hintertür hat, da sogar der Zugriff auf nicht vorhandene Seiten mit etwas wie google \ erfolgt. im Referer wird umgeleitet. Z.B. wie 

  GET / diese Seite existiert nicht / HTTP / 1.0Host: www.changewise.bizReferer: foobargoogle.

Suchen Sie einfach bei Google Für 'Apache Backdoor Redirect Referer' finden Sie genügend Berichte über ähnliche Probleme. Die beste Reaktion wäre, den Server sofort herunterzufahren (um Kunden vor einer Infektion zu schützen und damit Ihren Ruf zu schützen) und ihn erneut von einer Quelle zu installieren, von der bekannt ist, dass sie nicht von der Hintertür betroffen ist.

Aber bitte sichern Sie zuerst Ihre (vermutlich * pwnd *) Apache-Installation. Es wäre schön, wenn Sie sie zur weiteren Analyse freigeben könnten, wenn dies tatsächlich das Problem wäre.
[sucuri] (http://blog.sucuri.net/?s=apache+backdoor) hat Sachen dazu
Um übereinzustimmen: Wenn Sie http://changewise.biz direkt eingeben, wird die Website gut angezeigt. Http://www.changewise.biz/foobar leitet mich jedoch zu http: // medtabletinc.com weiter (nicht zu mywifeishappy.com).
Sucuri ist das Ticket. Vielen Dank für diesen Vorschlag!
paul
2014-04-26 07:04:13 UTC
view on stackexchange narkive permalink

Ich hatte vor ein paar Monaten etwas Ähnliches. Es stellt sich heraus, dass der problematische Code in einer JPG-Datei im Upload-Ordner versteckt war.

Gehen Sie Ihre Uploads (einschließlich versteckter Dateien) durch und führen Sie jeweils die Datei file aus. Stellen Sie sicher, dass die Schafe alle Schafe sind und keinen Wolf verstecken.

Douglas Leeder
2014-04-25 19:05:55 UTC
view on stackexchange narkive permalink

Deaktivieren Sie Javascript und prüfen Sie, ob Sie immer noch umgeleitet werden:

1) Wenn Sie immer noch umgeleitet werden, liegt das Problem im serverseitigen Code und generiert eine Weiterleitung (permanent und von Ihrem gespeichert) Der Browser des Clients ist möglicherweise).

2) Wenn Sie nicht umgeleitet werden, liegt das Problem in dem zurückgegebenen Javascript. Überprüfen Sie möglicherweise das Caching von Javascript im Browser und stellen Sie sicher, dass die Site bereinigt ist .

Oder Sie könnten einfach "curl -v" ...
Brillant. Ja, ich habe JS deaktiviert und wurde NICHT umgeleitet. Die Frage ist nun, welche JS dies verursacht. Anzeigen von JS über den Browser Extras> Web Developer Extension> Informationen> JavaScript anzeigen zeigt alle aktuell geladenen JS an, aber nichts in diesen Dateien führt eine Umleitung durch. Diese Installation enthält mehrere hundert JS-Dateien und ist nicht einfach zu überprüfen, da die Umleitung auf 101 verschiedene Arten implementiert werden kann.
Oder, wenn nicht ein Stapel von JS-Dateien, dann ein paar Zeilen JS-Code, die am Ende einer Seite vergraben sind und eine Art Verschleierung verwenden, um ihren Zweck zu verbergen. Der Malware-Scan identifizierte 6 infizierte Seiten und ich fand 2, die ich löschen konnte, aber nicht in den anderen.
Ist es möglich, die Dateidaten zu überprüfen und so Ihre Suche auf Dateien zu beschränken, die in den letzten Tagen geändert wurden (oder was auch immer)?
that guy from over there
2014-04-25 19:45:53 UTC
view on stackexchange narkive permalink

Dies ist definitiv eine Art Überweisung von Referrern. Sie haben die Dateien .htaccess und den PHP-Code überprüft, aber versucht, die gefundene base64 zu dekodieren?

Wenn Ihre Docroot sauber ist, möchten Sie möglicherweise Ihre Serverkonfiguration überprüfen. und es besteht immer noch die Möglichkeit einer Art Apache / Ebury / CDork-Rootkit, aber meine erste Vermutung wäre:

  • einige böswillige PHP-Includes, die diese Weiterleitungen berechnen, wenn Google befindet sich im Referrer-Header
.htaccess .

Ist Ihre Version der WordPress + -Plugins auf dem neuesten Stand? Führen Sie eine Art Pest wie PLESK oder WMHC oder eine andere Serververwaltungssoftware aus, um Ihren Server zu verwalten?

Bearbeiten:

Wenn Sie eine saubere Sicherung haben, führen Sie für jede Datei einen Diff aus böswillige Includes'n'Stuff zu finden; Ich hoffe, Sie haben eine Kopie der "infizierten" Docroot?

Wenn jemand in der Lage ist, Ihre Dateien auf dem Server zu ändern, sollten Sie auch die Vuln finden, die zum Kompromiss führt. Andernfalls geschieht dies erneut.

Sie sollten auch nach seltsamen Crontabs für den Webserver-Benutzer suchen (als root: crontab -l -u $ webserver-user)

Ja. habe versucht, diese base64-Zeichenfolge zu dekodieren. Es ist über 50.000 Bytes lang und bietet alles, was man sich vorstellen kann - Dateizugriffe, alle möglichen verrückten Dinge. Das Entfernen des gesamten Codes hat das Problem jedoch nicht behoben. Ihre Theorie über PHP, die die Weiterleitung berechnet, erscheint plausibel. Die .htaccess-Dateien waren alle sauber, und das war das erste, was ich überprüft habe.
@Lew: siehe meine Bearbeitung
Tiernan
2014-04-28 04:23:00 UTC
view on stackexchange narkive permalink

Versuchen Sie, das Verzeichnis public_html in public_html.bak oder ähnliches umzubenennen, und erstellen Sie dann ein neues neues Verzeichnis public_html mit einer statischen HTML-Seite zum Testen.

Dies beweist, ob das Problem auf der Site selbst oder in der Datenbank liegt oder wenn der Apache-Server oder die Konfiguration selbst gefährdet ist. Wenn das oben genannte Problem dadurch nicht behoben wird, gehe ich davon aus, dass die Hosting-Box selbst kompromittiert ist.

Wenn das oben Gesagte die Umleitung stoppt, würde ich sie mit einer neuen WordPress-Installation und -Wiederherstellung neu erstellen die Daten.

Danke für diesen Tipp. Ich habe es versucht und die neue statische HTML-Datei wird angezeigt. Wir haben jedoch auch festgestellt, dass der direkte Zugriff auf die Website nicht in Frage kommt. Wenn Sie die URL in die Adressleiste eingeben, gelangen Sie dorthin. Durch Klicken auf den Link in einer Google-Suche wird jedoch umgeleitet. Durch Deaktivieren von JavaScript wird NICHT umgeleitet. Es scheint also immer noch etwas auf der Seite zu sein. Wahrscheinlich würde eine Neuerstellung die JS eliminieren, die die Umleitung verursacht. Vielen Dank, dass Sie sich die Zeit genommen haben, um zu antworten - schätzen Sie es.


ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...