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

Java 7 0day - Frissítve

2012.08.27. 15:13 | buherator | 30 komment

Ma reggel egy vadiúj Java 7-et érintő 0day exploitról érkeztek hírek. A problémát az ok.aa24.net-en jelenleg is aktívan kihasználják kártékony kódok terjesztésére. Mint minden jóra való Java exploit, ez is igen megbízhatóan működik tetszőleges platformon, az Oracle következő frissítése viszont csak október közepére van betervezve. Az egyetlen jó hír, hogy a probléma csak a JVM 7-es változatát érinti, tehát a 6-os verzióra történő visszaállás segít a problémán. Az OpenJDK érintettségével kapcsolatban egyelőre nem találtam információt.

A Metasploit projekt 24 órán belül portolta az exploitot a keretrendszerbe, így most már bárki tesztelheti a rendszereit a sérülékenységgel szemben. Maga a kód meglepően egyszerű, és bár részletes elemzést nem láttam nálam okosabbaktól, ha jól látom arról van szó, hogy a java.awt.SunToolkit.getField() privilegizált környezedben hajlandó kikapcsolni bármelyik objektum bármelyik mezőjén a Java hozzáférésellenőrzését, így egy Applet számára elérhetővé tehető a System.setSecurityManager() amivel beállíthatjuk, hogy a távoli szkript a helyi megbízható programoknak megfelelő jogosultságokat kapjon.

Axtaxt jobban érzi a Java-fu-t:

Egészen pontosan az történik, hogy az exploit kreál egy java.beans.Statementet ami execute() esetén a "setSecurityManager(null)"-t hívja. Ez azonban SecurityExceptionnel elszállna, ezért az AccessControlContextjét felülírják egy az az exploit által definiálttal (AllPermission). Ehhez van szükség a sun.awt.SunToolkit osztály getField függvényére, ami elvégzi privilegizált környezetben a setAccessible(true) hívást a kívánt fieldre, hogy így már reflectionnel könnyen megtehető legyen az AccessControlContext felülírása. Viszont a "sun.awt.SunToolkit"-re alapból nem tudnánk class referenciát szerezni appletből, mert az applet security managere ezt nem engedi, hiszen az osztály a "sun.*" csomag része. Ezt viszont egy elegáns new Expression(Class.class, "forName", new Object[] {"sun.awt.SunToolkit"}).invoke() hívással mégiscsak sikerül megoldani.

Ha jön még infó, frissítem a posztot, addig is kapcsoljátok ki a Java-t, vagy legalábbis váltsatok 6-os főverzióra (ez nem biztos hogy tartós megoldás lesz, lásd a frissítést!), esetleg próbáljátok ki a Deep End Research foltját!

Friss:

A Deep End Research is publikálta a sérülékenység részleteit. Michael Schierl szerint a problémát egész konkrétan a sun.beans.finder.ClassFinder osztály helytelen megvalósítása okozza, ez teszi lehetővé a tiltott csomagokhoz történő hozzáférést. Az exploitnak ezen túl meg kell oldania azt is, hogy a byte kód ellenőrző ne kezdjen visítani, ha meglátja az appletben a sun csomagra történő hivatkozást, erre nyújt megoldást a Statement osztály használata - nem mellesleg, reflectionnel egy csomó víruskergető is átvágható. A cikk szerint Java 7-nél korábbi változatokon a SunToolkit.getField() még privát metódus volt, ezért nem megy az exploit, a ClassFinder problémája más tiltott osztály közreműködésével is kihasználható lehet! 

Friss2:

A MITRE a CVE-2012-4681 hibajegyet rendelte a sérülékenységhez. Egyes biztonsági cégek állításával szemben jó eséllyel nem célzott támadásokról van szó.

Friss3:

Java6u34-el tesztelve az exploit már a Class.forName("sun.awt.SunToolkit")-nél hozzáférési kivételt dob, ez jó hír a 6-os verziót futtatók számára.

