adore-ng rootkit a 2.6 kernelhez

Titkosítás, biztonság, privát szféra

Sajnos megjelent a legújabb adore rootkit, amely már használható a 2.6-os kernelekhez is, így fokozott figyelemmel kell lennünk!

Az adore-ng nem más, mint egy kernel modul, amelynek célja, hogy a cracker kezébe teljes irányítást adjon afelett a rendszer felett, amelyet már egyszer feltört. Mindezt úgy, hogy saját maga ne legyen detektálható.

Az rootkit számos ponton ``telepíti'' magát a kompromittált rendszer kernelében, így biztosítva, hogy felfedezhetetlen legyen. Egészen addig észrevétlen próbál maradni, amíg nem jön valaki, aki tudja a helyes ``KEY''-t (ADORE_KEY), amely nem más, mint egy process ID. Ha valaki nem tudja ezt a ``kulcsot'', akkor bizony nem egyszerű felfedezni az adore-ng-t.

Lássuk miért:Az adore-ng több álcázó mechanizmussal is fel van szerelve. Felejtsük el, hogy egy egyszerű chkrootkit programmal detektálni tudjuk.

A kernel modul azzal kezdi ténykedését, hogy hozzáhurkolja magát több filerendszerhez is.

1.) File és könyvtár rejtés: Az első dolog amit megtesz, hogy a root filerendszer inode-jainak readdir() függvény mutatóját lecserélni a sajátjára. Az adore-féle verzió is pontosan ugyanazt teszi, mint az eredeti, annyi különbséggel, hogy elrejt minden olyan filet amely egy megadott felhasználó vagy csoport tulajdonában van (ELITE_UID, ELITE_GID). Ezzel a script kiddie által telepített fileok láthatatlanok maradnak a rendszergazda számára.

2.) Processz rejtés: Hasonlóan hurkolja magát a /proc filerendszer lookup funkciójához. Ezzel lehetővé teszi, hogy a top, ps, stb. parancsok nem listázzák ki a betörő processzeit.

3.) Socket rejtés: Az adore-ng lecseréli a /proc/net/tcp show() függvényét is. Az új verzió editálja a hálózati kapcsolatok listáját, így eltüntet minden olyan kapcsolatra utaló jelet, amely a betörőre utalna.

Egyéb funkciók:

4.) Teljes értékű backdoor.

5.) syslog szűrés, wtmp/utmp/lastlog szűrés, stb.

A kernel modul egyetlen dologra nem képes, mégpedig elrejteni saját magát. Ezt azt jelenti, hogy a betöltött kernel modulok listázásakor (lsmod) látszik. Ezt kiküszöbölendő, a készítő szerkesztett egy másik kernel modult, amely a cleanup névre hallgat, így az elrejti a adore-ng-t.

Használata:

insmod ./adore-ng.o

insmod ./cleaner.o

rmmod cleaner

Érdemes tanulmányozni a forráskódot, hogy jobban megismerjük a működését.

A rootkit letölthető innen.

igazabol amit fel szoktak torni az tavoli szerverek, amelyek valahol colocation-ban vannak (ritka szerintem, hogy otthon az asztal alatt ketyeg a webszerver, stb.) , ott meg nehez knoppixrol bootolni.

Valoban gyorsabb ujrahuzni a gepet. Na meg jailbe, chrootba zarni fontosabb szervereket. Nem beszelve arrol hogy, nem kell modularis kernelt fordítani, stb. :-)

Több rencergazda is akadt akkoriban a cégnél, és nem voltak elosztva a felelősségek, így senki se update-elte az ssh-t.

Csak azért írom le, hogy tanuljatok belőle.

A szerver helyileg szófiában volt... :) Roppantmód örültünk, mikor telefonáltak, hogy "nem működik".

Nem fogunk neked itt kiseloadast tartani a chrootolasrol ;)

Szerintem erre senkinek nincs ideje. Ha van kedved es turelmed, akkor probald ki a balabit kft termeket a restrict-et, meg egy-ket chroot csinalo programot (mkjail, makejail, jailer, de a debootstrap is jo vegso soron)


asd

( batyu v | 2004. 03. 29., h – 13:15 )

Lehetséges olyan linux rendszer készítése, ahol "nincs" root?

Illetve az jutott eszembe, mi lenne, ha a root lenne így elrejtve?

Lehet, hogy nagy marhaságot kérdeztem, nem értek hozzá, csak gondolkoztam ;-)

Szóval kivitelezhető lenne ez? Mert akkor asszem elég sokmindenre gyógyszert találnánk. Egy rendszer, ahol nem lehet detektálni root-ot...

Leteznek olyan Linux kernel kiegeszitok, amelyet alkalmazva nincs jelentosege annak, hogy root vagy-e vagy sem. Ilyen pl. a SELinux [www.nsa.gov].

Voltak mar olyan probalkozasok, hogy SELinux-szal (pontosabban LSM-mel) megerositett gepet kitettek az internetre, megadtak a root jelszot, be lehetett ssh-zni, es meg lehetett probalni kart okozni benne. Igazabol a root jelszo birtokaban sem lehetett veluk mit kezdeni.

Ilyen probalkozas volt a Törjünk együtt Debiant! korabbi cikkunkben leirt eset, vagy a Megerősített Gentoo demo gép cikkunkben leirt eset is.

Ezeken kivul meg szamos mas megoldas letezik arra, hogy csokkentsuk a root felhasznalo jogait.

( zsolt | 2004. 03. 27., szo – 17:47 )

Ezek szerint ha nem engedélyezzük a modulokat kernel-fordításkor, akkor nem tudják telepíteni?

( nevergone v | 2004. 03. 27., szo – 21:45 )

