A jelenlegi helyzetről és a megoldási lehetőségekről a KPMG kiberbiztonsági laborjának munkatársai készítettek egy összefoglalót – ezt közöljük az alábbiakban.

A közlemény az elejéről indít: a sokak életét felkavaró hiba egy Log4j nevű programcsomagban van, amit 20 éve lényegében változatlan formában beépítenek minden Java alapú programba, amiben van jelentősége annak, hogy naplózni tudja a tevékenységeket, márpedig erre szinte mindenben szükség van.

A szoftverfejlesztők az általánosnak mondható feladatokat nem programozzák le újra és újra, hanem végrehajtásukra kész programcsomagokat húznak be egy alapkészletből. Most ennek az alapcsomagnak az egyik darabjáról derült ki, hogy hibás. A Google becslése alapján több mint 35 ezer olyan Java csomag van, ami használja az Apache Log4j könyvtárat. „A Log4j használata annyira általános, hogy cégek, kormányzatok és magánszemélyek életében egyaránt jelen van. Ez azt jelenti, hogy ezekben a napokban nemcsak a rosszindulatú hackerek, de a jó oldal képviselő (fejlesztők, biztonsági kutatók, rendszerintegrátorok) is keresik a Log4j csomagokat a rendszerekben. Detektáló programok már vannak, de teljesen bolondbiztos automatizált keresésről sajnos még nem beszélhetünk” – mondja Tanos Áron, a KPMG kiberbiztonsági laborjának vezetője.

A 2.17.0 és a 2.12.3 jól semlegesítik a Log4Shell hibából eredő problémát, és csökkentik az okozott kárt. Csakhogy a csere a gyártó felelőssége lenne, de mint mondtuk, gyakran ő sem tudja, hogy annak idején a beszállítói mibe, milyen környezetben építették be a Log4j, sőt az sem kizárt, hogy a beszállító már nem is létezik.

Tovább nehezíti a helyzetet, hogy a Log4j-ben nem is egy, hanem mindjárt két hiba van. Az egyik maga a Log4Shell (két CVE-t is találtak: CVE -2021-44228, CVE-2021-45046), másik a CVE-2021-45105, ami ugyancsak szoktak az ismertté vált néven illetni, de nem ugyanaz (mi most Log4Shell/2 néven fogjuk illetni). Maga a Log4Shell távoli kódfuttatást tesz lehetővé, vagyis a támadók a sérülékenység kihasználásával saját céljaikat szolgáló parancsokat adhatnak az alkalmazásnak, amire normális használat közben nem lenne lehetőségük. A Log4Shell/2 ezzel szemben azt teszi lehetővé, hogy a támadók a távolból túlterheléssel ellehetetlenítsék a szoftverek működését.

Tanos Áron szerint előfordulhat, hogy a frissítéshez, javításhoz, le kellene állítani az eszközt, ám ez lehetetlen, mert mondjuk egy lélegeztetőgépben van, és az éppen életben tart valakit. Az is elképzelhető, hogy Log4j olyan részegységben (konténer) található, amit eleve cserélni kell, ez mind megnehezíti, hogy megszabaduljunk a hibától.

Amiről eddig azt mondtuk, hogy a semlegesíti a problémát vagy enyhíti a kárt, azt szoftveres nyelven gyűjtőnéven mitigációnak nevezzük. „A mitigáció nem egyenértékű sem a javítással, sem a kárenyhítéssel. Valami olyasmit jelent, hogy elérjük, hogy a káros esemény többet ne forduljon elő, de addig is teszünk róla, hogy a lehető legkisebb kárt okozza” – mondja a KPMG szakértője. Ad abszurdum az is része lehet a mitigációnak, ha lemondunk az adott eszköz vagy szoftver használatáról, és kihúzzuk a falból. Ez persze drasztikus megoldás, aminek mérlegeléséhez tudnunk kell, hogy milyen kárt okozunk vele.

