Log4j — бібліотека журналювання Java програм, частина загального проєкту «Apache Logging Project». Log4j спочатку розвивався в рамках «Apache Jakarta Project», відповідального за всі Java-проєкти Apache, але згодом виділився в окремий, дуже популярний проєкт журналювання.

Log4j
Тип Журналювання
Розробники Apache Software Foundation і Ceki Gülcüd
Платформа віртуальна машина Java
Операційна система кросплатформова програма
Мова програмування Java
Ліцензія Apache License, Version 2.0[d]
Репозиторій github.com/apache/logging-log4j2
Вебсайт logging.apache.org/log4j/2.x/

Log4Shell ред.

На початку грудня 2021 року низка сайтів, що пропонували різні послуги для гравців у гру Minecraft повідомили про уразливість в серверних системах, а також в Java-клієнті Minecraft[1].

Перші відомі спроби її реалізації датовані 1 або 2 грудня 2021 року, проте ознак масового використання для атак на той час зареєстровано не було[2], попри те, що вона існувала приблизно з 2013 року. А вже 14 грудня 2021 року було зареєстровано понад 840 тисяч спроб її реалізувати[3].

Дана уразливість отримала код CVE-2021-44228 та 10 балів з 10 за рівнем небезпеки[1][2].

Вона спричинена особливістю обробки фрагментів ${} в рядках для журналів функціями Log4j. При певній комбінації кодових слів існує можливість завантаження класів через JNDI (англ. Java Naming and Directory Interface) з LDAP-серверів та виконання їхнього коду[1].

Версії Java новіші за 6u211, 7u201, 8u191, та 11.0.1 начебто менш вразливі, оскільки вони за замовченням не дозволяють JNDI завантажувати код з серверів LDAP. Проте й новіші версії Java дають можливість виконувати код, який вже наявний в локальній системі[1].

14 грудня 2021 року була випущена версія 2.16.0, в якій обробка запитів JNDI взагалі вимкнена за замовченням. Аби її увімкнути, користувач має виконати відповідне налаштування. Дослідження оригінальної уразливості показали, що такий підхід — єдиний спосіб захисту, оскільки навіть новіші версії Java без змін в Log4j уразливі до неї[4].

Опис уразливості ред.

Уразливість з'явилась в коді Log4j завдяки латці LOG4J2-313[5] та вперше потрапила в реліз 2.0-beta9 (випущена у вересні 2013 року), а прибрати її вперше спробували у версії 2.14.1 (березень 2021 року)[6].

Новим функціоналом була додана можливість робити запит на віддалені ресурси із використанням спеціального синтаксису. При цьому, кодова комбінація може зустрічатись як в налаштуваннях бібліотеки, так і при додаванні нових записів в журнал[6].

Оскільки вебсервери часто зберігають інформацію передану користувачем, наприклад, заголовок User-Agent в запиті HTTP, або ж ім'я облікового запису під час автентифікації користувача, то зловмисник має широкі можливості для передачі потрібного йому рядка в уразливий код[6].

Крім того, уразливість може бути реалізована й проти програмних систем, які обробляють дані отримані не безпосередньо з інтернету, а від інших додатків, або ж при обробці QR-кодів тощо[6].

Спеціальний синтаксис складається з комбінації спеціальних символів та кодових слів: ${jndi:протокол://сервер}. При цьому спеціальні символи можуть визначати вкладені фрагменти рядка, наприклад, ${${lower:jn}${lower:di}} буде перетворене на ${jndi} й при цьому омине прості правила виявлення[6].

Коли бібліотека зустрічає вказану директиву, вона надсилає запит за вказаною адресою, і якщо атрибут ObjectClass завантаженого класу має значення javaNamingReference та має атрибути javaCodebase, javaFactory та javaClassName, то завантажувач об'єктів LDAP завантажить клас за URL вказаним в атрибуті javaCodebase та створить його екземпляр. При створенні екземпляра цього, завантаженого зі стороннього сервера, класу, буде виконаний його конструктор[6].

Таким чином, зловмисник отримує можливість віддаленого виконання коду в ураженій системі[6].

Навіть без віддаленого виконання коду (наприклад, якщо вказаний інший, не LDAP, протокол) зловмисники можуть додавати в адресу запиту значення змінних середовища, іншу конфіденційну інформацію з середини системи[6].

Захист ред.

Перша спроба позбутись уразливості призвела до релізу Log4j 2.15.0. Проте, виявилось, що вжитих заходів недостатньо — за певного збігу налаштувань зловмисники все одно мали можливість реалізувати атаку на відмову в обслуговуванні, відомої як CVE-2021-45046 або CVSS 3.7[7].

Також, подальший аналіз показав, що у версії 2.15.0 залишилась уразливість із витоком чутливих даних[8].

Ця уразливість з'являлась при використанні параметрів «контекстної перевірки» англ. Context Lookup, типу $${ctx:loginId}) або англ. Thread Context Map, типу %X, %mdc або %MDC в шаблонах журнальних записів[7].

Дана уразливість залишається і при встановленні системного прапорця log4j2.noFormatMsgLookup в значення true[7].

Тому було терміново випущено реліз 2.16.0, в якому обробка запитів через JNDI була повністю вимкнена за замовченням[7].

У випадку неможливості оновити версію бібліотеки можна видалити відповідний клас вручну[7]:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Примітки ред.

  1. а б в г Dan Goodin (10 грудня 2021). Zero-day in ubiquitous Log4j tool poses a grave threat to the Internet. Ars Technica.
  2. а б Dan Goodin (13 грудня 2021). The Log4Shell 0-day, four days on: What is it, and how bad is it really?. Ars Technica.
  3. Hannah Murphy (14 грудня 2021). Hackers launch over 840,000 attacks through Log4J flaw. Ars Technica.
  4. Dirk Knop (14 грудня 2021). Log4j 2.16.0 verbessert Schutz vor Log4Shell-Lücke. Heise security. Архів оригіналу за 14 грудня 2021. Процитовано 14 грудня 2021.
  5. Архівована копія. Архів оригіналу за 14 грудня 2021. Процитовано 15 грудня 2021.{{cite web}}: Обслуговування CS1: Сторінки з текстом «archived copy» як значення параметру title (посилання)
  6. а б в г д е ж и Martin Zugec (13 грудня 2021). Technical Advisory: Zero-day critical vulnerability in Log4j2 exploited in the wild. BitDefender. Архів оригіналу за 15 грудня 2021. Процитовано 15 грудня 2021.
  7. а б в г д Dirk Knop (15 грудня 2021). Neue Probleme - Log4j-Patch genügt nicht. Heise security. Архів оригіналу за 15 грудня 2021. Процитовано 15 грудня 2021.
  8. Dan Goodin (15 грудня 2021). Patch fixing critical Log4J 0-day has its own vulnerability that’s under exploit. Ars Technica.

Посилання ред.

Інформація про уразливості: