Viren auf dem Server – meine Schuld?

[27apricot]

Hallo,

von einem Kunden, dem ich ein CMS programmiert habe, erhielt ich einen Anruf, dass Besucher seiner Seite beim Aufruf eine Virenmeldung bekämen. Und tatsächlich fand ich auf dem Server verschiedene Dateien (vor allem PHP, dazu zwei HTML-Dateien mit JS und eine JS-Datei) und Verzeichnisse, die nichts mit mit meinem CMS zu tun haben. Diese Dateien und Verzeichnisse liegen an verschiedenen Stellen, nur eine davon in einem Verzeichnis, in das der Betreiber der Seite im internen Bereich Dateien hochladen kann – allerdings werden dort von meinem Script nur Bild-Dateien (JPG/GIF/PNG) zugelassen. Eine Einbindung der fremden Dateien in meine Scripte ist zudem nicht auffindbar.

Der interne Bereich ist nirgends öffentlich verlinkt und mit einer einfachen Session-basierten Anmeldung zugangsgeschützt. Im Frontend gibt es keinerlei Formulare, über die Dateien auf den Server geladen werden können. Die Scripte liegen auf einem Server bei 1und1, auf dem Safe-Mode Off ist. Sämtliche Verzeichnisse des CMS haben die Zugriffsrechte 755, die Dateien 644. Auch die Verzeichnisse, in die der Betreiber der Seite Dateien laden kann, sind auf 755 gesetzt.

Dieses Problem ist bisher noch nirgendwoanders aufgetaucht. Das CMS wird inzwischen unter ca. 10 verschiedenen Domains genutzt. Allerdings liegen die in der Regel bei Providern, auf deren Servern der Safe-Mode angeschaltet ist. Dort muss ich auch die Upload-Verzeichnisse auf 777 setzen.

Kann diese Sicherheitslücke in meinen Scripten liegen oder liegt das am ausgeschalteten Safe-Mode auf dem Server? Grundsätzlich: ist es unklug, die Upload-Verzeichnisse, in die aus dem internen Bereich Dateien geladen werden können, auf 777 zu setzen?

Vielen Dank im Voraus und schöne Grüße,
27apricot.

 

[KD3]

Ich will dich persönlich oder sonst wie Angreifen, aber es ist deine Schuld, kann aber auch an der Server Konfiguration liegen, hängt davon ab was für Dienste laufen und ob der Apache Server richtig konfiguriert wurde. Es könnte folgendes passiert sein:

Entweder der Cracker hat eine normale Sicherheitslücke im Script gefunden und hat sich die Adminrechte "angeeignet" und hat dann eine PHP Datei mit Schadcode hochgeladen, oder er hat eine RFI Lücke gefunden und einfach die Datei eingeschleust weil die php.ini nicht richtig eingestellt war. Es kann aber auch sein, dass er über ne LFI die etc/passwd und etc/shadow datei bekommen hat und da die root-rechte hatte..... Es gibt viel mehrere Methoden aber das sind die Standardmethoden, die der Cracker denk ich mal benutzt hat.

Zu den JS-Viren: Die JS-Viren wie mpack oder jikto werden schon längst erkannt, aber die neueren versionen noch nicht. Besser mal einen Full-Check starten

 

[27apricot]

Hallo KD3,

vielen Dank für deine Antwort. Ich hab’ tatsächlich eine Stelle gefunden, an der eine Datei aus einer URL-Angabe includiert wurde. Das wird mir nun nicht nochmal passieren. Verstehe ich es richtig, dass ein Angreifer über einen solchen Aufruf dann auch Dateien von seinem auf den angegriffenen Server laden kann?

Meinst du mit etc/passwd und etc/shadow solche Dateien, die von der .htaccess benutzt werden? Solche gibt es nicht, da die Anmeldung im internen Bereich über einen eingebauten Passwortschutz und nicht über Verzeichnisschutz funktioniert.

Jetzt trotzdem nochmal eine Frage: wie funktioniert es dann, dass ein Betrachter der Seite eine Virenwarnung bekommt? Der Betrachter ruft doch nur http://domain.tld/ ein und eben nicht http://domain.tld/?seite=http://boeseviren.tld/... auf?

