Kim Dotcom nem rég 10.000 euró jutalmat ajánlott annak, aki sikeresen "feltöri" (bármit jelentsen is ez) a nem rég indult MEGA.co.nz védelmét. A felajánlásra azután került sor, hogy biztonsági szakértők számos kritikát fogalmaztak meg az oldallal kapcsolatban. 

Kriptót csinálni "a felhőben" ugyanis bajos, leginkább azért, mert a szolgáltató nem igazán tudja garantálni, hogy saját maga (vagy egy őt komprommitáló támadó) nem tud hozzáférni az elméletben titkosított adatokhoz. A MEGA helyzete első blikkre annyival egyszerűbb, hogy a szolgáltató elsősorban a jogi bonyadalmaktól igyekszik megóvni felhasználóit azzal a felkiáltással, hogy maga sem tud információt szolgáltatni a hatóságoknak.

Ez azonban valójában azonos helyzet: mint azt többen észrevételezték, onnantól kezdve, hogy a szolgáltató szerver-oldalon végez titkosítást, a hatóság (vagy ismét egy támadó) elméletileg elérheti, hogy pl. a titkosító szkript mentsen egy nyílt változatot is minden feltöltött anyagból. 

De nem ez volt az egyetlen probléma: a szolgáltatás külső felhőszolgáltatóktól lehúzott JavaScriptjeinek integritását például sima CRC-MAC-el ellenőrizte a rendszer, ez az amatőr megoldás pedig nem sok jót ígér a teljes rendszer biztonságával kapcsolatban, mint ahogy a felfedezett XSS-ek sem a nagy gonddal felügyelt fejlesztés képét mutatják. 

Mindez persze nem jelenti azt, hogy Dotcom úr a közeljövőben megrövidülne néhány lepedővel. A most feszegetett támadások leginkább egy 10.000 eurónál eleve jobban motivált támadói modellre épülnek, illetve a szolgáltatás elvi működőképességét kérdőjelezik meg, így az alapvetően szimpatikus felajánlás mégis csak egy egyszerű marketingfogásnak tűnik.

Bár a Google az idei Pwn2Own szervezésébe is besegített, megrendezésre kerül a Pwnium is, melyen a Chrome böngésző helyett (ami a HP versenyén már szerepel) a Chrome OS lesz a főszereplő. A keresőóriás összesen 3.14159 millió dollárt ajánl fel azoknak a hackereknek, akik képesek egy weboldalon keresztül átvenni az irányítást a legfrissebb operációs rendszer változatot futtató Samsung kütyü felett. Egy "sima", böngésző alapú támadásért 110.000 dollár jár, ha pedig a támadó újraindítás után is képes uralni a gépet, 150.000 dollár üti a markát, ezen kívül a cég részdíjakat is kioszthat. A busás jutalomért természetesen a résztvevők vállalják, hogy a támadás részleteit megosztják a gyártóval, aki így képes lesz javítani a problémákat.

A versenyre a Pwn2Own-al együtt a kanadai CanSecWest konferencián kerül majd sor.

Úgy tűnik, az idei év slágere a Java mellet a Ruby (on Rails) lesz: a bugvadászok újabb, szerializációval kapcoslatos problémát találtak a RoR 2.3.x és 3.0.x változatainak egyik JSON parserében. A probléma oka - hasonlóan az előző sérülékenységhez - az, hogy a JSON formátumú adatok feldolgozásakor a keretrendszer bizonyos esetekben YAML-ként értelmezi a bemenetet, így a JSON kontrollálásával a felhasználó bármilyen Ruby objektumot példányosíthat, ami könnyedén az alkalmazás-kontrollok megkerüléséhez vagy kódfuttatáshoz vezethet*.

Megoldás a verziófrissítés, a patchelés, vagy alternatív JSON parser választása lehet. A 3.1-es és 3.2-es RoR változatok, valamint a yajl gemet használó alkalmazások nem érintettek.

* Egy erre járó Ruby guru elmagyarázhatná, hogy ez az eval miért is fut le

Friss (2013. 01. 30. - 13:28): Itt a MSF modul

Friss (2013.01.31. - 13:08): A sérülékenység kihasználásával hatoltak be a Rubygems.org-ra, folyamatos státuszinfó Twitteren.

Azt beszéltük apuval :) hogy a kiddós feltörések már mocskos unalmasak. Az a terv, hogy néhány módszert és technikát írásos formába öntök, ennek első morzsájaként született ez a post. Nem túl mély, de feltételezem hogy valamennyire képben van az olvasó a hálózati protkollokkal, és remélem hogy annak is tudok újat mondani aki arccal benne van a paketolásban.

Egy penteszt során amikor aktív paketolásra kerül a sor, az elsők között lefut egy portscan, többnyire nmap, -de ugye kinek mi a kedvenc scannere- amiből látszani fog néhány open port. Ezzel is meg lehet elégedni, hiszen ennyi információ elég ahoz hogy a szolgáltatásra lehessen uszítani az X/Y vulnscannert, ami böködi egy darabig a szolgáltatást/alkalmazást, aztán vagy mond valamit vagy nem. Az automatizált eszközök mindenféle okosságot elmondanak, de ne hagyjuk hogy elvakítson a könnyű haszon. Hasznosak -persze-, de nem mindenhatóak, elsiklanak a részletek fölött. Ezt majd egy másik alkalommal elpanaszkodom. :)

Most csak az open portokkal foglalkozunk, de a scannelésre még ebben a sorozatban visszatérek. Még annyit hogy a cikk méretére tekintettel nem fejtek ki mindent részletekbe menően, viszont feltüntetem hogy hol tudsz utánanézni. Most viszont lássuk miből élünk (és tényleg).

Az elmúlt hetek valahogy a különleges keresőkifejezések jegyében tellt: Legutóbb a GitHub állította le nem rég továbbfejlesztett keresőmotorját, miután az új indexelőnek hála könnyedén rá lehetett keresni a jó képességű felhasználók által megosztott privát SSH és PGP kulcsokat, és jelszavakat tartalmazó .bash_history fájlokat. A RoR titkos tokenek repóban felejtését még csak-csak megértem, de nem igazán tudom elképzelni, milyen indíttatásból veszi fel egy repóba a .ssh könyvtárát... Bár a GitHub gyorsan reagált a problémára, a Google és más keresők azért még vígan visszaadják az érzékeny találatokat onnan és más szolgáltatóktól is.

Aztán itt van a #TrendNetExposed: Egy PasteBines gyűjtés nyomán több oldal is elkezdte gyűjteni az internet irányából elérhető TrendNet IP kamerákat. 

