Před několika týdny zpráva o bezpečnostních problémech Log4j obrátila mnoho uživatelů v síti vzhůru nohama a je to jedna z chyb, která byla nejvíce zneužívána a kterou mnozí odborníci označili za „nejnebezpečnější v dlouho », O zranitelnostech, které byly v síti oznámeny, hovoříme o některých z nich zde na blogu a tentokrát jsme našli zprávu o dalším.
A to je před pár dny byla zveřejněna zpráva, že v knihovně Log4j 2 byla identifikována další chyba zabezpečení (který je již uveden pod CVE-2021-45105) a který byl na rozdíl od předchozích dvou problémů klasifikován jako nebezpečný, ale ne kritický.
Nový problém umožňuje odmítnutí služby a projevuje se ve formě smyček a abnormálních ukončení při zpracování určitých řádků.
Zranitelnost ovlivňuje systémy, které používají kontextové vyhledávání, jako je $ {ctx: var}, k určení výstupního formátu protokolu.
the Log4j verze 2.0-alpha1 až 2.16.0 postrádaly ochranu proti nekontrolované rekurzi, co dovolil útočníkovi manipulovat s hodnotou použitou při substituci způsobit nekonečnou smyčku, která by došla místo na zásobníku a způsobovala by zablokování procesu. Problém nastal zejména při dosazování hodnot jako "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
Navíc, Lze poznamenat, že výzkumníci Blumira navrhli útok na zranitelné Java aplikace které nepřijímají požadavky z externích sítí, například systémy vývojářů nebo uživatelů Java aplikací mohou být napadeny tímto způsobem.
Podstatou metody je, že pokud existují zranitelné procesy Java v systému uživatele, které přijímají síťová připojení pouze od místního hostitele (localhost) nebo zpracovávají požadavky RMI (Remote Method Invocation, port 1099), útok lze provést pomocí spuštěného kódu JavaScript když uživatel otevře v prohlížeči škodlivou stránku. Pro navázání spojení se síťovým portem Java aplikace při takovém útoku se používá WebSocket API, na které se na rozdíl od HTTP požadavků nevztahují žádná omezení stejného původu (WebSocket lze použít i ke skenování síťových portů na lokálním hostitele k určení dostupných síťových ovladačů).
Zajímavé jsou také výsledky hodnocení zranitelnosti knihoven souvisejících se závislostmi s Log4j publikované společností Google. Podle Googlu se problém týká 8 % všech balíčků v úložišti Maven Central.
Zejména 35863 4 balíčků Java souvisejících s Log4j s přímou a nepřímou závislostí bylo vystaveno zranitelnostem. Log17j se zase používá jako přímá závislost první úrovně pouze v 83 % případů a v 4 % balíčků pokrytých zranitelností se vazba provádí prostřednictvím mezilehlých balíčků, které jsou závislé na Log21j, tedy tell. závislosti druhé a nejvyšší úrovně (12 % - druhá úroveň, 14 % - třetí, 26 % - čtvrtá, 6 % - pátá, XNUMX % - šestá).
Tempo oprav zranitelnosti stále zůstává nedostačující, týden poté, co byla zranitelnost identifikována, byl z 35863 4620 identifikovaných balíčků problém zatím vyřešen pouze u 13 XNUMX, tedy na XNUMX %.
Změny balíčků jsou nezbytné k aktualizaci požadavků na závislosti a nahrazení starých vazeb verzí pevnými verzemi Log4j 2 (balíčky Java praktikují vazbu na konkrétní verzi, nikoli na otevřený rozsah, který umožňuje instalaci nejnovější verze).
Odstranění zranitelnosti v aplikacích Java je ztíženo tím, že programy často obsahují kopii knihoven v dodávce a nestačí aktualizovat verzi Log4j 2 v systémových balíčcích.
Mezitím americká Agentura pro ochranu infrastruktury a kybernetickou bezpečnost vydala nouzovou směrnici, která vyžaduje, aby federální úřady identifikovaly informační systémy postižené zranitelností Log4j a nainstalovaly aktualizace, které problém blokují, do 23. prosince.
Naproti tomu do 28. prosince byla dána směrnice, ve které měly organizace povinnost podávat zprávy o provedených pracích. Pro zjednodušení identifikace problémových systémů je zpracován seznam produktů, u kterých byl potvrzen projev zranitelnosti (v seznamu je více než 23 tisíc aplikací).
Konečně, Za zmínku stojí, že zranitelnost byla opravena v Log4j 2.17, který byl publikován před několika dny a uživatelům, kteří mají aktualizace deaktivované, se doporučuje provést odpovídající aktualizaci, kromě toho, že nebezpečí zranitelnosti je zmírněno tím, že se problém projevuje pouze na systémech s Java 8.
zdroj: https://logging.apache.org/