Und noch etwas: ich habe jetzt außerdem eine php.ini erstellt, die safe_mode anschaltet, und register_globals und allow_url_fopen aus und diese im Root-Verzeichnis gespeichert. In diesem liegt die index.php von der aus sämtliche Inhalte angezeigt werden, auch solche, die von Dateien in Unterverzeichnissen generiert werden. Muss die php.ini trotzdem auch in die Unterverzeichnisse?

Schöne Grüße und Dank im Voraus,
27apricot

 

[KD3]

Verstehe ich es richtig, dass ein Angreifer über einen solchen Aufruf dann auch Dateien von seinem auf den angegriffenen Server laden kann?

In diesem augenblick bindest du die PHP Datei auf den angegriffenen Server. Wenn dein Apache so konfiguriert ist und die Funktion wie system() oder exec() noch funktionieren und nicht gesperrt sind kann es schlimm enden. Auch über SQL Injections sind PHP Datei erstellungen möglich(Dem ist es nicht so wenn gewisse Rechte nicht existieren wie z.B FILE). Sogar das herausfiltern der etc/passwd Datei ist über SQL möglich.....

Meinst du mit etc/passwd und etc/shadow solche Dateien, die von der .htaccess benutzt werden? Solche gibt es nicht, da die Anmeldung im internen Bereich über einen eingebauten Passwortschutz und nicht über Verzeichnisschutz funktioniert.

Die Usernamen und Passwörter die in der etc/passwd Datei sind für das Verwalten von Standardkennwörtern und Systemzugriff. Wenn einer in der lage ist, das Passwort zu knacken, dann hat er direkt alle Rechte auf dem Server. Das allergrößte Problem ist, dass die etc/passwd Datei auch im Arbeitsspeicher liegt und man durch eine bestimmte Adressierung die Datei bekommen könnte.

Jetzt trotzdem nochmal eine Frage: wie funktioniert es dann, dass ein Betrachter der Seite eine Virenwarnung bekommt? Der Betrachter ruft doch nur http://domain.tld/ ein und eben nicht http://domain.tld/?seite=http://boeseviren.tld/... auf?

Jeder weiß, dass JavaScript Dateien beim Clienten im Browser-Cache bis zum Beenden des Browsers sich befinden. (Praktisch gesehen auf der Platte) Somit ist schon Schadcode eingeschleust, aber zum Glück gibt es nette Anti-Virus oder Anti-Spyware Programme die direkt eingreifen und alles retten. Aber dennoch werden die neuesten Versionen von mpack und so noch nicht erkannt, also aufpassen welche Seite man besucht.

Und noch etwas: ich habe jetzt außerdem eine php.ini erstellt, die safe_mode anschaltet, und register_globals und allow_url_fopen aus und diese im Root-Verzeichnis gespeichert. In diesem liegt die index.php von der aus sämtliche Inhalte angezeigt werden, auch solche, die von Dateien in Unterverzeichnissen generiert werden. Muss die php.ini trotzdem auch in die Unterverzeichnisse?

Die php.ini existiert schon so auf deinem Server.

$ updatedb
$ locate php.ini

Alle Dateien bearbeiten und Apache neustarten

MfG
KD3

 

[27apricot]

Hallo KD3,

danke für die ausführlichen Antworten.

Jeder weiß, dass JavaScript Dateien beim Clienten im Browser-Cache bis zum Beenden des Browsers sich befinden. (Praktisch gesehen auf der Platte) Somit ist schon Schadcode eingeschleust, aber zum Glück gibt es nette Anti-Virus oder Anti-Spyware Programme die direkt eingreifen und alles retten. Aber dennoch werden die neuesten Versionen von mpack und so noch nicht erkannt, also aufpassen welche Seite man besucht.

Gut. Aber sorry, dass ich noch immer nicht verstehe, wie der Betrachter der Seite beim Aufruf der Seite die bösen Dateien mit aufruft. Wenn ich nur index.php aufrufe, können doch sonstwelche Dateien auf dem Server liegen, von denen der Browser in dem Moment gar nix weiß, oder? Solange diese nicht per include aufgerufen werden – oder im Falle von JS-Dateien eben im HTML-Header. Wo also werden beispielsweise die bösen JS-Dateien aufgerufen, damit der Browser überhaupt erstmal einen Grund hat, diese zu lesen und in den Cache zu schreiben?

