Veränderte index-seiten

D

DomiOh

New Member
Hallo,

zuerst möchte ich sagen, dass ich neu hier bin und alle erstmal herzlich begrüßen.
Natürlich habe ich mich nicht ohne Hintergedanken hier im Forum angemeldet, sondern hoffe, dass ihr mir helfen könnt.
Ich habe einen v-Server mit Rootzugriff auf dem 4 Domains gehostet habe.

Bei einer Domain ist es nun so, dass ALLE index-dateien (sowohl index.htm, index.html als auch index.php) verändert wurden.
Und zwar wurde der body-tag um eine "OnLoad" direktive verändert, so dass eine Spyware geladen wird.
Dabei wurden auch index-Seiten verändert, die eigentlich gar nicht erreichbar - also absolut unbekannt und nirgendwo verlinkt oder verwendet werden - verändert.

Meine Frage: Wie war es möglich, die gesamte Verzeichnisstruktur zu scannen und zu verändern? Wie schütze ich mich dagegen?

PS: Das anzeigen eines Verzeichnisindex ist im Apache abgeschaltet.

Ich hoffe ihr könnt mir helfen.

Gruß,
DomiOh
 
Übliches Einfallstor dafür sind unsichere Scripte, welche durch den Webserver ausgeführt werden und entsprechende Schreibberechtigungen für die jeweiligen Dateien haben oder ein gehackter FTP Zugang.
 
Scripts laufen auf dieser Seite derzeit keine.

Aber ich habe auf diesem Server dieses Sicherheitsloch beim proFTP gehabt, was inzwischen wohl behoben sein sollte.

@Firewire2002: Danke für die Infos.
Gibt es evtl. noch Einstellungen im PHP die geändert werden sollten?
 
Last edited by a moderator:
Ähm, wenn du 'ne index.php auf dem Server hast, ist das ein Script...
Wenn du ein Sicherheitloch im ProFTPd hattest, weißt du sicher, ob dieses auch nicht ausgenutzt wurde? Was nützt es, die Lücke zu schließen, wenn sie schon einer genutzt hat, um sich Zugang zu verschaffen und sich eine Backdoor o.ä. installiert hat.
 
Die Index.php wird aber nirgendwo ausgeführt, noch ist sie unter normalen Umständen ausführbar, da sie in einem Verzeichnis liegt, was eigentlich niemand kennen kann. Sie dient nur zu Testzwecken derzeit.

Die einzige erreichbare Datei ist eine index.html im root-verzeichnis der Domain, und diese zeigt nur ein Bild an.

Ich habe auf dem Server - wie vom Hoster empfohlen - chkrootkit ausgeführt ohne ein nenneswertes Ergebnis (also alles clean).
Die FTP-Zugänge sind geändert, sprich Login geändert.

Ich bin zwar eigentlich nicht dumm, habe aber, was das Webhosting angeht noch wenig Erfahrung.
Was kann ein PHP-Script unsicher (bzw. sicher) machen?
 
chkrootkit bringt dir keine Sicherheit, denn wenn jemand in dein System eingebrochen ist, dann kann er ja auch solche Tools austauschen und damit ein sauberes System vorgaukeln. Ist wie bei einem Virenscanner - der erkennt ja auch nur die Viren, die er kennt und ggfl. greift noch eine Heuristik gegen unbekannte Viren - die aber auch nicht alles erkennt.
Was den Aufruf der index.php betrifft: Nur weil sie nirgends verlinkt ist, heißt es nicht, daß sie nicht gefunden werden kann - und wenn der Verzeichnisname erraten wurde.
Was Script-Sicherheit betrifft, gilt das folgende für jede Scriptsprache, also auch Perl, Python, etc.: Alles was vom Benutzer kommt, die potenziell ein Risiko. Du mußt also alles, was per GET/POST/Cookie kommt, sehr genau überprüfen. Wenn du das nicht tust, hast du schneller eine Remote-Inclusion-Lücke oder SQL-Injection-Lücke in deinem Script, als dir lieb ist.
 
Wobei du mit einer SQL-Injection noch keinen aktiven Code auf den Server bringst, es sei denn, dass du Scripte hast, die von dort gelesenen Code ausführen. Dann müsste dein Angreifer den Code aber sehr genau kennen.

Meine Frage wäre jetzt, ob du dir schonmal die Log-Dateien angesehen hast. Eventuell verraten sie etwas darüber, wie Mr. X reingekommen ist. Wenn sich die Änderungen auf einen einzelnen vHost beschränken, hast du denke ich gute Karten das Problem einzugrenzen.
 
Last edited by a moderator:
Dein ungebetener Besucher kann sich ueber einen Virus auf deinem oder einem anderen Rechner eingenistet haben welcher entweder selbststaendig die Dateien ueber FTP veraendert oder die abgelauschten Zugangsdaten an seinen Herrn weiterleitet.
Entsprechender Payload war einige Zeit in Viren verbreitet welche sich ueber Instant-Messaging (ICQ,MSN,...) verbreiten, wie es aktuell ist weiss ich nicht.
 
Bachsau said:
Wobei du mit einer SQL-Injection noch keinen aktiven Code auf den Server bringst, es sei denn, dass du Scripte hast, die von dort gelesenen Code ausführen.
Click to expand...

Das ist meist der Sinn, wenn eine Webseite Daten in einer Datenbank speichert, daß sie von dort auch wieder abgerufen werden. Da viele Seite fertige Scripte einsetzen, ist es auch oft nicht so schwer, diese auszunutzen, wenn sie denn Lücken enthalten. Reicht ja schon, wenn man dort ein bißchen Java-Script einschmuggeln kann - ein ungepatchter Browser und ein neue PC ist verseucht...
Und mit Remote-Injection kann natürlich auch direkt der Server betroffen sein.
ABER: Der Server hatte eine offene Sicherheitslücke im ProFTPd, die sehr aktiv ausgenutzt wurde. Bisher lese ich nur, daß die Lücke geschlossen sein sollte (ja wie jetzt - sollte oder ist geschlossen?) wurde und der Server einmal mit chkrootkit gescannt - damit ist das System in meinen Augen nicht sauber!
 
Zugegeben: Mein Beispiel paßt nicht ganz zum Begriff "SQL-Injection" (gehört eher in die Rubrik XSS), denn mit einer richtigen SQL-Injection-Lücke kann ich eigene SQL-Befehle auf dem Server ausführen. Reicht ja schon, wenn ich das Passwort vom Admin des eingesetzten CMS änder und mit so in diesem einloggen kann - das reicht voll und ganz aus, um ordentlich Schaden zu verbreiten...

Aber Back2Topic: Vielleicht schreibt der TE ja mal, was er alles unternommen hat, nachdem ihm die ProFTPd-Lücke bekannt war, um dieser zu begegnen.
 
You must log in or register to reply here.
Back
Top