Ошибка в вездесущей библиотеке Log4j может позволить злоумышленнику выполнить произвольный код на любой системе, которая использует Log4j для записи логов.
Apache Foundation выпустила экстренное обновление для устранения критической уязвимости нулевого дня в Log4j, вездесущем инструменте протоколирования, включенном почти в каждое Java-приложение. Проблема была названа Log4Shell и получила идентификатор CVE-2021-44228.
Проблема связана с ошибкой в библиотеке Log4j, которая может позволить злоумышленнику выполнить произвольный код на системе, использующей Log4j для записи сообщений журнала. Эта уязвимость безопасности имеет широкое влияние и является тем, на что следует немедленно обратить внимание всем, чьи приложения содержат Log4j.
Почему решение проблемы Log4Shell является важной задачей?
Log4j — это библиотека, которая используется во многих Java-приложениях. Это одна из самых распространенных библиотек Java на сегодняшний день. Большинство Java-приложений записывают логи в журнал, и нет ничего, что делает это проще, чем Log4j.
Проблема заключается в том, чтобы найти Log4j из-за особенностей упаковки Java. Вполне возможно, что Log4j прячется где-то в вашем приложении и вы даже не подозреваете об этом.
В экосистеме Java зависимости распространяются в виде архивных файлов Java (JAR), которые представляют собой пакеты, которые можно использовать в качестве библиотеки Java. Широко используемые инструменты, такие как Maven и Gradle, могут автоматически добавлять JAR-файлы по мере сборки Java-приложения. Кроме того, JAR может содержать другой JAR для удовлетворения зависимости, что означает, что уязвимость может быть скрыта на несколько уровней ниже в вашем приложении. В некоторых ситуациях одна зависимость влечет за собой сотни других зависимостей, что еще больше затрудняет поиск.
По сути, в мире Java вы можете иметь JAR, вложенный в JAR, вложенный в JAR. Это создает множество слоев, которые необходимо исследовать. Простого просмотра JAR-файлов, которые ваш проект получает напрямую, может быть недостаточно, поскольку Log4j может скрываться в другом JAR-файле!
Поиск Log4j с помощью инструментов с открытым исходным кодом
Существует два инструмента с открытым исходным кодом под руководством Anchore, которые способны сканировать большое количество упакованных форматов зависимостей, определять их существование и сообщать, содержат ли они уязвимости. В данном случае возможность сканирования JAR-файлов, особенно вложенных слоев JAR-файлов, — это то, что нам нужно. Syft генерирует спецификацию материалов программного обеспечения (SBOM), а Grype является сканером уязвимостей. Оба этих инструмента способны проверять несколько вложенных слоев JAR-архивов, чтобы обнаружить и идентифицировать версии Log4j.
Syft также способен определить, какую версию Log4j содержит Java-приложение. Log4j JAR может быть непосредственно включен в наш проект, или он может быть скрыт в одной из зависимостей, которые мы включаем. Например, использование Syft для сканирования этого примера Java-проекта показывает, что он включает Log4j версии 2.14.1, которая уязвима для Log4Shell.
Независимо от того, какая версия Log4j используется, есть смысл в создании и хранении SBOM, чтобы вести учет всего, что включено в любой программный компонент или приложение, которое вы поставляете. Когда обнаруживается новая уязвимость, например, Log4Shell, гораздо быстрее провести поиск в хранилище SBOM, чем искать и сканировать все Java-приложения.
Grype — это сканер, который способен сообщить нам, какие конкретные уязвимости содержит наше программное обеспечение. Когда вы включаете зависимость в свое приложение, вы также можете определить уязвимости, которые содержит зависимость, и так далее через несколько уровней вложенности. Grype может сканировать программное обеспечение напрямую или сканировать SBOM, созданный Syft. Это позволяет вам повторно сканировать SBOM на наличие новых уязвимостей даже после того, как программное обеспечение было развернуто или поставлено клиентам.
Сканирование того же образца Java-проекта с помощью Grype обнаруживает уязвимость Log4j и идентифицирует ее как критическую.
Syft и Grype имеют возможность сканировать ваши приложения независимо от того, где они находятся. Вы можете сканировать каталог на диске, сканировать образ контейнера локально или даже сканировать контейнер в удаленном реестре. Вы можете сканировать исходный код до сборки или конечное приложение после сборки. Важно сканировать приложения на всех этапах разработки, ведь если исходный код чист, это еще не значит, что чиста будет и конечная сборка. Даже сканирование после развертывания — хорошая идея. Возможно, на прошлой неделе вы не обнаружили критическую уязвимость Log4j, но на этой неделе вы можете это сделать!
Держите Syft и Grype вчегда под рукой
Каждый раз, когда обнаруживается новая уязвимость нулевого дня, пострадавшим организациям бывает трудно и проблематично быстро устранить проблему. Первый и самый важный шаг — понять, затрагивает ли конкретная уязвимость вообще вас, а в случае с JAR-файлами понять это без инструментария может быть непросто. Инструменты Grype и Syft от Anchore с открытым исходным кодом докапываются до самого низа дерева зависимостей, чтобы определить, не прячется ли где-нибудь копия Log4j.
Как отрасль, то, как мы реагируем и поддерживаем друг друга во время появления уязвимостей нулевого дня, имеет решающее значение. Сейчас самое время поделиться решениями и информацией, чтобы помочь предотвратить подобные нарушения в ближайшие годы.
— Джош Брессерс — вице-президент по безопасности в компании Anchore.
