Log4j
Log4j — бібліотека журналювання Java програм, частина загального проєкту «Apache Logging Project». Log4j спочатку розвивався в рамках «Apache Jakarta Project», відповідального за всі Java-проєкти Apache, але згодом виділився в окремий, дуже популярний проєкт журналювання.
На початку грудня 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
- ↑ а б в г Dan Goodin (10 грудня 2021). Zero-day in ubiquitous Log4j tool poses a grave threat to the Internet. Ars Technica.
- ↑ а б Dan Goodin (13 грудня 2021). The Log4Shell 0-day, four days on: What is it, and how bad is it really?. Ars Technica.
- ↑ Hannah Murphy (14 грудня 2021). Hackers launch over 840,000 attacks through Log4J flaw. Ars Technica.
- ↑ Dirk Knop (14 грудня 2021). Log4j 2.16.0 verbessert Schutz vor Log4Shell-Lücke. Heise security. Архів оригіналу за 14 грудня 2021. Процитовано 14 грудня 2021.
- ↑ Архівована копія. Архів оригіналу за 14 грудня 2021. Процитовано 15 грудня 2021.
{{cite web}}: Обслуговування CS1: Сторінки з текстом «archived copy» як значення параметру title (посилання) - ↑ а б в г д е ж и Martin Zugec (13 грудня 2021). Technical Advisory: Zero-day critical vulnerability in Log4j2 exploited in the wild. BitDefender. Архів оригіналу за 15 грудня 2021. Процитовано 15 грудня 2021.
- ↑ а б в г д Dirk Knop (15 грудня 2021). Neue Probleme - Log4j-Patch genügt nicht. Heise security. Архів оригіналу за 15 грудня 2021. Процитовано 15 грудня 2021.
- ↑ Dan Goodin (15 грудня 2021). Patch fixing critical Log4J 0-day has its own vulnerability that’s under exploit. Ars Technica.
- Головний сайт проєкту [Архівовано 14 грудня 2021 у Wayback Machine.]
Інформація про уразливості:
- CVE-2021-44228 [Архівовано 14 грудня 2021 у Wayback Machine.]
- CVE-2021-45046 [Архівовано 16 грудня 2021 у Wayback Machine.]