Friss4:

Kicsit keveset vagyok netközelben mostanság, néhány gyors infó:

Címkék: java 0day metasploit

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.

buherator · http://buhera.blog.hu 2012.08.27. 16:57:51

@axtaxt: Köszi, mindjárt beemelem a posztba a kommented! Nekem még nem volt időm tesztelni, első körben arra gyanakodtam, hogy a java.bean-t csak obfuszkációra használják. Akkor jól értem, hogy a SunToolkit helyesen működik, a probléma gyökere az, hogy Appletből is el tudjuk érni az Expression osztály segítségével?

axt · http://axtaxt.wordpress.com/ 2012.08.27. 17:18:16

@buherator: ok, nyugodtan töröld utána a kommentem, felesleges a redundáns info.

A kérdésre viszont nem egyszerű a válasz, mert az biztosan egy elég durva security bug, hogy az Expression osztály segítségével mégiscsak lehet egyébként nem betölthető osztályokra referenciát szerezni, vagy gondolom ennyi erővel akár példányosítani is őket. Viszont a sun.awt.SunToolkitben is teljesen feleslegesen van egy public static függvény ami doPrivileged blokkban setAccessible-t hív, főleg úgy, hogy nem is láttam rá referenciát (csak greppeltem), hogy bárki használná valamire. Arra tippelek, hogy ez egy "defective by design" függvény, ami "bent maradt" a kódban, ahelyett, hogy törölték volna.

Erendis42 2012.08.28. 18:42:43

azt olvastam, hogy mivel a régebbi verziókban meg régi lukak vannak, legbiztonságosabb ideiglenesen kikapcsolni a java plugint úgy, ahogy van (aztán kihúzni a gépből a tápkábelt).

Joe80 2012.08.28. 22:03:59

Mi az hogy tiltott osztály? Ha tiltott akkor ki használhatja?

buherator · http://buhera.blog.hu 2012.08.28. 22:14:39

@Joe80: Az itnernetről letöltődő appletek megbízhatatlan kódnak számítanak, amik nem férhetnek hozzá egy csomó olyan erőforráshoz közvetlenül, amihez a megbízható Java programok igen: doc.sumy.ua/prog/java/javanut/ch06_08.htm

auth.gabor · http://wiki.javaforum.hu/display/~auth.gabor 2012.08.29. 22:34:59

Update: wiki.javaforum.hu/pages/viewpage.action?pageId=28442766

Úgy néz ki, hogy az OpenJDK6-ba is backportolták a hibát az JDK7-ből, az Oracle JDK6 viszont nem érintett a hibában.

Hunger 2012.08.30. 20:59:15

@auth.gabor: "nem feltétlen szükséges a JRE/JDK eltávolítása a gépekről, ahogy azt több helyen is olvashatjuk, a helyzet kezelését rábízhatjuk a víruskereső szoftverekre"

ne kacagtasd ki magad security témában még jobban, az FDE@Cloud témánál már úgyis megtetted legutóbb... ;)

auth.gabor · http://wiki.javaforum.hu/display/~auth.gabor 2012.08.30. 21:17:16

@Hunger: "ne kacagtasd ki magad security témában még jobban, az FDE@Cloud témánál már úgyis megtetted legutóbb... ;) "

Maximum Te kacagtál...

auth.gabor · http://wiki.javaforum.hu/display/~auth.gabor 2012.08.30. 21:20:01

@Hunger: Mondjuk kifejthetnéd, hogy vírus és egyéb ellen védő szoftverek miért ne tudnának blokkolni egy ilyen helyzetet...

Hunger 2012.08.30. 22:38:25

@auth.gabor:

