2021. december 9-én vált ismertté, és azóta hangos a kiberbiztonsági sajtó (ha van ilyen) attól a sérülékenységtől, amely az Apache Foundation által fejlesztett Java alapú Log4j elnevezésű naplózási eszköz 2. verziójával kapcsolatosan derült ki. A sérülékenység a CVE-2021-44228 azonosítót és a Log4Shell nevet, CVSS skálán (Common Vulnerability Scoring System, a sérülékenységek súlyosságát meghatározó pontozási rendszer) pedig a legmagasabb 10-es értéket kapta. Súlyosságát jelzi, hogy a Log4j használata rendkívül elterjedt, valamint a Log4Shell nehezen detektálható módon ad lehetőséget kártékony kódok távolról történő lefuttatására. Szükségesnek láttam röviden, nem belebonyolódva a technikai mélységekbe bemutatni a sérülékenységet és annak ipari (ICS) hálózatokra gyakorolt hatását.

Mi is az a Log4Shell?

A sérülékenység a széles körben elterjedt logolási eszköz, a Log4j log-kezelési mechanizmusára épül. A támadó a hálózaton kívülről indíthat kérést a kiszemelt szerver irányába, amelynek fejlécébe beágyaz egy JNDI keresést indító (Java Naming and Directory Interface) string-et. Ahogy a Log4j naplózza a kérést, lefuttattja a benne kapott keresést, amely viszont egy távoli, a támadó által kontrollált LDAP szervert kérdez le, ahonnan letöltődik és lefut a kártékony kód, akár egy, a gyártást teljesen leállítani képes ransomware. Így gyakorlatilag távoli hozzáférés, vagy C2 kapcsolat nélkül nyílik lehetőség bármely malware célbajuttatására és lefuttatására a támadók gépeiről (RCE – Remote Code Execution), és megszerezhető a hozzáférés az áldozat rendszeréhez (Initial Access).

Ha azt feltételezzük, hogy a támadó már bejutott a hálózatunkba, akkor az ezen belüli mozgáshoz (Lateral Movement) is kihasználható a Log4Shell, ebben az esetben viszont a már egy helyi szerverre eljuttatott kártékony kódot kell lefuttatni (LCE – Local Code Execution).

A Log4Shell-re válaszul kiadott első patch-eket követően derült fény egy másik ezzel összefüggő sérülékenységre, amely a CVE-2021-45105 azonosítót kapta, és DoS (Denial of Service) támadásra ad lehetőséget. A Log4j a „ThreadContext map”-ben megkeresi a naplózott kérésekben található változókat, mint például a felhasználónevet. A támadó ezt képes úgy manipulálni, hogy ez a keresés végtelenszer újra generálódjon, ha egyszer elindították, amely túlcsordulásos hibához (Stack Overflow failure) vezet és leállíthat létfontosságú szolgáltatásokat, amelyek talán épp a legkritikusabb termelési folyamatokhoz szükségesek.

ICS érintettség

A Log4j használata, mint már azt említettem, nagyon elterjedt és ez alól nem kivételek ICS gyártók sem, mivel az ipari rendszereknél is fontos funkció a különböző biztonsági és teljesítmény információk naplózása. Az egyik legnagyobb és legelterjedtebb ICS és IIoT gyártó Siemens jelentése szerint 17 termékük érintett az elsőként felfedezett sérülékenységben, melyek között megtalálható a PLC-k programozására használt LOGO! SoftComfort szoftver is. Érintettek még többek között a Java-t használó OPC-UA szerverek, SCADA (Supervisory Control and Data Acquisition) és EMS (Energy Management System) rendszerek, valamint a szerverek virtualizációjánál ICS környezetben is előszeretettel használt VMware ESXi.

Az ipari hálózatok gyenge pontjai tehát az internetre kilátó és Log4j 2-t használó eszközök, valamint azok a hálózati kapcsolatok, amelyek egyik végén az irodai IT hálózat valamely, ebben a sérülékenységben érintett eszköze található.

Hogyan reagáljunk?