Nos, kipróbáltam a cuccot, elég durva, érdemes lesz védekezni ellene.

Csak pár dolgot nem értek.

Az egyik az, hogy feltelepítik a programot egy gépre, akkor távolról hozzá lehet -e csatlakozni. Azaz elég figyelni a helyi felhasználókra, vagy rootkit távolról is ad hozzáférést? A másik az, hogy ha csak helyileg használható ki, akkor miért kellenek neki a foglalt portok? Na meg a jelszó... fordításkor meg kell adni neki egy jelszót, azt hol használja fel?

És a legfontosabb kérdés: hogyan lehet védekezni ellene... ???

Amúgy a processz elrejtése működött, de az állomány elrejtése nem:

elrejtés elött:

never:~/ggggg$ ls -la

összesen 8

drwxr-xr-x 2 never users 4096 2004-03-27 21:52 .

drwxr-xr-x 89 never users 4096 2004-03-27 21:36 ..

-rw-r--r-- 1 never users 0 2004-03-27 21:52 g.g


elrejtés után:

never:~/ggggg$ ls -la

összesen 8

drwxr-xr-x 2 never users 4096 2004-03-27 21:52 .

drwxr-xr-x 89 never users 4096 2004-03-27 21:36 ..

-rw-r--r-- 1 3006360198 2070697803 0 2004-03-27 21:52 g.g

tehát az UID és a GID megváltozott, de attól még megjelenik az állomány.

( Gabucino | 2004. 03. 28., v – 01:52 )

Naesakkor mi a faszom az a "hurkolas" ?

Újratelepíted a rendszert. Egy olyan környezetben, ahova betörtek, mindenképpen ez a megfelelő megoldás (persze nem árt tudni, hogy hogyan jutott be az illető, hogy megakadályozd a visszajövetelét. Viszont nem szabad abban bízni, hogy 'megtaláltam a rootkitet és legyilkoltam, most már nem jön vissza', mert lehet, hogy más backdoort is hagyott, amit nem vettél észre.

Egyetertek az elottem szoloval viszont a chkrootkit es debsums nevu programok esetleg segitseget nyujthatnak lamakkal szemben(persze ezek se 100%osak). Amugy pedig letezik valami progit, aminek a nevet nem tudom(de itt a HUPon tobbszor is szobkerult) amely md5 sumokat csinal az osszes filerol a rendszeren, es igy betores utan egy tiszta rendszerrol bootolva konnyen ellenorizni tudod mely fileokat cserelte le a tamado.

( selli | 2004. 03. 28., v – 11:55 )

Akkor is nyitva van a "hátsóajtó" ha van tuzfalam ? Magyarul az iptables-t kinyitja a megfelelo porton ?

Amúgy lehet ebben az elrejtésben valami, mert kipróbáltam egy teszt-rendszeren...

A processz rejtése és mutatása szépen működött. Állomány elrejtése nem működött (feljebb már idéztem), viszont asszem én bénáztam valamit, mert miután telepítettem, eltünt a forrást tartalmazó könyvtár. Ezért aztán úgy gondoltam, hogy biztos letörölte... nos, akkor én is letörlöm a szülőkönyvtárát, ami üresnek látszott.

Érdekes helyzet állt elő: A könyvtár üresnek látszott (hiszen csak az elrejtett forrás volt benne), de törölni nem tudtam rendszergazdaként sem, mert hozzáférés megtagadva. Utána eltávolítottam az adore -t, és tényleg ott volt a program forrása...

A két port is már tiszta, mert a kódot átnézve rájöttem, hogy az azokhoz tartozó adatforgalmat is elrejti, és a portokat nem jelzi semmi program (pl. netstat).

Már csak arra nem igazán tudtam rájönni, minek kell neki a jelszó, illetve a speciális PID

Amennyiben lehetőséged van tiszta rendszerről bootolni (pl. knoppix), akkor az elrejtett file-ok látszani fognak, tehát _elvileg_ jó lehet a tripwire, amennyiben korábban rendesen megvolt a karbantartás. Ezzel együtt ilyenkor a tripwire checksumjai alapján jöhet a találgatás, hogy mi változott, miért, stb. Ez pedig hosszú idő.

Szóval ilyen esetben inkább elő kell venni egy új gépet (esetleg csak egy új winchestert) és elindulni egy friss telepítésről, a régit pedig félretenni későbbi elemzésre. Ez a módszer arra is jó (lehet), hogy rájöjjünk arra, hol volt lyukas a korábbi rendszer. Persze ha nincs plusz winchester, jó a dd is :)

( hory v | 2004. 03. 28., v – 14:11 )

Ez a rootkit kutya füle ahhoz képest, ami egy-két évvel ezelőtt láttam. hasonló stealth technikája volt, de az képes volt megfertőzni ELF binárisokat, majd ha azt root indította, akkor szépen belepatchelte magát a kernelbe, mindenféle modul support nélkül is. Utána meg már minden ELF-ből az eredetit mutatta, meg persze tudott PID meg minden egyéb rejtést is.

Na, EZ az igazi vírus.

A nevét már nemtom, valami 'dua0wnzu' string rémlik. A 'dua' nem biztos, az owns you igen. Roppant kellemes ilyen konyvtarat talalni a szerveremen...

Ez a betörés egy három éves ssh-n át történt, automatizálva (az otthagyott forrasokbol latszik, hogy felment volna irc-re jelezni a sikeres torest, ha nem szurte volna a kifele meno forgalmaz is a firewall).

A másik véglet az, amikor a script kiddie simán lecseréli a netstat-ot, a ps-t, a top-ot, ..., aztán reméli, hogy nem veszem észre. Ez az ultragagyi kategória, de ilyet is talaltam (masik gep, szinten harom eves ssh :)