Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

Obfuszkáljunk Java exploitot!

2012.09.02. 22:51 | buherator | 27 komment

A Java 7 0day-el kapcsolatos infókat tárgyaló posztban rendes kis flame alakult ki azzal kapcsolatban, hogy tulajdonképpen mennyit is ér egy antivítus szoftver egy nulladik napi sérülékenységgel szemben. Ma este volt egy kis időm foglalkozni a dologgal, és csináltam pár nagyon egyszerű tesztet, az eredmények sajnos nem túl szívderítőek.

Mielőtt azonban belemennénk a részletekbe egy kis disclaimer:

  • Tegnap volt Depth születésnapja (boldogat mégegyszer ;), szóval lehet, hogy nem leszek 100%-ig precíz ma este, építő kritikát most is szívesen fogadok
  • Bár elég sokat fejlesztettem annak idején Javaban, nem vagyok Java hacker
  • Nem azt akarom mondani, hogy az antivírus termékek feleslegesek, mert nem azok, de mint minden szoftvernek, ezeknek is megvannak a korlátai, amivel nem árt tisztában lenni

A méréshez a nagyszerű VirusTotalt használtam, ahol 42 különböző víruskerető motor vizsgálta a feltöltött mintákat. A teszteléshez a Metasploithoz járó, "nem felfegyverzett" exploit kódot használtam a CVE-2012-4681 sérülékenységre - erről részletes infók olvashatók az Immunity jóvoltából itt, illetve magyarul a JavaForumon. Azért tettem így, mert bár sok esetben éppen a hasznos teher (shellkód, downloader, stb.) az, amit a biztonsági szoftverek detektálnak, ezeknek elkészítésére és variálására végtelen számú módszer létezik, nem lehet megmondani, hogy egy adott célpont vagy kampány esetében milyen kódok fognak eleget tenni a támadó szándékainak. 

I. Az első teszt természetesen az eredeti kóddal történt, így 15/41-es (37%) detektálási rátát lehetett elérni, ami nem éppen magas, de feltételezhetjük, hogy a többi termék a nagy mennyiségben terített payloadokat kapja el. 

II. Egy baki következtében ez után leteszteltem egy olyan osztályt is, amiben a SunToolkit osztálynak nem a  getField metódusára hoztam létre az Expression objektumot - így a felismerési arány 10/42-re (24%) esett vissza, de természetesen ezzel a változtatással az exploit nem is működne.

III. A következő lépésben az exploit eredeti terjesztői által adott Gondvv névről átneveztem az osztályt Buherator-ra. Ezzel a csellel csak a DrWeb-et sikerült átverni, a felismerés 14/42-re (33%) esett vissza.

IV. Többet nyertem azzal, hogy a tévedésből beküldött tesztesetből (II.) kiindulva a "getField" sztringet így állítottam össze:

String gf="xetField";
Expression localExpression = new Expression(GetClass("sun.awt.SunToolkit"), "g"+gf.substring(1), arrayOfObject);

Ezzel a félelmetesen bonyolult trükkel hat víruskergetőt sikerült kiiktatni, ezzel 9/42-re (21%) esett vissza az arány.

V. A sikeren felbuzdulva hasonló módon átalakítottam a "setSecurityManager"-t is, ezzel még két vetélytárstól sikerült megszabadulni - 7/42 (17%)

VI. Mire vadásznék ha szignatúrát gyártanék? A SunToolkit-et viszonylag ritkán kell hívni normál esetben, így ennek az osztálynak a nevével is bűvészkedtem kicsit:

private Class GetClass(String paramString)
throws Throwable
{
paramString="sun"+paramString+"Toolkit";
// ...
}

A megérzésem nem volt túl jó, csak egy játékos használt ilyen illesztési mintát - 6/42 (14%)

VII. A disableSecurity() metódus neve elég beszédes - mi lenne, ha átneveznénk? Még egy játékos kiesett: 5/42 (12%)

Ennél a pontnál a nagyobb gyártók közül az ESET, az F-Secure, a Kaspersky, a McAfee, a Sophos és a Symantec is széttárja kezeit, az apróhalak mellett csak az AVG és az Avira ismeri fel a veszélyt (és amennyire látom ezek sem annyira dominánsak vállalati környezetben, de javítsatok ki ha tévednék!).

