PHP-Angriff auf Server?

[Fabienne]

Hallo und guten Abend,

gibt es eine Möglichkeit von außen PHP-Dateien auf einem anderen Webserver abzulegen?
Auf meinem Server sind auf einmal einige Dateien aufgetaucht, die mit folgender Zeile beginnen:

$version = "PHP Agent Version (c) ".'s'.'o'.'l'.'o'.'s'.'t'.'e'.'l'.'l'." 2007";

Mehr möchte ich nicht darstellen, um den offensichlich bösartigen Code nicht weiter zu verbreiten.
Wie zum Teufel kommt so was auf meinen Server? SafeMode ist on!
Kann man in Verzeichnisse mit 777 auch von extern (also von einem anderen Server aus) Dateien ablegen?

Vielen Dank für Eure Antworten!
Fabienne

[Johannes Zeller]

Hallo Fabienne,

gibt es eine Möglichkeit von außen PHP-Dateien auf einem anderen Webserver abzulegen?

Wenn jemand Zugriff auf deinen Server bekommen hat, z.B. durch eine Sicherheitslücke, dann ja. Ansonsten nein.

Auf meinem Server sind auf einmal einige Dateien aufgetaucht, die mit folgender Zeile beginnen:

$version = "PHP Agent Version (c) ".'s'.'o'.'l'.'o'.'s'.'t'.'e'.'l'.'l'." 2007";

Mehr möchte ich nicht darstellen, um den offensichlich bösartigen Code nicht weiter zu verbreiten.

Wenn du den Code lediglich hier ins forum postest, wird er keinen Schaden anrichten können.

Wie zum Teufel kommt so was auf meinen Server? SafeMode ist on!
Kann man in Verzeichnisse mit 777 auch von extern (also von einem anderen Server aus) Dateien ablegen?

Normalerweise nicht, jedenfalls nicht unbefugt. Ich würde an deiner Stelle mal mit dem Admin von deinem Server reden und den fragen, was er davon hält. Der kennt auch die Konfiguration des Servers und kann so herausfinden, wo die Schwachstelle, über die sich ein Angreifer Zugriff verschaffen kann, liegt.

Schöne Grüße,

Johannes

[Tom]

Hello,

Mehr möchte ich nicht darstellen, um den offensichlich bösartigen Code nicht weiter zu verbreiten.

Wenn du den Code lediglich hier ins forum postest, wird er keinen Schaden anrichten können.

Er sollte vor allem mal sein Upload-Script für die Bilder hier posten und diskutieren.
Das ist ja wohl der Knackepunkt.

Und dann sollte er schauen, dass in Bilderverzeichnissen keine Dateien geparst werden, wenn man sie als Ressource über HTTP direkt anspricht. Das kann er sicherlich mit .htaccess und einem LIMIT-Eintrag ändern.

Im übrigen wäre das auch eine gute Idee für alle Provider, ihren Usern in der Standard-Server-Einrichtung ein Verzeichnis "Bilder" zur Verfügung zu stellen, in dem (nebst Unterverzeichnissen) die eingerichteten Parser nicht tätig werden.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Er sollte vor allem mal sein Upload-Script für die Bilder hier posten und diskutieren.
Das ist ja wohl der Knackepunkt.

Nein, das ist absolut nicht gesichert.

- Sven Rautenberg

[Tom]

Hello,

Er sollte vor allem mal sein Upload-Script für die Bilder hier posten und diskutieren.
Das ist ja wohl der Knackepunkt.

Nein, das ist absolut nicht gesichert.

Was ist nicht gesichert? Dass es der Knackepunkt ist, den er uns bisher schon mitgeteilt hat?
Oder meinst Du jetzt, dass es der der einzige Knackepunkt sein kann.
Da stimme ich Dir natürlich zu.

fopen-Wrapper, include über Namen, die per Parameter übergeben werden usw... da gibt's genügend weitere Möglichkeiten.

Aber Fabienne hatte in
https://forum.selfhtml.org/?t=159787&m=1039442
geschrieben: "Außerhalb gibt es einige Verzeichnisse mit 777, in die durch PHP z.B. Bilder reinkopiert (nach Upload) werden."

