buuz urtun küldte az alábbi képeket, főleg az utolsó figyelemreméltó:

Megint hétfő van, a hét eleji sokkhatásokat mérséklendő íme néhány rövid hír, nagyrészt az újjászülető Hacker News Network jóvoltából:

• Hamis ATM-et helyeztek el az idei Defcon-nak otthont adó las vegasi Riviera Hotelben. A gépet telepítő bűnözők pechükre nem számítottak rá, hogy éppen egy biztonsági szakembereknek szóló nagyszabású konferencián próbálják az átverést kivitelezni. A csalást természetesen hamar leleplezték: a "kameranyíláson" bevilágítva a konferencia szervezői a szokásos berendezés helyett egy egyszerű PC-t találtak, ezután pedig értesítették a helyi hatóságokat az esetről. 
• Fájlmegosztókon is elérhető a legnagyobb orosz közösségi oldal, a Vkontakte.ru mintegy 135.000 felhasználójának belépési adata. A gyűjteményt valószínűleg egy adathalász oldal segítségével állították össze. A rekordok között szerepel néhány egyértelműen használhatatlan darab, tehát a listát nem ellenőrizték, minden esetre ebből az adathalmazból is érdekes statisztikákat lehetne összehozni.

Tudtátok, hogy az Apple asztali klaviatúrái annyira kúlak, hogy saját memóriával és firmware-rel rendelkeznek? Van is hozzá még gyári frissítő szoftver is, mivel "az Apple-nek megvan az a jó szokása, hogy azelőtt adja ki termékeit, mielőtt azok elkészülnének" :) Bizonyos K. Chen a BlackHat-en megmutatta, hogy ezeket a remek lehetőségeket hogyan lehet arra használni, rootkitet telepítsünk magára a billentyűzetre.

A módszer pofonegyszerű: elindítod a frissítő szoftvert egy debuggerben, beállítasz egy töréspontot a megfelelő helyre, megvárod hogy a processzor ráfussona kijelölt utasításra, majd szépen kicseréled a feltöltendő kódot a sajátodra, majd szabad utat engedsz a program folyásának.

No persze a gyakorlatban a dolog nem volt ilyen fájdalommentes: meg kellett piszkálni a firmware kódjának ellenőrzőösszegét, meg kellett találni a firmwarefrissítéshez alkalmazandó jelszót, és nem utolsó sorban ki kellett deríteni, hogy egyáltalán milyen hardverre írunk szoftvert.

A munka azonban meghozza a gyümölcsét: a billentyűzetre telepített, megberhelt firmware nem tűnik el akkor sem, ha esetleg újraformázzák a Mac-et, a megfelelő karakterszekvenciák elküldésével pedig - mintha egy szellem is ülne a gép előtt - könnyedén kitehetünk egy root shellt valamelyik magasan figyelő portra, és még  a biztonsági szoftvereket is megnyugtathatjuk, hogy ne terheljék a felhasználót mindenféle összetett üzenetekkel. Szép munka Chen!

Slide-ok és a papír erre van.

Új kriptoanalízis eredményeket jelentettek be az AES titkosítási eljárással kapcsoaltban. A támadások 256 bites megvalósítás csökkentett körszámú változataival szemben hatásosak, és igen alacsony lépésszámban képesek visszaállítani az eredeti kulcsokat.

Az AES-256 szabvány 12 titkosítási kört ír elő, míg az eddig publikálatlan tanulmány a 9, 10 és 11 körös implementációkkal kapcsolatban mutat be ún. kapcsolódó kulcsokon alapuló támadást. Ennek kivitelezésekor meg kell tudnunk figyelni a titkosító be- és kimeneteit ismeretlen, de egymással valamilyen módon kapcsolatban álló kulcsokkal működtetve. A kulcsok közötti relációk felderítését az teszi lehetővé, hogy a 256 bites AES kulcsütemezője "elég vacak". Ez azt jelenti, hogy a rövidebb kulcsokat használó AES-128 nem érintett, az viszont figyelemre méltó, hogy a 256 bites változatban használt kulcsok a körök számától függően rendre 2^39, 2^45 illetve 2^70 lépésben visszaállíthatók!