A 10%-os álomhatár átlépésével most nem foglalkoztam, így is harmadára sikerült leszorítani a detekciós rátát, nagyjából fél óra munkával, és teljesen primitív sztring manipulációval. A Permissions, ProtectionDomain illetve AccessControlContext osztályok valamiféle indirekt elérésével (pl. reflection vagy az exploit által egyébként is használt Statement illetve Expression osztályok) egyébként valószínűleg hamar ki lehetne lőni még pár versenyzőt - jó játék ;)

Tanulságként azt tudnám megfogalmazni, hogy az antivírus telepítésénél nem állhat meg a védelem kiépítése. A fejlett támadásokat hoszt illetve hálózati szintű megerősítő megoldásokkal kell kordában tartani, szem előtt tartva, hogy a támadók előbb vagy utóbb át fognak törni az első védelmi vonalainkon.

Friss:

Csaba jóvoltából, az OPSWAT felmérése alapján sikerült kiszámolnom a visszaesést piaci lefedettség tekintetében a nagyobb gyártókra vonatkozóan. A táblázatot megtekinthetitek itt, az eredmény röviden: 

A fenti trükkökkel világ szinten az AV felhasználók legalább egyharmadának lehetett volna kellemetlen perceket okozni azokon kívül, akiknek egyébként sem detektálta az eszköze az exploitot. Az utolsó iteráció után a felhasználók 27.5%-a biztosan védett maradt, 20.7%-ról nem állt rendelkezésre elegendő információ. A maradék több mint 50%-ot a vírusírtók valószínűleg megvédték a legtöbb internetről érkező támadástól, de egy új variáns már valószínűleg bajt csinált volna. 

Meglepő egybeesés egyébként, hogy az 5 legnagyobb részesedéssel rendelkező gyártó fel volt készülve a hasznos teher nélküli exploitokra, míg a TOP10 alsó része nem.

Címkék: java antivírus

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

zomg · http://lixnix.tumblr.com 2012.09.02. 23:25:21

szegeny IsteeF most hogy arccal haritotta a murvat AV ugyben johet kommentelni hogy akkor meg mi ved a Java 0day ellen.

Hunger 2012.09.03. 00:04:58

én csak annyit szeretnék mondani:

Boldog szülinapot Depth! ;)

|Z| 2012.09.03. 09:35:33

Amennyiben exploit kódról van szó, akkor a virustotal-os összehasonlítás szerintem nem mond sokat, csak a szignatúra alapú keresés hátrányát mutatja be. De a virustotal gyakorlatilag csak szignatúra alapú keresést használ az AV termékekben, meg minimál heurisztikát. Véleményem szerint egy jó hoszt IPS-t exploit obfuszkációval nehezebb átverni, mint a szignatúra védelmet.

blog.virustotal.com/2012/08/av-comparative-analyses-marketing-and.html

_2501 2012.09.03. 10:08:02

Boldog Szülinapot Depth! :)

buherator · http://buhera.blog.hu 2012.09.03. 21:55:32

@|Z|: "csak a szignatúra alapú keresés hátrányát mutatja be" - erről szólt a poszt ;) No meg arról, ami az említett előző threadben, illetve a JavaForumon szóba került, nevezetesen, h "használj AV-t, jó lesz neked".

auth.gabor · http://wiki.javaforum.hu/display/~auth.gabor 2012.09.03. 22:38:29

@buherator: Ahja... ebből is látszik, hogy mennyire kevés Java-hoz értő dolgozik a AV fejlesztések körül... :)

Továbbra is azt mondom, hogy az aláírás nélküli appleteket szinte 0% false positive rátával lehetne blokkolni, és tovább konvergálna a nulla felé a false positive, ha néhány -- aláíratlan appletben kevéssé előforduló osztályra is lenne szűrés...

Segítsetek már, mondjatok olyan weboldalakat, ahol van aláíratlan applet és gyakran belebotlik az ember... lehet, hogy én járok rossz oldalakra, de évek óta nem találkoztam ilyennel. :)

IsteeF. 2012.09.04. 10:05:59

Bocs fiúk, de ne vegyük már egy kalap alá a statisztikában a "noname" antivirusokat, mint pl. TheHacker, TotalDefense, soha senki nem hallott róluk. Szóval abból a 40 antivirusból kb 10 ismert van, és mint látom az ingyenes víruskeresőkközül amit a legtöbb ember használ mivel ingyenes (AVAST és AVG) mindkettő bennemaradt az 5%ban. Ennyi, zomg.

