Website infiziert?

[heinetz]

Hallo Forum,

beim Aufruf einer Kundendomain wurde mir heute so ein (inline)-Popup mit folgendem Hinweis:

VIO Player required to play this video, click DOWNLOAD NOW

... angezeigt. Weil sich die lokale Version auf meinem Entwicklungssystem der (Wordpress-)Website anders verhält, bin ich skeptisch geworden. Bei einem Scann der Site unter https://website-klinik.de wird "Die Domain wurde als Problem eingestuft". Der (relativ neue) Kunde behauptete vor dem Projekt, seine alte Website wäre gehackt worden (worunter ich mir nichts weiter vorstellen konnte) und ich habe überhaupt keine Erfahrung mit Schadsoftware auf dem Webserver.

Ich kann mir nicht vorstellen, was genau da passiert ist und daher auch nicht, was ich da nun machen muss. Aus dem Bauch heraus, würde ich das Problem 1&1 zuordnen, denn ich kann mir nicht vorstellen, warum und wie jemand explizit dieses kleine Webvisitenkarte "hacken" wollen würde.

Wie gehe ich mit dem Problem um?

beste gruesse,
martin

[tron]

Hallo,

wäre gut, wenn du einen Link posten würdest.

Wie gehe ich mit dem Problem um?

zuerst FTP-Passwort ändern. Dann Quellcode nach lokal kopieren und nach auffälligem, nicht von dir stammenden Code suchen. Falls es sich um ein Content-Management-system o.ä. handelt: Update.

1&1 wurde sicher nicht gehackt. Vermutlich liegen die Zugangsdaten von dem FTP-Account schon lange bei irgendwelchen Botnetzen.

tron

[Rowland]

Hey heinetz,

Wie gehe ich mit dem Problem um?

Herausfinden, woher das Pop-Up kommt. Ein Pop-Up benötigt ja eine Quelle, z.B. einen Javascript Code oder ähnliches. Eventuell wird im Quelltext nur ein externes Script aufgerufen. Erstmal rauslöschen bzw. wenn du dir die Arbeit sparen willst und es nicht auf anhieb findest, neuinstallieren aber Daten vorher sichern. Nach Dateien auf dem Wepspace suchen, die da nicht hingehören.

Wenn der Kunde sagt, dass seine Seite schonmal gehackt wurde, würde ich das eher darauf zurückführen, dass er selbst einen Virus auf seinem PC hat und wahrscheinlich auch die Passwörter in einem Dokument, beliebt mit dem Titel Passwort.txt auf dem Desktop rumliegen. Das ist natürlich nur eine Möglichkeit auf welchem Weg es reingekommen sein kann, denn dieser Schadcode muss ja irgendwo auf dem Webspace sein bzw. eine Refenz zu einer Quelle außerhalb. Und da 1und1 nun wirklich keine Neulinge auf dem Gebiet des Webhostings sind, würde ich mich erstmal um den kümmern, der kein WordPress Blog aufsetzen kann.

Ich empfehle dir also erstmal den Kunden unter die Lupe zu nehmen. Die Leute kennen meist den Begriff von Virenprogrammen, denken aber, dass solange der PC noch hochfährt und sonst nichts außergewöhnliches geschieht, haben sie auch keinen Virus, Trojaner usw.

Es kann auch sein, dass es an dem WordPress Blog selbst liegt und da eine Lücke ist. Aber auch da ist die Wahrscheinlichkeit geringer.

VE,
Rowland

[M.]

Mahlzeit,

denn ich kann mir nicht vorstellen, warum und wie jemand explizit dieses kleine Webvisitenkarte "hacken" wollen würde.

Wieso glaubst du, die grösse einer Webseite spielt eine Rolle?

[1UnitedPower]

Meine Herren!

denn ich kann mir nicht vorstellen, warum und wie jemand explizit dieses kleine Webvisitenkarte "hacken" wollen würde.

Das kann ich mir auch nicht vorstellen, und es passt auch nicht zu den Symptomen des Angriffs. Der Angriff ist mit hoher Wahrscheinlich nicht explizit – nicht ausdrücklich – sondern massenweise durchgeführt worden. Irgend ein Botnetz, dass automatisiert etliche Seiten crawlt und auf bekannt gewordene Sicherheitslücken testet. Bei einem solchen Angriff geht es nicht darum, gezielt auf bestimmten Plattformen Schadcode einzufügen, sondern nur darum den Schadcode möglichst weit zu verbreiten. Wenn es bei einer Webseite nicht klappt, dann hält sich das Botnetz nicht daran auf, sondern dann wird es mit eben mit der nächsten probiert.