- Mert triviális obfuszkálni az exploit kódját úgy, hogy az AV ne tudja detektálni?
- Mert az AV nem rendelkezik saját Java VM-el, így maximum mintaillesztéssel tud kártékony kódokat felismerni, ami édes kevés?
- Mert az egész AV ipar egy hatalmas hazugságon alapul és annyira hatékonyak, mint az egyensúlyjavító mágneskarkötők?
- Mert az egész visszavezethető Turing eldönthetetlen problémaosztályára? (Halting Problem)

De te voltál középiskolai tanár, neked kellene ezt jobban tudnod... ;)

auth.gabor · http://wiki.javaforum.hu/display/~auth.gabor 2012.08.30. 22:47:55

@Hunger: "Mert triviális obfuszkálni az exploit kódját úgy, hogy az AV ne tudja detektálni?"

Túl sok módszer nincs a java.beans.Expression adott konstruktorának hívására és ilyen szinten nem obfuszkálható a (byte)kód.

"Mert az AV nem rendelkezik saját Java VM-el, így maximum mintaillesztéssel tud kártékony kódokat felismerni, ami édes kevés?"

Lásd fenn. Annyira-de-annyira nem hemzsegnek a Java appletek a nagy közönség által használt oldalakon, hogy kapásból gyanús és/vagy tiltható lehetne az összes aláíratlan applet futtatása. Akinek kell az applet futtatás, tudni fog róla, hogy neki szükséges.

Az egész appletes szívás a JavaFX vergődés miatt van még életben, az Oracle-nél nem merik kimondani, hogy az applet és a JavaFX halott.

"Mert az egész AV ipar egy hatalmas hazugságon alapul és annyira hatékonyak, mint az egyensúlyjavító mágneskarkötők?"

Ezt inkább nem kommentelném.

"Mert az egész visszavezethető Turing eldönthetetlen problémaosztályára? (Halting Problem)"

Ezt se.

Hunger 2012.08.30. 23:07:11

@auth.gabor: Ne is kommentelj, legutóbb se fogtad fel, hogy miért nincs értelme FDE-nek a Cloudban...

auth.gabor · http://wiki.javaforum.hu/display/~auth.gabor 2012.08.30. 23:22:07

@Hunger: "Ne is kommentelj, legutóbb se fogtad fel, hogy miért nincs értelme FDE-nek a Cloudban..."

Egyrészt felfogtam, csak a hozzá fűzött kérdéseimet nem tudtad vagy akartad megérteni, másrészt ennek semmi köze a témához... hiába próbálsz terelni. :)

Hunger 2012.08.31. 01:01:25

@auth.gabor: A hozzá fűzött kérdéseid valójában kijelentések voltak, amelyek ugyanakkora csúsztatásokat tartalmaztak, mint az a jelenlegi szerecsenmosdatásod, hogy nincs nagy jelentősége ennek a hibának, mert akik ki akarják használni "azoknak nem okozhat nehézséget egy hamis, de érvényes és hiteles aláírás megszerzése" sem.

auth.gabor · http://wiki.javaforum.hu/display/~auth.gabor 2012.08.31. 07:32:25

@Hunger: "A hozzá fűzött kérdéseid valójában kijelentések voltak, "

Benned ez mély nyomot hagyott. :)

"amelyek ugyanakkora csúsztatásokat tartalmaztak"

Mint amekkorára válaszoltam.

"mert akik ki akarják használni "azoknak nem okozhat nehézséget egy hamis, de érvényes és hiteles aláírás megszerzése" sem. "

Szerinted nehéz nem EV certet szerezni?

Hunger 2012.08.31. 08:39:48

@auth.gabor: Nehezebb és veszélyesebb, mint ezt a publikus hibát egyszerűen csak felhasználni.

Nem látod a határvonalakat. Ez volt a baj legutóbb is. Azzal érveltél, hogy ennyi erővel kihasználhatnak egy 0dayt a hardverben is. Nem látod a különbséget egy VPS snapshotból való FDE kulcs kinyerése és egy hardver 0day hiba között. Egyenrangú problémáknak tartod.