|Z| 2012.09.04. 10:21:46

@buherator: és a politikai korrektség miatt illik megemlíteni, hogy egy mai modern AV már nem csak szignatúra keresésből áll ;)

buherator · http://buhera.blog.hu 2012.09.04. 13:29:34

@IsteeF.: A nagy gyártókra az eredeti posztban is külön kitértem, a VirusTotal eredményeket bárki átböngészheti, a frissítésben pedig szerepelnek a piaci részesedésre vetített adatok. Jó lenne ha nem WO módban kommentelnél.

buherator · http://buhera.blog.hu 2012.09.04. 13:30:45

@auth.gabor: A terv az nem rossz, de a megvalósítások egyszerűen nem így működnek. De ha gondolod, elkezdhetsz házalni a gyártóknál az ötlettel :)

buherator · http://buhera.blog.hu 2012.09.04. 13:31:59

@|Z|: A kedvedért felveszem a TODO listára a HIPS/Security Suite teszteket is ;)

IsteeF. 2012.09.04. 16:11:36

@buherator: A WO mód az append módnak köszönhető, utólag frissitések hozzáadvaa poszthoz, amit későn vettem észre :P

Hunger 2012.09.04. 19:00:56

@|Z|: Mit tud kezdeni egy AV/HIPS ezzel a Java design problémával? Van saját Java VM-je, emulátora, bármilye, amivel ezt detektálni tudná?

auth.gabor · http://wiki.javaforum.hu/display/~auth.gabor 2012.09.04. 22:33:57

@Hunger: "Van saját Java VM-je, emulátora, bármilye, amivel ezt detektálni tudná?"

Miért kellene JVM ehhez?

Például rá tud(na) akaszkodni a classloading folyamat végére, amikor egy egyszerű és jól meghatározott jar/zip fájlból való olvasás történik, amiből rövid úton kiderülhet, hogy az adott JVM (amiről lehet tudni, hogy a böngésző indította el) akar-e olyan osztályokat betölteni, amelyeket nem szabadna neki. De nem hinném, hogy nekem kellene ötleteket adni az AV gyártóknak... :)

Hunger 2012.09.05. 01:18:58

@auth.gabor: aha, és van a Javanak erre interfésze, hogy rá tudjon "akaszkodni" a classloading folyamatára egy külső alkalmazás csak úgy? Vagy hogy gondolod? Hogy megpatcheli az AV runtime a JVM kódját, hogy megszerezze az ellenőrzést, vagy esetleg debug regisztereket állít be a classloader belépési pontjaira? És van egy külön adatbázisa, amelyik csak a különböző Java verziók megfelelő offset címeit tartalmazza ehhez? Vicces lenne.

De ha ezt meg is tudná tenni, akkor is mi van... Egy adott class betöltése főben járó bűn, vagy mi? Ha azt valaki betölti, akkor az csak tuti malware lehet? Akkor ezek szerint az a class eleve erre van tervezve a Sun/Oracle által? ;)

Érted, ez ilyen meseszép, amit így elképzelsz a securityről és a világról, de az AV megoldások nem így működnek...

auth.gabor · http://wiki.javaforum.hu/display/~auth.gabor 2012.09.05. 08:31:37

@Hunger: " aha, és van a Javanak erre interfésze, hogy rá tudjon "akaszkodni" a classloading folyamatára egy külső alkalmazás csak úgy? Vagy hogy gondolod?"

Már írtam. Egészen pontosan az rt.jar-ból való olvasás a legprimitívebb módszer. :)

"De ha ezt meg is tudná tenni, akkor is mi van... Egy adott class betöltése főben járó bűn, vagy mi? Ha azt valaki betölti, akkor az csak tuti malware lehet?"

Egy class betöltése nem feltétlen, több class betöltése már lehet minta.

"Érted, ez ilyen meseszép, amit így elképzelsz a securityről és a világról, de az AV megoldások nem így működnek... "

Ha kicsit visszavennél az arcodból, akkor több erőforrásod maradna gondolkodni...

|Z| 2012.09.05. 09:35:16

@Hunger: Teljesen igazad van, az AV termékek hips része a Java exploitok detektálásában nem jeleskednek. Pont ezért várom nagy izgalommal Buherátor frissítését a HIPS és egyéb tesztekkel kapcsolatban, és akkor már teljes lesz a kép, és bátrabban ki lehet jelenteni a tutit :)