Pánikra egyelőre azonban nincs ok, mivel a fentiek nem vonatkoznak a szabványban rögzített, 12 körös változatra, és a kapcsolódó kulcsokon alapuló támadás is viszonylag ritkán kivitelezhető a gyakorlatban (bár gyanús, hogy a 802.11i esetében pl. el lehetne gondolkozni ilyesmin...). Bruce Schneier szerint viszont megfontolandó, hogy módosítsák a szabványt, és megemeljék a szükséges körök számát, ezen felül a szakértő nem javasolja az AES-256 alkalmazását a gyakorlatban.

Egyik kedves olvasóm hívta fel a figyelmem erre a Technetes cikkre, amiben Radics Boglárka osztja az észt a NULL karakteres SSL trükközéssel kapcsolatban. Néhány gyöngyszem (bár tulajdonképpen az egész cikket ide lehetne másolni...):

A Black Hat biztonsági konferencián a legelterjedtebb titkosító protokoll, az SSL több kritikus hibáját mutatták be.

A probléma ott gyökerezik, hogy számos böngészőbe be van építve az SSL protokoll, valamint az X-509 típusú aláírásokba is, ezen digitális tanúsítványokat használja az SSL annak meghatározására, hogy hiteles-e az weboldal.

Ez a Marlinspike féle támadás kísértetiesen hasonlít az SQL injection támadásra.

Az injection típusú támadásoknak több vállfaja is van, a másik igen ismert az e-mail injection, amikor levélküldő űrlapokat (kapcsolatfelvétel, hozzászólás) használnak fel spam-küldésre.

Kedves Boglárka: ment volna inkább péknek!

Kedves Technet szerkesztők: ha az egész bandában nincs egy ember, aki kiszúrja ezt a rengeteg baromságot, lehet hogy inkább át kéne alakulni viccmagazinná...vagy ez már meg is történt?

Tízperces speedposzt következik, figyeljetek:

• Legjobb szerver-oldali hiba: Linux SCTP memory corruption (erre jó magyar kifejezést valaki?)
  ... amiről sokáig azt állították, hogy csak DoS-ra elég, aztán kiderült, hogy segítségével távolról lehet hátsókaput nyitni az érintett gépeken, megkerülve az SELinuxot is.
• Legjobb helyi jogosultságkitéerjesztésre alkalmas hiba: A Linux kernel és a NETLINK üzenetek
  ... melyektől senki nem kérdezte meg, hogy honnan jöttek 
• Legjobb kliens-oldali hiba: Windows msvidctl.dll puffer túlcsordulás
  ... aminek a Microsoft 16 hónapja nem járt utána, pedig kiderülhetett volna: az ATL hibái miatt fújhatjuk a killbitjeinket.
• Legnagyobb tömeges 0wnage: Megtört Red Hat szerverek, megberhelt OpenSSH csomagok
  ... ami magárét beszél, a történet legszebb része pedig az, hogy a Red Hat még mindig nem vonta vissza azokat a kulcsokat, melyeket a támadók egyértelműen megszereztek, mejd felhasználtak a hátsó kapukkal ellátott OpenSSH csomagok terjesztéséhez.
• Legjobb kutatási eredmény: Bernhard Müller Symbian hackelős papírja
  ... amit még mindig nem sikerült elolvasnom :(
• Leglámább gyártói reakció: Linux
  ... ahol is még mindig úgy tartják, hogy a memory corruption csak DoS-re jó (lásd a legjobb szerver-oldali hibát)
• A leginkább túlpörgött hiba: MS08-067
  ... vagyis a Conficker egyik kedvelt belépési pontja a lusta rendszergazdák rendszereibe, ami remek alkalmat ad a lusta újságíróknak hogy félévig ugyanarról cikkezzenek
• A legjobb dal ez lett  :)
• A legeposzibb bukás: Twitter
  ... ahonnan egyetlen béna Hotmail jelszó miatt kerültek a dolgozók személyes adatai, a teljes üzleti terv, pénzügyi jelentések, ésatöbbi, hála a Web 2.0-nek
