Wurde gehackt. Willst du verstehen, wie

Jemand hat zum zweiten Mal einen Teil von Javascript an eine Site angehängt, die ich betreue. Dieses Javascript hijackt Google Adsense, indem es seine eigene Kontonummer einfügt und überall Werbung anbringt.

Der Code wird immer angehängt, immer in einem bestimmten Verzeichnis (eines, das von einem Anzeigenprogramm eines Drittanbieters verwendet wird), wirkt sich auf eine Anzahl von Dateien in einer Anzahl von Verzeichnissen in diesem einen Anzeigenverzeichnis aus (etwa 20) und wird ungefähr über Nacht an derselben Stelle eingefügt Zeit. Der Adsense-Account gehört zu einer chinesischen Website (befindet sich in einer Stadt, nicht eine Stunde von der Stelle entfernt, an der ich nächsten Monat in China sein werde. Vielleicht sollte ich Kopfzerbrechen machen ... Scherz, irgendwie). Übrigens ... hier ist die Info zu die Website: http://serversiders.com/fhr.com.cn

Wie können sie also Text an diese Dateien anhängen? Hängt es mit den Berechtigungen zusammen, die für die Dateien festgelegt wurden (zwischen 755 und 644)? Für den Webserver-Benutzer (auf MediaTemple, sollte es also sicher sein, ja?)? Ich meine, wenn Sie eine Datei haben, deren Berechtigungen auf 777 gesetzt sind, kann ich trotzdem nicht einfach nach Belieben Code hinzufügen ... wie könnten sie das tun?

Hier ist ein Beispiel des aktuellen Codes für Ihr Sehvergnügen (und wie Sie sehen können ... nicht viel dazu. Der eigentliche Trick ist, wie sie ihn dort hineingelegt haben):

<script type="text/javascript"><!--
google_ad_client = "pub-5465156513898836";
/* 728x90_as */
google_ad_slot = "4840387765";
google_ad_width = 728;
google_ad_height = 90;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