Ezek után minek koptatta volna tovább PaX Team is a billentyűzetet, amikor turdusi magasságokba szökkeltél a neki adott válaszoddal szintén...

hup.hu/cikkek/20120415/ubuntu_alapokon_fut_az_instagram_milliard_dollaros_uzlete#comment-1451429

auth.gabor · http://wiki.javaforum.hu/display/~auth.gabor 2012.08.31. 10:16:42

@Hunger: "Ezek után minek koptatta volna tovább PaX Team is a billentyűzetet"

Az egész PaX Team... mind a ketten ott voltatok? Nem emlékeztem már erre ennyire pontosan... :)

"Nem látod a határvonalakat. Ez volt a baj legutóbb is."

Továbbra is fenntartom, amit akkor írtam:
"Nézd, én leírtam többször, hogy értem a problémát, ahogy azt is, hogy bármikor korlátlanul tovább lehet vinni a bizalom vs biztonság fogalmát... ez egy határvonal, amelynek fekvése láthatóan teljesen szubjektív alapokon nyugszik..."

Amíg csak olyan komponensei vannak a rendszerednek, amelyeket a legutolsó alkatrészig csak és kizárólag egy személyben Te magad terveztél meg, gyártottál le a saját egyszemélyes gyáradban és üzemeltetsz a saját egyszemélyes felügyeleteddel, addig van lehetőséged biztonságról beszélni.

Ha már van egy komponens, amelyre ez nem igaz, akkor már csak bizalomról beszélhetsz és a biztonság jogi fogalommá válik.

buherator · http://buhera.blog.hu 2012.08.31. 13:13:19

@Hunger: Ontopic plz
@auth.gabor: Kösz a linket, víruskergetőkről ennyit: www.h-online.com/security/news/item/Only-9-of-22-virus-scanners-block-Java-exploit-1696462.html

Rég óta tervezek egyébként Java sploit vs. AV posztot, adtál még egy lökést :)

auth.gabor · http://wiki.javaforum.hu/display/~auth.gabor 2012.08.31. 13:29:35

@buherator: "víruskergetőkről ennyit"

Ezek szerint mégis csak detektálható és blokkolható.

"Rég óta tervezek egyébként Java sploit vs. AV posztot, adtál még egy lökést :) "

Az érdekelne majd. Bár a Java applet és JavaFX kvázi halott, egyre kevesebb helyen van böngésző plugin...

Jah, a javításról háttérinfó:
wiki.javaforum.hu/pages/viewpage.action?pageId=28442797

:)

buherator · http://buhera.blog.hu 2012.08.31. 13:44:56

@auth.gabor: Nagyon durva becsléssel az AV felhasználók fele még mindig veszélyben van, pedig napok óta ettől hangos a web. A másik felével meg az a baj, hogy módosítasz pár helyen a kódban, és ez a detekciós ráta erősen lecsökken (kis önreklám: silentsignal.hu/docs/S2_Kliens_oldali_tamadas_tanulmany.pdf ).
Egy-egy konkrét kártevőt mindig könnyű elkapni, a kihívás az, hogy olyan szignatúrát gyárts, ami nagyjából általános védelmet ad az exploit (és nem a payload!) ellen, anélkül, hogy a legitim használatot sértené. Persze lehetne úgy játszani, hogy sok a false+, de felhasználók döntő többsége számára ez nem elfogadható, az AV-k nem így működnek.

auth.gabor · http://wiki.javaforum.hu/display/~auth.gabor 2012.08.31. 21:59:09

Egy befoltozva, de van másik:
wiki.javaforum.hu/pages/viewpage.action?pageId=28442806

Erről most nincs még információ, hogy milyen új lehetőséget talált. :)

IsteeF. 2012.09.01. 10:59:58

@Hunger: Hunger már megint itt okoskodik, bármilyen kommentedet látom, lesül róla hogy imádsz okoskodni. Miért épülne hazugságra az AV ipar? Kaspersky a képedbe röhögne.