Die php.ini existiert schon so auf deinem Server.
$ updatedb
$ locate php.ini

Alle Dateien bearbeiten und Apache neustarten

Die Seite ist ganz normal gehostet bei 1und1. Also nix Apache-Neustart ;-)
Ich habe das mit der eigenen php.ini in einem anderen Forum gelesen. Mit Hilfe von ini_get() habe ich es auch überprüft: die Server-Einstellungen sind tatsächlich überschrieben. Wollte nur wissen, ob ich das auch für die Unterverzeichnisse machen muss, in denen nur Dateien stehen, die in die index.php includiert werden (oder aber per HTML einzubindende Bilder), oder ob das hinfällig ist, da ja alles über die index.php aufgerufen wird.

Schöne Grüße,
27apricot.

 

[KD3]

Dann musst du dich beim 1und1 Support oder Kundendienst beschweren. An deiner stelle würd ich selber alles in die hand nehmen weil wenn man alles selber macht dann hat man ein reines gewissen, glaub mir Lern Linux zu Administrieren oder hol dir noch ein zusatz lapi worauf Linux installiert ist, die Distru. ist egal. Nachdem du ein halbes Jahr lang, Erfahrung in Linux gemacht hast und wenn schon einbisschen angepasst hast, könntest du überlegen dir einen eigenen Server von Strato zu besorgen Aber damit du so auch über die runden kommst, hilft eigentlich ini_set() aber wirklich helfen kann es auch nicht, denn du bist auf einem Server worin bestimmt auch 10 andere Kunden hosten(vielleicht mehr). Macht der eine einen Fehler, bricht alles zusammen. Deshalb weise am besten den Technischen Kundendienst über die mangelnde Sicherheit.

Gut. Aber sorry, dass ich noch immer nicht verstehe, wie der Betrachter der Seite beim Aufruf der Seite die bösen Dateien mit aufruft. Wenn ich nur index.php aufrufe, können doch sonstwelche Dateien auf dem Server liegen, von denen der Browser in dem Moment gar nix weiß, oder? Solange diese nicht per include aufgerufen werden – oder im Falle von JS-Dateien eben im HTML-Header. Wo also werden beispielsweise die bösen JS-Dateien aufgerufen, damit der Browser überhaupt erstmal einen Grund hat, diese zu lesen und in den Cache zu schreiben?

Der Angreifer hatte ja Rechte Dateien und Ordner beliebig zu löschen und zu verändern, also hat er einfach die PHP Dateien an verschiedenen stellen verändert und somit die JS-Viren eingebindet. Und diese JS Dateien werden auch bei jedem Abruf der PHP Datei geladen. Somit gelangt es dann in den Cache

 

[pamax]

Hey,

also die meisten "Hacker" sind zu dumm einen Server zu rooten. Sie suchen mit Hilfe von Google-Dorks Seiten, die RFI (Remote File Inclusion) anfällig sind. Dann binden sie eine Shell ein, mit der sie die meisten Dateien modifizieren können. Also kein Grund zur Panik!

mfg

 

[27apricot]

Hallo ihr,

danke für die Hilfe. Jetzt habe ich auch die modifizierten Dateien gefunden: es waren die CSS-Dateien, in die JS-Code hineingeschrieben war. Dieser wiederum war komplett in hexadezimalen Zeichen geschrieben, so dass natürlich auch meine verzeichnisweite Text-Suche nach den Einbindungen der Fremd-Dateien in die meinigen nix gebracht hat. Perfide, perfide.

Ich glaub’, das mit dem Linux-Lernen und dem eigenen Server geht mir ein bisschen zu weit. Ich mach’ das nur »nebenberuflich« und bin für mich selbst mit meinem Mac ganz zufrieden ;-) Und wenn meine Kunden noch keinen Hosting-Vertrag haben, empfehle ich sowieso einen kleineren Provider, bei dem all diese Sicherheitseinstellungen Standard sind. Dort gab es auch noch nie Probleme. Die eine dank KD3 gefundene RFI-Angriffsfläche werde ich natürlich trotzdem überall löschen und den Fehler auch sicher nicht nochmal machen.

Schöne Grüße,
27apricot.