Végül ezzel a kereséssel HP nyomtatók admin felületeit lehet felkutatni. Hasonló érdekességekért továbbra is a GHDB-hez érdemes fordulni.

A Security Explorations több távoli elérést (SSH) biztosító bedrótozott jelszót talált a Barracuda SSL VPN eszközeiben. A rendszerek minden esetben azonos shadow fájllal érkeznek, az ezekben található hash-ek pedig megfelelő erőforrások birtokában feltörhetők. Néhány felhasználó esetében a kulcs alapú autentikáció is engedélyezett. A problémát tovább súlyosbítja, hogy a rendszerek beépített tűzfalszabályai alapértelmezetten engedélyezik az SSH hozzáférést a 192.168.200.0/24, 192.168.10.0./24 valamint több más, nyilvános, a Barracuda és más végekhez tartozó IP tartományokból. 

A Barracuda a 2.0.5-ös jelő Security Definitionnel igyekszik mérsékelni a problémát: ez több felhasználó esetében letiltja az SSH belépést, de a root, remote, és cluster felhasználók továbbra is bejlentkezhetnek a megadott tartományokból - a root felhasználó továbbra is bedrótozott jelszóval rendelkezik, ezt azonban a SE-nek eddig nem sikerült kipörgetnie, bár az értesítő szerint eddig csak egyszerűbb jelszavakkal próbálkoztak.

Javasolt az SSH port elérésének korlátozása az érintett eszközökön. 

Az Index egész jó összefoglalót közölt a legfrissebben felfedezett nagyszabású kémakcióról, a Vörös októberről. Idő közben a Kaspersky további részleteket is közölt az esettel kapcsolatban - akit mélyen érdekel a téma, ezekből tájékozódhat. Technikai szempontból a kampány legérdekesebb része véleményem szerint a multiplatform működés: A kémkedéshez használt kártevő modulok nem csak hagyományos munkaállomások adataira utaztak, de igyekeztek adatot nyerni különböző okostelefon platformokról (iPhone, Windows, Nokia) illetve Cisco hálózati eszközökről is. Ez egy viszonylag kézenfekvő fejlesztési iránynak tűnik, nem lepődnék meg rajta, ha hasonló technikák terjednének el (elsősorban a mobil eszközökkel kapcsolatban) a "kommersz" kártevők között is. Illúziódöntögető tény továbbá, hogy ismereteink szerint a célintézményekhez - diplomáciai intézmények, energetikai, hadászati vállalatok, stb. - történő bejutáshoz nem volt szükség 0-day exploitra, a frissítetlen rendszereket már ismert, javított sérülékenységeken keresztül is be lehetett venni.

A Kaspersky által felderített kártevők közös jellemzője, hogy egy sor orosz szleng kifejezést tartalmaznak. Ezek a kifejezések általában nem ismertek egy nem anyanyelvű személy számára, ezen kívül több C&C kiszolgáló is Oroszország területén található, a kártevők pedig néhány esetben bekapcsolják a crill karakterkészletet a fertőzött gépeken. Mindez tehát az oroszok irányába mutat, de vannak kételkedők: a felhasznált exploitok és a célpontok többek szerint ismét kínai szereplőket sejtetnek. 

Több mint félmillió dolláros összdíjazású lesz az idei CanSecWest Pwn2Own versenye. A szervezők - a HP-TippingPoint DVLabs - visszatérnek a régi, bevált szabályokhoz: aki elsőként futtat kódot teljeskörű felhasználói hozzáféréssel (sandbox megkerülést is beleértve), az viszi a gépet, a platformra felajánlott jutalmat, valamint automatikusan ZDI Silver taggá is válik. A legtöbbet a Google Chrome + Windows 7 és az IE10+Windows 8 kombinációk elejtésével lehet kaszálni, ezekért nem kevesebb mint 100.000 dollár jutalom jár. A legolcsóbb célpont nem meglepő módon a Java plugin lesz - ezért 20.000 dollárt adnak a szervezők, ami meglepő módon magasabb, mint a feketepiacon kínált ár. 

• Web Browser
  • Google Chrome on Windows 7 ($100,000)
  • Microsoft Internet Explorer, either
    • IE 10 on Windows 8 ($100,000), or
    • IE 9 on Windows 7 ($75,000)
  • Mozilla Firefox on Windows 7 ($60,000)
  • Apple Safari on OS X Mountain Lion ($65,000)
• Web Browser Plug-ins using Internet Explorer 9 on Windows 7
  • Adobe Reader XI ($70,000)
  • Adobe Flash ($70,000)
  • Oracle Java ($20,000)

A megemelt tétek fogadtatása igen pozitív: a versenyt korábban többször kritizáló, tavalyi győztes VUPEN már jelezte, hogy az összes(!) kiírt platformra rendelkeznek teljes értékű exploittal, melyeket be is szándékoznak vetni a konferencián. Várhatóan vitát fog kiváltani ugyanakkor, hogy a regisztrált bitbűvészek sorsolt sorrendben próbálkozhatnak, így a szárazon tartott puskapor mellett a szerencsének (vagy a befolyásnak...) is nagy szerepe lehet.

A bemutatott exploitokat a versenyzők a játék végén átadják a ZDI-nek, akik az így szerzett információkat az érintett gyártóknak eljuttatva segítenek a sérülékenységek kijavításában. 

A héten a rendkívüli Java és Internet Explorer frissítések mellet megérkezett több gyártó rendszeres csomagja is:

Az Adobe a ClodFusion-t javította (ennek a terméknek még nincs szinkronizálva a frissítési ciklus a Microsoft-éval), a kiküszöbölt sérülékenységek az autentikáció megkerülésére adnak lehetőséget, és aktív támadások során már kihasználták őket, ezért javasolt a mielőbbi frissítés.

A Cisco távolról root-ot adó problémát javított az LMS appliance-ben, DoS problémákat oldott meg az ASA 1000V-ben is az IOS kernelben,  valamint orvosoltak néhányat (az összeset?) a Hacking Cisco Phones című előadásban bemutatottakból:

Ezzel együtt a szintén Cisco érdekeltségbe tartozó Linksys routereket továbbra is távoli, root-ot adó sérülékenység sújtja a DefenseCode szerint.

