facebook LinkedIN LinkedIN - follow
Exkluzivní partner sekce
Tematické sekce
 
Branžové sekce
Přihlášení SystemNEWSPřehledy
 
Tematické seriály

Jak uřídit IT projekt a nezbláznit se

Užitečné tipy a nástroje pro řešení problémů řízení inovací a vývoje produktů...

články >>

 

Industry 4.0

Průmysl 4.0

Jaký vliv bude mít čtvrtá průmyslová revoluce na výrobu a výrobní firmy?

články >>

 
Nové!

RPA - automatizace procesů

Softwaroví roboti automatizují obchodní procesy.

články >>

 
Nové!

IoT – internet věcí

Internet věcí a jeho uplatnění napříč obory.

články >>

 
Nové!

VR – virtuální realita

Praktické využití virtuální reality ve službách i podnikových aplikacích.

články >>

 
Nové!

Bankovní identita (BankID)

K službám eGovernmentu přímo z internetového bankovnictví.

články >>

 

Příručka úspěšného IT manažera

Dnes je řada IT manažerů opomíjena. Úspěšní bývají brouci Pytlíci a Ferdové...

články >>

 
 
Partneři webu
IT security , IT Security

Zranitelnost Log4j

V čem je jiná a co to znamená pro podnikovou IT bezpečnost

Michal Hebeda


Log4jV dnešní době ani neuplyne týden, abychom se nedozvěděli o nějaké nové zranitelnosti. Avšak zranitelnost objevená 8. prosince loňského roku se tak trochu vymyká – nejde o zranitelnost v konkrétní aplikaci nebo operačním systému, ale postiženou je knihovna Log4j z dílny nadace Apache. Tato knihovna, založená na programovacím jazyce Java, byla a je velmi často používána vývojáři různých aplikací a zařízení. Pomáhá jim řešit problematiku logování událostí a vyhledávání v nich, což je potřeba takřka v každé aplikaci, zejména v těch serverových.


Kdo všechno může být postižen a jaké mohou být následky? Na první část otázky není jednoduché odpovědět, neboť na rozdíl od klasické zranitelné aplikace nemusí mít administrátor povědomí o tom, že v některém z používaných software byla tato knihovna použita, případně v jaké verzi. To jej staví do značně nevýhodné role, protože musí spolu s dodavateli prověřit všechny používané aplikace a spoléhat na to, že výrobci rychle zareagují a doporučí buď nějakou rychlou opravu, nebo urychleně dodají opravný patch pro svou aplikaci či zařízení. Čistě technicky vzato mohou být postiženy opravdu různorodé aplikace ať již od těch nejmenších vývojářů nebo až po velké světové výrobce. A nemusí se jednat pouze o softwarové aplikace, ale též o hardwarová zařízení, jako jsou například síťová úložiště a další.

Téměř milion útoků za tři dny

Autor zmiňované knihovny nadace Apache uvedl, že postiženy jsou všechny verze od 2.0 až po 2.14.1. Útočníkovi zranitelnost umožňuje vhodně zaslaným dotazem vyvolat chybu a následné stažení a spuštění vlastního kódu, což může vést k získání kontroly nad daným počítačem, zcizení dat nebo přihlašovacích údajů. Jak je vidět, následky mohou být nedozírné a škody opravdu velké. S vydáváním záplat to také nebylo jednoduché, neboť díky zaměření útočníků na tuto knihovnu ji ihned podrobili zkoumání a našli nové jiné zranitelnosti. Již ne tak významné, ale i tak nebezpečné. Podařilo se až napotřetí a za bezpečnou je považována verze 2.17.

Útočníci na sebe nenechali dlouho čekat a začali masivně útočit již od prvních hodin od objevení zranitelnosti. Zprvu se jednalo o méně sofistikované útoky, například cryptomining – těžba kryptoměn. Což pro oběť paradoxně mohlo být štěstí v neštěstí – zjistili, že jsou napadeni a nepřišli o žádná data. Sofistikovanější a složitější útoky následovaly vzápětí, značná část z nich spočívala v přípravě prostředí pro budoucí útoky. Společnost Checkpoint uvádí, že 72 hodin po zveřejnění zranitelnosti bylo zaznamenáno přes 800 tisíc různých útoků, zneužívajících zranitelnosti Log4j.

Number of attack attempts exploiting the Log4j  vulnerability in the  hours after its discovery on 10 December, 2021

Proč je zranitelnost Log4j jiná?

Nyní se dostáváme k tomu, proč je tato zranitelnost tak jiná než předešlé a proč klade na správce systémů zvýšené nároky. U kla­sic­kých zranitelností například v aplikacích postačí správci systému ověřit, zda používaná verze aplikace patří mezi zranitelné a pokud ano, tak zajistit upgrade na verzi bezpečnou (za předpokladu, že ji výrobce již vydal), případně izolování takové aplikace od vnějšího či vnitřního prostředí. V našem případě se ale nejedná přímo o aplikaci, ale knihovnu, kterou vývojář mohl či nemusel použít. Obvykle není veřejně dostupná informace o verzích použitých knihoven.

Před správci systémů tak leží daleko obtížnější úkol – musí kontaktovat všechny dodavatele aplikací a zařízení a zjišťovat, zda daná knihovna v nich byla či nebyla použita. V kladném případě vyžadovat příslušnou opravu nebo doporučení, jak systémy zabezpečit, aby zranitelnost nemohla být zneužita. Na místě je také kontrola, zda již k útoku v dané síti nedošlo (lze využít například vyhledávání řetezců `${jndi:ldap://`, `${jndi:rmi://`, `${jndi:ldaps://` v lozích serveru).

Nutno také podotknout, že Národní úřad pro kybernetickou bezpečnost (NÚKIB) vydal reaktivní opatření, které správcům kritické infrastruktury nařizuje a ostatním doporučuje provést patřičné kroky. Je vidět, že jde opravdu o závažné ohrožení bezpečnosti a není dobré jej brát na lehkou váhu.

V takovéto situaci jistě každý správce IT systému ocení, pokud jeho dodavatel reaguje pružně a rychle. Proto společnost GFI Software velmi rychle vydala doporučení, jak přenastavit a tím zabezpečit poštovní server Kerio Control a ještě před Vánoci byl vydán opravný patch. Současně s tím byl upraven produkt GFI LanGuard tak, aby detekoval zranitelnou verzi knihovny Log4j v nainstalovaných aplikacích.

Michal Hebeda Michal Hebeda
Autor je Sales Engineer ve společnosti ZEBRA SYSTEMS, distributora GFI Software.
Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.