Wie gehe ich mit dem Problem um?

1. Erstmal solltest du das System herunterfahren oder vom Netz trennen. Irgendwie dafür sorgen, dass es keinen weiteren Schaden anrichten kann.

2. Dann solltest du recherchieren, woher der Angriff kam und welche Sicherheitslücke ausgenutzt wurde. Mit dem Wissen, dass es sich um einen Massenangriff handelt, wirst du vermutlich schnell mit einer Suchmaschine fündig. Hat das eingeschleuste Skript auf irgend eine andere Seite weitergeleitet, oder gab es einen charakteristischen Text zu sehen? Das wären Suchbegriffe, die sich bei der Recherche gut eignen.

3. Wenn die Ursache gefunden ist, kannst du beginnen die kontaminierten Bereiche wieder zu bereinigen, das kann sehr leidig werden und u.U. viel Arbeit bedeuten. Die Recherche wird vermutlich direkt einen Lösungsweg vorschlagen.

4. Ist das System bereinigt, dann solltest du die Sicherheitslücke wieder schließen. Im Regelfall wird dazu nicht mehr als Software-Patch notwendig sein.

5. System wieder anklemmmen ;)

Du solltest auch nicht zögern, einen Experten und deinen Hoster hinzuziehen, wenn noch größere wirtschaftliche Schäden zu erwarten sind.

[heinetz]

Hello,

2. Dann solltest du recherchieren, woher der Angriff kam und welche Sicherheitslücke ausgenutzt wurde. Mit dem Wissen, dass es sich um einen Massenangriff handelt, wirst du vermutlich schnell mit einer Suchmaschine fündig. Hat das eingeschleuste Skript auf irgend eine andere Seite weitergeleitet, oder gab es einen charakteristischen Text zu sehen? Das wären Suchbegriffe, die sich bei der Recherche gut eignen.

ja, so gehe ich auch immer und recht erfolgreich damit um, wenn sich ein rechner irgendwann merkwürdig verhält. Bei diesem konkreten Problem finde ich kaum was verwertbares im Netz. Firebug zeigt zwei Requests auf externe Ressourcen im Network-Panel an, die ich nicht zuordnen kann und die verdächtig sein könnten:

1. das js, dass für das Popup verantwortlich zu sein scheint wird von einer lets-study-english.com geladen, mit der ich nichts anfangen kann.

2. dann gibt es einen Request auf eine 0.gravatar.com, den ich nicht zuordnen kann

... aber google gibt mir keine desbezüglich eindeutigen Hinweise.

Ich habe gerade einen neuen Anhaltspunkt:

Mein FTP-Client zeigt an, dass sämtlichen Dateien/Verzeichnisse auf oberster Dateiebene ein Änderungsdatum "vor 3 Tagen" haben und in der index.php ist am Ende ein "<script ...". Das kann ich nun natürlich einfach wieder rausschmeissen und das Problem wird damit behoben sein, aber eben nicht dauerhaft und vor Allem würde ich das gerne interpretieren, um das Problem
dauerhaft und vollständig zu beseitigen:

Ich gehe nun davon aus, dass irgendWAS einen FTP-Zugang zum Server hat. Das grenzt das Problem ein und schliesst Sicherheitslücken im PHP-Code (z.b. mysql-injection) weitgehend aus aber auch nachdem ich das System bereitigt hätte, wäre diesem irgendWAS der FTP-Zugang noch bekannt und das Problem wird sich potentiell wiederholen. Ändere ich die Passwörter aller FTP-User stellt sich immernoch die Frage, wie ist das irgendWAS an den FTP-Zugang gekommen
und könnte das wieder passieren?

Kann da tatsächlich nur der Kunde (oder sonstwer) mit dem Passwort unvorsichtig umgegangen sein oder kann es vielleicht doch sein, dass 1&1 die undichte Stelle ist, bei denen sich irgendwelche Bots Zugang zum Kundenwebspace verschaffen können.

gruss,
heinetz

[Kay]

und könnte das wieder passieren?