Das hat mich veranlasst, doch zumindest erstmal nach diesem Scriptstückchen zu fragen.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Fabienne]

Hi Tom,

den Ansatz mit der htaccess-Datei (nur Bilddateien zulassen) hatte ich auch schon. Werde ich umsetzen.

Der Upload findet hinter einer htacces-Barriere statt.
Ergo muss der Angriefer das Passwort ausspähen. Das gleiche könnte er auch bei der FTP-Übertragung machen.
In diesem Fall brauche ich nicht mehr über Sicherheitslücken in Skripten suchen, wenn der Angreifer direkten Zugang via FTP zum Server bekommen.

Mein einziger Ansatzpunkt: meine Haupt-CMS-Datei.
Ich "escape" alle Parameterübergaben an die DB mit mysql_real_escape_string().
Denke, das reicht, oder etwa nicht?
Im Filesystem wird in der Ausgabedatei nicht gearbeitet.
Alle verwendeten Variablen setze ich vorher immer auf "" (z.B. $var="";), zusätzlich zu globals=off.
Bin ratlos.

Viele Grüße
Fabienne

[Sven Rautenberg]

Moin!

Mein einziger Ansatzpunkt: meine Haupt-CMS-Datei.

Dessen Quellcode hätte ich gerne gesehen.

Ich "escape" alle Parameterübergaben an die DB mit mysql_real_escape_string().
Denke, das reicht, oder etwa nicht?

Das ist einer von vielen Angriffspunkten, die man beachten muß, aber bei weitem nicht der einzige.

- Sven Rautenberg

[Fabienne]

Hallo Sven,

Dessen Quellcode hätte ich gerne gesehen.