A mitigáció tehát rendkívül tág fogalom, ezért a legtöbb sebezhetőség esetében léteznek drasztikus és kevésbé drasztikus alternatív megoldások. „Többféle módon lehet helyesen és sajnos helytelenül is semlegesíteni a sérülékenységet, de fontos megérteni ezek korlátait. Ezek nemcsak a fent már említett közvetlen károk lehetnek, hanem közvetettek is: az átmenti megoldások hamis biztonságérzetet teremtenek, a kibervédelmi szakma általában nem győz csodálkozni a korábban úgy felejtett alkalmi megoldásokon. Ilyen körülmények között már az is komoly tudás, ha tudjuk, hogy mit ne tegyünk” – mondja a KPMG kibervédelmi laborjának vezetője.

A sebezhető rendszerek azonosítása

Az első és legfontosabb lépés, mielőtt bármilyen javítási megközelítést választanánk, hogy azonosítsuk az összes olyan alkalmazást és rendszert, amelyek sérülékenyek lehetnek a Log4j exploitra. Ezt nem könnyű megtenni, tekintve, hogy minden alkalmazás képes a saját Log4j példányát használni, de van amikor kívülről húz be a működés során olyan programcsomagot, ami már maga is tartalmaz egy Lof4j-t. Ilyenkor hiába találjuk meg az adott céges program saját Log4J blokkját, nem az fogja okozni a problémát, hanem a behívott külső programé.

A biztonsági közösség gyorsan reagált azáltal, több nyílt forráskódú eszközt is kifejlesztettek a sérülékeny kiszolgálók és a Log4j csomag példányainak automatizált átvizsgálására. Van megoldás, ami képes ellenőrizni a .jar és .war fájlokat egy projektkönyvtárban, és jelenteni tudja, ha vannak sebezhetőek, de a Log4j sérülékenység kimutatása más nyílt forráskódú és kereskedelmi sérülékenység-ellenőrzőket és eszközöket is tartalmaz.

A JndiLookup osztály eltávolítása

Ezt a sérülékenységet az okozza, ahogy a Log4j a JNDI (Java Naming and Directory Interface) nevű Java szolgáltatást használja, amelyet úgy terveztek, hogy lehetővé tegye további Java objektumok betöltését a futásidejű végrehajtás során. A JNDI több protokollon keresztül használható ilyen objektumok betöltésére a remote naming servicesből. Az eredeti kihasználás (exploit) az LDAP-t (Lightweight Directory Access Protocol) használta, amely a leggyakoribb, de sajnos más szolgáltatásokon keresztül is ki lehet használni: DNS (Domain Name System), RMI (Remote Method Invocation), NDS (Novell Directory Services), NIS (Network Information). Service) és a CORBA (Common Object Request Broker Architecture).

A biztonsági rés javításának egyik módja, ha a JNDI üzenetkereséseket letiltjuk, ezt teszi a Log4j 2.16.0 is. Ezt azonban úgy is elérhetjük, hogy lényegében a teljes, ezt a funkcionalitást megvalósító JndiLookup osztályt kivágjuk egy érintett Log4j csomagból.

Gyorsjavítás egy Java ágens használatával

A gyorsjavítás (hotpatching) az a folyamat, amelynek során egy futó folyamathoz egy javítást telepítenek anélkül, hogy újra kellene indítani. A Java támogatja a Java Virtual Machine-ben (JVM) már futó bájtkód futás közbeni módosítását műszeres API-n és úgynevezett Java-ágenseken keresztül. A Java ágens lényegében egy JAR (Java Archive) fájl, amely futás közben dinamikusan csatolható egy JVM-hez.

A Log4j sebezhetőségére válaszul az Amazon Web Services csapata kifejlesztett egy Java-ügynököt, amely megkísérli az összes betöltött org.apache.logging.log4j.core.lookup.JndiLookup instance lookup() metódusát javítani, hogy a „Patched JndiLookup::lookup()” karakterláncot adja vissza a távoli szerverhez való csatlakozás helyett.

Magának a hibának a kihasználása a kihasználás ideiglenes megakadályozására

Egy érdekes megközelítés lehet magát a sebezhetőséget kihasználni az érintett szervereken, hogy bizonyos változtatásokat hajtsanak végre az élő rendszeren és alkalmazáson, amelyek megakadályozzák a további kihasználást.

