Apache php sebezhetőség

Linux-security

Üdv mindenkinek !

Olyan problémám lenne, hogy van egy visszatérő pajtásom aki folyton be betör az apache-om ra. a /tmp és /var/tmp könyvtárokba ír, és botokat helyez el amikkel szépen floodol is. időről időre kilőttem a pidjüket, és eltávolítottam a botokat, de ujra visszatért az illető. Ekkor raktam fel suphp-t mert "aztmondták az jó". A probléma nem oldódott meg, csak annyiban hogy más könyvtárba írkál. www-data userként futtatja a filejait, szoval még nem szerzett más jogosultságot.

roundcube , drupal 6.9 , dragonfly cms, gamecontrolpanel van rajta. a dragonfly már maintenance módban fut, azthittem az a bugos, de ma reggel megint bejött a srác.

Itt vannak a verziók:

Server version: Apache/2.2.9 (Debian)
Server built: Jan 21 2009 00:10:51

PHP 5.2.6-1+lenny2 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 26 2009 21:54:14)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with the ionCube PHP Loader v3.1.33, Copyright (c) 2002-2007, by ionCube Ltd., and
with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies
with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies

Egyelőre ötletem sincs hogyan előzzem meg, mert a log fileban csak az van hogy leszedte ezt és ezt a filet, nem pedig az hogy hogyan és miként.
Ha tudnátok segíteni nagyon megköszönném!

device

  • 3010 megtekintés

( edaile | 2009. 02. 19., cs – 07:53 )

azt kellene megnézned, hogy amikor létrejönnek a bot fájljai, előtte milyen apache kérések futnak le. Így tudnád behatárolni, hogy mivel is van a baj, hogy min keresztül jön be a szerverre.

--
Ami elől menekülnek, az után szaladnak.

Ok, azt meg tudom nézni mikor jöttek létre, mert az error.log ba (érdekes hogy odairta) le van irva hogy mikor szedte le a fileokat. Viszont az hogy abban a pillanatban milyen parancs futott, azt hol tudom megnézni? illetve ha nincs "bekapcsolva" az a funkció akkor hogyan tudom elérni hogy írja?

Rendszerparancsok, php utasitások nincsenek logolva. Azt nezd meg az apache access logokban, hogy milyen normal lekeresek erkeztek be a fura aktivitas kozvetlenul megelozve. Nagy valoszinuseggel ott lesz a hunyo. Azaz ha 18:00-kor jottek letre a fileok a /tmp-ben es 17:59-kor van egy halom furca lekeres a drupalra, akkor bingo.
Egyebkent mindegyik alkalmazas frissitve van? Jogosultsagok megfeleloen vannak beallitva, pl. ugye nincs anonymous php content drupalban?
A php.ini-t is tesset megszigoritani, open_basedir es disable_funtions. Ha csak szimplan attersz suphp-re, attol nem lesz biztonsagosabb semmi sem.

Ha mar egyszer bejutottak a gepre, akkor siman elhelyezhettek hatso bejaratot barmelyik portalra. Egy ilyen utan illik mindent ujratelepiteni, csak statikus adatot (adatbazist) de semmi (forras)kodot atmasolni.

--
The Net is indeed vast and infinite...
http://gablog.eu

( wladek1 | 2009. 02. 19., cs – 08:13 )

Esetleg?

Részletek saját logomból a logwatch szerint: 

/round/CHANGELOG: 1 Time(s)
/roundcube/CHANGELOG: 1 Time(s)
/roundcubemail/CHANGELOG: 1 Time(s)

....

Persze nekem nincs ilyen stuff,sőt, a másik webmail stuff egy más porton futó másik apaccsal elérhető csak, de ha véletlenül elfelejtenék CVE -t keresni, a logwatch mindíg tudatja, hogy mégi kellene...:P

Tipp:
Ha beraksz az aktuális engine -re, amire tesztelsz egy Apache auth -ot, szvsz kiderülhet a turpisság (természetesen eddig nem használt user és pass párossal a .htpasswd -be, vagy ahonnan autholsz).

kötöjelkötöjel
Pedig ez nem az! - lécinetámagy! - ervéó

( andrej_ v | 2009. 02. 19., cs – 09:04 )