Kann da tatsächlich nur der Kunde (oder sonstwer) mit dem Passwort unvorsichtig umgegangen sein oder kann es vielleicht doch sein, dass 1&1 die undichte Stelle ist, bei denen sich irgendwelche Bots Zugang zum Kundenwebspace verschaffen können.

Da reichen schon schlechtgewählte Passworte. Ich kann mich noch gut daran erinnern, mein erster V-Server lag 8 Wochen lang brach ohne etwas installiert oder betrieben zu haben, aber jede Menge Traffic. Ein Blick in die Logdateien zeigte, da hat jemand in Intervallen die immer zwischen 45 Minuten und 3 Stunden dauerten, mehrmals täglich seine Wörterbuchdateien ausprobiert. Wahrscheinlich Skriptkiddies, als normales Grundrauschen. Nur den Port 22 umgelegt und schon war ruhe. http://de.wikipedia.org/wiki/Skriptkiddie

Hier mal etwas aus dem richtigen Leben:
http://www.youtube.com/watch?v=2bu_T8vUs4I

Mein Tipp System platt machen und jemand der Ahnung hat beauftragen, das System neu aufsetzen.

[Jörg Reinholz]

Ein Blick in die Logdateien zeigte, da hat jemand in Intervallen die immer zwischen 45 Minuten und 3 Stunden dauerten, mehrmals täglich seine Wörterbuchdateien ausprobiert.

Ja...

Mein Tipp System platt machen und jemand der Ahnung hat beauftragen, das System neu aufsetzen.

... der könnte und sollte auch gleich fail2ban mit konfigurieren. Das beugt derartigen Angriffen sehr effektiv vor. Natürlich geht das nur wenn man einen eigenen (virtuellen) Server betreibt - weil die Massenhoster die schwierig zu lösenden Anfragen an den Kundendienst vermeiden wollen welche fast unweigerlich auflaufen nachdem deren Kunden sich durch falsche Passwörter selbst für eine gewisse Zeit ausgesperrt haben.

Ansonsten hilft, weil die Angreifer ja erst mal nach verwundbaren suchen, ein angepasster Honeypot.

Natürlich hilft das nichts wenn das Login scheinbar berechtigt erfolgt weil entweder ein FTP-Benutzer einen infizierten Rechner hat oder die Freundlichkeit hatte, aus fragwürdigen Netzen heraus Benutzername und Passwort via unverschlüsseltem Protokoll zu verschenken. Hier gilt es die Ursache durch Nachsuchen in den Protokollen zu ermitteln.

=========================================================================  
Beim Massenhosting sollte man auch sehr genau auf die Dateirechte achten.  
=========================================================================

Nehmen wir mal an, ein Kunde habe ein eigenes Verzeichnis:

/kunden/k0815

Dieses Verzeichnis muss für jeden betretbar sein (sondt könnte es der Webserver nicht). Die Rechte am Verzeichnis werden also sinnvoller Weise auf 0755 (rwx,r-x,r-x) gesetzt.

In diesem Verzeichnis liegt jetzt eine index.html mit den Rechten 0666 (rw-,rw-,rw-) - was KEINE gute Idee ist, wei sich gleich zeigt:

Ist es einem Angreifer gelungen sich im Auftritt irgend eines der anderen 1000 Kunden auf dem Server eine php-shell zu installieren, dann kann er mit einem simplen ...

echo '<script type="text/javascript">alert("Toll! Das hat geklappt!");</script>' >> /kunden/k0815/index.html

... seinen virulenten Code anhängen ohne eingeloggt zu sein.

Abhilfe: Setzen der Rechte an der Datei auf 0644 (rw-,r--,r--)

Viele denken nämlich, wenn man der Gruppe und der Welt das Schreiben ins Verzeichnis verbietet, so hätte man denen auch das Schreiben in die darin enthaltenen Dateien verboten.

So ist es aber NICHT.

Jörg Reinholz

[BongoBob]

Hallo Jörg,

ich finde das mit dem Honeypot sehr interessant, nur leider kapier ich es nicht so recht.
Wie genau setzt du das ein?

Ansonsten hilft, weil die Angreifer ja erst mal nach verwundbaren suchen, ein angepasster Honeypot.

viele Grüße
Bongo Bob

[Gunther]

Hallo!

ich finde das mit dem Honeypot sehr interessant, nur leider kapier ich es nicht so recht.
Wie genau setzt du das ein?