Hunger 2012.09.05. 09:43:13

@auth.gabor: ROTFL. Itt gondolkozni neked kellene már egy kicsit, mert ha nem vetted volna észre, akkor csupán a te képzeletbeli víruskeresődről beszélgetünk és te ugyanazt ismételgeted napok óta. Majd ha mutattál egyetlen AV-t, amelyik ilyen Java classloader hookolást végez és úgy ellenőrzi az Appleteket futásidőben, akkor majd lesz értelme gondolkozni azon, hogy az hogyan játszható ki. Persze ezen se kell majd sokat agyalni, mivel már másnap jöttek arról hírek, hogy más osztályokon keresztül is kihasználható a hiba. Aztán majd, amikor már minden második appletre fals pozitív riasztást dob az AV, akkor majd jót kacarászunk a remek ötleten, mivel ugye nem csak ezt kellene felismernie, hanem a többi Java sebezhetőség kihasználását is, amelyek nem túl meglepő módon megint csak más osztályokban találhatók.

Amikor a több mint fél éves Java hibát is még aktívan használják ki remekül obfuszkált exploitokkal ( www.virustotal.com/file/3392b09c5e038dcc51f81bdf23e55fa35376445c112bed34263debb677b90fc7/analysis/ ), akkor esetleg elgondolkozhatnál azon, hogy lehet már másnak is eszébe juthatott az ötleted, de a való életben nem annyira könnyen kivitelezhető, mint ahogy te azt elképzeled.

Kettőnk közül én már fejlesztettem víruskeresőt is, meg IDS/IPS megoldást is és tudom milyen problémák és buktatók vannak a témában, úgyhogy az arcodból neked kellene már visszavenned... Nyilván ez nem lesz könnyű, amikor még a FDE@VPS baromságodnál se ismerted be, hogy rohadtul semmi értelme.

axt · http://axtaxt.wordpress.com/ 2012.09.05. 11:52:15

@auth.gabor: Azért ez nem feltétlen ilyen egyszerű, tekintve, hogy olyan java security hibák is vannak, ahol nem az rt.jarból betöltés ellenőrzése nem fog meg semmit (pl AtomicReferenceArray bug). Vagy pl egy doPrivileged-es hibát, nem tudsz a classloadingnál megfogni.

@Hunger: Van ilyen interface. Tudsz agent librarykat definiálni (nem összetévesztendő a sima javában írt instrumentation agentekkel), elég sok mindenhez hozzá lehet férni ezen keresztül, de nem teljes a lefedettsége:

java.sun.com/developer/technicalArticles/J2SE/jvm_ti/

buherator · http://buhera.blog.hu 2012.09.05. 15:32:07

@|Z|: Milyen tesztalanyokat ajánlanál?

auth.gabor · http://wiki.javaforum.hu/display/~auth.gabor 2012.09.05. 17:27:15

@axtaxt: "Azért ez nem feltétlen ilyen egyszerű, tekintve, hogy olyan java security hibák is vannak, ahol nem az rt.jarból betöltés ellenőrzése nem fog meg semmit "

Bocsánatot kívánok, én ezt nem is említettem... csak azt, hogy a bytecode elemzés mellett van még jó néhány lehetőség, amely segíthet a detektálásban.

Joe80 2012.09.05. 22:22:39

Ha van egy java kod amit letoltok es lokalisan inditok el akkor az több mindenhez hozzáfér? tehát ha úgy indítom el a böngészőből hogy file:// és nem ?

Amúgy jó lenne ha eleve le lehetne korlátozni a java appokat és csak dedikáltan egy-egynek megengedni bizonyos könyvtárak olvasását.

kb 1 java program van amivel beolvastatok filet lokálisan ez az abevjava :)

Joe80 2012.09.05. 22:23:43

Ha van egy java kod amit letoltok es lokalisan inditok el akkor az több mindenhez hozzáfér? tehát ha úgy indítom el a böngészőből hogy file:// és nem h t t p : / /?

|Z| 2012.09.06. 13:31:58

@buherator: Norton, Kaspersky, Gdata, Bitdefender, AVG, FSecure, ESET, Avast, Avira . Mindenből az internet securiy suite.

Nekem az első háromról vannak pozitív felhasználói tapasztalataim.
süti beállítások módosítása