Végül, de nem utolsó sorban az Oracle is kiadta a nem-Java termékekre vonatkozó első negyedéves CPU-ját, ami a zászkóshajó 11g, és a népszerű nyílt-forrású MySQL mellett egy sor más termékben is fontos problémákat orvosol. A legújabb Java 0-day-el kapcsolatban egyelőre annyi az újdonság, hogy a Security Explorations bejelentette, hogy a Java 7u11 még legalább két (az eddigiekkel feltehetően rokon) kihasználható sérülékenységet tartalmaz, de azt nem tudjuk, hogy ezek valamelyike megegyezik-e a feketepiacon árusítottal. Jelen állás szerint a legjobb, ha a távoli kódfuttatást Java feature-nek tekintjük.

Aki nem barlangban töltötte az elmúlt éveket, az tudja, hogy a böngésző biztonság hatalmas hangsúlyt kapott az információbiztonságon belül. Ez (a különböző bővítmények sérülékenységei mellett) a böngészők memóriakorrupciós sérülékenységeinek erős felértékelődését hozta magával, ezen belül pedig a use-after-free (vagy dangling pointer) típusú problémák kiemelt figyelmet kaptak. Mivel az ilyen jellegű sérülékenységek várhatóan még jó ideig a támadók eszköztárának hasznos részei lesznek, úgy gondoltam, hogy mindenki okulására összerakok egy részletes tutorial-sorozatot a use-after-free sérülékenységek kihasználási lehetőségeiről. Ebben az első posztban igyekszem bemutatni az elméleti alapokat és egy nagyon egyszerű példaalkalmazással demonstrálni a kihasználás egyik legegyszerűbb módját. A későbbiekben a célom az, hogy eljussunk a valódi böngésző-exploitokig és a haladó heap-rendezgető technikákig. A leírás alapvetően C++ programokról szól Windows környezetben, de a legtöbb gondolat könnyen átültethető más kontextusba is.

A KrebsOnSecurity szerint már el is kelt a BlackHole készítő által piacra dobott, Java7u11-t is lenyomó 0-day exploit. Az árusok az első két szerencsés vásárlónak 5000-5000 dollárért adták tovább a széles tömegek számítógépének lenyúlását lehetővé tevő kódot. Ha jól számolom, a legutóbbi sérülékenységek (részleges) javítása óta kicsitvel több mint 48 óra telt el.

Ha napvilágot látnak további részletek, frissítem a posztot. (Ma kijött egyébként egy Oracle CPU a Java-n kívüli termékekhez, erről kicsit később)

Az alábbiakban Stef vendégposztját olvashatjátok:

Ha ezt a blogot - vagy bármi mást - RSS-en keresztül követed, ha redditet olvasol, akkor Aaron munkájának gyümölcseit fogyasztod. Az hogy az Egyesült Államokban nincs SOPA/PIPA, és nálunk sincs ACTA, azt is részben Aaronnak köszönhetjük. Azt hogy Aaron most halott, azt részben egy karrierista ügyésznek köszönhetjük. Nem valami DoS támadás, deface vagy államtitok kiszivárogtatása miatt került az "igazság"-szolgáltatás karmai közé, hanem azért mert 2010-ben a széles nyilvánosság számára akart elérhetővé tenni tudományos cikkeket*. Aaron a Creative Commons egyik korai kontribútora volt.

2001-ben pont Budapesten alakult meg az Open Access Initiative, amelynek célja szintén az volt, hogy a tudományos cikkekhez mindenki számára biztosítson hozzáférést. A mai napig uralkodó modell szerint a tudományos munkatársat leginkább közpénzekből fizetjük, akik ezután mint szerző - szintén közpénzből - azért fizet a kiadónak, hogy az megjelenítse a cikkeket, amikre ezek után a felsőoktatási intézmények megint közpénzből vesznek előfizetést. Pont egy éve volt botrány ebből az Elsevier kiadó kapcsán, amely egy Egyesült Államokbeli törvényjavaslatot próbált lobbierővel megakadályozni. Ebből lett a Arab^HTudósok Tavasza.

Az érintett kiadó - a JSTOR - nem erőltette az ügyet jogi útra való tereléssel, sőt azóta már szabadon elérhetővé tette ezeket a folyóiratokat. Azonban az MIT nem volt ilyen progresszív (pont az MIT?), így ez elegendő indokot adott a túlbuzgó ügyésznek, hogy koholt vádpontokkal bruteforceolja Aaront, 35 évre börtönnel fenyegesse. Ezek a vádak egy tapasztalt és az ügyben is felkért igazságügyi szakertő szerint alaptalanok és Aaron ártatlan.

Aaron igazi hacker volt, a technológia okozta legális szürkezónát használta fel, hogy kitágítsa a rendelkezésre álló kereteket, és a világot egy jobb irányba fordítsa. Aaron a JSTOR/MIT incidens előtt egy évvel az Egyesült Államokbeli bírósági határozatok jelentős részét szabadította fel. Aki emléket akar neki állítani, vagy folytatni a munkáját, annak itthon is bőven van hasonló kisajátított adatsiló. A rendszerváltozás után kialakult vadkeleti körülmények között sok olyan információt magánosítottak, amely közérdekű vagy közérdekből nyilvánosnak kell lennie, ennek ellenére mai napig csak nagyon korlátozottan érhető el. A jelenlegi kormány sok adathalmazt visszaállamosított, de igazából csak tulajdonosváltás történt, az adatok hozzáférése és újrafelhasználása továbbra is komoly akadályokba ütközik. Szerencsére a nemzetközi Open Government és Open Data kezdeményezések jó példát mutatnak, hogyan lehet ezeket legálisan és tartósan felszabadítani.

Nagyon kevesen tudják, hogy Aaron pár éve járt a Független Magyar Tudásközpontban és azonnal több havi tagsági hozzájárulással támogatott bennünket, és vált ezzel - számomra legalábbis - az egyik legtitkosabb, mégis egyik legismertebb tagunkká.

Aaron a tehetségét, erőforrásait és szenvedélyét önzetlenül arra használta, hogy mindannyiunk számára elérhetővé tegye a tudást. Az öngyilkosságot leszámítva, róla érdemes példát venni. Jó lenne, ha itthon is többen többen tolnák ezt.

* Ha valaki úgy konfigolja a TOR proxyját, hogy véletlenül pont egy MIT-hez hasonló egyetemi hálózathoz tartozó IP tartományba essen az exit-node, akkor maga is simán hozza tud férni ilyen tudományos cikkekhez, és a lebukás veszélye is jelentősen csökken. De hallottam egészen progresszív országokról, ahol az állam fizet elő ilyen tudományos adatbázisokhoz való hozzáférésére az ország egész IP címtartományából.