Das ist eine "abgespeckte" Variante von fail2ban, welches ich dir wenn eher empfehlen würde.

Denn anders als der "Honeypot" arbeitet es nicht mit .htaccess Dateien, sondern wertet das Serverlog aus. Das hat imho diverse Vorteile und ist dadurch auch wesentlich umfangreicher in seiner Abdeckung und den Einsatzmöglichkeiten, bei einfacherer Konfiguration.

Gruß Gunther

[Jörg Reinholz]

Das ist eine "abgespeckte" Variante von fail2ban, welches ich dir wenn eher empfehlen würde.

Denn anders als der "Honeypot" arbeitet es nicht mit .htaccess Dateien, sondern wertet das Serverlog aus. Das hat imho diverse Vorteile und ist dadurch auch wesentlich umfangreicher in seiner Abdeckung und den Einsatzmöglichkeiten, bei einfacherer Konfiguration.

Ja. fail2ban ist eine sehr feine Sache. Und ich setze das auch ein: Der 6. vergebliche Anmeldeversuch unter https://78.49.35.128/Cloud/ [maximal bis 7.3.2014 03:00 gültig] führt zu einer Sperre...

Aber:

Im Massenhosting hat man nichts davon, da es für die Konfiguration root-Rechte braucht, vor allem aber dass die Massenhoster ihren Kundendienst nicht damit belasten wollen, dass irgendwelche von deren Kunden sich ständig selbst aussperren und dann anrufen, weil angeblich "der Webserver nicht geht".  Damit fällt fail2ban in den vielen Fällen, in denen die geringe Serverlast kundenseitig die Kosten für einen (V-)server nicht rechtfertigt, unter die Marketing-Rubrik "leider nicht möglich".

Andererseits bringt mich das auf eine gute Idee, Da ich ja gerade an einer Lösung für (m)eine Home-"Cloud" stricke (s. URL oben) könnte ich etwas wie fail2ban mit einbauen.

Jörg Reinholz

[Jörg Reinholz]

Hallo Jörg,

ich finde das mit dem Honeypot sehr interessant, nur leider kapier ich es nicht so recht.
Wie genau setzt du das ein?

Nun, zuerst einmal ist mod_rewrite die Grundvoraussetzung.

Es könnte Dir entgangen sein, dass unter "3. Einträge in Datei .htaccess" eine Zeile

RewriteEngine on

fehlt. Deshalb heißt es ja auch nicht "Datei .htaccess" sondern "Einträge in Datei .htaccess".

Abgesehen davon sollte der Honeypot "out of the box" laufen.

Jörg Reinholz

[tron]

hallo,

Ich gehe nun davon aus, dass irgendWAS einen FTP-Zugang zum Server hat. Das grenzt das Problem ein und schliesst Sicherheitslücken im PHP-Code (z.b. mysql-injection) weitgehend aus aber auch nachdem ich das System bereitigt hätte, wäre diesem irgendWAS der FTP-Zugang noch bekannt und das Problem wird sich potentiell wiederholen. Ändere ich die Passwörter aller FTP-User stellt sich immernoch die Frage, wie ist das irgendWAS an den FTP-Zugang gekommen
und könnte das wieder passieren?

genauso ist es wohl.

Kann da tatsächlich nur der Kunde (oder sonstwer) mit dem Passwort unvorsichtig umgegangen sein

vermutlich. Da reicht schon dass Speichern des Passworts im Klienten, vor allem, wenn man eine Windose nutzt. Trojaner sniffen das gerne mal.

oder kann es vielleicht doch sein, dass 1&1 die undichte Stelle ist, bei denen sich irgendwelche Bots Zugang zum Kundenwebspace verschaffen können.

alles in allem eher unwahrscheinlich, wenn die Zugangsdaten einigermaßen sicher sind.

FTP-Passwort ändern, 1und1-Accountpasswort ändern, Wordpress updaten, Zugangsdaten nicht in FTP-Klienten speichern, bei Dir (falls windose) und Kunden Trojanercheck.

[Jan]

Hallo,

Mein FTP-Client zeigt an...

FTP Cleint ist aber nicht FileZilla?

Ansonsten vielleicht:

http://www.heise.de/security/meldung/Trojanisierte-FileZilla-Version-greift-Zugangsdaten-ab-2099232.html

Gruß
Jan