- A hozzászóláshoz be kell jelentkezni
- 3724 megtekintés
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.
- A hozzászóláshoz be kell jelentkezni
Na becsüld alá az emberi hülyeséget. Láttam már nagy cégnél Oracle AppServerben annó default admin jelszót otthagyva....
- A hozzászóláshoz be kell jelentkezni
Ööö én szinte csak olyat láttam ;o)
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
A mindent mindenkinél jobban tudó webfejlesztők első körben szoktak egy chmod -R 777 /srv/www-t nyomni, ha valami nem megy, csakis utána szoktak bármi mást megnézni...
Ezért nem kapnak soha ssh-t, ftpn meg letiltom nekik a chmodot.
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
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 ... )
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.)
- A hozzászóláshoz be kell jelentkezni
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 :).
- A hozzászóláshoz be kell jelentkezni
É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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
FTPS?
- A hozzászóláshoz be kell jelentkezni
- ha van acc-om a gépre, akkor tudok csinálni ~/lib -et és oda fájlt bemásolni
-> és ezzel root shellt szerezni a gépen ;)
- A hozzászóláshoz be kell jelentkezni
Mondj valamit a chflags-re is :-) Bíztam benne, hogy megjelensz és elmondod, hogy mi benne a rossz, erre azt épp kihagytad. Szerintem a chflags-s dolog a lokális root-ot is kivédi - de én ugye nem ebben a témakörben mozgok.
- A hozzászóláshoz be kell jelentkezni
Amikor még a válasz linkre kattintottam nem volt chflags hozzászólás. Egyébként meg az ~/etc-t kihagytad. :)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
szép. subscribe
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Igen értem, de az mindegy is, hogy mi adott esetben az ok.
Lényeg, hogy valami miatt rootként fut az a daemon és a végeredmény egy root shell egy sima user shell helyett :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Szólj, ha találsz olyan oprendszert, amelyik gondoskodik, hogy a programozók hibái ne történhessenek meg... :)
- A hozzászóláshoz be kell jelentkezni
Az oprendszerek nagyresze probalja minimalizalni a programozoi hibak altal okozhato karokat. Tudod.. memory protection, preemptive multitasking, stb. :)
- A hozzászóláshoz be kell jelentkezni
Ugy-e nem a linux kernelre gondoltal... :)
--
1 leszel vagy 0 élő vagy hulla!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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?).
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Köszi, most már értem, hogy miért nem dobta el a root privilégiumát a proftpd.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni