A számítógépes bűnözők digitális aláírással ellátott Java-exploiteket használnak a felhasználók megcsalására

A biztonsági kutatók arra figyelmeztetnek, hogy a számítógépes bűnözők elkezdték használni a digitális tanúsítványokkal aláírt Java-exploiteket, hogy becsapják a felhasználókat, hogy lehetővé tegyék a rosszindulatú kódok böngészőkön belüli futtatását. a németországi Chemnitz-tudományi Egyetemhez tartozó weboldalt, melyet egy g01pack nevű Web exploit toolkit fertőzött meg, a biztonsági kutató Eric Romang kedden egy blogbejegyzésben elmondta.

"Ez határozottan go01 csomag", Jindrich Kubec, a fenyegetett hírszerzés igazgatója víruskereső eladó Avast, mondta e-mailben.

[További olvasnivalók: Hogyan távolítsuk el a rosszindulatú programokat Windows számítógépről]

Nem volt azonnal világos, hogy ez a kizsákmányolás új biztonsági rést vagy egy régebbi Java-hiba, amelyet már korrigáltak. Az Oracle új hétfői biztonsági frissítéseket adott ki két kritikus sebezhetőség kezelésére, amelyek közül az egyiket a támadók aktívan kihasználták.

A Java-kihasználásokat hagyományosan nem aláírt appletekként - Java webes alkalmazásokként szállították. Az ilyen kisalkalmazások végrehajtását régebbi Java verziókban automatizálták, ami lehetővé tette a hackerek számára, hogy elindítsák az áldozatok számára teljesen átlátható letöltési támadást.

A tanúsítvány visszavonásának ellenőrzési beállításai a Java 7-ben

A januári kiadással kezdődően A Java 7 Update 11 alapértelmezett biztonsági beállításai a webalapú Java tartalom magas szintűek, így a felhasználók megerősítést kérnek, mielőtt az alkalmazások böngészőkön belül futhatnak, függetlenül attól, hogy digitálisan alá vannak-e írva.

az aláírt aláírások használata az aláírók számára előnyökkel jár a támadók számára, mivel a két esetben a Java által megjelenített megerősítési párbeszédek jelentősen eltérőek. Az aláírás nélküli Java-kisalkalmazások párbeszédablakai "Biztonsági figyelmeztetés" néven szerepelnek.

A digitális aláírás fontos része azoknak a felhasználóknak, akik megbízhatnak a kódban, mondja Bogdan Botezatu, a Bitdefender víruskereső gyártója, az e-fenyegetettség elemzője. Az aláírt kódra vonatkozó megerősítő párbeszédablak sokkal diszkrétabb és kevésbé fenyegető, mint az előjel nélküli kód esetében.

"Ezen túlmenően a Java maga is feldolgozza az aláírt és az alá nem írt kódokat, és megfelelően érvényesíteti a biztonsági korlátozásokat." Botezatu mondott. Például, ha a Java biztonsági beállítások "nagyon magasak", az aláírás nélküli kisalkalmazások egyáltalán nem futnak, míg az aláírt kisalkalmazások futnak, ha a felhasználó megerősíti a műveletet. A vállalati környezetekben, ahol nagyon magas szintű Java biztonsági beállítások érvényesülnek, a kódkódolás lehet az egyetlen módja annak, hogy a támadók rosszindulatú kis appletet futtassanak egy célzott rendszeren.

Példa a biztonsági javításra az aláírt Java-applethez a Java 7 frissítésében 17

Ez az új Java-kihasználás arra is rávilágított, hogy a Java alapértelmezés szerint nem ellenőrzi a digitális tanúsítványok visszavonását.

A hétfői kutatók által felfedezett kizsákmányolás digitális bizonyítvánnyal íródott, amely valószínűleg ellopott. A tanúsítványt Go Daddy adta ki a Texas-i Austin-i székhelyű Clearesult Consulting cégnek, és ezt követően visszavonták a 2012. december 7-i dátummal.

A tanúsítvány visszavonása visszamenőleges hatállyal alkalmazható, és nem világos, hogy mikor pontosan Go Daddy megjelölte a visszavonási igazolás. Azonban, a február 25-én, három nappal a kizsákmányolás legrégebbi mintájának feltárása előtt a tanúsítvány már szerepel a vállalat által közzétett tanúsítvány-visszavonási listában, mondta Kubec. Ennek ellenére a Java a tanúsítványt érvényesnek tekinti.

A Java vezérlőpult "Speciális" fülén a "Speciális biztonsági beállítások" kategóriában két opció található: "A visszavonási tanúsítványok ellenőrzése a tanúsítvány-visszavonási listák használatával (CRL-ek) "És" Az online tanúsítványok érvényesítésének engedélyezése "- a második opció OCSP (Online Certificate Status Protocol) protokollt használ. Mindkét opció alapértelmezés szerint le van tiltva.

Az Oracle e-mailen az e-mailben kedden elmondta: "A biztonság megőrzése kényelemért komoly biztonsági felügyelet, különösen, mivel a Java a leginkább célzott, harmadik féltől származó darab volt a szoftver 2012 novembere óta "- mondta Botezatu. Mindazonáltal az Oracle nem egyedül van ebben, a kutató azt mondta, megjegyezve, hogy az Adobe az Adobe Reader 11-et olyan fontos homokozó-mechanizmussal zárta le, amely alapértelmezés szerint le van tiltva használhatósági okok miatt.

Mind a Botezatu, mind a Kubec meg van győződve arról, hogy a támadók egyre inkább elkezdenek digitálisan aláírt Java kihasználja, hogy könnyebben megkerülje a Java új biztonsági korlátait.

A Bit9 biztonsági cég a közelmúltban kiderítette, hogy a hackerek veszélyeztették egyik digitális tanúsítványát, és felhasználták a rosszindulatú programokat. Az elmúlt évben a hackerek ugyanezt tették az Adobe kompromittált digitális tanúsítvánnyal.

Ezek az incidensek és ez az új Java-exploit bizonyítja, hogy az érvényes digitális tanúsítványok a rosszindulatú kód aláírásával zárulhatnak, mondta Botezatu. Ebben az összefüggésben különösen fontos a tanúsítványok visszavonásának aktívan ellenőrzése, mivel ez az egyetlen mérséklés, amely tanúsítvány-kompromisszum esetén áll rendelkezésre.

Azok a felhasználók, akik napi rendszerességgel a böngészőben Java-ot igényelnek, fontolóra kell venniük a tanúsítvány visszavonásának ellenőrzését megvédje az ellopott tanúsítványokat kihasználó támadásokkal szemben, mondta Adam Gowdiak, a lengyel sebezhetőségi kutatóintézet, a Security Explorations alapítója, e-mailben. A biztonsági kutatások során a kutatók az elmúlt évben több mint 50 Java sebezhetőséget találták és jelentettek be.

A felhasználóknak manuálisan engedélyezniük kell ezeket a tanúsítvány-visszavonási lehetőségeket, sokan valószínűleg nem teszik meg, mivel nem is telepítik a biztonsági frissítéseket, mondta Kubec.. A kutató reméli, hogy az Oracle automatikusan bekapcsolja a funkciót egy későbbi frissítésben.