Da es von einigen Leuten erwähnt wurde, habe ich Folgendes überprüft (und damit meine ich, dass ich mich nach der Zeit umgesehen habe, als die Dateien auf seltsame Weise geändert wurden, und die Dateien nach POST-Anweisungen und Verzeichnisdurchläufen durchsucht habe:

• access_log (zeitweise nichts außer normalem (dh übermäßigem) msn bot Verkehr)
• error_log (nichts als die übliche Datei gibt es keine Fehler für harmlos aussehende Dateien)
• ssl_log (nichts als das Übliche)
• messages_log (hier ist außer mir kein FTP-Zugang)

* UPDATE: ** OK, habe es gelöst. Hacker aus China haben physisch eine Datei auf unserer Website abgelegt, mit der sie alle administrativen Aufgaben erledigen können (Datenbankzugriff, Löschen und Erstellen von Dateien und Verzeichnissen, wie Sie es nennen, sie hatten Zugriff). Wir hatten Glück, dass sie nichts Destruktiveres getan haben. Die normalen Apache-Protokolldateien enthielten nichts, aber ich fand in einem Webserver-Protokollanalysator einen anderen Satz von Protokolldateien, und die Beweise waren darin enthalten. Sie haben auf diese Datei mit ihrem eigenen Administrator-Benutzernamen und -Passwort zugegriffen und dann alles, was sie brauchten, direkt auf dem Server bearbeitet. Ihre Datei hat "Apache" als Benutzer festgelegt, während alle anderen Dateien auf unserer Website einen anderen Benutzernamen haben. Jetzt muss ich herausfinden, wie sie diese Datei physisch auf unser System bekommen haben. Ich vermute, die Schuld liegt irgendwann bei unserem Webhost (Media Temple).

Vor allem ist es chmod 744nicht das, was Sie wollen. Der Zweck von chmod besteht darin, den Zugriff auf andere Konten im System zu widerrufen. Chmod 700ist viel sicherer als chmod 744. Apache benötigt jedoch nur das Ausführungsbit, um Ihre PHP-Anwendung auszuführen.

chmod 500 -R /your/webroot/

chown www-data:www-data -R /your/webroot/

www-data wird üblicherweise als Apache-Account verwendet, der zur Ausführung von PHP verwendet wird. Sie können auch diesen Befehl ausführen, um das Benutzerkonto anzuzeigen:

`<?php
print system("whoami");
?>`

FTP ist fürchterlich unsicher und es ist sehr wahrscheinlich, dass Sie von dieser Methode gehackt wurden. Mit FTP können Sie Dateien beschreibbar machen und anschließend erneut infizieren. Stellen Sie sicher, dass Sie auf allen Computern mit FTP-Zugriff ein Virenschutzprogramm ausführen . Es gibt Viren, die den lokalen Datenverkehr nach FTP-Benutzernamen und -Kennwörtern durchsuchen und sich dann anmelden und die Dateien infizieren. Wenn Sie Wert auf Sicherheit legen, verwenden Sie SFTP, das alles verschlüsselt. Das Senden von Quellcode und Passwörtern im Klartext über das Internet ist Wahnsinn.

Eine andere Möglichkeit besteht darin, dass Sie eine alte Bibliothek oder Anwendung verwenden. Besuchen Sie die Website des Softwareanbieters und vergewissern Sie sich, dass Sie die neueste Version verwenden.

Meine Media Temple Grid Server-Konten wurden mehrmals auf diese Weise "gehackt". Ihre Sicherheit ist sehr schlecht ... angefangen mit PLAIN TEXT PASSWORDS im letzten Jahr und bis heute (Sie können den technischen Support anrufen und sie sagen: "Wie lautet Ihr Passwort?"). Ich weiß es, weil ich monatlich E-Mails bekomme, in denen beschrieben wird, wie sie alle meine Kontokennwörter geändert haben, und dass sie jedes Mal, wenn sie gehackt werden, Datenbankkennwörter für Sie ändern. Diese Firma sieht auf der Oberfläche verdammt glänzend aus, aber der Grid-Server ist ein Chaos. Ich empfehle sofort zu wechseln .

Bitte lesen Sie diesen Beitrag aus dem letzten Jahr über das ursprüngliche Fiasko (Warnung, es wird Sie verärgern). Von dort geht es bergab. Ich habe letztes Jahr Thanksgiving außerhalb meiner Familie verbracht und Pornolinks von meinen Websites entfernt. Schön.

Behalten Sie den Spaß auf ihrer Statusseite im Auge : Sie informiert Sie über die neuesten Exploits (und tatsächlich gibt es dort oben einen "möglichen Exploit").

Aufgrund der mangelnden Aktivität in Zugriffsprotokollen usw. und der Tatsache, dass dies ungefähr zur gleichen Zeit geschieht, scheint es, dass der Server kompromittiert wurde und ein Shell-Skript ausgeführt wird, um das Anhängen auszuführen.

Haben Sie Crontab auf etwas Seltsames überprüft?

Haben Sie versucht, das Verzeichnis und die Verweise darauf umzubenennen (dies kann das Shell-Skript beschädigen)?

Ja, es könnte definitiv mit den Dateiberechtigungen zusammenhängen. Durch Dateien, die vom Webprozess beschreibbar sind, sind Sie für Sicherheitslücken in den von Ihnen ausgeführten Webanwendungen offen. Sperren Sie alles, damit der Webprozess nicht mehr lesen oder schreiben kann, als er muss.

Die andere Komponente spürt genau auf, wie sie Ihre Dateien ändert. Das Überprüfen der Zugriffsprotokolle des Webservers ist ein guter Anfang. Überprüfen Sie die letzten Anmeldezeiten für verschiedene Benutzer. Sie können auch ein Skript einrichten, das die Dateien auf Änderungen überwacht und Sie benachrichtigt, damit Sie versuchen können, die Verbrecher auf frischer Tat zu ertappen!

Dies kommt den Wordpress-Hacks , die in letzter Zeit eine ganze Reihe von Network Solutions-Sites getroffen haben, furchtbar bekannt vor. Da Sie sich in Media Temple befinden, ist es möglich, dass Sie einige Dateien für andere Benutzer sichtbar gelassen haben, die Ihren Computer gemeinsam nutzen. Das würde das Fehlen von POST- oder Apache-Protokollspuren erklären. Wenn dies der Fall ist, wäre es tödlich einfach, Code in die Befehlszeile einzufügen.

Der Code wird immer in einem bestimmten Verzeichnis angehängt

Hängt es mit den Berechtigungen zusammen, die für die Dateien festgelegt wurden (zwischen 755 und 644)? An den Webserver Benutzer

Befinden Sie sich auf einem freigegebenen Server? Wenn ja (oder auch nicht), hat möglicherweise jemand ein FTP-Passwort erzwungen und ein Skript hochgeladen, das alle Dateien anhängt, die es in die Hände bekommen könnte.

Eines, das von einem Drittanbieter-Anzeigenprogramm verwendet wird

Oder vielleicht hat dieses Programm einen Exploit.

Wenn Sie über einen entsprechenden Zugriff (und Kernel-Unterstützung) verfügen, können Sie versuchen, einen Überwachungsdämon basierend auf inotify oder dnotify zu starten , um nach Änderungen an Ihren Dateien zu suchen. Verwenden Sie dann "lsof", um zu sehen, mit welchem ​​Prozess die Datei geöffnet ist Schreibzugriff. Möglicherweise können Sie strace auch zur Überwachung verwenden. Dies sollte einen Hinweis darauf geben, welche ausführbare Datei ausgenutzt wird.

Die FTP-Prüfung von Protokollen ist der erste Startpunkt. Das Protokoll sollte die meisten, wenn nicht alle Aktivitäten zusammen mit Zeitstempeln enthalten. Wenn Sie also wissen, wann Ihre Dateien geändert wurden, können Sie feststellen, ob Ihr FTP-Konto gefährdet ist oder nicht.

Als nächstes könnte es sich um ein Skript auf Ihrem Webserver handeln, das diesen Code einfügt. In einem Shared-Hosting-Szenario ist es meiner Meinung nach möglich, eine cat /web/malicious.com/script.js >> /web/innocent.com/index.php. Dies kann unter bestimmten Bedingungen funktionieren, z. B. wenn der Befehl vom Benutzer httpd ausgeführt wird und die Datei index.php auch diesem Benutzer gehört oder von ihm geschrieben werden kann. In diesem Fall sollten Sie Ihren Hosting-Anbieter bitten, das Konto zu verfolgen, mit dem die Skripte eingefügt werden.

Die meisten Site-Dateien müssen vom Webserver gelesen werden können. Auf einer schreibgeschützten Site müssen nur die Protokolle vom Webserver beschreibbar sein. Setzen Sie den Eigentümer auf eine andere Person als die vom Webserver verwendete. Stellen Sie den Schutz 640 für alle Dateien außer Skripten ein. Festlegen von Skripten und Verzeichnissen 750. Für Dateien oder Verzeichnisse, die vom websever geschrieben werden müssen, können Sie den Eigentümer in den Webserver ändern oder im chmod g + 2 die entsprechenden Dateien oder Verzeichnisse festlegen.

Es gibt unzählige Möglichkeiten, eine Site zu knacken. Sie haben möglicherweise eine Sicherheitsanfälligkeit in Ihrem Skript ausgenutzt, Ihr Kennwort gestohlen, eine Sicherheitsanfälligkeit einer gemeinsam gehosteten Site (wenn Sie sich auf einem günstigen Host befinden) und eine Sicherheitsanfälligkeit eines nicht mit dem Web zusammenhängenden Dienstes auf dem Servercomputer ausgenutzt. .

Überprüfen Sie in einem ersten Schritt das Datum der Dateiänderung und die Zugriffs-, Fehler- und FTP-Protokolle auf verdächtige Aktivitäten zu diesem Zeitpunkt.

Das gleiche ist mir vor einiger Zeit passiert. Wordpress war meines Wissens die einzige Software, die so etwas verursacht hätte.