В мрежата се говори много за уязвимостта в Log4J, който позволява на нападателя да задейства дистанционно изпълнение на произволен код ако имате възможност да изпращате данни към приложение, което използва библиотеката log4j за регистриране на събитието.
Тази атака може да се направи без удостоверяванеНапример чрез използване на страница за удостоверяване, която регистрира грешки при удостоверяване.
Този недостатък накара компании, специализирани в киберсигурността, да работят върху събитието и показва, че броят на атаките, които се възползват от този недостатък, се увеличава.
Членовете на Apache Software Foundation разработи кръпка с цел коригиране на уязвимостта и това е версия 2.15.0, в допълнение към факта, че са известни и възможни решения за намаляване на рисковете.
Какво е Apache Log4j? Колко сериозна е грешката?
За тези, които все още не знаят колко сериозен е проблема, мога да ви кажа това На 9 декември е открита уязвимост в лза запис на библиотека log4j Apache.
Тази библиотека широко използвани в проекти за разработка на приложения Java / J2EE, както и базирани на Java / J2EE стандартни доставчици на софтуерни решения.
log4j включва механизъм за търсене, който може да се използва за запитване чрез специален синтаксис във форматен низ. Например, може да се използва за заявка на различни параметри като версията на средата на Java чрез $ {java: version} и т.н.
След това посочете ключа jndi в низа, механизма за търсене използвайте JNDI API. По подразбиране всички заявки се правят с префикса java: comp / env / *; авторите обаче внедриха опцията за използване на персонализиран префикс, използвайки двоеточие в ключа.
Ето къде се крие уязвимостта: sijndi: ldap: // се използва като ключ, заявката отива към посочения LDAP сървър. Могат да се използват и други комуникационни протоколи като LDAPS, DNS и RMI.
Следователно, отдалечен сървър, контролиран от нападател, може да върне обект на уязвим сървър, което може да доведе до изпълнение на произволен код в системата или изтичане на поверителни данни.
Всичко, което нападателят трябва да направи, е да изпрати специален низ Чрез механизма, който записва този низ в регистрационен файл и следователно се управлява от библиотеката Log4j.
Това може да се направи с прости HTTP заявки, например тези, изпратени чрез уеб формуляри, полета с данни и т.н., или с всякакъв друг тип взаимодействия, използвайки регистрация от страна на сървъра.
Tenable характеризира уязвимостта като „най-важната и критична уязвимост за последното десетилетие“.
Доказателството за концепцията вече е публикувано. Тази уязвимост сега се използва активно.
Тежестта на уязвимостта е Максимум 10 по скалата на CVSS.
Ето списъка на засегнатите системи:
- Apache Log4j версии от 2.0 до 2.14.1
- Apache Log4j версии 1.x (остарели версии) подлежат на специална конфигурация.
- Продукти, използващи уязвима версия на Apache Log4j - Европейските национални сертификати поддържат пълен списък с продукти и тяхното състояние на уязвимост
CERT-FR препоръчва извършването на задълбочен анализ на мрежовите регистрационни файлове. Следните причини могат да се използват за идентифициране на опит за използване на тази уязвимост, когато се използва в URL адреси или определени HTTP заглавки като потребителски агент
Накрая си струва да споменем това силно се препоръчва да използвате log2.15.0j версия 4 възможно най-скоро.
Въпреки това, в случай на трудности при мигрирането към тази версия, могат временно да се приложат следните решения:
За приложения, които използват версии 2.7.0 и по-нови на библиотеката log4j, е възможно да се защитят срещу всякакви атаки чрез промяна на формата на събитията, които ще бъдат регистрирани със синтаксис% m {nolookups} за данните, които потребителят ще предостави .
Тази модификация изисква промяна на конфигурационния файл log4j, за да се създаде нова версия на приложението. Следователно, това изисква повторно извършване на техническите и функционални стъпки за валидиране, преди да внедрите тази нова версия.
За приложения, използващи версии 2.10.0 и по-нови на библиотеката log4j, също е възможно да се защити срещу всяка атака чрез промяна на конфигурационния параметър log4j2.formatMsgNoLo