Log4j — бібліотека журналювання Java програм, частина загального проєкту «Apache Logging Project». Log4j спочатку розвивався в рамках «Apache Jakarta Project», відповідального за всі Java-проєкти Apache, але згодом виділився в окремий, дуже популярний проєкт журналювання.
Log4Shell
На початку грудня 2021 року низка сайтів, що пропонували різні послуги для гравців у гру Minecraft повідомили про уразливість в серверних системах, а також в Java-клієнті Minecraft.
Перші відомі спроби її реалізації датовані 1 або 2 грудня 2021 року, проте ознак масового використання для атак на той час зареєстровано не було, попри те, що вона існувала приблизно з 2013 року. А вже 14 грудня 2021 року було зареєстровано понад 840 тисяч спроб її реалізувати.
Дана уразливість отримала код CVE-2021-44228 та 10 балів з 10 за рівнем небезпеки.
Вона спричинена особливістю обробки фрагментів ${} в рядках для журналів функціями Log4j. При певній комбінації кодових слів існує можливість завантаження класів через JNDI () з LDAP-серверів та виконання їхнього коду.
Версії Java новіші за 6u211, 7u201, 8u191, та 11.0.1 начебто менш вразливі, оскільки вони за замовченням не дозволяють JNDI завантажувати код з серверів LDAP. Проте й новіші версії Java дають можливість виконувати код, який вже наявний в локальній системі.
14 грудня 2021 року була випущена версія 2.16.0, в якій обробка запитів JNDI взагалі вимкнена за замовченням. Аби її увімкнути, користувач має виконати відповідне налаштування. Дослідження оригінальної уразливості показали, що такий підхід — єдиний спосіб захисту, оскільки навіть новіші версії Java без змін в Log4j уразливі до неї.
Опис уразливості
Уразливість з'явилась в коді Log4j завдяки латці LOG4J2-313 та вперше потрапила в реліз 2.0-beta9 (випущена у вересні 2013 року), а прибрати її вперше спробували у версії 2.14.1 (березень 2021 року).
Новим функціоналом була додана можливість робити запит на віддалені ресурси із використанням спеціального синтаксису. При цьому, кодова комбінація може зустрічатись як в налаштуваннях бібліотеки, так і при додаванні нових записів в журнал.
Оскільки вебсервери часто зберігають інформацію передану користувачем, наприклад, заголовок User-Agent в запиті HTTP, або ж ім'я облікового запису під час автентифікації користувача, то зловмисник має широкі можливості для передачі потрібного йому рядка в уразливий код.
Крім того, уразливість може бути реалізована й проти програмних систем, які обробляють дані отримані не безпосередньо з інтернету, а від інших додатків, або ж при обробці QR-кодів тощо.
Спеціальний синтаксис складається з комбінації спеціальних символів та кодових слів: ${jndi:протокол://сервер}. При цьому спеціальні символи можуть визначати вкладені фрагменти рядка, наприклад, ${${lower:jn}${lower:di}} буде перетворене на ${jndi} й при цьому омине прості правила виявлення.
Коли бібліотека зустрічає вказану директиву, вона надсилає запит за вказаною адресою, і якщо атрибут ObjectClass завантаженого класу має значення javaNamingReference та має атрибути javaCodebase, javaFactory та javaClassName, то завантажувач об'єктів LDAP завантажить клас за URL вказаним в атрибуті javaCodebase та створить його екземпляр. При створенні екземпляра цього, завантаженого зі стороннього сервера, класу, буде виконаний його конструктор.
Таким чином, зловмисник отримує можливість віддаленого виконання коду в ураженій системі.
Навіть без віддаленого виконання коду (наприклад, якщо вказаний інший, не LDAP, протокол) зловмисники можуть додавати в адресу запиту значення змінних середовища, іншу конфіденційну інформацію з середини системи.
Захист
Перша спроба позбутись уразливості призвела до релізу Log4j 2.15.0. Проте, виявилось, що вжитих заходів недостатньо — за певного збігу налаштувань зловмисники все одно мали можливість реалізувати атаку на відмову в обслуговуванні, відомої як CVE-2021-45046 або CVSS 3.7.
Також, подальший аналіз показав, що у версії 2.15.0 залишилась уразливість із витоком чутливих даних.
Ця уразливість з'являлась при використанні параметрів «контекстної перевірки» , типу $${ctx:loginId}) або , типу %X, %mdc або %MDC в шаблонах журнальних записів.
Дана уразливість залишається і при встановленні системного прапорця log4j2.noFormatMsgLookup в значення true.
Тому було терміново випущено реліз 2.16.0, в якому обробка запитів через JNDI була повністю вимкнена за замовченням.
У випадку неможливості оновити версію бібліотеки можна видалити відповідний клас вручну: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Примітки
Посилання Головний сайт проєкту
Інформація про уразливості: CVE-2021-44228 CVE-2021-45046