Eigene Homepage kompromittiert

Thomas

Neu angemeldet
Registriert
26 Juli 2013
Beiträge
269
Ich habe eine Frage: ein Freund von mir hat eine Homepage. Dies ist laut Virustotal kompromittiert ( 6 Scanner melden dies). Wie kann ich am Besten den Quellcode analysieren, wenn kein sauberes Backup bestehen sollte? Welche Tools nehme ich am Besten dafür? Da 6 Scanner Funde bzw. verdächtige Seiten gemeldet haben, gehe ich davon aus, dass dies kein falsch-positiver Fall ist.
 
Hallo Thomas,

Analyse-Tools eignen sich nur bedingt, um Fehler ausfindig zu machen. Das Problem dabei: Eine Maschine hat (noch) nicht die nötige Intelligenz, um Angriffe abseits von geläufigen Methoden und bekannten Schwachstellen durchzuführen.

Sofern du selbst also keine Erfahrung mit der Thematik hast, könntest du über Google Glück haben, wenn ein CMS eingesetzt wurde und findest dann dort hilfreiche Beitrage, die dir eine Lösung des Problems erklären. Je nach Umfang und Brisans der Daten könntest du natürlich auch den Link hier posten, sodass man einen Blick darauf werfen könnte. Im schlimmsten Fall müsstest du entweder die Homepage von einem anderen Programmierer neu entwickeln lassen oder einen professionellen Penetration Test durchführen lassen.

Ansonsten ist die übliche Vorgehensweise, die Seite zunächst für öffentliche Besucher zu sperren und die Dateien (auch wenn diese kompromittiert sein mögen) zu sichern, um lokal Analysen durchführen zu können. Bedenke, dass dies aber gefährlich sein kann, wenn du nicht weiß, was du tust (beispielsweise wenn Schadcode über einen lokalen Webserver ausgeführt wird und so Zugriff auf dein System ermöglicht).

Weiterhin sind die Log-Dateien ein guter Ansatzpunkt, um den Angriff rekonstruieren zu können, sofern diese nicht vom Angreifer gelöscht/geändert wurden.

Darüber hinaus könnten aber auch Schwachstellen in der Serversoftware existieren. Bei gehosteten Webspaces und Datenbank ist es aber nicht deine Aufgabe, dort Fehler zu finden, sondern das übernimmt der Serveradministrator. Hast du jedoch einen eigenen Server, so solltest du diesen komplett vom Internet trennen.
 
  • Thread Starter Thread Starter
  • #3
Zunächst vielen Dank! Ja, ich meinte keine automatisierten Tools, sondern eher einfach ein Editor, einen HTML Editor oder so. Den Link kann ich leider nicht posten, da dieser mit dem direkten Namen des Inhabers verbunden ist.

(beispielsweise wenn Schadcode über einen lokalen Webserver

Ein lokaler Webserver wird nicht installiert und wenn, dann analysiere ich das in einer virtuellen Umgebung.

sondern das übernimmt der Serveradministrator

Nun ja, es ist bei einem Webspace gehostet, aber bin mir nicht ganz sicher, ob die das übernehmen.
 
Du kannst ja deinen bevorzugten Editor zum Anzeigen des Codes verwenden.

Wenn ein CMS oder ähnliches verwendet wurde, kannst du ja eine nackte Installation verwenden und die Änderungen mit deiner kompromittierten Version vergleichen. Die Differenz prüfst du dann.
 
Ein lokaler Webserver wird nicht installiert und wenn, dann analysiere ich das in einer virtuellen Umgebung.

Naja, ein lokaler Webserver ist insofern nicht die schlechteste Idee als dass du dann selbst versuchen kannst, die Seite zu hacken und nicht im Quellcode nach Lücken suchen musst. Ersteres ist deutlich erfolgsversprechender, da man bei der zweiten Variante ja wirklich jede Datei durchkauen muss und alle Zusammenhänge verstehen muss. Eine virtuelle Maschine ist aber in der tat sinnvoll.

Nun ja, es ist bei einem Webspace gehostet, aber bin mir nicht ganz sicher, ob die das übernehmen.

Dass die Administration das übernimmt, bezog sich nur auf Sicherheitslücken, die in der Serversoftware, also beispielsweise beim Webserver, zu finden sind. Ist dies nicht der Fall und die Lücken sind im Quellcode der Seite zu finden, dann ist das deine Aufgabe, diese zu finden und zu beseitigen ;)

Edit:
@ nik: Auf diese Weise kann man feststellen, wo der Schadcode implementiert wurde, jedoch wird man unter Umständen nicht das eigentliche Problem - die Sicherheitslücke - finden. Sollte sich diese im CMS befinden, so beinhaltet auch ein frisch eingerichtetes System der gleichen Version diese Lücke. Höchstens wenn der Fehler erst durch eine Modifikation des CMS entstand, kann man so auf das Problem stoßen, sofern man dieselbe Änderung nicht auch beim frisch installierten System vorgenommen hat.
 
Zurück
Oben