A múlt héten egy súlyos, tetszőleges kódvégrehajtást eredményező, és széleskörűen kihasználható biztonsági hiba rázta meg az internetet. A hiba Marcus Hutchins biztonsági szakértő becslése szerint több millió alkalmazást érinthet, és az iCloud platform is köztük van – vagyis volt, az Apple már javította.

Ez azt jelenti, hogy a rendszeres alkalmazás- és internethasználók jó eséllyel futtatnak olyan appot vagy nyitnak meg olyan oldalt, amelyben létezik a hiba.

A sérülékenység kihasználása a létező legsúlyosabb, illetve károkozásra legkönnyebben használható eredménnyel járhat: tetszőleges kód távoli végrehajtásával a védtelen alkalmazásban. A hibáról részletes beszámolót író LunaSec adatbiztonsági cég kutatója, Free Wortley szerint:

“It’s a design failure of catastrophic proportions.”

Azaz: “Ez egy katasztrofális méretű tervezési hiba.”

Technikai háttér

A hiba Java nyelven írt alkalmazásokat és weboldalakat érint. A sérülékenység a Log4j nevű naplózó (logging) könyvtárban található. A naplózás igazából egy szakkifejezés arra, hogy egy informatikai rendszerben bizonyos, fontos eseményekről rövid, tömör, általában egysoros szöveges üzeneteket írnak egy erre fenntartott fájlba és/vagy az üzemeltetést végző informatikusok által szemmel tartott felületre. Ennek a tevékenységnek az a célja, hogy információval szolgáljon akkor, amikor például hibát kell keresni a rendszerben, vagy amikor egy betörési kísérletet próbálnak meg utólag felgöngyölíteni.

Önmagában tehát ez nem egy nehéz probléma, legalábbis elviekben nem kellene, hogy az legyen. Az alapfeladat csak az, hogy a programozó által specifikált formában egy fájlba sorokat írjon a naplózószoftver, és biztosítsa, hogy ezek a fájlok elérhetők maradjanak (például archiválással és új, időbélyeges fájl kezdésével naponta, vagy amikor az előző már túl nagyra nőtt.) Mégis, a sok apró technikai részlet miatt érdemes külön erre a célra kifejlesztett library-t használni.

A Log4j pontosan egy ilyen szoftverkönyvtár, amelyet majdnem minden Java-fejlesztő ismer és használ. A Java ugyan mostanában kevésbé elterjedt a felhasználói alkalmazások írása szempontjából, azonban az üzleti életben még így is rengeteg helyen használják. Mint minden valamirevaló szoftver, ez is túlburjánzott az egészséges határokon. A sima szöveges naplózás mellett támogatja ugyanis különböző “változók” beillesztését az üzenetekbe, és nem is akárhogyan. Az üzenetek kiírása előtt a Log4j előfeldolgozója ${prefixum:név} formájú sablonokat keres, és kiértékeli azokat. Az egyik ilyen speciális forma a ${jndi:url}, ami a Java Naming and Directory Interface (JNDI) nevű technológia segítségével képes Java kódot dinamikusan betölteni, futtatni, és az eredményt az üzenetbe naplózás előtt beszúrni.

Amennyiben a megadott erőforrás egy LDAP URL, a Log4j kérdés nélkül betölti és végrehajtja az ott található Java végrehajtható fájlt. Természetesen ez azt jelenti, hogyha egy támadónak sikerül egy olyan URL-t bejuttatnia a rendszerbe, ami az általa írt rosszindulatú kódot tartalmazza, akkor nyert ügye van. Ezt pedig nem olyan nehéz elérni, hiszen az alkalmazások egy sor különböző eseményt, felhasználói interakciót logolnak. A Java programozási nyelvnek egy időben szlogenje volt, hogy “3 millárd készüléken fut”. A szituációt tehát úgy is összefoglalhatjuk, hogy a Java szinte mindenhol fut, még ott is, ahol nem kéne.

Gondoljunk csak arra, hogy például emailezés közben mennyi minden történik: bejelentkezünk, kijelentkezünk, megnyitunk egy emailt, a kukába tesszük, megjelöljük spamként, betöltődik benne egy kép, stb. Egy emailszolgáltató lehet, hogy akár minden egyes ilyen ponton naplózni fog egyet. Lehet például, hogy ha az adott szolgáltatáson keresztül megpróbálunk egy olyan emailt küldeni, aminek a címzettje egy érvénytelen email-cím, de tartalmaz a fenti formátumban megadott rosszindulatú kódot, akkor az egyszerűen végrehajtódik az email-szolgáltató gépein.

Ha a külső forrásból származó kód végrehajtása történetesen le is van tiltva a rendszerben, már önmagában az URL meghívása is okozhat problémát. Lehetséges például ilyen módon adatot lopni: ha az üzenetet úgy állítja össze a támadó, hogy a meghívott URL részét képezze valamilyen érzékeny információ is, akkor ezáltal ki tudja csempészni az adatokat a rendszerből.

Az LDAP protokoll mellett egyébként más, külső szerverekkel kommunikálni képes protokollok is kihasználhatóak ugyanerre a célra, például az LDAPS (az LDAP titkosított változata), az RMI (a Java beépített távolifüggvényhívás-protokollja), vagy a DNS, az internet kiszolgálóneveket (például szifon.com) IP címekké feloldó infrastruktúrája is.

Idővonal

• 2021. november 24. | A hibát jelenlegi ismereteink szerint az Alibaba Cloud Security Team fedezte fel és hozta titokban az Apache tudomására. (A Log4j könyvtárat már nem annak eredeti írója, Ceki Gülcü tartja karban, hanem az Apache Software Foundation égisze alatt fejlesztik tovább.)
• 2021. december 6. | Megjelenik a Log4j 2.15.0-rc1 verziója, amely részben javítja a sebezhetőséget.
• 2021. december 9. | A sebezhetőség első nyilvános megjelenése. Egy magát “Web Security Engineer” (internetes biztonsági szakértő) foglalkozásúként megjelölő felhasználó a Twitteren tette közzé a Log4Shell-t, egy példakóddal (PoC) együtt. Az eredeti tweetet azóta törölte; az érdeklődők az Internet Archive Wayback Machine segítségével itt tekinthetik meg.

Hatás és javítás

Az Amerikai Egyesült Államok Kiberbiztonsági és Infrastruktúra-biztonsági Ügynökségének (Cybersecurity and Infrastructure Security Agency, CISA) igazgatója, Jen Easterly kritikusnak és magas prioritásúnak nevezte a hibát.

A Log4j-t fejlesztő Apache Software Foundation a hibát 10-es súlyossági skálán 10-re értékelte. A Tenable kiberbiztonsági cég elnöke, Amit Yoran, az “elmúlt évtized hibájának” nevezte.

E sorok írója szerint, habár a hiba valóban rendkívül súlyos, azért a 2018 elején nyilvánosságra hozott Spectre és Meltdown még ennél is rosszabbak voltak, hiszen a Log4shell tisztán szoftverhiba, és szoftverfrissítéssel orvosolható.

Az Apple az iCloud esetén már javította

Az Apple-felhasználók szempontjából lényeges, hogy az almás cég is gyorsan reagált: már december 11-én kijavították a sérülékenységet az iCloudban. Ezt az Eclectic Light Company biztonsági elemzői állapították meg, akik december 9-én is 10-én még képesek voltak az iCloud rendszerén az exploitot demonstrálni, amely azonban egy nappal később már nem működött.