Az open_basedir és a disable_functions csodáit használod? Ez utóbbinál a passthru/shell_exec/exec/system quartettet alaphangon lődd ki. A suphp olyan sokminden ellen nem véd és ha www-data-val használod, akkor pláne.

Bónuszként a allow_url_include es allow_url_fopen -t is tedd off-ra.

Nagyon jó eséllyel eséllyel valamelyik oldalban van XSS hiba. Az apache access.logot meg tedd külön. Attól hogy vmi maintenance módban van, a bugjai még működni szoktak. Az apache konfigban tedd deny-ra átmenetileg, hogy mindenre forbiddent adjon az adott vhoston.

Ha már megvan a huncutság, akkor pedig mod_securityvel tudsz rule-t csinálni, illetve több más megelőző intézkedést tenni.

Ha Linux akkor az iptables-ben van modul, amivel pl. adott user _kimenő_ forgalmát tudod tiltani/engedni.

Nálunk a fentiek valamelyikén eddig még általában fennakadtak a T. jelentkezők, bár nemrég volt oldal ahol kérték az allow_url_fopent. Persze megfogadta az oldalgazda, hogy nem lehet kihasználni távolról, de persze ki lehetett, mint nemrég kiderült.

Esetleg meg a mod_itk utan erdemes nezegelodni.

andrej, ti hogy allitjatok be a open_basedir-t? Nyilvan engedni kell az adott vhost dirjeit... Amugy ez rekurziv? azaz ha engedem a /usr/share/php/valami mappat akkor a /usr/share/php/valami/mappa is engedve van?
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Rekurzív és : -al elválasztva lehet többet megadni. A /var/tmp (session_save_path miatt) és a saját home-ja (ezen belül upload dir van és több vhost könyvtára is lehet) van benne.

Az sem utolsó hogy a webszerver egy FreeBSD és chrootban megy az apache. :) Sok eleve Linuxra felkészített cucc eleve elhasalna, ahogy erre még jónéhány éve volt egyszer példa.

Lehetne, de történelmi okokból nem variáltunk többszáz könyvtáron, ahol még nem is volt teljesen egységes a szerkezet. A session.save_path pedig nem volt mindíg az open_basedirhez kötve, csak valamelyik PHP verzió óta és baromira nem volt idő hirtelen (tudom changelog, de akkor ez nem tűnt fel benne) a vhost konfigokat hegesztgetni jobban. Egyébként meg tökmind1, hogy az upload_tmp-et vagy mást szemetel tele és ha tudja akkor futtatja a csodáit.

( eax | 2009. 02. 19., cs – 10:28 )

A roundcube milyen verzio? Abban pl. talaltak nemreg egy eleg csunya bugot.
A www-data usernek mire van meg irasi joga a /tmp-n es a /var/tmp-n kivul?

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

( gabori | 2009. 02. 19., cs – 12:29 )

Hali!

Nekem még egy olyan ötlet jutott eszembe, hogy mi van ha valami kis szépséget ott hagyott és azzal jut vissza mindig? Persze azt nem írtad, hogy az első eset után mindent újra pakkoltál-e. Az saját oldalakat egy cvs-ből újra húztad-e.

Nekem egyébként az apparmor jutott eszembe még. Azzal nagyon jól lehet szabályozni a védelmedet.

( lacika v | 2009. 02. 19., cs – 12:42 )

A /tmp és a /var/tmp külön partícióra (noexec, nosetuid mount opciókkal)
Már is nem fogja tudni futtatni a botjait.

--
http://laszlo.co.hu/

( Frantique v | 2009. 02. 19., cs – 13:18 )

Amit felpakolász azért csomagold össze későbbi elemzés céljából, esetleg oszd meg velünk is, hadd tudjuk, mire kell figyelni.
--
Coding for fun. ;)

igen csinalta ez is ezt. amugy ez is perl script volt. meg van az összes cumója a gyereknek , ha esetleg valakit érdekel elemézsre. amugy még olyan kérdésem lenne felétek, hogy ez a gép egy game hosting szerver. Elkezdtek panaszkodni az emberek hogy laggol. hát mondom oks, volt már ilyen, az első hálókártya (tyan lap 2 gigabit porttal) too many iterations üzeneteket dobált, ugyhogy átdugattam az operátorral a másik csatiba. most nincs üzenet, és elég meglepő hogy a processzorok terhelése is visszaesett 50%ról 20-30 % ra. azért az nem kevés. hálózati adatforgalom elenyésző ahhoz hogy laggoljon. végignéztem a futó processzeket, idegent nem találtam köztük, szoval nem hagyott semmit maga után az illető.

