"FreeBSD ftpd and ProFTPd on FreeBSD remote r00t exploit"

Címkék

Hozzászólások

A FullDisclosure-on ugye egy hang nincs róla, ellenben a FreeBSD Security listán eléggé hamar feldobták, hogy azért az nem egy normális dolog, hogy az ftphome (meg mondjuk alatta az etc) publikusan írható, és így fel lehet tölteni libeket/binárisokat.

Attól még csúnya bug, és ügyes volt, hogy észrevette.

Két dolgot vettem észre a videón. Alapból nem tudott írni az ftp user könyvtárba, hanem mondott egy vastag chmod 777-et rá, ami után tudott, valamint nem a ports proftpd-t, hanem saját fordítást használt, szintén a chmod 777 könyvtárra. Jól láttam? Ezt hány ember teszi így?

Kisse mas tema de: ez amugy PHP "programozok" koreben elterjedt: csinaltam FCGI szerveren olyan vizsgalatot, hogy a kerdeses path-ban (ahol a kiszolgalando cucc van) van-e 777 jogu dir, ha van: alert, stb. Nem lehetett nekik megmagyarazni, hogy a 777 felesleges. Hiaba mondtam, hogy a webservernek kell tudnia olvasni, esetleg az FCGI-bol futo PHP-nak irni is, ok allitjak hogy mindenhol azt irjak hogy a 777 jog _kotelezo_, ha irni is akarsz, es mindegy, hogy kie a konyvtar stb. Hogy meg rosszabb legyen, par remek PHP-s cucc ezt le is ellenorzi, es pl nem enged tovabb enelkul. Ilyen szokasok mellett nehez megertettni, hogy miert nem annyira jo otlet az ilyen.

Nem a /etc-t kell tudni írnia a usernek.

The ftpd will look for a file in /etc/nsswitch.conf, if this file exists
it will load various library files (.so) from /lib and /usr/lib such as
"/lib/nss_compat.so.1".
In a chroot'ed environment this is a remote and local root exploit, because
the lookup for the libraries is INSIDE THE chroot!

No most a kérdés, hogy
a) a chroot-olt etc-beli nsswitch.conf -ot keresi-e, mert ha igen, akkor igenis az etc-t kell írni, ha azt én akarom jól megcsinálni
b) akármelyiket keresi, a chrooton belül keresi a lib-et, de azt oda is kell pakolni valahogy, tehát az etc helyett (mellett?) a lib-et kell tudni írni.

Egyik sem normális.

