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.
zomg · http://lixnix.tumblr.com 2012.09.02. 23:25:21
Hunger 2012.09.03. 00:04:58
Boldog szülinapot Depth! ;)
|Z| 2012.09.03. 09:35:33
blog.virustotal.com/2012/08/av-comparative-analyses-marketing-and.html
_2501 2012.09.03. 10:08:02
synapse · http://www.synsecblog.com 2012.09.03. 12:36:02
Depth 2012.09.03. 19:46:28
buherator · http://buhera.blog.hu 2012.09.03. 21:55:32
auth.gabor · http://wiki.javaforum.hu/display/~auth.gabor 2012.09.03. 22:38:29
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
|Z| 2012.09.04. 10:21:46
buherator · http://buhera.blog.hu 2012.09.04. 13:29:34
buherator · http://buhera.blog.hu 2012.09.04. 13:30:45
buherator · http://buhera.blog.hu 2012.09.04. 13:31:59
IsteeF. 2012.09.04. 16:11:36
Hunger 2012.09.04. 19:00:56
auth.gabor · http://wiki.javaforum.hu/display/~auth.gabor 2012.09.04. 22:33:57
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
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
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 2012.09.05. 09:43:13
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
@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
auth.gabor · http://wiki.javaforum.hu/display/~auth.gabor 2012.09.05. 17:27:15
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
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
|Z| 2012.09.06. 13:31:58
Nekem az első háromról vannak pozitív felhasználói tapasztalataim.
axt · http://axtaxt.wordpress.com/ 2012.11.22. 17:26:47
security-obscurity.blogspot.hu/2012/11/java-exploit-code-obfuscation-and.html