Комментарии 10
Ну-у-у. Я когда прочитал описание, тоже так думал… Однако же, был кто-то, кто вообще придумал парсить сообщения на предмет наличия в них шаблонов, и выполнять по факту произвольный код, который приходит извне. Ну вот постфактум вы бы что сказали про этого человека, не дурак ли он? А он однако же коммитил в код log4j.
Редко кто пользовательский ввод в логи кладет, там могут быть персданные, такие логи потом тяжело у поддержки получать.
Ну вот теперь, наконец-то, понятно, откуда вообще такие уязвимости берутся. Пользовательские данные — это ж только паспортные данные и фото!
А все остальные данные (ну, к примеру, URL запроса или там User-Agent со всякими Content-Encoding) пользователь, паинька из паинек, подменять не будет.
Он же такой лапочка!
Даже если злоумышленник.
P.S. Для тех, кто в танке: под user data тут понимаются любые данные, которые вы получаете от пользователя. Даже если вы их сами формируете, ему отдаёте и обратно получаете. Всякие куки, сессионные ключи и прочая лабуда. И огромный процент разработчиков не аномизирует их прямо в вызове функции логирования, а делает это уже потом, когда они в базе. А для того, чтобы Log4Shell сработал попадания в базу не нужно.
Редко кто пользовательский ввод в логи кладет
tasklist /NH /FO CSV ^| findstr /I java
А приложения, которые не запускаются через java.exe?
Ещё один момент который многие игнорируют акцентируя внимание на веб-приложениях: уязвимости могут быть подвержены любые приложения, которые при логгировании используют внешние данные.
Например, какая-нибудь аггрегация логов, ваш dwh, streaming pipeline, batch processing, etl-системы, fraud detection и т.д. и т.п.
Строчка с нужными паттерном из условного user-agent попала в текстовый лог nginx, уехала в какой-нибудь clickhouse, а через сутки сработала в какой-нибудь считалке статистики браузеров, которая в лог выводила браузеры на которых наблюдается больше всего ошибок. И ура, rce сработало сильно далеко и совсем не в веб-приложении.
Строчка с нужными паттерном из условного user-agent попала в текстовый лог nginx, уехала в какой-нибудь clickhouse
именно такой кейс мне вчера продемонстрировали, только вместо кликхауса был эластик
url из акеслога nginx улетел в эластик и эластик начал майнить, забавно.
Это почти прямой вариант и про него большинство у кого есть Elastic/Apache Solr были уже в курсе. И патчить параметры запуска могли начать исходя из того они предоставляют web-интерфейс и очевидно что плохим запросом можно дотянуться (если, конечно, query logging включен). А просачивание через non-java системы куда-нибудь в более-менее закрытый контур (но без серьёзной фильтрации исходящих соединений) куда менее ожидаемо.
Log4Shell — это критическая уязвимость в библиотеке логирования Log4j, которую используют многие веб-приложения на Java.
сначала показалось, что многие веб-приложения используют уязвимость, а не библиотеку)
Помощь в борьбе с Log4Shell: сделали сканер для Log4j