• Az Életműdíj pedig Solar Designernek ítéltetett, akinek érdemeit azt hiszem nem kell ecsetelnem...

A teljes bejelentést is érdemes elolvasni, rendkívül szórakoztató, így gyorsult tempóban is :) 

Akad egy kis dolgom külföldön, szóval sajnos nem tudom hirtelem beposztolni a rengeteg BlackHat-es újdonságot, de azért ezúton kívánnék boldog Rendszergazdák Megbecsülésének Napját mindenkinek, aki megérdemli!

Amíg helyreáll az Erő egyensúlya, olvassatok HUP-ot, írnak ott sok jó dolgot!

Ja és bocs...

PS: A levelekre kb. vasárnap fogok tudni válaszolni...

Megkezdődött az idei Black Hat konferencia, melyen szokásosan az IT-biztonsági szakma elmúlt évének minden bizonnyal legnagyobb kaliberű felfedezéseit mutatják be.

A tavalyi hisztéria után Moxie Marlinspkie idén is úgy érezte, hogy lenne feltornászni picit az emberek vérnyomását, ezúttal azonban a hacker olyan felfedezést hozott a batyujában, amitől az én szám is tátva maradt egy pillanatra:

Persze mielőtt bárki is elrohanna lemondani a netbank/paypal/ebay hozzáféréseit, megnyugtatásul közlöm, hogy az SSL még mindig jól érzi magát, egyes kliens oldali megvalósításokon azonban sürgős változtatásokat kell eszközölni! Marlinpsike arra jött rá, hogy ha egy tanúsító szervezetnél beregisztráljuk mondjuk a www.paypal.com\0.gonoszoldal.com-ot, akkor a CA a gonoszoldal.com-nál fog érdeklődni a kérelem érvényessége felől, majd kiadja a tanúsítványt. Amikor azonban egy pl. Firefox böngészőt használó kliens ellátogat egy, a fenti tanúsítvánnyal büszkélkedő weboldalra, a böngésző abbahagyja a tanúsítványhoz tartozó domaint jelölő karakterlánc olvasását az első NULL karakternél, és azt fogja gondolni, hogy a gonoszoldal.com helyett a paypal.com-mal kommuikál! Ugyanez játszódik le akkor is, ha a szemfüles felhasználó a böngészőben kézzel ellenőrzi a tanúsítványt, ugyanis ekkor szintén csak az első NULL-ig terjedő szöveg fog látszani a tanúsítvány tárgyánál.

Ez hatalmas szarvashiba az érintett böngészőgyártók részéről, reméljük, minél hamarabb orvosolják ezt a problémát.

A Mozilla biztonsági csapata a Firefox webböngésző összes verzióját valamint a Netscape és Flock alkalmazásokat érintő, címsorhamisításra lehetőséget adó sebezhetőségről számol be. A hiba kihasználásával pl. egy adathalász akció során a kártékony weboldal átírhatja a böngésző címsorát, ezzel elhitetve a felhasználóval, hogy valójában legitim helyen jár.

PoC itt található, FF 3.0.12-n nálam nem működött. NoScript mindenképpen védelmet nyújt.

Szolgáltatásmegtagadást eredményező problémát fedeztek fel a BIND DNS kiszolgáló összes verziójában. A sebezhetőségre elérhető publikus exploit (ha valaki megtalálja, linkelje!), a nagyobb Linux disztribútorok már kiadták a megfelelő javításokat, forráskódból dolgozók a 9.4.3-P3, 9.5.1-P3 vagy 9.6.1-P1 verziókat telepítsék!

Azt hiszem, egy kép ebben az esetben beszédesebb lesz a szavaknál:

Hunger volt olyan kedves, hogy lőtt Dan Kaminsky blogjáról egy képernyőképet, amíg még elérhető volt.

A Microsoft tegnap rendkívüli frissítéseket adott ki az Internet Explorerhez valamint a Visual Studio Active Template Library-jéhez. A két javítócsomag igen összetett hibákat orvosol, és egymást kiegészítve igyekszik mélyreható védelmi mechanizmusokat bevezetni.