Az Aaron elleni eljárást irányítő ügyész leváltásáért indított petíció a szükséges 25.000 aláírás már több mint felét megszerezte. Ebben az ellenvéleményben (ami a JSTOR ügy jó összefoglalója is egyben) viszont tisztán jogi szempontok alapján igazat adnak az állam képviselőjének.

A mai napon két, aktívan kihasznált sérülékenységre is javítást kaptunk. 

Az első a híres-neves CVE-2013-0422 Java 7 sérülékenységre (és egy másik, kevésbé égető problémára is) ad megoldást az update 11 formájában. A konkrét hiba, de talán általában a Java sérülékenységek komplexitását is jól mutatja, hogy a problémát elemző neves szakértők is egymás segítségére szorulnak a hibák gyökerének feltárásához: először Adam Gowdiak kényszerült kisebb helyesbítésre, majd az Immunity etalonként kezelt elemzéséről is kiderült, hogy kissé pontatlan. A szomorú az a történetben, hogy úgy tűnik, maga a gyártó sem végzett kifogástalan munkát: a illetéktelen osztályreferencia-szerzésre lehetőséget adó sérülékenység ugyanis a JDK7u11-ben is jelent van. Értékelendő lépés ugyanakkor az Oracle részéről, hogy az új Java 7 változatok biztonsági szintjét alapértelmezetten Magasra emelte, azaz csak a hitelesített appletek futthatnak automatikusan (nem mintha a botmesterek ne tudnának fillérekért tanúsítványt vásárolni a sarki CA-nál...).

Friss (jan. 14 21:32): A DHS továbbra sem javasolja a Java használatát (böngészőkben), Altieres Rohr ettől független, de megfontolandó érvelést is ad a jótanács mellé.

A másik javítócsomag (MS13-008) a Microsoft Internet Explorer 6-8 változatait érintő, use-after-free sérülékenységre ad megoldást. Bár a gyártó korábban egy ideiglenes megoldásnak szánt FixIt-et is kiadott a problémára, ez nem bizonyult 100%-ig hatékonyak, így a frissítés most a gyorsajvítással rendelkezőknek is erősen ajánlott.

Elég sok érdekes információ jelent meg az aktuális, javítatlan Java sérülékenységgel kapcsolatban - ezek egy részéről az előző poszt alatt a kedves Olvasók is megemlékeztek (köszi!) ebben a bejegyzésben igyekszem összegyűjteni a legfontosabb tudnivalókat és hivatkozásokat.

A legrészletesebb elemzést a sérülékenységről az Immunity szolgáltatja. Ebből megtudhatjuk, hogy a most kihasznált sérülékenység nagyon hasonlít a tavaly augusztusban észlelt támadásokban kihasználthoz, illetve a Security Explorations által tárgyaltakhoz:

Egy, a Reflection API-t nem biztonságos módon használó osztályon (ezesetben a com.sun.jmx.mbeanserver.MBeanInstantiator osztály findClass() metódusán) keresztül referencia szerezető bármilyen, elméletileg korlátozottan elérhető osztályra, majd a Reflection API hibáját kihasználva az osztály metódusai is meghívhatók - a sikeres kódfuttatáshoz tehát két hiba összekapcsolása szükséges.

A vicc az, hogy a második problémát az Oracle elvileg már az előző fiaskó után javította. Elvileg. Annak idején is a MethodHandle.invokeWithArguments() okozta a bajt azáltal, hogy nem ellenőrizte megfelelően a hívó Class Loaderét, így  reflection-ön keresztül hívva hajlandó volt bármely osztály bármely metódusát meghívni, mivel a reflection API osztályai megbízható (NULL) CL-el rendelkeznek. A gyártó úgy igekezett orvosolni a problémát, hogy a valódi hívó felkutatásakor kihagyta a régi reflecion API hívásait, magával az új Reflection API-val ugyanakkor nem számolt a javításkor, a probléma így kihasználható maradt: "egyszerűen" a Reflection-t is Reflection-nel kell hívni.

Mivel az új Reflection API Java 7-től van jelen, ez a kihasználási út csak a futtatókörnyezet említett főverzióján működik, az MBeanInstantiator viszont legalább a JDK 6u10-től kezdve sérülékeny. Ilyen esetben kicsit nehéz az egyszeri tanácsadó dolga: ugyan a 7-es főverzió már hasznos biztonsági feature-ökkel rendelkezik, a vadon tenyésző exploitok mégis csak ezt a családot támadják - én jelenleg úgy gondolom hogy a Java 7 biztonsági szintjének "Nagyon magasra" állítása jó kompromisszum lehet a használhatóság és a biztonság között (ha az ember nem játszik céllövöldét az "Engedélyezés" gombbal).

További segítséget jelenthetnek a Mozilla és az Apple megoldásai, melyek a Chrome példáját követve alapértelmezetten megerősítéshez kötik ileltve letiltják az appletek futtatását a Firefox illetve Safari böngészőkben. Itt hangúlyoznám, hogy - bár a támadások egyelőre Windows felhasználók ellen irányulnak - a sérülékenységek triviálisan átültethetők bármely Java appleteket futtatni képes platformra ide értve OS X-t és Linux-t is (OpenJDK érintettségéről eddig nem láttam infót, ezügyben kiegészítést szívesen vennék).

Az Oracle azt ígérte, hogy "rövidesen" (agyameláll) kiadják a biztonsági frissítést a problémára. Bár a cég tavaly év végén elvileg ígéretet tett arra (Oracle link), hogy a Java-t is a többi termékkel, évente minimum négy alkalommal fogja frissíteni, a hivatalos oldal jelenleg 3 Java CPU-t jósol, a következőt február közepére. A többi termék jövő kedden kap javítást, azonban ez a csomag az előzetes értesítő szerint sem fogja érinteni a Java-t.

Friss (jan. 14 10:00): Az Oracle rendkívüli javítást adott ki a problémára, ezen kívül alapértelmezetten Magas-ra emelte a Java 7 futtatókörnyezetek biztonsági szintjét - ez azt jelenti, hogy az aláíratlan/önaláírt appletek nem futnak alapértelmezetten. 

Friss (jan. 14 10:55): A Security Explorations pontosította az Oracle korábbi frissítéséről szóló elemzését.

Nem rég a BlackHole exploit kit fejlesztői új programot hírdettek, melynek keretében összesen 100.000 dollárt ajánlottak fel eddig ismeretlen böngésző vagy böngésző plug-in sérülékenységekért, exploitokért, vagy meglévő exploitok továbbfejlesztéséért (pl. új célplatformok). Ezzel a BlackHole gyakorlatilag új konkurenciája lett a (fél)legitim exploit kereskedőknek. 

