Pred niekoľkými týždňami správa o bezpečnostných problémoch Log4j obrátila mnohých používateľov siete hore nohami a je to jedna z chýb, ktorá bola najviac zneužívaná a ktorú mnohí odborníci označili za „najnebezpečnejšiu za dlhú dobu », Hovoríme o niektorých zraniteľnostiach, ktoré boli v sieti známe tu na blogu a tentokrát sme našli správu o ďalšej.
A to je pred pár dňami bola zverejnená správa, že v knižnici Log4j 2 bola identifikovaná ďalšia zraniteľnosť (ktorý je už uvedený pod CVE-2021-45105) a ktorý bol na rozdiel od predchádzajúcich dvoch problémov klasifikovaný ako nebezpečný, ale nie kritický.
Nový problém umožňuje odmietnutie služby a prejavuje sa vo forme slučiek a abnormálnych ukončení pri spracovaní určitých riadkov.
Zraniteľnosť ovplyvňuje systémy, ktoré používajú kontextové vyhľadávanie, ako napríklad $ {ctx: var}na určenie výstupného formátu protokolu.
L Log4j verzie 2.0-alpha1 až 2.16.0 postrádali ochranu proti nekontrolovanej rekurzii, čo umožnilo útočníkovi manipulovať s hodnotou použitou pri nahrádzaní spôsobiť nekonečnú slučku, ktorej by sa minulo miesto v zásobníku a proces by sa zablokoval. Problém nastal najmä pri dosadzovaní hodnôt, ako napríklad "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
Okrem toho, Je možné poznamenať, že výskumníci Blumira navrhli útok na zraniteľné Java aplikácie ktoré neprijímajú požiadavky z externých sietí, napríklad systémy vývojárov alebo používateľov Java aplikácií môžu byť napadnuté týmto spôsobom.
Podstatou metódy je, že ak existujú zraniteľné procesy Java v systéme používateľa, ktoré akceptujú sieťové pripojenia iba z lokálneho hostiteľa (localhost) alebo spracúvajú požiadavky RMI (Remote Method Invocation, port 1099), útok môže byť vykonaný vykonaným kódom JavaScript keď používateľ otvorí v prehliadači škodlivú stránku. Na nadviazanie spojenia so sieťovým portom Java aplikácie pri takomto útoku sa používa WebSocket API, na ktoré sa na rozdiel od HTTP požiadaviek nevzťahujú žiadne obmedzenia rovnakého pôvodu (WebSocket je možné použiť aj na skenovanie sieťových portov na lokálnom hostiteľa na určenie dostupných sieťových ovládačov).
Zaujímavé sú aj výsledky hodnotenia zraniteľnosti knižníc spojených so závislosťami s Log4j, ktoré zverejnil Google. Podľa Google sa problém týka 8 % všetkých balíkov v úložisku Maven Central.
Najmä 35863 4 balíkov Java súvisiacich s Log4j s priamymi a nepriamymi závislosťami bolo vystavených zraniteľnostiam. Log17j sa zasa používa ako priama závislosť prvej úrovne iba v 83 % prípadov a v 4 % balíkov pokrytých zraniteľnosťou sa väzba vykonáva prostredníctvom prechodných balíkov, ktoré závisia od Log21j, teda povedzme. závislosti druhej a najvyššej úrovne (12 % - druhá úroveň, 14 % - tretia, 26 % - štvrtá, 6 % - piata, XNUMX % - šiesta).
Miera opráv zraniteľnosti je stále veľmi nedostačujúca, týždeň po identifikácii zraniteľnosti bol z 35863 4620 identifikovaných balíkov problém zatiaľ odstránený iba v 13 XNUMX, teda na XNUMX %.
Zmeny v balíkoch sú potrebné na aktualizáciu požiadaviek na závislosti a nahradenie starých väzieb verzií pevnými verziami Log4j 2 (balíky Java praktizujú viazanie na špecifickú verziu a nie na otvorený rozsah, ktorý umožňuje inštaláciu najnovšej verzie).
Odstránenie zraniteľnosti v aplikáciách Java je sťažené skutočnosťou, že programy často obsahujú kópiu knižníc v dodávke a nestačí aktualizovať verziu Log4j 2 v systémových balíkoch.
Agentúra USA pre ochranu infraštruktúry a kybernetickú bezpečnosť medzitým vydala núdzovú smernicu, ktorá vyžaduje, aby federálne agentúry identifikovali informačné systémy ovplyvnené zraniteľnosťou Log4j a nainštalovali aktualizácie, ktoré problém blokujú.
Na druhej strane do 28. decembra bolo dané usmernenie, v ktorom mali organizácie povinnosť podávať správy o vykonaných prácach. Pre zjednodušenie identifikácie problémových systémov je vypracovaný zoznam produktov, u ktorých sa potvrdil prejav zraniteľnosti (v zozname je viac ako 23 tisíc aplikácií).
konečne, Za zmienku stojí, že chyba bola opravená v Log4j 2.17, ktorý bol zverejnený pred niekoľkými dňami a používateľom, ktorí majú aktualizácie zakázané, sa odporúča vykonať príslušnú aktualizáciu, okrem toho, že nebezpečenstvo zraniteľnosti je zmiernené tým, že problém sa prejavuje iba na systémoch s Java 8.
Fuente: https://logging.apache.org/