A Microsoft szakemberei példamutató módon számolnak be az általuk felfedezett sebezhetőségekről, és bár őszintén szólva így reggelire kicsit már megfeküdte a gyomromat ez az információtömeg, azért megpróbálok egy rövid áttekintést nyújtani a szóban forgó problémákkal kapcsolatban:

Az Active Template Library (ATL) egy C++ osztálygyűjtemény, amely lehetővé teszi a Visual Studio felhasználói számára, hogy egyszerűen hozzanak létre többek között COM objektumokat, pl. ActiveX vezérlőket is. Ezeket az objektumokat később különböző szkriptnyelvekben, tipikusan Internet Explorerből meghívva használhatjuk fel.

Mint kiderült, az ATL különböző osztályait három sebezhetőség súlytja, melyek közül kettő kódfuttatást tesz lehetővé, ráadásul a sebezhető ActiveX objektumok kiiktatására szolgáló killbit mechanizmus is megkerülhető egyikük kihasználásával (tehát a kártékony kód akkor is lefut, ha a sebezhető objektum használatát letiltottuk!).

Mivel alapvető programkomponensekről van szó, az ATL-t használó fejlesztőknek felül kell vizsgálniuk eddigi kódjaikat. Ha kiderül, hogy a fejlesztett szoftver sebezhető, a javított ATL-lel történő újrafordításra, vagy a sebezhető kódrészek átírására van szükség a felhasználók védelme érdekében.

Mivel az összes egyedi fejlesztésű komponens átvizsgálása gyakorlatilag lehetetlen, a második javítócsomag a lehetséges támadások elsőszámú táptalajának számító Internet Explorerben vezet be (többek között) az ATL sebezhetőségeire irányuló támadásokkal szembeni megelőző intézkedéseket.

Az ATL konkrét sebezhetőségeiről, valamint arról, hogy a Microsoft szakembereinek miért nem sikerül eddig rájuk akadniuk, kiváló posztot olvashattok a cég Security Development Lifecycle blogjában. Mint kiderült, az egyik stack overflowt például egy egyszerű elírás okozza, melyet az automatikus ellenőrző eszközök azért nem jeleztek, mert a kasztolás (ezt így írják magyarul?) "azt a benyomást kelti" az analizátorban, hogy a fejlesztő tudja mit csinál, ezért a további jajveszékelés úgyis csak hamis pozitívokat eredményezne a teszt eredményében.

Bár a teljes, javításokkal kapcsolatos cikktenger átolvasása nem sétegalopp, én azért mindenkit arra bíztatnék, hogy vágjon bele a feladatba! Ritkán lehet találkozni ennyire tanulságos, és jól kommunikált esetekkel, le a kalappal a MS biztonsági csapata előtt!

Frissítés: A Cisco több termékét is érinti a sebezhetőség, javítások egyelőre nincsenek.

Frissítés 2: Az Adobe Shockwave és Flash Player is érintett, amennyiben Internet Exploreres beépülőként használjuk őket (mivel csak itt jönnek szóba az ActiveX vezérlők). Előbbi szoftverhez elérhető frissítés.

A Verzion Business készített egy tesztfelületet, mellyel ellenőrizhető a különböző beépülők érintettsége

A Mozilla biztonsági blogjában egy új kiegészítőről számol be, amely jó szolgálatot tehet a közbeékelődéses, illetve SSLStrip-pel elkövetett támadások kivédésére. A ForceTLS a Collin Jackson és Adam Barth által javasolt ForceHTTPS protokollkiegészítés egy megvalósítása:

Minden webes domain, amellyel HTTPS protokollon kommunikálunk, egy speciális HTTP fejléc segítségével megmondhatja a böngészőnek, hogy vele a jövőben bizony már csak titkosított csatornán kommunikálhatunk. Az ilyen kérést benyújtó domainek listáját a kiegészítő megjegyzi, és a jövőben már csak HTTPS protokollon keresztül lesz hajlandó hozzáférést biztosítani pl. online bankfiókunkhoz. 