Most úgy tűnik, a program eddig eredményes volt: Brian Krebs szerint a BlackHole most már tartalmaz egy eddig ismeretlen Java 0-day exploitot (még egyszer mondom: kapcsoljátók ki azt a rohadt bővítményt!). 

A BlackHole kitet évi 1.500 dollárért vesztegetik, de a készítők állítólag egy új csomaggal is készülnek, amiért havi 10.000 dodót (!) kérnének - az egyelőre nem tiszta, hogy az új 0-day (már ha valóban létezik) melyik csomagban szerepel. 

Friss: Élesítés után közvetlenül esett be a hír, hogy a 0-day létezését az AlienVault Labs is megerősítette, az exploit működik a legfrissebb Java 7-tel szemben.

Friss (január 10. 17:02): Innen letölthető a minta (Kösz Boldi!).

Friss (január 10. 17:24): A VirusTotal nullás felismerést dob a fent letölthető csomagra...

Friss (január 10. 18:40): Szóval a fenti ZIP jelszava 'infected', jelszó nélkül újracsomagolva 16/46-t ad a VT, a prominensebbek közül McAfee, Symantec, AVG, ClamAV nem jelzett. Eszerint az elemzés szerint az exploit a BlackHole mellett a Cool és a Nuclear kiteknek is része, még több minta itt, forrás itt.

„Mindenkinek ott volt az orra előtt. Tyler meg én csak rámutattunk. Mindenkinek ott volt a nyelve hegyén. Tyler meg én csak kimondtuk.”

Az NTLM protokollal kapcsolatos pass-the-hash támadások már rég óta ismertek: Egy támadó megszemélyesíthet távoli felhasználókat az autentikációs protokollt alkalmazó szolgáltatások számára, amennyiben rendelkezik egy legitim felhasználó jelszavának MD4 hash-ével. Ez támadói szemszögből azért barátságos, mert a felhasználó választhat bármilyen erős jelszót, nekünk nem kell feltörnünk azt, hiszen az autentikációs folyamat csak a hash ismeretét igényli.

Hogy honnan szerezzük meg a hash-t? Tipikus eset, hogy egy hálózatban hozzáférést szerzünk egyetlen hoszthoz, majd a helyi jelszó adatbázist vagy a gyorsítótárat kirámolva hash-ekkel autentikálunk a hálózat más gépeire. Egy másik lehetőség, hogy az NTLM kihívás-válasz protokolljába ékelődve, vagy pl. egy SMB szervernek kiadva magunkat olyan kihívásokat osztunk egy kliensnek, melyre már van egy szép rainbow táblánk, ami remélhetőleg kipörgeti a kapott válaszból az áhított hash-t. 

Az idő azonban telik: ma már nem érdemes rainbow-táblákkal vacakolni, mikor néhány GPU jobb teljesítményt nyújt, ráadásul tetszőleges kihívásra. De ennél még jobb (rosszabb) a helyzet:

Mark Gamache nem rég rámutatott, hogy a Moxie Marlinspike-ék által demonstált MS-CHAPv2 törési módszer gyakorlatilag egy-az-egyben alkalmazható az NTLM protokollra is:

by Moxie Marlinspike - az MD4 ezesetben még 5 db 0-t csap a normál kimenethez

Egy lehallgatott kihívás-válasz párból két darab hét karakteres (és egy darab két karakteres) DES kulcs kipörgetésével megkaphatjuk a hash-ünket, ami minimális költséget jelent egy támadó számára (CloudCracker-en kevesebb mint egy nap, valamint néhányszor tíz dollár). 

A Windows XP és a Server 2003 még mindig alapértelmezetten engedélyezi ezt az autentikációs módot, a veszélyes kézfogásra pedig a felhasználók könnyen rávehetők (lásd még fájlmegosztások és UNC elérési utak). Az LM és NTLM protokollok Registry-ből tilthatók, a Microsoft pedig FixIt-eket is kiadott, melyekkel néhány kattintással biztonságosabbá tehetjük rendszereinket. Az összes támogatott Windows verzió, de még az NT 4.0 utolsó változata és a Samba is támogatja az NTLMv2-t, tessék letiltani az elavult protokollokat!

Újabb problémát fedeztek fel a Ruby on Rails keretrendszerben - ezúttal egy szinte minden felhasználót érintő problémáról van szó, melynek kihasználásához nem szükséges a csillagok különös együttállása (vagy hanyag fejlesztői gyakorlat) így a frissítést ajánlott mihamarabb elvégezni. 

A sérülékenység az Action Pack komponenst érinti, és alapvetően egyfajta nem-biztonságos deszerializációról van szó: az Rails képes XML illetve XML-be ágyazott YAML formátumú, felhasználótól érkező bemeneteket automatikusan Ruby objektumokká alakítani, ami egy igen hasznos szolgáltatás, a bökkenő azonban az, hogy ilyen módon tetszőleges szimbólum illetve objektum futásidőben módosíthatóvá válik. Az Insinuator elemzése egy olyan kihasználási vektort mutat, melyben a támadó a Rails által használt Arel SQL interfész objektumainak állapotát manipulálja közvetlenül, kikerülve ezzel a setter metódusok ellenőrzéseit, gyakorlatilag SQL injectiont hozva létre. Megjegyzendő ugyanakkor, hogy a hírek szerint a sérülékenység akár operációs rendszer szintű kódfuttatásra is lehetőséget adhat - ha ezzel kapcsolatban megjelennek részletek, frissítem a posztot. 

Addig is frissítsetek, vagy legalább tiltsátok le az XML paraméterek feldolgozását!

Friss1 (jan 9. 10:43): Kicsivel részletesebb elemzés jelent meg a Rapid 7 jóvoltából, a Metasploit felhasználók pedig foltot kaptak.

Friss2 (jan 9. 17:48): Hollandia a bejlentés hatására inkább lekapcsolta Railsen futó kormányzati portálját.

Friss3 (jan 10. 15:52):  A távoli kódfuttatásra alkalmas explit megérkezett Metasploitba. Aki érti, hogy működik, írjon kommentet!

Microsoft

MS13-001: Erős darabbal indul az új év: a sokak szívében kiemelt helyet elfoglaló Printer Spooler szolgáltatás hibája lényegében a nyomtatási sorok "megfertőzését" teszi lehetővé: egy nomtatási joggal rendelkező felhasználó olyan feladatokat hozhat létre a nyomtató kiszolgálón, melyek kódfuttaáshoz vezetnek a nyomtatási sorhoz hozáfférő más felhasználók számítógépén. Fontos megjegyezni ugyanakkor, hogy a Windows beépített eszközein keresztül nem használható ki a probléma, kizárólag egyes más gyártótól származó, Windows API-t használó szoftverek lehetnek érintettek. Helyi hozzáféréssel rendelkező támadók jogosultságkiterjesztésre használhatják a problémát, a sérülékeny szolgáltatás ugyanis Local System jogkörrel fut.

