Tanos Áron, a KPMG kiberbiztonsági laborjának vezetője

Fejlesztői műhelytitok, hogy a szoftverfejlesztők az általánosnak mondható feladatokat nem programozzák le újra és újra, hanem végrehajtásukra kész programcsomagokat húznak be egy alapkészletből. Most ennek az alapcsomagnak az egyik darabjáról derült ki, hogy hibás. A Google becslése alapján több mint 35 ezher olyan Java-csomag van, ami használja az Apache Log4j könyvtárat. A Log4j használata általános, cégek, kormányzatok és magánszemélyek életében egyaránt jelen van.

Kis túlzással a helyzet olyan, mintha bejelentenék, hogy holnap minden széteshet, amiben laposfejű csavar van, ezért mindet ki kell cserélni. Ez akkor is meglehetősen nagy kapkodást váltana ki, ha egyúttal azt is közölnék, hogy mind a 35 ezer csavartípusnak megvan a megfelelő cseréje. Ez most messze nem lenne igaz, de ha az lenne, akkor sincs gőzünk se, hogy a szobában körülnézve mi mindenben van laposfejű csavar, és milyen van a mosogatógépben, a porszívóban, vagy a laptopban.

Adná magát a lehetőség, hogy hívjuk a gyártót, vagy megnézzük az oldalán, hogy mit javasol, de most ez sem segít. Ugyanis 10-15 évre visszamenőleg a gyártók sem tudják, mit mivel "szereltek", ráadásul a termék egyes részeit ők is vették, és csak beépítették a saját termékükbe. Emiatt a Log4j-t most nemcsak a hackerek keresik nagy erőkkel mindenféle szoftverben, de a "jó oldalon" is mindenki, aki az elmúlt 20 évben szoftvert fejlesztett, vagy adott el. Detektálóprogramok már vannak, de nem hiba nélküliek.

Az új csavar a 2.16.0 Java 8 és a 2.12.2 Java 7 lenne. Ezek jól semlegesítik a Log4Shell hibából eredő problémát, és csökkentik az okozott kárt. Csakhogy az egyszeri felhasználó nem tudja a tévében, a mosogatógépben, vagy egy laptopban kicserélni az összes csavart. A csere a gyártó felelőssége lenne, de mint mondtuk, gyakran ő sem tudja, hogy annak idején a beszállítói milyen csavart adtak a konyhapulthoz, ami még fából és nem pozdorjából készült, sőt az sem kizárt, hogy a beszállító már nem is létezik.

Tovább nehezíti a helyzetet, hogy a Log4j-ben nem is egy, hanem mindjárt két hiba van. Az egyik maga a Log4Shell (két CVE-t is találtak CVE -2021-44228, CVE-2021-45046), másik a CVE-2021-45105, amit ugyancsak szoktak az ismertté vált néven illetni, de nem ugyanaz (mi most Log4Shell/2 néven fogjuk illetni). Maga a Log4Shell távoli kódfuttatást tesz lehetővé, vagyis a támadók a sérülékenység kihasználásával saját céljaikat szolgáló parancsokat adhatnak az alkalmazásnak, amire normális használat közben nem lenne lehetőségük. A Log4Shell/2 ezzel szemben azt teszi lehetővé, hogy a támadók a távolból túlterheléssel ellehetetlenítsék a szoftverek működését.

Előfordulhat, hogy a csavarok cseréjéhez le kellene állítani az eszközt, ám ez lehetetlen, mert mondjuk egy lélegeztetőgépben van, és éppen életben tart valakit, vagy olyan részegységekben találhatók, amiket nem lehet károsodás nélkül felnyitni. A szoftveriparban az ilyen kis egységeket konténereknek nevezzük. Ezekben az alkalmazás és az azokhoz szükséges perifériák egybe vannak építve, vagyis itt nem elég a csavar cseréje, az egész konténert kell kiváltani egy másikkal.

Amiről eddig azt mondtuk, hogy a semlegesíti a problémát, vagy enyhíti a kárt, azt szakmai nyelven gyűjtőnéven mitigációnak nevezzük. A mitigáció nemcsak javítást jelent, hanem valami olyasmit is, hogy elérjük, hogy a káros esemény többet ne forduljon elő, de addig is teszünk róla, hogy a lehető legkisebb kárt okozza. Ad abszurdum az is része lehet a mitigációnak, ha lemondunk az adott eszköz, szolgáltatás vagy szoftver használatáról, és kihúzzuk a falból. Ez persze drasztikus megoldás, aminek mérlegeléséhez tudnunk kell, hogy milyen kárt okozunk vele.

Nem mindegy ugyanis, hogy átmenetileg megszakadnak az ügyfélkapcsolataink, vagy ennél súlyosabbak a várható következmények. Klasszikus mitigáció a Die Hard nagyjelenete, amikor Bruce Willis egy egész repülőgépet robbant fel, hogy a kiömlő égő kerozin nyomán a többi gép leszállhasson. Lett fény a leszálláshoz? Lett.

A mitigáció tehát rendkívül tág fogalom, ezért a legtöbb sebezhetőség esetében léteznek drasztikus és kevésbé drasztikus alternatív megoldások. Többféle módon lehet helyesen és sajnos helytelenül is semlegesíteni a sérülékenységet, de fontos megérteni ezek korlátait. Az égő kerozin egyáltalán nem jó megoldás a kifutópályák kivilágítására. Alkalmasint beválhat, de hamis illúzióba ringatja magát, aki azt hiszi, hogy hősünk ezzel hosszú távon is megoldotta a problémát.

A Log4Shell kapcsán máris látszanak ilyen alkalmi megoldások, sőt olyanok is, amikről máris kiderült, hogy több kárt okoznak, mint hasznot. Érdekes – és létező – elgondolás például, hogy a sebezhetőséget magát kihasználva jussunk be a rendszerekbe, és helyezzünk el ott olyan programcsomagokat, amelyek útját állják egy második behatolónak. Ez saját rendszereinken is csak átmeneti megoldást hozhat, másokén végrehajtani pedig bűncselekmény, akkor is, ha az ember közben Bruce Willisnek érzi magát. Ilyen körülmények között már az is komoly tudás, ha tudjuk, hogy mit ne tegyünk.

A Log4Shell hibával sokáig együtt élünk még. Jelenlététől egy darabig még hangos lesz a sajtó, aztán már csak a nyomait érzékeljük majd. Gyakoribb váratlan rendszerleállások, előre bejelentett „adásszünetek” kísérik az útját, így utólag elemezhető módon erőteljes nyomot hagy, a kiberbiztonságról szóló statisztikákban. Csak remélni lehet, hogy a kilengés átmenetinek bizonyul, és az adatok később belesimulnak az egyébként is dinamikus emelkedést mutató trendvonalba. Addig is magánemberként rendszeresen frissítsük az internetet használó eszközeinket, és ahol lehet, váltsunk át a többlépcsős azonosításra.

Tanos Áron, a KPMG kiberbiztonsági laborjának vezetője