Nem gyakran posztolok egyszerű Firefox kiegészítőkről, de ezesetben egyrészt azt hiszem eleve jelentős újításról van szó, másrészt az, hogy a kiegészítőt maga a Mozilla fejleszti és promótálja azt sejteti, hogy ez az eszköz alapértelmezett tartozéka lehet akár a későbbi Firefox kiadásoknak is!

Amennyiben ez bekövetkezik, az valószínűleg a többi gyártót is rá fogja kényszeríteni a funkció implementálására, ami a nyilvános WiFi hálózatokat egycsapásra sokkal unalmasabb biztonságosabb területekké változtathatja.

Tegnap mikor Kelt megkért, hogy értékeljem egy kicsit az anti-sec csoport "munkásságát", éppen úsztam a tennivalóimmal és próbáltam halasztani a dolgot, de végül csak sikerült még aznap lehozni a cikket az utóbbi idők legnagyobb "hacker háborújáról"/flame-jéről.

Most azonban úgy tűnik, érdemes lett volna vármi még néhány órát, egy nem rég beérkezett levélben ugyanis valaki azt állítja, hogy leleplezte a teljes nyilvánosságrahozatal ellen küzdő csoport több tagját. A személyes adatokkal teletűzdelt e-mail tanúsága szerint a csoport a világban szétszórva, az USA-ban, Szaud-Arábiában, és Oroszországban tevékenykedik, az információkat állítólag már eljuttaták az FBI-nak, valamint az ImageShack-nek is. 

Persze mindez egyelőre semmivel sincs alátámasztva, nem tudjuk, hogy a levél küldője hogyan jutott a támadók nyomára, illetve hogy a nyilvánosságra került adatok nem pl. egy moszkvai hajléktalanhoz vezetnek-e. Minden esetre érdemes lesz odafigyelni, frissítem a posztot, ha fejlemény van.

Kikerült az idei Hacktivity tervezett programja, valamint elindult a jegyelővétel is. Az idei rendezvény programja véleményem szerint az előzőekhez képest még szakmaibb irányvonalat képvisel, és a helyzetértékelést szolgáló prezentációkon túl szembetűnő az innovatív témákat bemutató előadások szép száma is. Idén első alkalommal külföldi vendégelőadók is tiszteletüket fogják tenni a rendezvényen, ami mindenképpen jelentős lépést jelent a nemzetközi vizekre történő kihajózás felé. Izgalmasnak ígérkezik tehát az esemény, foglaljatok helyet magatoknak, ameddig még lehet ;)

Jonathan Zdziarski, ismert iPhone hacker szerint az új iPhone 3GS hardveres titkosítása a gyakorlatban haszontalan. Elsősorban a nagyvállalati és kormányzati felhasználók számára az Apple 256 bites AES titkosítást tett elérhetővé új generációs készülékeiben, melynek segítségével elviekben az elhagyott eszközökön tárolt adatokat is biztonságban tudhatjuk. 

Zdziarski azonban rámutatott, hogy bár a készülék által használt titkosítás valóban erős, az architektúra gyakorlatilag mellékeli a kulcsokat a becstelen megtaláló számára. Bár a módszer pontos részletei nem derülnek ki a beszámolókból, annyit azért lehet tudni, hogy a probléma gyökere abban rejlik, hogy a kifogástalan felhasználói élmény érdekében az okostelefon minden fájlművelet elvégzésekor elvégzi az érintett fájlok titkosításának megfejtését. És bár a hacker az alant látható bemutatókban saját, egyedi szoftvereit használja a fájlrendszer titkosítatlan adatainak kinyeréséhez valamint a telefont lezáró kód és a mentés titkosításának deaktiválásához, állítása szerint egy szabadon elérhető jailbreak eszköz és némi Unix-os tapasztalat már elegendő az eredmények reprodukálásához. 

Így ha valakinek valóban megbízható titkosításra van szüksége iPhone-on tárolt adatainak védelme érdekében, az jól teszi, ha a beépített lehetőség helyett (vagy legalábbis mellett) megbízhatóbb (szoftveres) megoldást keres. 

