Log4Shell: как одна уязвимость поставила под угрозу весь интернет

Log4Shell: как одна уязвимость поставила под угрозу весь интернет

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

Как и эпидемия шифровальщика Wannacry, это стало ещё одним уроком по оперативной реакции на критическую киберугрозу. В этой статье вспомним, что такое Log4Shell, почему её эксплуатация оказалась такой опасной и какие выводы сделали специалисты по информационной безопасности.

Содержание:

  1. Как работает уязвимость Log4Shell
  2. Масштаб угрозы
  3. Защита в кризисных условиях
  4. Уроки катастрофы

Как работает уязвимость Log4Shell

Итак, Log4Shell — это ошибка в библиотеке Log4j, популярном компоненте, который используется для логирования в миллионах приложений на Java. Log4j используется почти повсеместно: от веб-приложений и корпоративных сервисов до облачных платформ.

Именно распространённость уязвимости сыграла ключевую роль в эпидемии. Log4Shell затронула десятки миллионов серверов и приложений, а её простота эксплуатации сделала её идеальной целью для киберпреступников.

Иван Костыря

Старший аналитик SOC UserGate

Apache Log4j — это часть проекта Apache Logging Project, библиотека, которая служит для ведения логов. По большому счету, ее применение является одним из самых простых способов ведения журнала ошибок, поэтому большинство Java-разработчиках применяют именно ее. В ходе атаки злоумышленник отправляет на уязвимый сервер запрос, который записываются в журнал посредством уязвимого компонента Log4j. Это может быть HTTP-запрос, заполнение какой-либо веб-формы или поля для ввода данных на сайте, отправка сообщения в чат приложения и другое. Самое главное – чтобы эти данные записались в журнал атакуемого приложения.

Простейший пример атаки — отправка специально подготовленной строки в форму обратной связи на сайте. Если сервер использовал уязвимую версию Log4j, он выполнял команду злоумышленника, открывая полный доступ к системе.

Log4Shell была обнаружена в конце ноября 2021 года исследователем Чейтом Уоллсом из компании Alibaba. Он заметил необычное поведение серверов при обработке логов и понял, что через Log4j можно выполнять удалённый код. Через несколько дней уязвимость получила идентификатор CVE-2021-44228 с максимальной оценкой угрозы и мгновенно привлекла внимание ИБ-сообщества.

Александр Ястремской (B0rn2beR00T)

Специалист по тестированию на проникновение Compliance Control

Когда мир узнал о CVE-2021-44228, многие восприняли это как очередную критическую уязвимость. Однако очень скоро стало ясно, что это не просто баг и даже не фича, а системный сбой всей парадигмы современной разработки.

Максим Каширин

Руководитель отдела анализа защищенности Angara Security

Под угрозой оказались не только веб-приложения небольших компаний и частных разработчиков, для которых процессы обеспечения безопасности часто банально недоступны. Уязвимость всплывала везде - от корпоративных сервисов до облачных приложений, которыми пользуются миллионы. Например, всем известные продукты компании Atlassian - Jira и Confluence.

Дмитрий Калинин

Руководитель департамента по работе с уязвимостями и инцидентами ИБ Бастион

Важную роль сыграли косвенные зависимости компонентов друг от друга, так называемые transitive dependencies. Многие разработчики даже не знали, что их приложение использует Log4j, поскольку она присутствовала в проекте в качестве косвенной зависимости.

Разработчики Apache Log4j выпустили первый патч уже в первые дни после публикации, но масштабы использования библиотеки сделали быстрое исправление проблематичным. Миллионы приложений и серверов по всему миру содержали уязвимые версии, а злоумышленники начали создавать эксплойты почти сразу после обнародования.

Масштаб угрозы

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

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

Иван Костыря

Старший аналитик SOC UserGate

Уязвимая библиотека используется в разработках многих крупнейших производителей ПО, в том числе Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla и Twitter. Многие IT-продукты, как опенсорс, так и коммерческие решения использовали и используют компонент Apache Log4j как простой, доступный, производительный инструмент логирования событий.

Александр Ястремской (B0rn2beR00T)

Специалист по тестированию на проникновение Compliance Control

Разработчик 10 лет назад мог использовать фреймворк, который сам зависел от уязвимой версии Log4j. По итогу, банк потратит миллионы на firewall и шифрование, но его безопасность будет определяться решением junior-разработчика в стартапе десять лет назад, который выбрал «удобную библиотеку для логирования».

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

Ярослав Яцкевич

Аналитик ИБ SkyDNS

SOC-команды буквально “утопали” в алертах о попытках внедрения строк с “jndi:ldap” и последующей эксплуатацией, а пентестеры активно проверяли возможности выполнения кода в стороннем программном обеспечении.

