Преди няколко седмици новината за проблемите със сигурността на Log4j обърна много потребители в мрежата с главата надолу и това е един от недостатъците, който е използван най-много и който много експерти определиха като "най-опасният от дълго време", От уязвимостите, които станаха известни в мрежата, говорим за някои от тях тук в блога и този път открихме новината за друг.
И това е преди няколко дни беше пусната новината, че е идентифицирана друга уязвимост в библиотеката Log4j 2 (който вече е посочен под CVE-2021-45105) и който, за разлика от предишните два въпроса, беше класифициран като опасен, но не и критичен.
Новият проблем позволява отказ от услуга и се проявява под формата на цикли и необичайни завършвания при обработка на определени линии.
Уязвимост засяга системи, които използват контекстно търсене, като $ {ctx: var}, за да определите изходния формат на журнала.
на Log4j версии 2.0-alpha1 до 2.16.0 нямаха защита срещу неконтролирана рекурсия, Какво позволява на нападателя да манипулира стойността, използвана при заместване да предизвика безкраен цикъл, който ще свърши без място в стека и ще доведе до спиране на процеса. По-специално, проблемът възникна при заместване на стойности като "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
Освен това, Може да се отбележи, че изследователите на Blumira са предложили атака срещу уязвими Java приложения които не приемат заявки от външни мрежи, например системи на разработчици или потребители на Java приложения могат да бъдат атакувани по този начин.
Същността на метода е, че ако има уязвими Java процеси в системата на потребителя, които приемат мрежови връзки само от локалния хост (localhost) или обработват RMI-заявки (извикване на отдалечен метод, порт 1099), атаката може да се извърши чрез изпълнен JavaScript код когато потребителят отвори злонамерена страница в браузъра. За установяване на връзка с мрежовия порт на Java приложение при такава атака се използва WebSocket API, към който, за разлика от HTTP заявките, не се прилагат ограничения за същия произход (WebSocket може да се използва и за сканиране на мрежови портове на локалната хост, за да определи наличните мрежови драйвери).
Интерес представляват и резултатите от оценката на уязвимостта на библиотеките, свързани със зависимости с Log4j, публикувани от Google. Според Google проблемът засяга 8% от всички пакети в хранилището на Maven Central.
По-специално, 35863 4 Java пакета, свързани с Log4j с преки и непреки зависимости, бяха изложени на уязвимости. От своя страна Log17j се използва като директна зависимост на първо ниво само в 83% от случаите, а в 4% от пакетите, обхванати от уязвимостта, обвързването става чрез междинни пакети, които зависят от Log21j, т.е. зависимости от второ и най-високо ниво (12% - второ ниво, 14% - трето, 26% - четвърто, 6% - пето, XNUMX% - шесто).
Скоростта на поправяне на уязвимостта все още оставя много да се желае, седмица след идентифицирането на уязвимостта от 35863 4620 идентифицирани пакета проблемът е отстранен досега само в 13, тоест до XNUMX%.
Промените в пакета са необходими, за да се актуализират изискванията за зависимости и да се заменят обвързванията на старата версия с фиксирани версии на Log4j 2 (Пакетите на Java практикуват обвързване към конкретна версия, а не към отворен диапазон, който позволява инсталиране на най-новата версия).
Премахването на уязвимостта в Java приложенията е затруднено от факта, че програмите често включват копие на библиотеките в доставката и не е достатъчно да се актуализира версията Log4j 2 в системните пакети.
Междувременно американската агенция за защита на инфраструктурата и киберсигурност издаде директива за спешни случаи, изискваща от федералните агенции да идентифицират информационните системи, засегнати от уязвимостта Log4j, и да инсталират актуализации, които блокират проблема преди 23 декември.
От друга страна беше дадена насока до 28 декември, в която организациите имаха задължението да докладват за извършената работа. За да се опрости идентифицирането на проблемни системи, е изготвен списък с продукти, в които е потвърдена проява на уязвимост (в списъка има повече от 23 хиляди приложения).
И накрая, Струва си да се спомене, че уязвимостта беше коригирана в Log4j 2.17, която беше публикувана преди няколко дни и на потребителите, които имат деактивирани актуализации, се препоръчва да извършат съответната актуализация, в допълнение към факта, че опасността от уязвимостта е смекчена от факта, че проблемът се проявява само в системи с Java 8.
Fuente: https://logging.apache.org/