Szóval mi okozhatja a laggot ? mostmár sokkal kisebb mint a másik kártyával, mert akkor teamspeakre nem tudott senki kapcsolódni. viszont a battlefieldesek aztmondják még mindig van . Megkérdeztem a szerverhosting cég tulaját , nincs semmilyen olyan művelet a hálózaton, ami lefogná a sávszélt.

Ötlet? mert én kifogytam :(

Ha valami occsóhostingnál vagy, akkor lehet szar a switch is. Én annó egyszer csak azt vettem észre, hogy néha leesik a hálóról a gép és mint kiderült, a switch valamiért eldobta a portot. Hogy miért, azt a mai napig nem tudom, de a másik switchbe való átdugás csodákat tett.

Amit még érdemes lenne megnézni, az a hálókártya driverének a buglistája, mert az is izgalmas dolgokra képes. Nekem pl van olyan, hogy egy gép első inferface nem jön föl rendesen Debian alatt...

Esetleg még tcpdumpolni, netstatot nézni, de csak szelektíven, mert a gamék tudnak mindenfélét nyitogatni...

Érdekes hogy "eddig" nem volt ilyen gond. aztán egyszer csak ultra lagg, dosoltak a perl scriptek, le lettem tiltva udp-ről. most kipucoltam a gépet, másik hálókártyára raktam át, kihasználtság csökkent, de a lagg maradt... mármint ugy maradt, hogy aztmondják h már nem annyira laggos de azért van valami.

a switchel nem hiszem h baj van, mert akkor az egyik jóbarátom már mondta volna, neki is van egy gépe ennél a szolgáltatónál.

hmmm de most hogy álljak neki ? error logokban nincs semmi ....

( device | 2009. 02. 20., p – 20:15 )

Na akkor ugye ez a sebezhetőség téma lezárva, de itt a következő gondd. CPU-k terhelése 20% on. 4gb ramból 1.3 fel van használva. hálózati adatforgalom 1.5mbit a 100ból.

és mindenki laggol a szerveren

kicsit beleturtam tcp dumppal és ilyet dobott ki, lehet itt van a kutya elásva :

tcpdump -i eth2 -n host 88.xxx.xxx.xxx

29446 packets captured
55699 packets received by filter
26143 packets dropped by kernel

Másik két szerveren is lepróbáltam és ott 0 csomagot dob el a kernel.

Valakinek van rá tippje ?

Hálókártyát cseréltem mert az előző too many iterations-t nyomott, és masszivan laggolt. ez a mostani nem ugat, de a lagg most is van, bár nem olyan aggressziv.

Ja amugy iptables szinte üres, két port van tiltva, és kész.

előre is köszönöm!

device

update :

nyomtam rá egy iptables --flush -t

és változatlanul :

23793 packets captured
43283 packets received by filter
19383 packets dropped by kernel

ahogy néztem tele van udp checksum incorrect-al .

de egy kis capture-t itt találsz :

http://www.device-project.hu/uploads/downloads/wireshark.cap

update:

érdekes, mert kiprobaltam tcp-t, csinaltam egy ftp masolast, es a tcp csomagokat nem dobálja el, innentől kezdve fura nekem hogy az udp-ket meg igen. Eleinte hálókártyára gyanakodtam de most már nemtom mi lehet vele a baj. Megprobalok egy régebbi kernelt.

Mondjuk ha esetleg a konkrét forgalmat megnéznéd, hogy nincs-e benne gyanús a "sokudp-n" kívül? Mert a wireshark/tcpdump-on elég konkrétan meglátod hogy jééééééééé ircbot van meg spamküldés vagy akármi. Még egy tipp, hogy nézd meg a géped nem-e openproxy valamilyen protokollon.

Az UDP checksum, meg minden checksum előfordul hogy nem jó (marvell es nve cuccok előszeretettel produkálták nekem).

( Dwokfur v | 2009. 02. 21., szo – 09:00 )

Nálam legutóbb roundcube exploittal próbálkoztak. Mondjuk nálam nincs roundcube. A /roundcube/bin/msgimport file-t próbálták elérni. Szerintem a dragonfly helyett próbálkozz a roundcube környékén.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."