Remote exploit unter class.inuse.php

Evert · Beitrag von **Evert** » So 25. Dez 2005, 12:26

saluzusammen,

mein server mit contenido 4.4 wurde soeben gehackt mittels einem remote exploit im class.inuse.php wegen fehlernder input validierung

ist das ein bekannter exploit? muss nun halt ueber weihnachten auf 4.6 aktualisieren.

gruss
Evert

Beitrag von **Dodger77** » So 25. Dez 2005, 15:09

http://www.contenido.org/forum/viewtopic.php?t=10737

Sonst ist natürlich auch die neue 4.6.4 zu empfehlen, soweit die verwendeten Module darunter laufen bzw. du evtl. Anpassungen durchführen kannst.

goach · Beitrag von **goach** » Mo 2. Jan 2006, 18:06

Mit 4.6.4 ist der exploit in class.inuse.php (und anderen) zwar behoben, ich habe aber leider noch einige Files entdeckt, die denselben Fehler aufweisen. Das sind

contenido/includes/include.con_subnav.php (besteht noch in 4.6.4)
contenido/includes/include.grouprights_subnav.php (besteht noch in 4.6.4)
contenido/includes/include.right_top_blank.php (besteht noch in 4.6.4)
contenido/includes/include.rights_subnav.php (besteht noch in 4.6.4)
contenido/includes/include.subnav.php (besteht noch in 4.6.4)
contenido/includes/include.tpl_subnav.php (besteht noch in 4.6.4)
contenido/includes/pseudo-cron.inc.php (besteht noch in 4.6.4, möglicherweise via crontab.txt hackbar)

Der exploit funktioniert nur wenn PHP mit register_globals=On und allow_url_fopen=On betrieben wird, was leider bei vielen Providern der Fall ist. Wenn's geht würde ich zumindest die allow_url_fopen auf Off stellen, da das meistens nicht benötigt wird und eine Menge Risiken birgt.

Weiters kann man noch mit .htaccess "Deny from all" Direktiven (in "classes", "contenido/includes", etc.) arbeiten, habe das aber noch nicht vollständig durchgetestet. Wäre toll wenn diese .htaccess files schon im Installationspaket in den Verzeichnissen vorhanden wären (die vorhandene "index.php" bringt sicherheitstechnisch nichts).

Manuell kann man oben genannte Lücken auch relativ rasch schließen, und zwar mit der Zeile (immer ganz oben einfügen):

Code: Alles auswählen

if ( $_REQUEST['cfg'] ) { exit; }	// workaround remote hacking exploit

Gerhard

Beleuchtfix · Beitrag von **Beleuchtfix** » Mi 4. Jan 2006, 18:16

Diese ganzen Änderungen habe ich in einem kleine Paket zusammengepackt. Wer diese Änderungen ausführen möchte, findet alle Daten unter:

http://www.f-be.de/contenido-forum/contenidofix.zip

Einfach entpacken und die alten Daten überschreiben. Einstiegsebene ist das Verzeichnis /contenido/

Gruß
Florian

Nachtrag:
Der XML Fehler ist behoben, das kam bei mir aus einem andern Modul.

Johni · Beitrag von **Johni** » So 8. Jan 2006, 18:27

Mhhh bei mir geht der XML download noch. Hab die Dateien ersetzt und auch eine htaccess datei erstellt.

Beitrag von **HerrB** » So 8. Jan 2006, 22:51

Kannst Du mal den Inhalt Deiner htaccess posten?

Gruß
HerrB

DoroM · Beitrag von **DoroM** » Fr 3. Feb 2006, 12:02

Ja, bitte mir auch.
Wie sieht´s denn eigentlich mit den ganz alten Versionen aus?
4.1 oder 4.2. Vor allem, wenn der Hoster allow_url_fopen und register_globals auf on stehen hat und lässt.
Was kann man da machen?
.htaccess schätze ich, am besten, oder?

marphin · Beitrag von **marphin** » Di 14. Feb 2006, 14:22

Hallo,

ich habe die Dateien in der 4.6.4 nun auch ausgetauscht. Kann mir bitte jemand die htaccess posten und sagen, in welchem Verzeichnis die liegen muss?

Wie kann ich überprüfen, ob eine Seite vor Angriffen geschützt ist, letzte Woche hat jemand eine 4.6.2 Version gehackt?

Beleuchtfix · Beitrag von **Beleuchtfix** » Mi 22. Feb 2006, 22:48

Ich habe "meine" Änderungen noch einmal auf ein anderes System überspielt. Auch hier kann ich wieder keinen XML Export durchführen, Import geht.
Fehlermeldung:

Code: Alles auswählen

Fatal error: Call to undefined function: uplcreatefriendlyname() in /www/htdocs/w00592c6/contenido/includes/include.mod_edit_form.php on line 54

Hat jemand eine Idee, woher das kommt.
Gruß
Florian

rob1 · Beitrag von **rob1** » Mi 1. Mär 2006, 15:13

Hallo

goach hat geschrieben: Der exploit funktioniert nur wenn PHP mit register_globals=On und allow_url_fopen=On betrieben wird, was leider bei vielen Providern der Fall ist. Wenn's geht würde ich zumindest die allow_url_fopen auf Off stellen, da das meistens nicht benötigt wird und eine Menge Risiken birgt.

habe ich das richtig verstanden, sobald die register_globals auf off steht sind die sicherheitslücken auch automatisch geschlossen, ohne die dateien zu aktualisieren?

Gruss Robert

Beitrag von **HerrB** » Sa 4. Mär 2006, 01:02

Yep. allow_url_fopen = off ist aber auch eine gute Idee.

Gruß
HerrB

rob1 · Beitrag von **rob1** » So 5. Mär 2006, 13:49

super, hab ich gemacht.danke!

CONTENIDO Forum

Remote exploit unter class.inuse.php

Remote exploit unter class.inuse.php

Remote exploit auch in 4.6.4

Re: Remote exploit auch in 4.6.4