Massive Ausnutzung von Schwachstellen in PHP-Skripten

[andreask2]

Hi!

Das DFN-CERT hat eine Warnung ausgegeben, da sie zur Zeit "eine massive Ausnutzung von Schwachstellen in unsicheren PHP-Skripten auf Webservern" beobachten:

http://cert.uni-stuttgart.de/archive/wi ... 00015.html

Ich denke das kann man nur unterstreichen. Man sollte wirklich vorsichtig sein, vor allem mit oft verwendeten Paketen(PHP Nuke...) dessen Quellen offen liegen. Aber auch bei eigenen Scripten sollte man sich informieren und aufpassen was man da macht.

Ein paar Links zur PHP-Sicherheit hatte ich oben mal gepostet: http://www.rootforum.org/forum/viewtopi ... 352#183352

Grüße
Andreas

[floschi]

HMan sollte wirklich vorsichtig sein, vor allem mit oft verwendeten Paketen(PHP Nuke...) dessen Quellen offen liegen.

Die Offenheit einer Quelle tut normalerweise nichts zur _un_sicherheit.

[andreask2]

Die Offenheit einer Quelle tut normalerweise nichts zur _un_sicherheit.

Wenn es genügend gute Leute gibt die solche Quellen überprüfen und Fehler melden/verbessern, stimmt das ja. Ist aber anscheinend bei solchen Projekten nicht der Fall. Prinzipiell macht man es böswilligen Leuten einfacher, Schwachstellen zu finden. Wenn dann der Code nicht entsprechend besser ist/besser überprüft wird als bei nicht offener Software, haben alle die das einsetzen ein Problem. Das geht ja schon seit Jahren so dass immer wieder neue Schwachstellen entdeckt werden. Und es werden auch neue eingebaut... Natürlich, wenn die Software closed source wäre, dann wären die Sicherheitslücken immer noch da, und gerade bei Web-Scripten ist es erheblich einfacher Schwachstellen zu finden/zu erraten, als z.B. Buffer-Overflows zu finden (was aber auch funktioniert, siehe MS-Produkte...).

Das 2. "Problem" ist die Verbreitung, je mehr Leute sich sowas installieren, desto interessanter wird es hier Schwachstellen zu finden, da sie sich dann einfach in vielen anderen Installationen ausnutzen lassen. Bestes Beispiel ist Windows. Bestes Gegenbeispiel ist der Apache 1.3! Aber wie gesagt, hier entwickeln andere Leute, und hier schauen auch andere Leute über den Code als bei PHP-irgendwas.

Auch sind die derartige Schwachstellen allgemein bekannt, was aber viele Anwender anscheinend nicht davon abhält einmal eine Version zu installieren, und sich nachher kein Stück mehr drum zu kümmern. Dann können die Autoren natürlich Bugs beheben wie sie wollen...


Grüße
Andreas

[Joe User]

Das DFN-CERT hat eine Warnung ausgegeben, ...

Wenn ich die entsprechenden Threads im RF betrachte, ist das für mich eine verspätete Sommerloch-News ;)

[captaincrunch]

Auch, wenn's nicht 100%ig passt, vieleicht doch recht interessant für den einen oder anderen: http://lists.netsys.com/pipermail/full- ... 27156.html

[andreask2]

Auch, wenn's nicht 100%ig passt, vieleicht doch recht interessant für den einen oder anderen: http://lists.netsys.com/pipermail/full- ... 27156.html

;-) Wo denkst Du hin?

Code: Select all

# php -v
PHP 4.3.9 (cli) (built: Sep 29 2004 13:28:43)

Allerdings hatte ich mir, und auch die Gentoo-Leute sich Zeit gelassen, weil sowas IMHO nicht wirklich aus den Release-Notes hervorging!

[thomas80]

Hi,

genau diesen IRC-Bot hatten wir jetzt auf unserem Webserver am Lehrstuhl...und da ich ab dieser Woche Sysadmin bin und gerade den Server neuinstalliere, wollte ich Euch mal um Rat fragen:

Das Problem ist, dass auf dem Server jede Menge php-Code läuft, der von Leuten stammt, die nicht mehr am Institut sind (z.B. von meinem Vorgänger)...es ist also nicht oder nur schwer möglich, sich das alles anzuschauen um evtl. Sicherheitslöcher in den Scripten selbst zu entdecken...

Ich habe vor, zunächst folgendes zu unternehmen: Abgesehen von Woody und einem aktuellen Kernel werde ich php als cgi über suphp laufen lassen und zusätzlich die Rechte für den Dateiupload weiter einschränken bzw. mit (neuen) .htaccess-Passwörtern versehen.

Ich wollte auch grsecurity installieren und mal fragen, ob der nur auf Mehrbenutzersystemen was bringt, oder auch, wenn jemand versucht, sich z.B. über eine hochgeladene bash zu rooten??

Ausserdem wird der Server in einem eigenen Subnetz laufen und von selbst generell keine Verbindungen nach aussen mehr initialisieren können...dadurch wird er zumindest nicht mehr als Spambot oder DDoS-Bot verwendbar sein.

Hat jemand noch weitere Tipps / Ideen??

Gruß, Thomas

[Roger Wilco]

Ich wollte auch grsecurity installieren und mal fragen, ob der nur auf Mehrbenutzersystemen was bringt, oder auch, wenn jemand versucht, sich z.B. über eine hochgeladene bash zu rooten??

Nun, GRSecurity, SELinux, RSBAC und wie sie alle heissen bringen richtig konfiguriert (!) schon sehr viel, wenn du weißt, auf welche Dateien ein Prozess zugreifen darf bzw. muss, und eine entsprechende Policy schreiben kannst. Die richtige Konfiguration erfordert jedenfalls eine gewisse Einarbeitungszeit in die betreffende Technologie.

Hat jemand noch weitere Tipps / Ideen??

• PHP-Funktionen abschalten, die das Ausführen von Programmen im System ermöglichen, z. B. exec(), system() usw.
• fopen() auf lokale Dateien einschränken und keine URLs erlauben. Das ist seit PHP 4.3.7 glaube ich standardmäßig in der php.ini gesetzt.
• register_globals auf Off setzen. Das schaltet zwar einige (schlecht programmierte) Skripte aus, aber man weiß dann wenigstens, wo die einzelnen Variablen herkommen. Seit PHP 4.3.8 ebenfalls Standard in der php.ini.
• Keinen Compiler, wget usw. für normale Benutzer bzw. die Benutzer des Webservers anbieten. Somit liegt die Schwelle, etwas auf den Server zu laden und ein Exploit o. ä. zu kompilieren etwas höher.

[andreask2]

• PHP-Funktionen abschalten, die das Ausführen von Programmen im System ermöglichen, z. B. exec(), system() usw.

Und was macht man mit `` ? Ich z.B. brauche diese Funktionen leider gelegentlich.

[*]fopen() auf lokale Dateien einschränken und keine URLs erlauben. Das ist seit PHP 4.3.7 glaube ich standardmäßig in der php.ini gesetzt.

Ja, das ist eine gute Idee. Aber Standard ist es leider noch nicht: http://cvs.php.net/annotate.php/php-src ... 1.2.24#494

[*]register_globals auf Off setzen. Das schaltet zwar einige (schlecht programmierte) Skripte aus, aber man weiß dann wenigstens, wo die einzelnen Variablen herkommen. Seit PHP 4.3.8 ebenfalls Standard in der php.ini.

Ebenfalls eine gute Idee, und sogar seit PHP 4.2.0 schon Standard, aber aus Kompatibilitätsgründen hat sich bisher kaum ein Provider umgestellt...
http://de3.php.net/ChangeLog-4.php#4.2.0

[s4fuser]

Ich kann diese Meldung bestätigen. Auch bei mir wurde ein Loch in PHP-Nuke ausgenutzt, um einen IRC-Bot zu installieren. Und auch gerade jetzt, nachdem ich die Site seit fast zwei Jahren auf dem Server betreibe.