Уязвимость Log4j продолжает представлять серьезную угрозу для корпоративных организаций спустя год после того, как Apache Software Foundation раскрыла ее в ноябре прошлого года. - даже несмотря на то, что количество публично раскрытых атак, нацеленных на саму уязвимость, было меньше, чем многие могли первоначально ожидать.

Специалисты по безопасности говорят, что высокий процент систем по-прежнему не исправлен, и организации сталкиваются с трудностями при поиске и устранении проблемы, а затем предотвращении повторного появления уязвимости в среде.

«Тот факт, что Log4j используется в [почти] 64% приложений Java, и только 50% из них обновлены до полностью исправленной версии, означает, что злоумышленники будут продолжать нацеливаться на него», — говорит Дэвид Линднер, директор по информационным технологиям Contrast Security. «По крайней мере, на данный момент злоумышленники продолжают активно искать пути для использования Log4j».

Несколько атак, но меньше, чем ожидалось

Недостаток Log4j (CVE-2021-44228), обычно называемый Log4Shell, существует в функции Log4j Java Naming and Directory Interface (JNDI) для хранения и поиска данных. Это дает удаленным злоумышленникам тривиально простой способ получить контроль над уязвимыми системами — проблема, учитывая, что Log4J используется практически во всех средах приложений Java. Исследователи безопасности считают его одной из самых значительных уязвимостей за последние годы из-за его распространенности и относительной легкости, с которой злоумышленники могут его использовать.

За последний год появилось множество сообщений о том, что злоумышленники используют уязвимость как способ получить первоначальный доступ к целевой сети. Во многих из этих атак участвовали поддерживаемые государством группы продвинутых постоянных угроз (APT) из Китая, Северной Кореи, Ирана и других стран. Например, в ноябре Агентство США по кибербезопасности и безопасности инфраструктуры (CISA) предупредило о поддерживаемой правительством Ирана группе APT, которая использует уязвимость Log4j на неисправленном сервере VMware Horizon, чтобы развертывание программного обеспечения для криптомайнинга и сборщиков учетных данных в федеральной сети.

Предупреждение было похоже на предупреждение от Fortinet в марте о китайском злоумышленнике Deep Panda, использующем идентичный вектор для развертывания бэкдора на целевых системах и еще одного от Ahn Labs о северокорейской Lazarus Group распространение собственного бэкдора так же. Другие, такие как Microsoft, также сообщали о том, что наблюдают за государственными деятелями, такими как иранская группа Phosphorous и китайская организация по угрозе Hafnium, использующих Log4 для сбрасывать обратные оболочки на зараженные системы.

Несмотря на такие сообщения — и несколько других о финансово мотивированных группах киберпреступников, нацеленных на Log4j — фактическое количество публично заявленных компрометаций с использованием Log4 остается сравнительно низким, особенно по сравнению с инцидентами, связанными с уязвимостями Exchange Server, такими как ПроксиЛогон и ПроксиШелл. Боб Хубер, директор по безопасности в Tenable, говорит, что масштабы и охват зарегистрированных атак оказались на удивление ниже, чем ожидалось, учитывая простоту уязвимости и пути атаки. «Только недавно мы увидели некоторые существенные доказательства таргетинга, о чем свидетельствуют недавние действия национального государства от CISA», — говорит Хубер.

Неуменьшаемая угроза

Однако это не означает, что угроза со стороны Log4j за последний год уменьшилась, отмечают исследователи безопасности.

Во-первых, большой процент организаций остается столь же уязвимым перед угрозой, как и год назад. Анализ телеметрии, связанной с ошибкой, которую недавно провел Tenable, показал 72% организаций были уязвимы в Log4j по состоянию на 1 октября. Компания Tenable обнаружила, что 28% организаций по всему миру полностью устранили эту ошибку. Но компания Tenable обнаружила, что организации, исправившие свои системы, часто снова и снова сталкиваются с Log4j, добавляя новые активы в свои среды.

Во многих случаях — фактически 29% — серверы, веб-приложения, контейнеры и другие активы стали уязвимы для Log4j вскоре после первоначального исправления.

«Если предположить, что организации встраивают исправление в левую часть уравнения — во время конвейера сборки программного обеспечения — количество повторных внедрений должно уменьшиться», — говорит Хубер. «Скорость повторного внедрения и изменений во многом зависит от цикла выпуска программного обеспечения в организации».

Кроме того, несмотря на почти повсеместное осознание уязвимости в сообществе кибербезопасности, уязвимые версии Log4j по-прежнему трудно найти во многих организациях из-за того, как приложения используют его. Некоторые приложения могут использовать компонент ведения журнала с открытым исходным кодом в качестве прямой зависимости в своих приложениях, а в других случаях приложение может использовать Log4j в качестве транзитивной зависимости или зависимости от другой зависимости, говорит Брайан Фокс, технический директор Sonatype.

«Поскольку транзитивные зависимости вводятся из вашего выбора прямой зависимости, они не всегда могут быть известны или непосредственно видны вашим разработчикам», — говорит Фокс.

По словам Фокса, во многих случаях, когда Apache Foundation впервые раскрыла Log4Shell, компаниям приходилось рассылать тысячи внутренних электронных писем, собирать результаты в электронные таблицы и рекурсивно сканировать файловые системы. «Это стоило компаниям драгоценного времени и ресурсов на исправление компонента и увеличивало масштаб вредоносного воздействия уязвимости», — говорит он.

Данные из репозитория Maven Central Java, поддерживаемого Sonatype, показывают, что 35% загрузок Log4 В настоящее время продолжают оставаться уязвимые версии программного обеспечения. «Многие компании все еще пытаются создать инвентарь своего программного обеспечения, прежде чем они смогут даже начать реагировать, и не знают о последствиях транзитивных зависимостей», — говорит Фокс.

Из-за всех проблем наблюдательный совет Министерства внутренней безопасности США ранее в этом году пришел к выводу, что Log4 является эндемический риск безопасности с которыми организациям придется бороться годами. По оценке членов правления, уязвимые экземпляры Log4j останутся в системах на долгие годы и в обозримом будущем будут подвергать организации риску атак.

Единственный положительный результат

Исследователи безопасности, отслеживающие ошибку, говорят, что положительным результатом Log4j является повышенное внимание, которое она привлекла к таким методам, как анализ состава программного обеспечения и ведомость материалов (SBOM). Проблемы, с которыми организации столкнулись, просто определив, являются ли они уязвимыми или где уязвимость может существовать в их среде, способствовали лучшему пониманию необходимости прозрачности всех компонентов в их кодовой базе, особенно из открытых исходных кодов и сторонних источников.

«Расследование проблемы с Log4J подтвердило необходимость улучшения аттестации цепочки поставок программного обеспечения в дополнение к SBOM, которые не отстают от скорости DevOps, — говорит Мэтью Роуз, директор по информационной безопасности в ReversingLabs. «Команды по безопасности и архитектуре приложений поняли, что недостаточно просто искать риски в таких частях приложения, как исходный код, API или пакеты с открытым исходным кодом. Теперь они понимают, что полное понимание архитектуры приложения так же важно, как поиск ошибок SQLI или межсайтового скриптинга (XSS)», — говорит он.

• Коинсмарт. Лучшая в Европе биржа биткойнов и криптовалют.Кликните сюда
• Платоблокчейн. Интеллект метавселенной Web3. Расширение знаний. Доступ здесь.
• Источник: https://www.darkreading.com/application-security/one-year-later-log4shell-exposed-attack