В декабре 2021 года в одной из библиотек популярного языка программирования Java были обнаружены опасные уязвимости, получившие название Log4Shell. Эксперты по кибербезопасности охарактеризовали ее как самую крупную и опасную в истории по трем причинам:

1. Библиотека Apache Log4j используется миллионами корпоративных приложений и Java-серверами для регистрации сообщений об ошибках.
2. Для эксплуатации уязвимостей не требуются глубокие технические знания и навыки.
3. Найденная брешь позволяет злоумышленникам выполнять произвольный код на сервере или устройстве, что открывает перед ними огромные возможности – от похищения данных до внедрения в инфраструктуру программ-вымогателей и многого другого. Одна из уязвимостей в Apache Log4j (CVE-2021-44228) получила оценку опасности угрозы по CVSS в 10/10 баллов.

Даниил Чернов, директор Центра Solar appScreener компании «Ростелеком-Солар», рассказал, как защититься от подобных уязвимостей, почему выпущенные патчи безопасности не гарантия полной защиты и какую роль играет налаженный в компании процесс анализа кода программного обеспечения.

Что за уязвимость и в чем ее суть?

Уязвимости Log4Shell затрагивают библиотеку Apache Log4j, которая используется миллионами корпоративных приложений и Java-серверами для регистрации сообщений об ошибках. Параметры этой библиотеки позволяют путем несложных манипуляций заставить приложение выполнить произвольный код, который можно загрузить удаленно. Злоумышленники могут внедрить через эту брешь вредоносное программное обеспечение, в том числе шифровальщики, криптомайнеры и т. п.

Уязвимость затронула программное обеспечение множества компаний, в том числе таких гигантов, как Apple, Amazon, Google, Cisco и многих других. Под угрозой оказались не только те компании, которые разрабатывают собственное ПО с использованием Java, но и все, кто пользуется любым софтом, в котором есть уязвимые библиотеки.

Уже через несколько дней после появления информации об уязвимостях Log4j эксперты по кибербезопасности сообщили о массовом сканировании корпоративных сетей – злоумышленники искали подверженные угрозе приложения. Во всем мире, в том числе в России, было зафиксировано большое количество атак, которые эксплуатируют эту уязвимость.

Как устранить уязвимость?

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

Стоит отметить, что ситуация, когда уязвимость в ПО можно устранить собственными силами, скорее редкость. В случае с Log4Shell это связано с тем, что речь идет о языке Java и открытых библиотеках. При этом для внесения изменений не нужно привлекать квалифицированных разработчиков. Обычно корпоративным пользователям того или иного ПО приходится ждать, когда вендор выпустит обновления безопасности, которые закроют выявленную брешь.

Почему патчи справились лишь отчасти: зачем проверять код

Основная проблема в том, что даже в средней по размеру компании используется большое число приложений, которые могут работать с уязвимыми библиотеками. Таким образом, трудности возникают не с самим процессом обновления до безопасной версии или внесением изменений в параметры библиотеки. Сложность заключается именно в том, чтобы найти в корпоративной инфраструктуре все подобные библиотеки и понять, есть уязвимость в них или нет.

Спустя некоторое время после того, как o Log4Shell стало известно, в сети стали доступны бесплатные сканеры, призванные облегчить поиск уязвимых библиотек. По функционалу они существенно уступают полноценным статическим анализаторам кода (SAST). Простые скрипты для поиска уязвимых библиотек лишь анализируют названия файлов и их заголовки – они способны сказать о том, что есть такая-то библиотека определенной версии, но неизвестно, вносились ли в нее изменения и действительно ли в ней сейчас есть уязвимость. Учитывая, что во многих компаниях сразу после появления информации о Log4Shell ИТ-сотрудники правили файлы вручную, чтобы скорее закрыть дыру, результаты сканирования простыми скриптами могут привести к дополнительной неавтоматизированной проверке ликвидированных уязвимостей.

В отличие от простых скриптов статический анализатор кода проверяет приложения на уровне синтаксиса и семантики кода. Это значит, что он непредвзято смотрит не на версию той или иной библиотеки, а оценивает наличие ошибок и их потенциальную опасность с точки зрения кода. Для этого разработчики прописывают в анализаторе десятки правил, по которым определяются уязвимости в приложении. Чем более совершенные технологии и алгоритмы анализа кода используются, тем точнее результат. Важно не только поймать все серьезные уязвимости, но и свести к минимуму количество ложных срабатываний. Последние могут серьезно тормозить рабочие процессы в компании, в том числе разработку ПО. Таким образом, в случае с log4Shell, как и с другими уязвимостями, SAST достоверно покажет, устранена проблема или нет. В случае обнаружения угрозы анализатор даст конкретную инструкцию по устранению проблемы в коде.

Все обновили, все проверили. А что, если нас уже взломали?

Массовые атаки, эксплуатирующие log4Shell, начались спустя несколько минут после того, как о ней стало широко известно. А значит, даже если сейчас в компании установлены свежие версии библиотеки и анализатор кода подтверждает отсутствие угрозы, не факт, что в инфраструктуру никто не проник. Пока уязвимость еще не была устранена, злоумышленники могли взломать серверы компании, но не проявлять активных действий сразу, а распространяться по инфраструктуре, собирать информацию и получать доступы, чтобы позднее монетизировать взлом в максимальном объеме.

Низкоквалифицированные хакеры могут выдать себя, перекачивая большие объемы трафика, и тогда понять, что что-то не так, будет просто. Более профессиональные киберпреступники действуют менее заметно. Чтобы обнаружить их присутствие в ИТ-инфраструктуре и снизить ущерб, понадобится более кропотливая работа. Придется тщательно анализировать все сетевые аномалии. Если в компании нет полноценной системы защиты информации и налаженных ИБ-процессов, лучше обратиться за помощью к сервис-провайдерам, которые оказывают услуги по обследованию инфраструктуры, анализу трафика и т. п.

Как не пропустить новые уязвимости?

Безопасная разработка, подход к тестированию Shift Left, когда оно смещается на более ранние стадии разработки продукта, – все это сегодня не модное веяние, а скорее примета времени и рационального подхода к защите от киберугроз. Поэтому для компаний, которые постоянно разрабатывают свое ПО, крайне важно наладить процессы поиска уязвимостей. Здесь возможны варианты: тесная интеграция анализатора кода в среды разработки или регулярный ручной запуск сканирования с помощью SAST. Чем раньше будут выявлены уязвимости, тем легче их будет устранить. Кроме того, очень важно проверять код перед каждым релизом и при внесении любых изменений. И обязательно нужно регулярно обновлять анализатор, чтобы он своевременно пополнялся актуальными базами правил поиска уязвимостей. При добавлении новых угроз полезно устраивать дополнительные проверки кода.

Что касается компаний, которые не разрабатывают ПО, но при этом активно его используют, они точно так же могут сканировать свой софт с помощью анализаторов. Некоторые вендоры предлагают лицензии на свой продукт, стоимость которых рассчитывается по количеству проведенных проверок. Когда исходный код ПО недоступен, можно использовать SAST, который умеет проверять исполняемые файлы.

Напоследок стоит отметить, что анализаторы ведущих вендоров подсвечивали фрагмент кода в библиотеке log4j как потенциальную угрозу еще до того, как это стало мейнстримом. Угроза определялась как уязвимость вида «Подделка файла лога» (Log Forging). Таким образом, продвинутые алгоритмы анализа кода позволяют предупреждать компьютерные угрозы. А компании, которые реагируют только после того, когда уязвимость становится общеизвестной, рискуют быть атакованными, не успев ее устранить.