[LINK:http://mitglied.lycos.de/fabienne22/cms_main.txt@title=Hier ist er...]

Viele Grüße
Fabienne

[Fabienne]

Hallo Sven,

OK, nochmals:

Dessen Quellcode hätte ich gerne gesehen.

Hier ist er...

Viele Grüße
Fabienne

[Sven Rautenberg]

Moin!

Dessen Quellcode hätte ich gerne gesehen.

Hier ist er...

Danke.

Ich habe keine offensichtlichen Angreifbarkeiten feststellen können. Es werden einige andere Dateien included, aber mindestens mit statischem Präfix im Dateinamen, so dass Codeinclude von externen Quellen unmöglich ist. Sofern die eingebundenen Dateien ebenso aufgebaut sind, wie diese zentrale Datei, sehe ich keine offensichtliche Angreifbarkeit durch dieses Skript.

Es empfiehlt sich, die Suche nach Einfallstoren zunächst auf andere Möglichkeiten zu konzentrieren. In diesem Code weiterzusuchen wäre ziemlich aufwendig (so wahnsinnig schön geschrieben ist er dann doch nicht) und vermutlich nicht von Erfolg gekrönt.

- Sven Rautenberg

[Fabienne]

Hallo Sven,

Ich habe keine offensichtlichen Angreifbarkeiten feststellen können. Es werden einige andere Dateien included, aber mindestens mit statischem Präfix im Dateinamen, so dass Codeinclude von externen Quellen unmöglich ist. Sofern die eingebundenen Dateien ebenso aufgebaut sind, wie diese zentrale Datei, sehe ich keine offensichtliche Angreifbarkeit durch dieses Skript.

Vielen Dank für Deine Bemühungen!
Die anderen Dateien sind ähnlich aufgebaut.

Wenn ich was gefunden habe, laß ich es Euch wissen.

Viele Grüße
Fabienne

[Fabienne]

Nochmals hi Tom,

den Ansatz mit der htaccess-Datei (nur Bilddateien zulassen) hatte ich auch schon. Werde ich umsetzen.

Wie fändest Du als Quick-and-Dirty-Lösung eine Rewrite-Rule:

RewriteRule ^(.*).php$ $1.jpg

Damit wären alle php in jpgs umfunktioniert bzw. die php-Files wären nicht mehr abrufbar.

Viele Grüße
Fabienne

[Bio]

Sup!

Kann man in Verzeichnisse mit 777 auch von extern (also von einem anderen Server aus) Dateien ablegen?

Wenn Du ein anonymes FTP-Login erlaubst ja. Sonst würde man dazu ein unsicheres PHP-Skript brauchen, dass auf Deinem Server läuft.

Gruesse,

Bio

[Sven Rautenberg]

Moin!

gibt es eine Möglichkeit von außen PHP-Dateien auf einem anderen Webserver abzulegen?

Es gibt zahlreiche Einfallstore, die man nutzen kann, sofern bei der Konfiguration und Pflege des Servers durch den Admin, bei der Programmierung von genutzten Skripten oder durch Nachlässigkeit bei der Passwortwahl Angriffspunkte entstanden sind.

Wie zum Teufel kommt so was auf meinen Server? SafeMode ist on!

SafeMode in PHP fügt lediglich ein paar Prüfungen hinzu und schaltet ein paar potentiell gefährliche Funktionen ab - sorgt aber keinesfalls dafür, dass auf einen Schlag alles "sicher" ist. Wenn du fehlerhafte, angreifbare Skripte verwendest, nützt dir der SafeMode absolut gar nichts. Und wenn irgendwo anders die Schwachstelle liegt, und PHP gar nicht genutzt wurde, ist das natürlich noch irrelevanter.

Kann man in Verzeichnisse mit 777 auch von extern (also von einem anderen Server aus) Dateien ablegen?

Nein, ohne zusätzliche Angriffsmöglichkeit kann man das nicht. Aber wenn man das bei dir konnte, ist Alarmstufe Rot eigentlich noch zu niedrig.

- Sven Rautenberg

[Fabienne]

Hallo Sven,

Nein, ohne zusätzliche Angriffsmöglichkeit kann man das nicht. Aber wenn man das bei dir konnte, ist Alarmstufe Rot eigentlich noch zu niedrig.

Jop. Bei mir ist schon Alarmstufe "tiefrot" angesagt!

Ich habe mir ein eigenes CMS programmiert.
Alle Skripte sind im Verzeichnis "admin", das durch htaccess geschützt ist. Außerhalb gibt es einige Verzeichnisse mit 777, in die durch PHP z.B. Bilder reinkopiert (nach Upload) werden.
In diesen Verzeichnissen lagen diese ominösen Dateien.

Kann durch so etwas ein Backdoor-Skript eingeschleust werden?
(Vorausgesetzt htaccess-Passwort wurde nicht geknackt)?

Sonst gibt es keine Skripte, die auf diese Verzeichnisse zugreifen.

Was ist alles im Safemode gesperrt?

Hier steht das Script auch schon im Netz:
http://www.menola.org/~matjaz/images/info/o_meni/config.inc.php
Kann das im Safemode großen Schaden anrichten?

Vielen Dank für den schnellen Support!
Fabienne

[Johannes Zeller]

Hallo Fabienne,

Kann durch so etwas ein Backdoor-Skript eingeschleust werden?
(Vorausgesetzt htaccess-Passwort wurde nicht geknackt)?

Das kann man definitiv nur beanworten, wenn man weiß, wie genau der Server konfiguriert ist. Ich kann deshalb nur wiederholen: Wende dich an denjenigen, der den Server administriert.

Sonst gibt es keine Skripte, die auf diese Verzeichnisse zugreifen.

Was ist alles im Safemode gesperrt?

Das wird im PHP-Handbuch erklärt. Safe Mode behandelt aber nur Probleme, die beim Betrieb von PHP auf Servern, die du dir mit anderen Benutzern teilst, entstehen können und das auch nur unzureichend. Nicht umsonst gibt es den Safe Mode ab PHP 6 nicht mehr.

Schöne Grüße,

Johannes

[Sven Rautenberg]

Moin!

Ich habe mir ein eigenes CMS programmiert.

Das bietet dann vermutlich Angriffspunkte.

Alle Skripte sind im Verzeichnis "admin", das durch htaccess geschützt ist.

Wie kommen die Inhalte, die im CMS gespeichert sind, denn in die Welt hinaus?

Außerhalb gibt es einige Verzeichnisse mit 777, in die durch PHP z.B. Bilder reinkopiert (nach Upload) werden.
In diesen Verzeichnissen lagen diese ominösen Dateien.

Das mag vermutlich dann der einzige Ort sein, in dem man im Safe-Mode was speichern kann.

Kann durch so etwas ein Backdoor-Skript eingeschleust werden?
(Vorausgesetzt htaccess-Passwort wurde nicht geknackt)?

Das gehackte Passwort wäre der zweite Ansatzpunkt. Prüfe deine Server-Logs. Alle Zugriffe auf den Admin-Bereich werden dort, mit Username, geloggt und können nachvollzogen werden. Deinen eigenen IP-Raum kennst du - Zugriffe von anderen IPs, oder häufigere Versuche von anderen IPs, die mit 401-Status abgewiesen werden, deuten direkt auf diesen Weg des Hackens hin.

Sonst gibt es keine Skripte, die auf diese Verzeichnisse zugreifen.

Quellcode?

Kann das im Safemode großen Schaden anrichten?

Es ist unerheblich, ob dieses Skript böse sein kann oder nicht. Es hat zumindest ausreichend Prüfungen integriert, um auf allen bekannten Wegen beliebigen Code ausführen zu können (ganz am Anfang wird auf Verfügbarkeit aller möglichen Funktionen wie exec, passthru etc... geprüft).

Wichtiger ist, wie dieses Skript auf deinen Rechner kommen konnte. Egal ob DIESES Skript böse ist - irgendwas auf deinem Server ist derzeit EBENFALLS und mit Sicherheit böse.

- Sven Rautenberg

[Tom]

Hello,

[...] Außerhalb gibt es einige Verzeichnisse mit 777, in die durch PHP z.B. Bilder reinkopiert (nach Upload) werden.
In diesen Verzeichnissen lagen diese ominösen Dateien.

Das liegt dann an einer Lücke in Deinem Upload-Script.

Dieses muss selbstverständlich prüfen, ob es ein Bild ist, das hochgeladen worden ist, und darf es nur dann aus dem _geschützten_ Temporärverzeichnis in das Bild-Ablageverzeichnis überstellen.

Wenn das Bildablageverzeichnis direkt über HTTP erreichbar ist, und für dieses auch die "normalen" Einstellungen gelten, dass php-Dateien geparst werden, ist Dein System ziemlich offen. Der Angreifer kann dann über dieses eingeschleuste Script auch weitere nachladen und kann auf alles zugreifen, was der Webserver-User mittels PHP erreichen kann.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Fabienne]