Múlt héten már komolyan reménykedtem, hogy miután az anti-sec mégsem zúzta le a milw0rm.com-ot, és nem tette közzé állítólagos OpenSSH exploit-ját, végre lecseng ez a flame is. Tegnap viszont egy Full-Disclosure-re érkezett levél tanúsága szerint tekintélyes mélyütést vittek be a Matasano Security-nek - akiket egyebek mellett onnan ismerhetünk, hogy ők szivárogtatták ki annak idején a Kaminsky-féle DNS hiba részleteit, állítólag véletlenül. 

A támadást a "th3 just1f13d 4nc1ents 0f 0r0b0r0z" vállalta magára. A matasano.com jelenleg nem elérhető, Twitteren semmi...

Esküszöm, kéne csinálnom egy sablonposztot az Adobe Reader sebezhetőségeknek... Szóval megint kódfuttatásra alkalmas problémát találtak az Adobe Reader-ben, melyet két napja aktívan ki is használnak rosszindulatú támadók. A probléma elméletileg minden platformot érint, de egyelőre csak 9-es verziójú windowsos Adobe Readerek elleni támadásokról érkeztek bejelentések.

A sebezhetőséget speciális, Flash objekumokat tartalmazó PDF fájlokon keresztül lehet kihasználni, védekezésként az ilyen jellegű tartalmak letiltása (Szerkesztás->Tulajdonságok->Multimédia), vagy a program könyvtárában található authplay.dll elérhetetlenné tétele (törlés, átnevezés, ACL...) merülhet fel.

Az ésszel játszók számára rendelkezésre áll egy példány a jelenleg is kártevőterjesztésre használt PDF fájlokból. A fájl rosszindulatú kódot tartalmaz, ezért tényleg csak kezdjen bűvészkedni vele, aki tudja mit csinál! Az elemzések szerint a kártékony kód lefutásakor a fertőzött rendszerek három különböző távoli géphez próbálnak kapcsolódni, xorl rövid áttekintésében pedig három rejtélyes MD5 hash-t talált, talán a két dolognak köze lehet egymáshoz...

Az interjú második része (az első itt van), bocs a késedelemért, de Schmitt azon kívül, hogy simán Timothy C. May és William Gibson szerelemgyereke lehetne, igencsak szenvedélyesen (és hosszadalmasan) fejti ki forradalmi gondolatait.

Gyanús egyébként, hogy nem angol anyanyelvű illető készítette az interjút, így van néhány elég zavaros rész, ezek, valamint a typok miatt ezúton is elnézést kérek!

Remélem senki nem felejtette el (bár két mai telefonhívás alapján úgy tűnik, hogy mégis ;), hogy pénteken (azaz július 24-én) sörözünk, a paraméterek a szokásosak, de az esetlegesen érdeklődő újoncok kedvéért:

Óbester borozó, 1074 Bp., Huszár utca 5. 19:00

Vasárnap pedig, akinek kedve szottyan, nézzen el a Margitszigetre a Szertár blog piknikjére, jó bulinak ígérkezik, sok-sok kézzelfogható tudománnyal :)

Jó rég volt már jó kis böngészőhackelős poszt, igyekszem kicsit szépíteni a helyzetet:

Inferno kicsit tovább gondolta a már többször bemutatott csinos CSS hacket, melynek segítségével szépen bele lehet látni a böngészőkben tárolt előzményekbe. Az agyalás eredménye egy kliens oldali, CSRF-védelem megkerülésére szolgáló módszer lett, melynek lényege már körvonalazódhat a tájékozottabbak fejében.

A leggyakoribb CSRF elleni védelmi mechanizmus az, hogy egy véletelenszerű karaktersorozatot (tokent) biggyesztenek minden egyes elküldött HTML űrlap adatai közé, és ennek az értéknek a megfelelőségétől függően dobják el vagy dolgozzák fel a bejövő információkat. Ezek a tokenek sokszor egy egész munkamenet alatt érvényesek, így téve lehetővé a felhasználók számára, hogy az Előre/Vissza gombokat használják.

Ha azonban a token elég rövid, valamint GET paraméterként, vagyis az URL-ben kerül átadásra, akkor megfelelő mennyiségű "link" kigenerálása után a CSS előzményböngészés segítségével meg lehet tudni, hogy melyik is a megfelelő érték a sok közül az adott munkamenetben.