MS13-002: Szintén egy régi ismerős, az XML Core Services sérülékenységeinek javítása. Az érintett szoftverek listája igen széles, így pontos listáért a hivatalos bulletint tudom ajánlani. A sérülékenységek általában úgy triggerelhetők, hogy az áldozatot rávesszük egy speciális "dokumentum" (első sorban web, office) megnyitására. Friss PoC itt van.

MS13-003: Cross-Site Scripting sérülékenység javítása a System Center Operations Manager 2007-es változataiban. Tovább nem ecsetelném.

MS13-004: CAS megkerülésre illetve helyi jogosultságkiterjesztésre használható .NEt sérülékenységek javításai. 3.5 SP1-en kívül minden támogatott verzió érintett.

MS13-005: A win32k.sys sérülékenységének kihasználásával alacsony integritási szintű folyamatok üzeneteket küldhetnek magasabb szintű folyamatok számára, ezzel tipikusan lehetőséget adva a különböző alkalmazás-sandbox megoldások kijátszására.

MS13-006: Aktív hálózati támadók észrevétlenül downgrade-elhetik a Windows beépített SSL/TLS protokollstackjét használó kapcsolatokat SSLv2-re, engedélyezve gyenge kriptográfiai algoritmusokat is.

MS13-007: A .NET keretrendszerben megvalósított OpenData protokoll kezelőjének hibája szolgáltatásmegtagadást tehet lehetővé távoli autentikálatlan támadók számára speciális HTTP kérések segítségével. 

Adobe

Egy szem puffer túlcsordulásos problémát javítottak a Flash Playerben - a javítás 1-es prioritású Windows-on, a sérülésekre hamarosan exploitok készülhetnek.

Az Adobe Reader és Acrobat termékek 26 hibára kaptak foltot, 9-es vagy annál korábbi olvasók esetén Windows felhasználóknak a gyártó szintén 72 órán belüli frissítést javasol. 

Firefox 18

Letölthető a szokásos helyről. Buglista itt.

Egyebek

Elég ronda hibát javítottak az NVidia Display Driver Service-ben. Bár egy képernyődriver szolgáltatásról van szó, az általa használt named pipe ACL-je olyan, hogy ahhoz bármely tartományfelhasználó távolról hozzáférhez, rajta keresztül pedig kihasználhat egy stack overflow sérülékenységet. Külön szépség, hogy a szolgáltatás válaszüzenetekben a stack egy részét is visszaköpi, így a stack cookie védelem könnyen megkerülhető. 

Javítás érkezett ezen kívül a wiki.debian.org vesztét okozó MoinMoin sérülékenységre is.

A legutóbbi, célzott támadásokhoz használt IE 0-day hiba körül egyre sűrűbb az élet. Egyrészt az Exodus Intelligence közzétett egy leegyszerűsített, heap-spray-t nem igénylő PoC exploiot valamint az ennek kifejelesztéséhez vezető út részletes leírását , majd közölték, hogy a Microsoft által ideiglenes megoldásként kiadott FixIt nem nyújt megfelelő védelmet, és az EMET hardeningjei is megkerülhetők (utóbbihoz hozzá tartozik, hogy az eszköz soha nem ígért teljes körű védelmet, csak a támadó költségeinek emelését, ami be is vált). Ezzel kapcsolatban vadiúj posztsorozat van készülőben, az első darab remélhetőleg néhány héten belül elkészül.

Az exploit-mesterek mellett a biztonsági cégek sem tétlenkedtek: a Symantec szerint a most megfigyelt támadás egy évek óta zajló projekt része, melynek első állomását a Google elleni Aurora akciónál láthattuk. A különböző 0-day támadásokat egyebek mellett a heap sprayinghez használt (és a tényleges malware-t telepítő) SWF állományok kötik össze, melyek több függetlennek tűnő esetben is teljesen azonosak, vagy nagyon hasonlítottak egymásra, pl. ugyanolyan debug szimbólumokat tartalmaztak. Az egyik ilyen szimbólum neve alapján a támadóhadjáratot Elderwood Projectnek nevezték el. 

A projekt bonyolítói feltehetően nagy számú 0-day exploittal rendelkeznek, melyeket jellemzően két féle módon juttatnak el célpontjaikhoz: Célzott adathalász támadások esetén az exploitot egy legitim, a célpont számára releváns dokumentumba csomagolják, és e-mailen küldik el, míg az ún. "watering hole"* metódus alkalmazásakor a egy, a célpont által feltehetően gyakran látogatott honlapot törnek fel, és onnan szolgálják ki a támadó kódot. A projekt áldozata volt például az Amnesty International is, de így-vagy úgy, a legtöbb esettel már találkozhattatok a blogon:

• Aurora 
• CVE-2011-0609
• CVE-2011-06-11
• (Az IMF nem tudom, hogy ide tartozik-e, de gyanús)
• Amnesty International: egyik, másik
• CVE-2012-0779
• CVE-2012-1875
• CVE-2012-1889 és a másik
• CVE-2012-1535

A célpontok között a Symantec riportja szerint védelmi beszéllítók, fegyvergyártók és repüléstechnikai cégek, valamint más kritikus ágazatok szereplői kaptak helyet. A támadók felkészültségét jól mutatja, hogy több esetben akár 30 napon belül új 0-day támadást indítottak az előző akció lelepleződése után - mindez kiforrott infrastruktúrát (és persze egy rakat betárazott 0-day-t) igényel, így a Symantec már egy komplett Elderwood Frameworkről beszél, melynek különböző jellemzői, például a több támadásban megosztott C&C infrastruktúra, a kódolási és obfuszkációs módszerek, az újrahasznosított SWF fájlok valamint az általuk lehúzott trójaik alapján nagy magabisztossággal állítható, hogy nem utánzók, hanem ugyanaz a csoport áll a felsorolt támadások hátterében. 

(c) Symantec

És hogy kik lennének ők? Az AlienVault Labs kutatásai erre a kérdésre is részben választ adhatnak. A malware elemzéssel foglalkozó cég munkatársai még egy tibeti aktivistákkal szembeni akció kapcsán kezdtek el foglalkozni az Elderwood Projectben is használt PlugX trójaival, valamint az azt berántó SWF-fájllal. 