auth.gabor · http://wiki.javaforum.hu/display/~auth.gabor 2012.09.01. 13:45:09

@buherator: "Nagyon durva becsléssel az AV felhasználók fele még mindig veszélyben van, pedig napok óta ettől hangos a web."

Értem én, de ez szerintem mindig is így volt... nem hinném, hogy minden AV szoftver mindig azonnal minden támadási formát felismert vagy blokkolt. :)

"A másik felével meg az a baj, hogy módosítasz pár helyen a kódban, és ez a detekciós ráta erősen lecsökken"

A Java bytecode eléggé jól elemezhető, az RT hívások például nem obfuszkálhatóak.

"Egy-egy konkrét kártevőt mindig könnyű elkapni, a kihívás az, hogy olyan szignatúrát gyárts, ami nagyjából általános védelmet ad az exploit (és nem a payload!) ellen, anélkül, hogy a legitim használatot sértené."

Aláírás vagy hiteles aláírás nélküli applet szerintem nem legitim használat kb. 10 éve... nyugodtan ki lehetne mondani.

"Persze lehetne úgy játszani, hogy sok a false+, de felhasználók döntő többsége számára ez nem elfogadható, az AV-k nem így működnek."

Nem nagyon tudok példát mondani olyan Java applet-re, amely nincs aláírva hitelesen és széles körűen használva van.

Hunger 2012.09.01. 14:59:42

@IsteeF.: Zsenikém, Kaspersky egyet értene, mert tud számolni és ért a témához, ellenben veled. A jelenleg létező 20 millió egyedi malware szignatúrát esélytelen katékonyan real-time ellenőrizni a mai desktop gépeken úgy, hogy mellette használható maradjon a rendszer. Az egy másik kérdés, hogy nem fogja nagy nyilvánosság előtt ezt hangoztatni, mert védi az üzletét.

A Trend Micro viszont más üzleti stratégiát választott és már évekkel ezelőtt beismerte ezt:

hup.hu/cikkek/20080717/trend_micro_az_antivirus_iparag_20_evig_hazudott

Úgyhogy STFU.

IsteeF. 2012.09.02. 02:47:07

@Hunger: Kosz a linket okostoni, de nekem ne reklamozd a gagyi hupos oldalad, nem erdekel a gagyi portalod a szenzacio hajhasz cikkeiddel. Nem kell 20 millio virust felismerni te nagyon idiota, mivel a virusok elevulnek. A C&C szervereket bezarjak a hibakat befoltozzak. Amellett szignatura alapu felismeres mellett vannak mas teknikak, pl. az avast sandboxjarol gondolom meg nem hallottal te kis hulye, hogy csak egyet emlitsek.

Hunger 2012.09.02. 12:26:31

@IsteeF.: ROTFL

Látom képben vagy mindennel! (nem)

buherator · http://buhera.blog.hu 2012.09.02. 15:04:29

@auth.gabor: "nem hinném, hogy minden AV szoftver mindig azonnal minden támadási formát felismert vagy blokkolt. :)"
Világos, de egy aktuálisan aktívan kihasznált 0dayt illene azonnal betenni a DB-be, akár egy gyenge szignatúrával, másképp tényleg semmi értelme a userek erőforrásait pazarolni.

"A Java bytecode eléggé jól elemezhető, az RT hívások például nem obfuszkálhatóak"
Ezzel, és az aláírások képbehozásával pedig megint visszatérhetünk a false+ témához - látom hogy meg kell írnom az obfuszkálós cikket.

synapse · http://www.synsecblog.com 2012.09.03. 12:25:22

@Isteef: A fogalmatlansagodnal csak az arcod nagyobb, kerlek menj el innen mashova osztani az eszt. Nem allok le elmagyarazni miert nincs igazad, mert aki neked elmondja azt leszarod. Hulyekkel meg nem vitatkozom.