(Azé' ilyen erővel sechole, hogy chmod 777 / , és ez után azt tudom csinálni, hogy ... )

man nsswitch.conf(5)

A file-ban benne van, hogy compat service kell neki (jelen esetünkben). A user chrootolva van. A user belép a könyvtárába, csinál egy lib könyvtárat (eddig ugye elképzelhető a dolog, mert mondjuk minek tiltanánk, miért ne lehetne egy ilyen könyvtára), a lib könyvtárba bemásol egy libet amit az nsswitch.conf miatt a proftpd be fog tölteni loginkor. A probléma az, hogy ha a chrootolt környezeten belül talál egy lib könyvtárat benne a megfelelő file-al, akkor ő azt használni fogja. Lényegtelen az, hogy a videón mit chmodolt. A lényeg, hogy tök valid user ezt kitudja használni, anonymous user is, ha a könyvtára chrootolva van (és miért ne lenne ugye), és tud feltölteni file-t (persze úgy hogy korlátozva, hogy milyen file-okat tölthet fel).

Egyelőre félig adok neked igazat:

- ha van acc-om a gépre, akkor tudok csinálni ~/lib -et és oda fájlt bemásolni
- anon ftp esetén viszont változatlanul nem hiszem el, hogy normális az, hogy az anonftp-ben tudok csinálni /lib -et (vagy akár /usr/lib -et ), illetve ha valamiért már van /lib, akkor tudnék bele írni.

Gondolkoztam, ez jutott eszembe:

# for user in user1 user2 .... ; do
> mkdir -p ~$user/lib ~$user/usr/lib
> chflags sunlink,schg ~$user/lib ~$user/usr ~$user/usr/lib
> done
#

Ha jól gondolom, ezzel elérem azt, hogy nem tud magának lib és usr/lib könyvtárakat csinálni, és az én általam előkészítetteket nem tudja törölni és átnevezni (chflags sunlink) ; valamint nem tud beléjük odamásolni ronda előkészített lib-eket (chflags schg). És akkor az első pontot is kivédtem.

De nem baj, ha valaki rámutat a hiányosságra.

(OK, ha van egy local exploit, akkor le tudom szedni a chflags-sel beállított dolgokat, és akkor már távolról is támadható. Ha ezen kívül még a securelevel is legalább 1-ben van (asszem), akkor kernel exploit kell a dologhoz. Azé' ennyire ne legyünk már telhetetlenek.)

proftpd-ben van modul a file feltöltés tiltására, szóval akár ezzel is kivédhető a feltöltés:

http://doc.mpv.ru/proftpd/Configuration.html#PathAllowFilter

Bár legyünk őszinték, hány olyan helyet lát az ember ált. ahol le van ilyen korlátozva pl? Legtöbb helyen amiket láttam még arra se veszik a fáradtságot, hogy legalább ne /bin/sh legyen a shelljük az ftp usereknek. No meg tényleg van olyan programozó aki a saját cuccait a lib könyvtárba teszi, aztán lehet magyarázkodni ügyfélnek, hogy mi a probléma (bár jó még file-névrel ehet mindig szűrni a fent említett modullal). Van olyan megoldás is, hogy nem ilyen bugos szart használ az ember :).

Én azt nem értem, hogy 2011-ben milyen érv van az ftp használata mellett. Kiszolgálásra a HTTP sokkal jobb (tűzfalgondok sokkal kevésbé érintik, gyakorlatilag bárhonnan megy), feltöltésnél pedig valami titkosítás azért hasznos lenne, erre pedig csomó jobb megoldás létezik:
1. WebDAV (minden mai OS tudja külön kliens nélkül)
2. SFTP

Üdv,
Gergely

Amiket én üzemeltetek szervereket, és van ott a userek miatt van. Mást nem tudnak használni. Megkockáztatnám, hogy ha total commandert be kellene állítani, hogy FTPS legyen, meg is halnának (nem más kliens nem létezik). Így is hetente legalább 2x megkérdezik tőlem, hogy miért nem sikerül felmásolniuk a .htaccess file-t, mert nem látszik miután felmásolták. És akkor ez még mindig nem egy bonyolult művelet. Na most ezeknek elmagyarázni, hogy webdav-ot, vagy sftp-t hogyan kéne megcsinálni... :). BTW azokban is lehetnek ugyanilyen kritikus bugok még ráadásul, vsftpd pl. elég megbízható, talán DoS-olos mókázások voltak maximum hozzá, viszont webdav-nal meg talán mind IIS-nél, mind Apache-nál mintha lett volna valami komolyabb bug. De mondjuk ezt hunger,eax,bra,wooh,pipacs,thuglife stb jobban eltudja mondani, ezekben ők a meisterek.

Számomra a bejelentés legszórakoztatóbb részei ezek voltak:

"BTW my box (isowarez.de) got hacked so expect me in a zine :>"

[...]

"Hi lists,
sorry if I offended anyone with by referring to teso,
I really like teso as you might also.
all this happend because I was drunk hehe :>"

:)

--
trey @ gépház

Már az egész szerintem ott bukik, hogy mindenféle daemon-ok root-ként futnak.
Lásd apache master processz, mindenféle ftp szerverek, stb.
Amíg ilyen van addig lesznek hasonló exploitok.
Mert ugye ha nem root-ként futna az az ftp akkor az csak egy sima user shell lenne amit kap a támadó.
Nyilván az is fájdalmas, de azért nem annyira mint a root shell.
Tudtommal a rootként futásnak két oka szokott lenni (fixme): setuid(2) és társai illetve privileged port bind.
Ha megoldják majd azt rendesen egy MAC-el vagy esetleg az egész jogosultság/biztonság filozófia újragondolásával, hogy ne kelljen ezeknek root-ként futtatni, akkor szebb lesz a világ (legalábbis számomra).
Pl. egy olyan MAC-el ahol megmondhatom, hogy xy bináris/user ilyen userrel futhat, ezeket a portokon hallgathat, stb.
Már közelítünk ehhez, de azért én még teljes megoldást erre nem láttam.

