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 ezer 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 lapos fejű csavar van, ezért mindet ki kell cserélni” – magyarázza a probléma jelentőségét Tanos Áron, a KPMG kibervédelmi laborjának vezetője. 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 csavar tí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 lapos fejű 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. 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 hekkerek keresik nagy erőkkel mindenféle szoftverben, de a jó oldalon is mindenki, aki az elmúlt húsz évben szoftvert fejlesztett, vagy adott el. Detektáló programok már vannak, de nem hiba nélküliek.
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, ami 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ó nem csak 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 ” – mondja a KPMG szakértője. 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, hogy átmenetileg megszakadnak az ügyfélkapcsolatink, vagy ennél súlyosabbak a várható következmények. Klasszikus mitigáció a Die Hard című film nagyjelenete, amikor Bruce Willis egy egész repülőgépet robbant fel, hogy egyrészt elpusztítsa a rosszfiúkat, másrészt pedig, 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, ami ú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 a Die Hard-os John McClane-nek (alias Bruce Willis) é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.