Были зафиксированы и попытки внедрения шифровальщиков. Особенно уязвимы оказались крупные облачные платформы и сервисы с тысячами зависимостей от библиотек на Java.

Павел Захаров

Ведущий аналитик угроз компании WMX

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

Не обошлось и без использования уязвимости для скрытого сбора данных. Некоторые атаки были направлены на кражу учетных записей и конфиденциальной информации компаний, а также на создание бэкдоров для дальнейшего проникновения в инфраструктуру. Даже игровые серверы и популярные веб-приложения не остались в стороне: они становились частью ботнетов или площадкой для DDoS-атак.

Защита в кризисных условиях

Реакция на Log4Shell была молниеносной: производители и ИБ-сообщество начали срочно выпускать патчи и рекомендации по защите. Основной метод — обновление библиотеки Log4j до последних версий. Для компаний это означало массовую проверку зависимостей и срочную замену компонентов во всех приложениях.

Сергей Лунегов

Директор по продуктам Axiom JDK

Фикс был готов в течение пары часов после опубликования эксплойта. При этом он даже не требовал остановки или перезагрузки сервиса, его можно было применить к работающей JVM-машине. Сложность заключалась в том, что [в любой компании] любое применение изменения в рабочей среде должно пройти множество согласований. Внутренняя безопасность, юридический отдел, внедрение, тестирование и т.д. Суммарно это дает очень большой лаг по времени.

Павел Захаров

Ведущий аналитик угроз компании WMX

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

Антон Прокофьев

Руководитель отдела операционной поддержки Solar appScreener ГК «Солар»

Требуется хорошая координация между разными командами (ИТ, безопасность, разработка) для оперативного реагирования. Необходимо эффективно коммуницировать с поставщиками, партнерами и клиентами, чтобы оценить масштаб проблемы.

Промежуточной мерой стала фильтрация и блокировка подозрительных строк в логах. Многие организации настроили веб-фильтры и firewall-правила, чтобы блокировать  попытки удалённого выполнения кода. Также активно использовались средства мониторинга и системы обнаружения аномалий, которые отслеживали необычные обращения к серверу и потенциальные эксплойты.

Дмитрий Калинин

Руководитель департамента по работе с уязвимостями и инцидентами ИБ Бастион

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

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

Уроки катастрофы

Каждая масштабная эпидемия показывает, как быстро небольшая уязвимость может превратиться в глобальную угрозу. Защититься от очередного 0-day помогает только налаженное управление уязвимостями. Автоматическая инвентаризация компонентов, приоритизация патчей и оперативный деплой сокращают окно риска и дают шанс закрыть дыру до того, как начнутся массовые атаки.

Ярослав Яцкевич

Аналитик ИБ SkyDNS

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

Павел Захаров

Ведущий аналитик угроз компании WMX

Даже спустя столько лет с момента обнаружения уязвимости, заметить данную атаку среди вредоносных запросов – вполне обычная ситуация. Например, с попытками эксплуатации Log4Shell связано 60% веб-атак, которые с начала этого года отразил наш межсетевой экран уровня веб-приложений ПроWAF.

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

Сергей Лунегов

Директор по продуктам Axiom JDK

Подобные ситуации – повод пересмотреть подходы к использованию Open Source в сложных комплексных системах и критических информационных инфраструктурах. Ситуация с Log4J беспрецедентна и осложняется тем, что даже если в коде, написанном в организации ее нет, библиотека может наследоваться. Внедрение цикла безопасной разработки (РБПО) в совокупности с технической поддержкой от вендоров, разрабатывающих OpenSource, как раз являются требованиями ФСТЭК к подобным решениям.

Антон Прокофьев

Руководитель отдела операционной поддержки Solar appScreener ГК «Солар»

Со своей стороны рекомендуем постоянное применение модуля SCA в жизненном цикле разработки ПО , который позволяет анализировать используемые Open Source-библиотеки и зависимости на наличие уязвимостей и снижать риск использования уязвимых компонентов в коде приложения.

Наконец, обмен информацией с сообществом — это возможность узнать о новой угрозе ещё до того, как она попадёт в новости. Использование threat intelligence позволяет быстрее реагировать на новые атаки, а автоматические обновления и правильный мониторинг дополняют систему защиты.

похожие материалы

Стрелочка
Стрелочка
Переход на аутсорсинг информационной безопасности: топ-5 типовых проблем и практические советы по их решению
Переход на аутсорсинг информационной безопасности: топ-5 типовых проблем и практические советы по их решению

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

Как бизнесу защищать персональные данные в эпоху автоматизации
Как бизнесу защищать персональные данные в эпоху автоматизации

С ростом автоматизации бизнес-процессов появляются все новые типы рисков: компрометация API-интеграций, ошибки в конфигурации облачных сервисов, несанкционированные обращения к базам данных и утечки через внешние модули — считает директор по разработке компании Neuro.