Log4Shell — это критическая уязвимость в библиотеке логирования Log4j, которую используют многие веб-приложения на Java.
Чтобы защититься от атак с использованием Log4Shell, надо знать, какие приложения уязвимы — а это трудно выяснить. Мы упростили задачу: разработали и выложили на GitHub специальный сканер.
Log4Shell — это критическая уязвимость в библиотеке логирования Log4j, которую используют многие веб-приложения на Java. Эксплуатация уязвимости приводит к удаленному выполнению кода (RCE), эксплоит уже опубликован, и ему подвержены все версии библиотеки до 2.15.0.
Проблема. По описанию уязвимости понятно: ситуация серьезная, нужно срочно защищаться от атак с ее использованием. Однако не существует быстрого способа выяснить, каким именно приложениям нужны меры защиты.
- В интернете можно найти списки затронутого ПО. Но что делать, если в вашей организации есть собственные сервисы, которые могут использовать Log4j?
- Сканирование внешних адресов ваших сервисов даст только приблизительное понимание. Дело в том, что уязвимость Log4Shell может проявляться при логировании чего угодно — от заголовка User-Agent до значения, который пользователь вводит в форму в любой момент после аутентификации. Не факт, что сканер доберется до уязвимости. А вот злоумышленники вполне могут на нее наткнуться.
Решение команды BI.ZONE. Мы разработали и выложили на GitHub собственный сканер на основе YARA-правила. Он сканирует память процессов Java на наличие сигнатур библиотеки Log4j. При этом сканирование идет не снаружи, а изнутри — то есть не из сети, а прямо на хосте.
На выходе вы получите перечень хостов, на которых есть приложения с Log4j, и сможете проверить версию библиотеки.
А если версия окажется уязвимой, защититься от внешних атак с использованием Log4j поможет облачный сервис BI.ZONE WAF. Он не освободит от необходимости установить патчи, но снизит риск успешной эксплуатации Log4Shell.
Комментарии (10)
drdead
14.12.2021 21:40tasklist /NH /FO CSV ^| findstr /I java
А приложения, которые не запускаются через java.exe?
grossws
14.12.2021 23:31+1Ещё один момент который многие игнорируют акцентируя внимание на веб-приложениях: уязвимости могут быть подвержены любые приложения, которые при логгировании используют внешние данные.
Например, какая-нибудь аггрегация логов, ваш dwh, streaming pipeline, batch processing, etl-системы, fraud detection и т.д. и т.п.
Строчка с нужными паттерном из условного user-agent попала в текстовый лог nginx, уехала в какой-нибудь clickhouse, а через сутки сработала в какой-нибудь считалке статистики браузеров, которая в лог выводила браузеры на которых наблюдается больше всего ошибок. И ура, rce сработало сильно далеко и совсем не в веб-приложении.
13werwolf13
15.12.2021 06:30+1Строчка с нужными паттерном из условного user-agent попала в текстовый лог nginx, уехала в какой-нибудь clickhouse
именно такой кейс мне вчера продемонстрировали, только вместо кликхауса был эластик
url из акеслога nginx улетел в эластик и эластик начал майнить, забавно.
grossws
15.12.2021 10:05+1Это почти прямой вариант и про него большинство у кого есть Elastic/Apache Solr были уже в курсе. И патчить параметры запуска могли начать исходя из того они предоставляют web-интерфейс и очевидно что плохим запросом можно дотянуться (если, конечно, query logging включен). А просачивание через non-java системы куда-нибудь в более-менее закрытый контур (но без серьёзной фильтрации исходящих соединений) куда менее ожидаемо.
kira-dev
15.12.2021 12:56+3Log4Shell — это критическая уязвимость в библиотеке логирования Log4j, которую используют многие веб-приложения на Java.
сначала показалось, что многие веб-приложения используют уязвимость, а не библиотеку)
ProstakovAlexey
Вроде не все так жутко. В описание уязвимости написано, что уязвимы: Only applications using log4j-core and including user input in log messages are vulnerable. Редко кто пользовательский ввод в логи кладет, там могут быть персданные, такие логи потом тяжело у поддержки получать. Если приложения с мавен, то можно проверить:
mvn dependency:list | grep log4j
[INFO] org.apache.logging.log4j:log4j-to-slf4j:jar:2.15.0:compile -- module org.apache.logging.slf4j [auto] [INFO] org.apache.logging.log4j:log4j-api:jar:2.15.0:compile -- module org.apache.logging.log4j [INFO] log4j:log4j:jar:1.2.17:compile -- module log4j (auto)
к тому же вот тут https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot указано что можно запустить приложение с особыми параметрами, чтобы избежать проблем (если быстро зафиксить нельзя). Тоже выход не плохой.
sshikov
>Редко кто пользовательский ввод в логи кладет, там могут быть персданные,
Ну-у-у. Я когда прочитал описание, тоже так думал… Однако же, был кто-то, кто вообще придумал парсить сообщения на предмет наличия в них шаблонов, и выполнять по факту произвольный код, который приходит извне. Ну вот постфактум вы бы что сказали про этого человека, не дурак ли он? А он однако же коммитил в код log4j.
khim
Ну вот теперь, наконец-то, понятно, откуда вообще такие уязвимости берутся. Пользовательские данные — это ж только паспортные данные и фото!
А все остальные данные (ну, к примеру, URL запроса или там User-Agent со всякими Content-Encoding) пользователь, паинька из паинек, подменять не будет.
Он же такой лапочка!
Даже если злоумышленник.
P.S. Для тех, кто в танке: под user data тут понимаются любые данные, которые вы получаете от пользователя. Даже если вы их сами формируете, ему отдаёте и обратно получаете. Всякие куки, сессионные ключи и прочая лабуда. И огромный процент разработчиков не аномизирует их прямо в вызове функции логирования, а делает это уже потом, когда они в базе. А для того, чтобы Log4Shell сработал попадания в базу не нужно.
dartraiden
Dzzzen
Так можно и по 274.1 залететь, все банки сейчас - субъекты КИИ