A trójai telepítési módja külön szót érdemel: az exploit sikeres lefutása után az SWF fájlban lévő shellkód három fájlt tölt le: ezek közül az egyik az NvSmart.exe, az NVIDIA egy teljesen legitim programja a cég hiteles digitális aláírásával, a másik egy DLL, a harmadik pedig egy obfuszkált bitkatyvasz. Az NvSmart.exe, mivel digitálisan aláírt, az operációs rendszer illetve a biztonsági programok szemponjából kiemelt ügyfél, akire kevésbé szigorú ellenőrzések vonatkoznak, így könnyen telepítheti magát úgy, hogy automatikusan elinduljon minden rendszerindításkor. Szárnysegédjét, a bizonyos DLL-t azonban a támadók lecserélték, így az ebbe elhelyezett kicsomagoló kód minden alkalommal élesítheti a harmadik fájlban rejtőző PlugX trójait. 

Az  AlienValut kutatása azonban még érdekesebb infókkal is szolgált: a trójai debug információit összevetve korábbi kártevőmintákkal találtak egy debug szimbólumokra mutató elérési utat, ami tartalmazta a létrehozó felhasználó nevét is (ez az információ tipikusan benne marad a lefordított Windows binárisokban), például:

C:\Users\whg\Desktop\Plug\FastGui(LYT)\Shell\Release\Shell.pdb

De ki lehet ez a WHG? Az elmezett szoftverek forrása után kutatva a Google a cnasm.com-ra vezette a kutatókat, ahol meg is találták whg profilját egy e-mail címmel és egy ICQ azonosítóval egyetemben. Az e-mail címből aztán egy sor domain bejegyzést is elő lehetett keríteni, melyek egy kínai szoftverbiztonsággal  foglalkozó  céghez vezetnek, de WHG barátunk nem egy James Bond (de legalábbis nem látta a híres OPSEC for Hackers c. előadást), így még a profilképét is elérhetővé tette a CHDN-en (Chinese Software Developer Network), valamint mint utóbb kiderült, egy szintén WHG néven, arcképpel ellátott fórumbejegyzést használt a hálózati kapcsolat tesztelésére.

Talán mindez túl szép is ahhoz, hogy igaz legyen...

* A név az itatóknál várakozó ragadozóra utal, aki tudja, hogy a préda egyszer biztosan szomjas lesz

wiki.debian.org 

Steve McIntyre a Debian wiki adminisztrátora a debian-devel-announce listán nemrég bejelentette, hogy a "moin" csomag twikidraw / anywikidraw komponensének biztonsági sebezhetőségét illetéktelenek használták ki a Debian wiki szerverén (wiki.debian.org).

Tovább a HUP-on >>

Majomparádé

Aki felkeresi manapság a Majomparadé oldalt, azt tapasztalja, hogy átirányítódik egy másik torrentoldalra. Ezt persze nem az oldal staffja intézte így, egyszerűen megszerezték a domainhez való hozzáférést. [...] A legutóbbi történet hátterében az áll, hogy a Majomparadé tulajdonosának hozzáfértek a Skype és email fiókjához, így többek között hozzáfértek ahhoz az oldalhoz is, ahol a domaint regisztrálták és kezelték. 

Részletek az ASVA.info-n >>

Hétfő reggeli színes: John McAfee úgy tűnik, nem tud nyugton maradni. Miután az AV milliárdos "életművész" sikeresen megszökött Belize-ből, ahol gyilkossággal gyanúsítják, úgy döntött, hogy visszavág, és nyilvánosságra hozza a közép-amerikai miniállam kormányzati szennyesét, amit állítása szerint kifinomult social engineering módszerekkel gyűjtött be.

Ezek a kifinomult módszerek röviden azt takarják, hogy keyloggerrel megpakolt laptopokat osztogatott kormányzati tisztviselőknek és hozzátartozóiknak, valamint hogy lényegében prostituáltakat küldött a megfelelő személyek ágyába - a leírtak alapján ez utóbbi módszer kapott nagyobb szerepet. Lényeg ami lényeg, McAfee szerint Belize helyi útlevek kiadásával segíti a Hezbollah (terror)csoport beszivárgását az Egyesült Államokba. További bizonyítékok megszerzése érdekében McAfee emberei állítolag a Hezbollah nikaraguai sejtjeibe, illetve a szervezettel kapcsolatba hozható mexikói Zetas drogkartellbe (tudjátok, ők azok, akik tucatjával aggatják ki ellenfeleik megcsonkított tetmeit különböző nyilvános helyekre) is beépültek. Szép teljesítmény egy embertől, akinek az élete nagy részt "önmaga számára is rejtély".

A történet körülbelül annyira hihető, mint hogy McAfee homokba ásva egy kartondobozzal a fején rejtőzködött az őt kereső rendőrök elől, minden esetre a csóka elég szórakoztatóan adja elő magát - mondanám, hogy filmet kéne csinálnia, ha nem tudnám, hogy a dolog már folyamatban van.

A Google, a Mozilla és a Microsoft is biztonsági figyelmeztetést adott ki, miután kiderült, hogy a TURKTRUST hitelesítő szolgáltató "véletlenül" köztes CA tanúsítványokat osztott ki arra jogosulatlan szervek számára. A kibocsátott tanúsítványok tetszőleges domain-hez tartozó tanúsítvány hamisítását lehetővé teszik, a problémára is úgy derült fény, hogy a Google a Chrome böngésző hazabeszélő funkcióján keresztül egy illetéktelenül kibocsátott, *.google.com tartományra vonatkozó tanúsítványt észlelt.

A Google értesítette a TURKTRUST-t, akik azt találták, hogy 2011. augusztusában (!) két ilyen problémás tanúsítvány is készült. A google.com-ra vonatkozó tanúsítványt a *.ego.gov.tr-hez tartozó privát kulccsal hitelesítették - török kormányzati domain, hát nem furcsa? A legdurvább az egész történetben az, hogy a böngészőgyártók ezek után csak a "tévesen kiadott" köztes tanúsítványokat, valamint az illetéktelenül használt *.google.com tanúsítványt feketelistázzák, a TURKTRUST-t nem! 

Azt hiszem, nálam a CA alapú (globális) PKI most írta le magát véglegesen.

Záró gondolat Rob Grahamtől: ha tanúsítványt hamisítasz, hagyd ki a Google-t, a százmilliós Chrome-szenzor hálózat úgyis lebuktat.

Friss1: Bocs, a Mozilla mégis megvonta a bizalmat a TURKTRUST-tól (legalábbis ideiglenesen, és csak az egyik gyökerükre)