A legkézenfekvőbb megoldás a sérülékeny eszközök frissítése a legújabb verzióra (patch-elés). Az Apache Foundation által kiadott 2.17 verzió mindkét tárgyalt sérülékenységre megoldást kínál. Viszont itt jön a képbe az időtényező, ami nem a biztonsági szakembereknek dolgozik. A Log4j sokszor több szinten van alkalmazva, így a teljeskörű frissítés bonyolult és hosszadalmas feladat akár csak egy rendszer esetén is. Mindenképp szükséges a patch-ek telepítése, viszont a reakciónkat érdemes több vonalon elindítani.

Legyünk tisztában az érintettségünkkel.

Gyakori probléma, hogy az üzemeltetők nem ismerik megfelelően a saját hálózatukat, főleg nem azt, hogy hány potenciálisan érintett eszközzel rendelkeznek. Érdemes most dönteni hálózatfelügyeleti képesség bevezetéséről, amely alkalmas a kommunikáló és nem kommunikáló eszközök felderítésére, jelezve azok sérülékenységeit. Több gyártó rendelkezik már frissítésekkel a Log4Shell és a kapcsolódó sérülékenységek felismerésére és az azokat kihasználó támadások detektálására. Az ezek által összegyűjtött eszközleltár segítségével hamarabb látható a hálózat támadási felülete, gyors észlelés pedig elengedhetetlen, ha a megtörtént incidens további eszkalálódását meg akarjuk előzni.

Figyeljünk az IT-re.

A Log4Shell a laterális mozgás eszköze is lehet, tehát használható az eleve kompromittált IT hálózatról a gyártási szegmensbe történő vándorláshoz. Jobb, ha a támadók csak az IT hálózaton maradnak, illetve, ha oda sem jutnak be. Hogy egy egész vállalati hálózatot érintő támadást csírájában elfojthassunk, szükségünk van IT oldalon valamilyen SIEM rendszer alkalmazására, valamint az ez és az ICS oldali hálózatfelügyeleti rendszer által észlelt aktivitásokat közösen monitorozni egy IT/ICS műveleti központban (Security Operations Center, SOC). Ennek bevezetése igen komplex feladat, így természetesen ez hosszabb távú fejlesztés tárgya, ám annál nagyobb előrelépést jelent.

Gondoljuk újra a hálózati architektúrát.

A fő támadási vektorok a direkt internetkapcsolatok és az IT hálózattal való direkt kommunikáció. Mivel mindkettő forrásra szükség van, nem zárható le hermetikusan egy ICS rendszer sem, viszont érdemes minden külső kommunikációt DMZ szegmenseken (akár külön a közös elérésű szervereknek, és külön a gyártói frissítések kezelésének) keresztül bonyolítani, hogy egy esetleges kártékony kód futtatás minél kisebb területre legyen koncentrálható, elkülönítve a kritikus rendszerektől. A DoS támadásokkal szemben használjunk ICS környezeteknek megfelelő hálózati és végpontvédelmi eszközöket. A tűzfalakat frissítsük a legújabb szoftververziókra, és érvényesítsük a Zero Trust elvet az ICS hálózati hozzáférések kezelésénél.

Maradjunk naprakészek.

A fenyegetések és sérülékenységek kutatásával foglalkozó szervezetek (CISA), valamint az érintett gyártók (Siemens) folyamatosan publikálják a Log4j sebezhetőségeivel kapcsolatos fejleményeket, frissítéseket és termékspecifikus kockázatcsökkentési javaslatokat. Legyen egy felelős személy, aki követi ezeket. Gondoljunk arra, hogy a Log4j első, Log4Shell-re keresztelt sérülékenységének felfedezése és kezdeti patch-ek megjelenése után még fény derült újabb biztonsági résekre és a kiadott frissítések hiányosságaira.

Végezetül…

A Log4Shell és „kistestvérei” természete és az általuk jelentett veszély felderítése még gyerekcipőben jár, de rendkívül fontos az időben elkezdett és a jelenleg ismert „best practice”-ek szerinti reagálás. Különösen gyártással foglalkozó cégek és létfontosságú rendszerelemek esetében fontos az óvatosság, mivel sajnos pont az ünnepek előtt érte az IT/ICS világot ennek a híre és félő, hogy támadói oldalon hamarosan megnövekedik az aktivitás, ugyanis ki ne próbálná meg melegében kihasználni a jelenlegi, kissé kapkodás jellemezte légkört.

 Jövőre folytatjuk!

Boldog karácsonyt és sikeres új évet kíván az EURO ONE InfoSec csapata!