Почему разработчики должны заботиться о Log4j



9 декабря 2021 г. была обнаружена уязвимость в популярной библиотеке протоколирования Java Log4j. Уязвимость быстро окрестили Log4Shell. Короче говоря, злоумышленник может использовать компонент для введения определенной строки, что позволяет ему удаленно и произвольно выполнять код в целевом приложении. Довольно дикая штука, правда?

Практически невозможно представить, как такая атака не повлияет на пользовательский опыт и такие показатели, как среднее время подтверждения (MTTA) и среднее время разрешения (MTTR). Когда эти метрики начинают затягиваться, разработчикам приходится отвлекать значительные ресурсы на обеспечение наблюдаемости, поиск возможных эксплойтов и устранение уязвимостей. Если несколько лет назад кибербезопасность не была первостепенной задачей при разработке программного обеспечения, то ситуация очень быстро меняется, поскольку пользователи взаимодействуют непосредственно с этими приложениями, чтобы добиться своей цели.

Как Log4j влияет на разработчиков
Уязвимость Log4j относится к типу уязвимостей, которые при использовании в первую очередь затрагивают разработчиков, поскольку целью является их код. Организации могут даже не знать, что они подвергаются кибератаке, пока это не повлияет на работу пользователей, а ответственность за мониторинг работы пользователей обычно ложится на разработчиков, инженеров по надежности сайта и команды DevOps.

Эта уязвимость вызывает особую озабоченность из-за массового использования разработчиками библиотек Log4j, включая некоторые из самых популярных программных приложений, поставляемых такими компаниями, как Apple и Microsoft. Распределенный характер программного обеспечения означает, что приложения могут быть затронуты, даже если они не используют Log4j напрямую, поскольку они могут иметь другие зависимости, зависящие от затронутой библиотеки. Атака может проникнуть глубоко в архитектуру программного обеспечения.

Поскольку команды разработчиков программного обеспечения часто первыми сталкиваются с последствиями вторжения, с команд DevOps и разработчиков, скорее всего, будет взиматься плата за подготовку и смягчение последствий кибератак. Однако даже до того, как этот день наступит — а он наступит, — это окажет непосредственное влияние на ключевые показатели эффективности (KPI), которые измеряют продуктивность и успех команд разработки программного обеспечения.

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

Вы можете проверить свой стек: версии Log4j с 2.0-beta9 по 2.14.1 (включительно) уязвимы. Использование определенных версий JDK (6u211+, 7u201+, 8u191+ и 11.0.1+) усложняет эксплуатацию, но они по-прежнему уязвимы.

Однако, как я уже упоминал, из-за распределенного характера облачных вычислений найти Log4Shell немного сложнее. Так что вы должны спросить себя: если уязвимость существует в дикой природе, но я не могу ее найти, действительно ли она существует где-то в моем стеке? Ответ: Вероятно.

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

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

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

Конечно, решения для наблюдения технически не являются решениями для кибербезопасности. Им не поручено находить поверхности кибератак и предупреждать вас о них. Но они могут выступать в качестве первой линии защиты, поскольку они могут обеспечить первое предупреждение о простоях или ухудшении взаимодействия с пользователем, которые могут быть вызваны кибератакой, такой как распределенная атака типа «отказ в обслуживании».

https://cyberxhack.org/