Tudtommal a rootként futásnak két oka szokott lenni (fixme): setuid(2) és társai illetve privileged port bind.

privileged port bind után szépen ellehet dobni a privilégiumot, ahogy teszi ezt jópár nem rootként futó daemon... ami miatt "kell" itt a root, az a per-user chroot() jail lehetőség, hogy a usereket a saját homejukba, vagy kijelölt könyvtáraikba lehessen bezárni.

Nem. A lényeg, hogy elfelejti eldobni a privilégiumát (setuid vs. seteuid) és béna módon hívogat külső programot. Ennek semmi köze ahhoz, hogy a master process rootként fut.

Egyébként le van írva az ftpd manualban nagyon sok éve, hogy ha nem akarod hogy a rendszer biztonsága sérüljön, akkor a chroot utáni új root ne legyen írható és az alatta lévő etc se:



                                         In order that system security is not
     breached, it is recommended that the ``ftp'' subtree be constructed with
     care, following these rules:

           ~ftp      Make the home directory owned by ``root'' and unwritable
                     by anyone.

           ~ftp/etc  Make this directory owned by ``root'' and unwritable by
                     anyone (mode 555).  The files pwd.db (see passwd(5)) and
                     group(5) must be present for the ls(1) command to be able
                     to produce owner names rather than numbers.  The password
                     field in passwd(5) is not used, and should not contain
                     real passwords.  The file ftpmotd, if present, will be
                     printed after a successful login.  These files should be
                     mode 444.

No offense, de erre csak annyit tudok mondani,
hogy én nem szeretnék olyan oprendszert,
ahol egy root-ként futó alkalmazás esetében attól függ,
hogy lesz-e remote root shell vagy nem,
hogy a fejlesztő a megfelelő rendszerhívással dobja-e el a root privilégiumokat illetve eldobja-e.

Szeretem, ha arról az operációs rendszer gondoskodik, hogy ilyen ne történhessen és nem a proftpd codere.
És nyilván van köze hozzá. Ha az a processz soha nem futott volna root-ként, akkor nyilván
setuid(0);
setgid(0);
setresuid(0,0,0);
sorok is kevésbé lettek volna sikeresek.
Értem én hogy chroot-ot meg setuid-ot (ezesetben) csak root-ként lehet hívni, na pont ez a bajom.

És köszi a "(setuid vs. seteuid)" utalást, asszem kezdem sejteni, hogy mit csesztek el. :)

A preemptive multitasking nem tudom hogyan segíti elő a programozói hibák minimalizálását, mert én egyelőre csak annyit látok belőle biztonsági oldalról, hogy a kernelben található versenyhelyzet problémák kihasználását teszi jóval könyebbé... ;)

A jelenlegi sebezhetőség ráadásul egy logikai/tervezési hiba, ami ellen a különböző memória védelmek sem tudnak mit tenni.

Hát nagyon remélem, hogy már nem kell sok időnek eltelnie, hogy tudjak ilyen oprendszert mutatni és leginkább használni.
Bizakodó vagyok.

Btw. tudja valaki, hogy pontosan mi volt a konkrét bug?
Annyit értek, hogy a "SITE CHMOD 777 nonexistant" és a "STAT ." parancsok triggerelik az nsswitch.conf keresgetését és ezzel a compat library betöltését
(?ez talán valami Freebsd libc bug?).
Viszont, hogy ezt hol illetve hogyan csinálja azt nem tudom, és azt sem, hogy a proftpd-ben hol van az, ahol seteuid-ot hív setuid helyett(?ha egyáltalán ez a baj?).

Láttam pár pwned vasat a freebsd-k alatt gyanúsan volt mindenhol proftpd, vártam már mikor jön ki ez a hír.