Wurde gehackt. Willst du verstehen, wie

40

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).

Lothar_Grimpsenbacher
quelle
6
Ich weiß nicht, hast du jemandem dein Passwort gegeben?
4
Wenn Sie wissen, wann genau dies geschieht, durchsuchen Sie Ihr access_log nach allen ungewöhnlichen Ereignissen in dieser Zeit. Beachten Sie insbesondere alle POST-Anfragen: Wohin gehen sie, was haben sie getan?
Sanmai
3
Thx WhirlWind ... sehr hilfreich.
Lothar_Grimpsenbacher
2
Wenn Sie sie kennen, können Sie ihre Adressdaten in eine Anti-Spam-Site einfügen. Lassen Sie das Netz mit ihnen "sprechen" und geben Sie ihnen einen Vorgeschmack auf ihre eigene Medizin. :-)
4
@ Gaoshan88 - hilfreicher als Sie vielleicht denken. Ein Angriffsvektor ist ein Trojaner, der Passwörter von den FTP-Clients der Entwickler abfragt.
Quentin

Antworten:

9

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.

Turm
quelle
6
+1, vermeiden Sie FTP wie Seuche. Ein Kennwort-Sniffer-Trojaner kann Ihren Computer infizieren und Ihre Anmeldeinformationen zum Ändern von Dateien verwenden. Oder es kann Ihren Router infizieren. Oder der Computer Ihres Nachbarn im Netzcafe mit dem ungesicherten WLAN-Netzwerk. Das Passwort in clearext auszusenden ist eine schlechte Idee.
Tgr
1
FTP kommt mit SSL, wissen Sie.
Grawity
1
@grawity Die meisten Leute benutzen kein "ftps", aber das wird dich davon abhalten, gehackt zu werden. SFTP ist beliebter.
Rook
2
Die www-Daten sollten KEINE Dateien in Ihrem Webverzeichnis besitzen. Alles, was www-Daten enthält, kann durch ein schlecht geschriebenes Skript auf dem Server aktualisiert werden.
Zoredache
9

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").

Tippfehler
quelle
Haha. Meine gs-Sites sind momentan alle inaktiv. keine Email. weblog.mediatemple.net/weblog/category/system-incidents/…
typeoneerror
2

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)?

abarax
quelle
Umbenennen ist eine gute Idee. Ich werde es versuchen, sobald ich sehe, welche Auswirkungen es auf die Website haben wird. Crontab hatte eine etwas seltsame Sache, es gibt einen Eintrag für die Zeit, als die Dateien geändert wurden, aber es ist der Plesk Backup Manager ... eine kompilierte Anwendung. Wenn das gefährdet ist, hat Media Temple ein großes Problem.
Lothar_Grimpsenbacher
1

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!


quelle
1

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.

Editor
quelle
In den Protokollen wird der Datenverkehr zu der Zeit angezeigt, zu der diese Dateien geändert wurden, aber es handelt sich um harmloses Material wie: 207.46.13.43 - - [05 / May / 2010: 01: 42: 26 -0700] "GET /oped/bpr.php?edid= 211 & page = 4 HTTP / 1.1 404 257 - msnbot / 2.0b (+ search.msn.com/msnbot.htm )
Lothar_Grimpsenbacher
Wissen Sie, wie dieser Wordpress-Hack funktioniert hat? Könnte mir sagen, wie ich mein eigenes Problem beheben kann.
Lothar_Grimpsenbacher
2
Ja, es handelte sich um fehlerhafte Berechtigungen für freigegebene Boxen, die möglicherweise durch fehlerhafte Standardkonfigurationen von Network Solutions verursacht wurden. Es wurde empfohlen, die Berechtigungen für Ordner auf 755 und für Dateien auf 644 zu beschränken.
1

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.

webbiedave
quelle
Ich gehe davon aus, dass der Code eines Drittanbieters einen Exploit aufweist. Es befindet sich auf einem freigegebenen Server, aber ich hätte alle hochgeladenen Skripte gefunden (es sei denn, sie haben es hochgeladen, verwendet und dann gelöscht, aber selbst dann hätte ich etwas in den Protokolldateien gefunden, das ihre FTP-Verbindung
anzeigt
1
Wenn Ihre Dateien vom Webserver beschreibbar sind, können sie das Skript möglicherweise auf eine beliebige Website auf dem Server hochgeladen und Ihre Dateien überschrieben haben. Ich würde mir aber auch diese 3rd-Party-App genau ansehen.
Der Code von Drittanbietern ... ist es ein ausführbares Skript oder nur ein JavaScript-Snippet? JavaScript kann keine Dateien auf dem Server ändern.
Salman A
@Salman A - Dies ist eine Sammlung von PHP-Skripten, die Werbung verwalten.
Lothar_Grimpsenbacher
OK, dann hoffe ich, dass Sie diesen Code untersucht haben.
Salman A
1

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.

outis
quelle
1

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.

Salman A
quelle
1

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.

BillThor
quelle
Nicht-CGI-Skripte können häufig den Modus 600 oder 640 haben (abhängig vom Dateibesitzer und der Gruppe und dem Benutzer, unter dem der Webserver ausgeführt wird), da viele Skripte an einen Interpreter übergeben werden.
11.37 Uhr
0

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.

Tgr
quelle
0

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

Joe Phillips
quelle
Kein Wordpress hier beteiligt.
Lothar_Grimpsenbacher