Hi Tom,

Dieses muss selbstverständlich prüfen, ob es ein Bild ist, das hochgeladen worden ist, und darf es nur dann aus dem _geschützten_ Temporärverzeichnis in das Bild-Ablageverzeichnis überstellen.
Wenn das Bildablageverzeichnis direkt über HTTP erreichbar ist, und für dieses auch die "normalen" Einstellungen gelten, dass php-Dateien geparst werden, ist Dein System ziemlich offen. Der Angreifer kann dann über dieses eingeschleuste Script auch weitere nachladen und kann auf alles zugreifen, was der Webserver-User mittels PHP erreichen kann.

In dem Upload-Script wird auf die Endung geprüft, danach wird das Bild (es handelt sich ja um Bild-Uploads) mit Copyright-Wasserzeichen versehen und entsprechend skaliert. Das sollte mit keiner PHP-Datei möglich sein.
Im Fehlerfall wird die Datei nicht in das http-externe Verzeichnis kopiert.

In der Haupt-CMS-Datei werden "nur" Datenbankabfragen getätigt, keine File-Funktionen aufgerufen.

Wie funktioniert PHP-Injektion?
Wäre es denkbar, dass der Angreifer bösartigen Code eingeschleust hat, um danach seine Skripte hochzuladen?

Mein Admin sagt, dass PHP (und der Server) nach bestem Wissen und Gewissen dicht ist (eher zu dicht). Hauptangriffspunkt könnte die unverschlüsselte FTP-Übertragung sein, bei der man leicht das Passwort ausspähen könnte.

Ich lade gerade die LOG-Files runter. Danach weiß ich hoffentlich mehr.

Viele Grüße
Fabienne