„Ez a megoldás akkor lehet hasznos, ha harmadik féltől származó termékeket szeretnénk javítani (dobozos alkalmazások, beágyazott eszközök és alkalmazások), amelyekhez még nem állnak rendelkezésre javítások, vagy olyan sebezhető termékek, amelyek elérték az élettartamuk végét, és soha nem kapnak hivatalos frissítést. Az exploit önmaga ellen való alkalmazása a hivatalos frissítésig életképes rövid távú megoldás lehet” – figyelmeztet a KPMG szakértője.

Fontos megérteni, hogy ennek a megközelítésnek vannak bizonyos megkötései. Először is, a javítás átmeneti, mert az exploit által végrehajtott változtatások a futó Java folyamatra vonatkoznak, és a Java Virtual Machine (JVM) újraindulásakor visszaállnak. Ez azt jelenti, hogy az javítást újra kell alkalmazni, ha a szervert újraindítják. Másodszor, bár a módszert különféle konfigurációkon és rendszereken tesztelték, lehetséges, hogy nem működik mindenen, és egyes esetekben összeomláshoz vezethet. Az összeomlás utáni helyreállítás a kiszolgáló újraindításával járhat, ezért nem jó ötlet szakértelem nélkül olyan kritikus rendszereken futtatni, ahol az állásidő nem lehetséges.

Szintén fontos megjegyezni, hogy csak saját szervereken használhatunk ki sérülékenységeket, még akkor is, ha azt javító szándékkal tesszük.

Nem megfelelő mitigációk

Az első Log4j sebezhetőség bejelentése óta számos javasolt mitigáció hatástalannak bizonyult, és már nem szabad rájuk támaszkodni. Ezek elkerülésével nagyon sok időt megtakaríthatunk.

• sajnos a Java-verziók frissítése nem elegendő, az eredeti exploit nem működött a 6u212, 7u202, 8u192 vagy 11.0.2-es verzión, de a támadók sajnos tudnak olyan csomagokat (payload) létrehozni, amik az applikációk saját osztályait használják, ezzel hatástalanítva ezt a védekezést

• az applikáció tűzfalával (WAF) kiszűrni a rosszindulatú kéréseket jó ötletnek tűnhet, de egyrészt rengeteg potenciális ártalmas karakterlánc lehet, másrészt a rosszindulatú csomagokat a támadók össze tudják zavarni, hogy kijátsszák a tűzfalak filterezési szabályait. Arról az aspektusról nem is beszélve, hogy normális esetben a tűzfal a kintről jövő támadások ellen véd, és egy belső exploit a tűzfalon belül lesz kihasználva. Ettől függetlenül a gyártók folyamatosan frissítik a Log4j mintákat, hogy amit lehet, azt kiszűrjék a védelmi eszközök

• egy másik javasolt mérséklés az üzenetkeresések letiltása a naplókimutatás formátumok módosításával. Ebben az esetben az alkalmazásban az összes naplókimutatás formátumot módosítani kell %m, %msg vagy %message formátumról %m{nolookups}, %msg{nolookups} vagy %message{nolookups} értékre az üzenetkeresési funkció letiltása érdekében. Ez a módszer a szolgáltatásmegtagadás (DOS) sérülékenység ellen egyáltalán nem véd, de veszélyes is, mert hamis biztonságérzetet kelt. Nagyon könnyű elmulasztani egy naplózási utasítás frissítését, vagy később újra bevezetni egy sérülékeny %m utasítást anélkül, hogy észrevennénk. Ha már használta ezt a mérséklést, mindenképpen válasszon egy másik megoldást is

Sajnos az egyre komplexebb, egymásra épülő rendszerek magukkal hozzák azt a lehetőséget, hogy összetett megoldásokat kell találnunk a sérülékenységek kijavítására. Az biztos, hogy több támadó is fog más, széles körben használt összetevők hibái után kutatni a sérülékenység nyomán, ezért a sérülékenység mielőbbi kijavítása elengedhetetlen, különösen üzletkritikus rendszerek esetében.