Inferno mérései alapján egy 5 karakteres token kitalálása nagyjából 2 percet vesz igénybe, ami ugyan nem túl hosszú idő (gondoljunk csak bele, mennyi időt el lehet tölteni egy jobb Flash játékkal), de jól mutatja a módszer korlátait: kellően hosszú véletlen értékek esetében már nem segít a nyers erő.

Mindez persze nem egy félelmetes biztonsági rés, vagy a CSRF-védelem alapjait döntögető áttörés, csupán egy jó példa arra, hogy hogyan lenne érdemes gondolkozni ebben a fránya hacker szakmában...

Tényleg nem szeretek trollokkal foglalkozni, de a Full-Disclosure listát lázban tartó anti-sec csoport állítólag feltörte a (mély levegő...) cms.netrix.hu domain alatt található demó weboldalt. Ugyebár a teljes nyilvánosságrahozatalt támogató IT biztonsági csoportosulások elleni szent harc jegyében... Szánalom.

Az oldalt egyébként azóta úgy tűnik visszaállították...

Frissítés: Most látom, hogy a milw0rm-ön is megjelent egy hitelesítés megkerülésére szolgáló exploit (ha nevezhetjük ennek...) a Netrix CMS-éhez...

Vidi Rita volt olyan kedves és megkért, hogy foglaljak állást az alábbi kérdésben:

Létezik olyan, hogy “biztonságos böngésző”?

Minden böngésző magát kiáltja ki legbiztonságosabbnak, ugyanakkor aki kicsit is mélyebbre lát, tudja, hogy ezek a kinyilatkoztatások sok-sok rejtett, véletlenül ki nem domborított hibát takarhat.
Neked, mint témához szakértőnek mi a véleményed erről: létezik egyáltalán biztonságos böngésző? Vagy ez csak egy üres frázis?

Én természetesen örömmel eleget is tettem a felkérésnek, a válaszomat Ramboéval és Carter-ével együtt a Vírus Kommandón olvashatjátok.

A nagy nyári melegben úgy tűnik a Mozillás srácok kevésbé voltak képesek a 3.5-ös verzió biztonságára koncentrálni. Az új alverzió kiadása után nem sokkal megjelent, majd javított puffer túlcsordulásos sebezhetőség után a SANS ISC most újabb veszélyre hívja fel a figyelmet, amely a viharjelzők információi szerint a legújabb 3.5.1-es verziót is érinti.

Bár működő exploit is napvilágot látott az új, unicode karakterek feldolgozásával kapcsolatos problémára, de sem a BID, sem a CVE nem említi, hogy ez a legfrissebb változat is érintett lenne. Mindjárt kipróbálom, mit tud a drága, ha sikerült eredményt produkálni, jelentkezem!

Teszt1: A böngésző szépen hasal, de a regiszterek épek. Gyanús, hogy kéne még memória...

Frissítés: A Mozilla ma megjelent közleménye szerint a probléma ugyan néhány esetben valóban a böngésző összeomlásához vezet (DoS), de a hiba nem használható fel kódfuttatásra.

Fearlesstől kaptam az alábbi levelet, remélem Index anyánk nem sértődik meg rajta, ha megosztom a nagyközönséggel:

Az index.hu -t olvasva talátam 3 Cookies-t
I_AM_SIMPLE=0; path=/; domain=index.hu
I_AM_CAPTAIN_NEMO=0; path=/; domain=index.hu
I_AM_CAPTAIN_PROFILE=0; path=/; domain=index.hu

ezeket 1 re állítva a cikkek alatt lehet pár extra infót szerezni.
Nem szimatoltam körbe mi mindent lehet kezdeni az infókkal, de azért egy kis belátás a motorház alá. Lehet semmi használható.

És valóban, Némó kapitány például a következő debug informáiókat láthatja, ha a megfelelő oldalra navigál:

Ezek nyilánvalóan egyszerű teljesítményinformációk, de mindig jó kicsit bekukucskálni a gépezet belsejébe :)