Friss2: Közép-hosszú távú megoldás a hasonló problémákra például a Convergence lehet.

Friss3: A TURKTRUST magyarázata itt olvasható. Állításuk szerint a hiba egy teszt során keletkezett, a problémát pedig - egy ezzel összefüggő bejelentés hatására - még 2011-ben orvosolták. Én már csak azt nem értem, hogy ekkor miért nem derült ki, hogy rossz paraméterekkel lettek leosztva tanúsítványok? A Google MitM szituációra a szervezet szerint azért került sor, mert egy rendszergazda a hibáasn kiállított tanúsítványt feltöltötte egy CheckPoint eszközre, mely ennek hatására automatikusan MitM módba váltott - ezt a viselkedést azonban több szakértő vitatja.

Az elmúlt évben talán a szokásosnál is többet agyaltam azon, hogyan lehetne a blogot az új idők széljárásához igazítani, év végére ezek a gondolatok fogantak meg az agyamban:

Twitter

Ahogy azt már sokszor, sok helyen elmondtam, IT-biztonsági területen a Twittert nem lehet figyelmen kívül hagyni. Ezen kívül az én saram, hogy idő hiányában egy csomó infót az elmúlt 12 hónapban kizárólag csiripeléssel osztottam meg, ami nem feltétlenül jó, de biztos jobb, mint a semmi. Ezért a jövő év első feladata a Twitter-doboz újrapozicionálása/tervezése lesz, hogy az akár másodpercenként beömlő hírek jobban a látogató szeme előtt legyenek. 

Hírek

Elképesztően büszke vagyok magamra, mivel a tavaly év végi fogadalmamat, mi szerint minden héten csinálok összefoglaló posztot a megelőző 7 nap eseményeiről érzésem szerint minimális hibaaránnyal sikerült megtartanom. Ez azonban nem akadályoz meg abban, hogy ezt a fogadalmat a "hülye ötletek" kalapba tegyem: a hírösszefoglalók ugyanis rendesen ellustítottak, a blog esszenciáját adó kontent színvonala pedig úgy érzem, elsilányult. Emellett, ha annyi időt fordítottam volna hétvégenként szakmai tartalmak összeállítására, mint az n+1. szkriptsuttyó bandával kapcsolatos anyagok összevadászására, ma mindannyian sokkal okosabbak lennénk. 

Hírösszefoglalók tehát nem lesznek 2013-ban. Ennek valószínűleg az lesz a hátránya, hogy a kevésbé szakmai tartalmat (pl. bukták) nem itt fogjátok megkapni először, viszont becsszóra igyekezni fogok az érdekesebb témákat (lásd a betépett AV milliárdos közép-amerikai kalandjai) önálló posztokban úgy kifejteni, ahogy azt a hazai hírgyártó üzemektől nem kapjátok meg, plusz hétvégi kötelező posztokra eddig szánt időt remélhetőleg érdekesebb tartalom gyártására fogom tudni fordítani. 

Frissítések

A Microsoft frissítések követése a heti hírekkel szemben továbbra is beváltnak látszik, és szerencsére egyre többen próbálják magukat Redmond órájához igazítani. Mindezt figyelembe véve a frissítő posztok kibővülve, az egy időben frissítő nagy gyártók csomagjait egyben összefoglalva kerülnek majd bemutatásra.

+++

Természetesen a Kedves Olvasók véleménye a legfontosabb, így minden, a fentiekkel kapcsolatos kommentárt, vagy kiegészítést, új ötletet szívesen fogadok a poszt alatt!

Az év második felében kevésbé voltatok aktívak, így az utolsó két negyedév eredményeit így egyben közlöm. 9 bejelentésből az érintett weboldalak üzemeltetői 3 4 esetben reagáltak, egy esetben pedig a CERT vette kezébe az ügyeket. Ezúton is köszönöm kispaci, Dávid, zozi56, gyorkop, EQ, Dxt3r M0rg4n, Scott Anyo és buksikutya fáradozásait, csak így tovább srácok!

A hajtás után jöjjön a feketeleves!

Célzott támadáokhoz használt 0-day exploitot fedeztek fel, melyet a amerikai Külügyi Tanács (Council on Foreign Affairs - független tanácsadó testület) feltölt honlapján keresztül terjesztettek. A támadók gondosan ügyeltek rá, hogy a kártékony kód csak megfelelő nyelvi beállításokkal rendelkező böngészőkben fusson le, valamint igyekeztek kétszer nem ugyanarra a vadra lőni:

var h=navigator.systemLanguage.toLowerCase();
if(h!="zh-cn" && h!="en-us" && h!="zh-tw" && h!="ja" && h!="ru" && h!="ko")
{
  location.href="about:blank";
}

Maga az exploit az Internet Explorer legfeljebb 8-as verzióit támadja az mshtml.dll egy use-after-free sérülékenységén keresztül. A probléma kihasználásához a támadók Flash heap spray-t használnak, de a feladat nyilván más módszerrel is elvégezhető, ezért a Flash kikapcsolása nem segít. Mivel az eredeti dropper a különböző keresők cache-ében megtalálható, nagyon könnyen előfordulhat, hogy az exploitot beemelik a népszerű exploit kitekbe, így kiterjedt támadásokkal számolhatunk. 

Megoldásként egyelőre IE9 vagy 10, vagy alternatív böngésző használata javasolható.

Friss: A meglévő exploittal - és feltehetően a legtöbb leszármazottal szemben is - hatékony megoldás lehet az EMET Mandatory ASLR illetve ROP-mitigációs opcióinak használata. Az exploit a Java 6 által fix helyre betöltött MSVCR71.DLL-t, vagy az Office által használt HXDS.DLL-t használja az ASLR kijátszására, míg az összeállított ROP lánc a megszokott könyvtári függvényeket alkalmazza.

Friss 2: Megjelent a Microsoft FixIt készlete, ami átmeneti megoldást jelent a problémára. A készlet most is a Windows kompatibilitási rétegének felhasználásával, betöltéskor módosítja a sérülékeny DLL-t. Az Exodus Intelligence közben részletes elemzést közölt a problémáról (végre nem kell kínairól fordítani...), valamint a Low Fragmentation Heap memóriaallokációs tulajdonságainak kihasználásával heap-spray nélküli PoC-t is közzétettek.

Friss3: Az Exodus Intelligence elemezte a kiadott FixIt-et, és arra jutottak, hogy az nem nyújt kielégítő védelmet a sérülékenységgel szemben, egy módosított exploittal a FixIt-es rendszerek felett is átvehető az irányítás.