Tartalomjegyzék[Elrejt][Előadás]
A Log4Shell, az internetes biztonsági rés a közelmúltban több millió gépet érintett. A Log4j, egy homályos, de szinte mindenütt jelen lévő szoftver okozza.
A Log4j minden olyan művelet naplózására szolgál, amely a színfalak mögött történik számos számítógépes rendszerben.
Nyílt forráskódú naplózási könyvtáron alapul, amelyet a vállalkozások, sőt kormányzati szervezetek is használnak a legtöbb alkalmazásban.
Mivel a valaha feltárt egyik legrosszabb kiberbiztonsági lyuk, rendkívül fontos, hogy megvédje rendszereit ettől a sebezhetőségtől. De hogyan?
Vizsgáljuk meg részletesen a Log4j sebezhetőségét és az összes lehetséges javítási megoldást.
Mi az a Log4j?
A Log4j egy nyílt forráskódú naplózási keretrendszer, amely lehetővé teszi a szoftverfejlesztők számára, hogy különböző adatokat rögzítsenek alkalmazásaikban. Ez az Apache Logging Services projekt összetevője, amelyet a Apache Software Foundation.
Webhelyek és alkalmazások százai használják a Log4j-t kritikus műveletek végrehajtására, például adatok naplózására hibakereséshez és egyéb célokra.
Ha rossz online hivatkozást ír be, vagy rákattint, és 404-es hibaüzenetet kap, ez gyakori példa a Log4j működésére. Az elérni kívánt webhivatkozás tartományát futtató webszerver tájékoztatja Önt, hogy nem létezik ilyen weboldal. Ezenkívül naplózza az eseményt a Log4j-ben a kiszolgáló rendszergazdái számára.
A szoftverprogramokban hasonló diagnosztikai jeleket alkalmaznak. A Minecraft online játékban például a szerver a Log4j segítségével naplózza a tevékenységeket, például a teljes felhasznált RAM-ot és a konzolba küldött felhasználói utasításokat.
Hogyan jelentkezik a sebezhetőség?
A keresések a Log4j 2.0-ban bevezetett új szolgáltatás, amely segít további információk beépítésében a naplóbejegyzésekbe. Az egyik ilyen keresés a JNDI (Java Naming and Directory Interface) keresés, amely egy Java API a címtárszolgáltatással való kommunikációhoz.
Ezzel a megközelítéssel a belső felhasználói azonosítók leképezhetők a tényleges felhasználónevekre. Ez a lekérdezés felfedi az újonnan felfedezett RCE biztonsági rést, mivel az LDAP-kiszolgáló által szolgáltatott egyik adattípus egy Java osztályra mutató URI, amelyet ezután betölt a memóriába, és a Log4j példány futtatja.
A Log4j könyvtár bemeneti ellenőrzésének gyengesége miatt lehetséges egy tetszőleges LDAP-kiszolgáló beszúrása nem megbízható forrásból. Mivel a fejlesztők azt feltételezik, hogy a naplókba küldött adatokat sima szövegként kezelik, nem történik extra bemeneti ellenőrzés, és veszélyes felhasználói bevitel kerül be a naplókba.
A log utasítás így nézhet ki:
Egy rosszindulatú felhasználó most beszúr egy JNDI-keresést, amely egy rosszindulatú LDAP-kiszolgálóra hivatkozik egy URL-paraméterbe. A JNDI keresés a következő lenne:
A Log4j könyvtár ezután beszélget ezzel az LDAP-kiszolgálóval a attacker.com címen, hogy megkapja a címtárinformációkat, beleértve a Java Factory és a Java Codebase értékeit.
Ez a két érték tartalmazza a támadó Java osztályát, amely betöltődik a memóriába, és a Log4j példány végrehajtja, befejezve a kódvégrehajtást.
Ki van a veszélyben?
A Log4j biztonsági rése hihetetlenül széles körű, és hatással van az üzleti alkalmazásokra, a beágyazott eszközökre és azok alrendszereire. Az érintett alkalmazások közé tartozik a Cisco Webex, a Minecraft és a FileZilla FTP.
Ez azonban korántsem egy teljes lista. A hiba még az Ingenuity Mars 2020 chopper küldetést is érinti, amely Apache Log4j-t használ az események rögzítéséhez.
A biztonsági közösség összeállította a a sebezhető rendszerek listája. Rendkívül fontos megjegyezni, hogy ezek a listák folyamatosan frissülnek, így ha egy bizonyos program vagy rendszer nem szerepel, ne feltételezze, hogy ez nem érinti.
Ennek a sérülékenységnek való kitettség meglehetősen valószínű, és még akkor is, ha egy konkrét tech verem nem alkalmazza a Java-t, a biztonsági vezetőknek ezt kell elvárniuk a kritikus beszállítói rendszerektől, a SaaS-szolgáltatóktól, a felhőtárhely-szolgáltatóktól és a webszerver-szolgáltatóktól.
Hogyan lehet ellenőrizni a Log4j sebezhetőségét?
Az első lépés annak megállapítása, hogy történt-e már támadás. Ezt úgy teheti meg, hogy a rendszernaplókban ellenőrzi az RCE hasznos adattöredékeit.
Ha a „jndi”, „ldap” vagy „$::” kifejezésekre keresve bármilyen naplót adnak, a biztonsági kutatóknak tovább kell vizsgálniuk, hogy jogos támadásról van-e szó, vagy csupán ujjlenyomatvételről.
Sok olyan támadást fedeztek fel a vadonban, amelyek nem szállítottak káros rakományt. Ennek ellenére biztonsági szakértők végezték el, hogy meghatározzák, hány alkalmazás volt sebezhető a támadással szemben.
A következő lépés a Log4j könyvtár használata az összes projekt azonosítására. Ha 2.0-beta9 és 2.14.1 közötti verziókat használ, a projekt érzékeny lehet.
Tekintettel arra, hogy nehéz meghatározni, hol található ez a sérülékenység, célszerűbb feltételezni, hogy a projekt érzékeny, és hogy a programkönyvtár frissítése a legjobb lépés a kódfuttatás veszélyének elhárítására.
A projekt nem sérülékeny, ha a használt verzió kisebb, mint a 2.0-beta 9, bár a Log4j könyvtárat továbbra is frissíteni kell, mert az 1.x tartományba tartozó verziók régiek, és már nem kapnak frissítéseket.
Ha érzékeny projektet fedeznek fel, javasoljuk, hogy ellenőrizze, hogy a Log4j használatával naplózott információk tartalmaznak-e olyan információkat, amelyeket a felhasználó módosíthat. Az URL-ek, a kérésparaméterek, a fejlécek és a cookie-k példák ezekre az adatokra. Ha ezek közül valamelyik naplózásra kerül, a projekt veszélyben van.
Ezek az ismeretek segíthetnek a rendszernaplókban való további elmélyülésben, és annak megállapításában, hogy a webalkalmazást megtámadták-e már.
Vannak ingyenes online eszközök, amelyek képesek észlelni, ha egy webalkalmazás sebezhető. Az egyik ilyen program az Log4Shell vadász. Nyílt forráskódú, és itt érhető el GitHub.
Ha egy sérülékeny kódterületet fedeznek fel az online alkalmazásban, a közzétett eszköz által biztosított hasznos adat felhasználható a webalkalmazásba való beillesztésére. A tesztelőeszköz felfedi a webalkalmazás és az LDAP-kiszolgáló közötti kapcsolatokat, ha a biztonsági rést kihasználják.
Megoldások a Log4j sebezhetőségének javítására
Az első lépés a Log4j frissítése, amit a normál csomagkezelők használatával vagy közvetlenül innen tölthet le. oldal.
A sérülékenység kihasználhatósága a FORMAT MSG NO LOOKUPS környezeti változó true értékre állításával is csökkenthető. Ez az ellenintézkedés azonban csak a 4-nél nagyobb vagy azzal egyenlő Log2.10j-verziókra vonatkozik.
Most fontoljuk meg az alternatív lehetőségeket.
1. Megkerülő megoldások a Log4j 2.17.0-s verziójához
A Log4Shell elleni védelem érdekében mindenképpen a Log2.15.0j 4-s verzióját javasoljuk, de ha ez nem lehetséges, más megoldások is elérhetőek.
A Log2.7.0j 4 és újabb verziói: A naplózandó események formátumának megváltoztatásával, a felhasználó által szolgáltatott adatok százalékos m nolookups szintaxisával meg lehet védeni minden támadást. A frissítéshez a Log4j konfigurációs fájl szerkesztése szükséges a program új verziójának létrehozásához. Ennek eredményeként az új verzió üzembe helyezése előtt meg kell ismételni a műszaki és funkcionális érvényesítési szakaszokat.
Log4j 2.10.0 és újabb verziók: A log4j2.formatMsgNoLookups konfigurációs paraméter igaz értékre állításával is védekezhet bármilyen támadás ellen, például amikor a Java virtuális gépet a -Dlog4j2 kapcsolóval indítjuk.” formatMsgNoLookups = true, Egy másik lehetőség a JndiLookup osztály eltávolítása az osztályút argumentumból, ami eltávolítja a fő támadási vektort (a kutatók nem zárják ki egy másik támadási vektor lehetőségét sem).
Az Amazon Web Services egy gyorsjavítót biztosít, amelyet „saját felelősségére kell használni”. Más „technikákat” tettek közzé, mint például a Logout4Shell, amely „maga ellen használja ezt a sebezhetőséget”. A biztonsági szakértő megkérdőjelezi ennek a lépésnek a jogszerűségét, amely magában foglalja „egy gép feltörését a javítás érdekében”.
2. A probléma megoldódott a Log4j v2.17.0 verziójában.
2.10-nél nagyobb verziók esetén: A Log4j2.formatMsgNoLookups értéket igazra kell állítani.
2.0–2.10.0 verziók esetén: Futtassa a következő parancsot az LDAP osztály eltávolításához a Log4j-ből.
A Log4j2.formatMsgNoLookups értéket igazra kell állítani a rendszerbeállításokban.
Enyhítés a JVM-ben
A JVM-paraméterekkel történő enyhítés már nem lehetséges. Más enyhítő módszerek továbbra is sikeresek. Ha lehetséges, frissítsen a Log4j 2.17.0-s verziójára. A Log4j v1-hez áll rendelkezésre egy migrációs útmutató.
Ha a frissítés nem lehetséges, győződjön meg arról, hogy az ügyféloldali és a kiszolgálóoldali összetevők a -Dlog4j2.formatMsgNoLookups = true rendszertulajdonság-készlettel rendelkeznek.
Felhívjuk figyelmét, hogy a Log4j v1 elérte élettartamának végét (EOL), és a továbbiakban nem kap hibajavításokat. Más RCE vektorok is érzékenyek a Log4j v1-re. Ezért azt javasoljuk, hogy a lehető leghamarabb frissítsen a Log4j 2.17.0-ra.
3. Mérséklő intézkedések
A jelenlegi kihasználások még akkor sem működnek, ha a Log4j bizonyos esetekben érzékeny, például ha a gazdagépen 6u212, 7u202, 8u192 vagy 11.0.2-nél magasabb Java-verzió fut.
Ennek oka a Java elnevezési és címtárinterfész (JNDI) jobb távoli osztálybetöltési védelme a jelenlegi verziókban, amely szükséges a támadás működéséhez.
Ezenkívül a 4-nél nagyobb Log2.10j verziók esetén a probléma elkerülhető a formatMsgNoLookups rendszerváltozó igaz értékre állításával, a JVM argumentum megadásával -Dlog4j2.formatMsgNoLookups = true, vagy a JndiLookup osztály törlésével az osztályútvonalból.
Addig is, amíg a sérülékeny példányokat ki nem javítják, a sérülékenység az alábbi technikák segítségével orvosolható:
- Állítsa igazra a log4j2.formatMsgNoLookups rendszertulajdonságot >=2.10 esetén.
- Állítsa igazra a LOG4J FORMAT MSG NO LOOKUPS környezeti beállítást >=2.10 esetén.
- Távolítsa el a JndiLookup.class fájlt a 2.0-beta9 és 2.10.0 közötti osztályútról: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Az egyik ajánlott bevált módszer az, hogy az internetre irányuló kimenő forgalmat csak a megfelelő portokra korlátozzuk.
Bár a legtöbb támadás a területen HTTP-n keresztül történik, a biztonsági rés kihasználható bármely olyan protokollon keresztül, amely a Log4j segítségével naplózza a felhasználói bemeneti adatokat.
A log4j 2.17.0 verzióra való frissítés azonban a legjobb megoldás, mert valaki felfedezhet egy további megközelítést a problémára. Ezenkívül sok kiadó és gyártó bejelentette szolgáltatásai vagy alkalmazásai fejlesztését.
4. Log4Shell sebezhetőségi javítás
A Log4j mindenütt jelen van, különösen most, amikor a biztonsági rést kihasználják. Összefoglalva, mindössze annyit kell tennie, hogy a következő karaktereket tartalmazza a Log4j által ellenőrzött naplókban.
Ez pedig letölti és végrehajtja az URL végén található Java fájlt. Ez olyan egyszerű, mint drámai.
Amint azt Ön is tudja, a Log4Shell biztonsági résének (CVE-2.17.0-4) orvoslásához elengedhetetlen a log2021j frissítése >= 44228 verzióra.
Ha ez nem lehetséges:
A Log4j könyvtár 2.10.0-s és újabb verzióit használó alkalmazások esetén a log4j2.formatMsgNoLookups konfigurációs paraméter true értékre állításával is védekezhet a támadásokkal szemben, például a Java virtuális gép -Dlog4j2.formatMsgNoLookups = true paraméterrel történő indításakor. választási lehetőség.
Egy másik lehetőség a JndiLookup osztály törlése az osztályút argumentumból, ami eltávolítja az elsődleges támadási vektort (a kutatók nem zárják ki egy másik támadási vektor létezését).
Megjegyzések
Azoknak a szervezeteknek, amelyek tétováznak vagy nem hajlandók módosítani az érzékeny rendszereken (vagy akik nem kívánnak további biztosítékokat beépíteni), gondoljanak a következőkre:
- Győződjön meg arról, hogy az összes forgalom egy iSensoron/WAF/IPS. Ez megakadályozhatja, hogy a támadás hozzáférjen a rendszerhez.
- Az érzékeny rendszert elérő forgalom korlátozása Ha a rendszernek nem kell csatlakoznia az internethez, korlátozza a hozzáférést az alapvető és megbízható IPS-ekre és tartományokra.
- A fogadó engedélyezett kimenő forgalmának csökkentése. Mivel ez a támadás egy rosszindulatú kiszolgálóhoz való csatlakozással működik, minden felesleges IP-címet és portot blokkolni kell a tűzfalon.
- Ha a szolgáltatásra már nincs szükség, le kell tiltani, amíg el nem készül a javítás.
Következtetés
A Log4j hibái sokkolták közösségünket, és mindannyiunkat emlékeztettek arra, hogy mennyire függünk a nyílt forráskódú szoftverektől.
A Log4j egyedi. Nem operációs rendszer, nem is böngésző, és nem is szoftver. Inkább az, amit a programozók könyvtárnak, csomagnak vagy kódmodulnak neveznek. Csupán egy célt szolgál, vagyis a szerveren történt események nyilvántartását.
Azok, akik kódot írnak, szívesebben koncentrálnak arra, hogy mi teszi szoftverüket jellegzetessé. Nem érdekli őket a kerék újrafeltalálása. Ennek eredményeként számos meglévő kódkönyvtárra támaszkodnak, például a Log4j-re.
A Log4j modul az Apache-ból, a legszélesebb körben használt webszerver-szoftverből származik. Éppen ezért több millió szerveren fedezhető fel. Emiatt fokozódik a biztonsági fenyegetés.
Remélem, hogy a fenti megoldások segítenek megőrizni eszközei biztonságát.
Maradjon velünk a HashDork oldalán, hogy további hasznos információkat kapjon a technológiai világból.
Hagy egy Válaszol