Спустя два года Log4Shell все еще остается проблемой, поскольку многие проекты все еще уязвимы.

log4j

Log4Shell — один из тех, кто появится в утечках данных в следующем десятилетии

Последний месяц 2023 года ознаменовался вторая годовщина обнаружения уязвимости Log4j/Log4Shell, Это уязвимость, которая сегодня продолжает влиять на многие проекты и представляет угрозу безопасности.

Согласно ежегодному отчету Cloudflare «Обзор года», а также результатам исследования значимости критических уязвимостей в Java-библиотеке Log4j, опубликованному исследователями безопасности Veracode, Log4j продолжает оставаться основной мишенью для кибератак.

Исследователи Veracode отмечают, что после изучения 38.278 XNUMX приложений используется 3.866 организациями, они обнаружили, что два из пяти приложений по-прежнему используют уязвимые версии библиотеки Apache Log4j, через два года после того, как была обнародована критическая уязвимость.

В отчете подчеркивается, что около трети приложений используют Log4j2 1.2.x. (срок службы которого истек в августе 2015 года и больше не получает обновлений), что составляет 38%. Основная причина продолжения использования устаревшего кода — интеграция старых библиотек в проекты или трудоемкость перехода от неподдерживаемых веток к новым, обратно совместимым. Кроме того, 2.8% приложений по-прежнему используют версии, уязвимые к известной уязвимости Log4Shell.

В дополнение к этому, Отмечается, что существует три основные категории. приложений, все еще использующих уязвимые версии Log4j, согласно отчету Veracode:

  1. Уязвимость Log4Shell (CVE-2021-44228):
    2.8% приложений продолжают использовать версии Log4j от 2.0-beta9 до 2.15.0, содержащие известную уязвимость.
  2. Уязвимость удаленного выполнения кода (RCE) (CVE-2021-44832):
    3.8% приложений используют версию Log4j2 2.17.0, которая устраняет уязвимость Log4Shell, но не устраняет уязвимость удаленного выполнения кода (RCE), идентифицированную как CVE-2021-44832.
  3. Ветка Log4j2 1.2.x (поддержка завершена в 2015 г.):
    32% приложений по-прежнему используют ветку Log4j2 1.2.x, поддержка которой закончилась в 2015 году. Эта ветка подвержена критическим уязвимостям, таким как CVE-2022-23307, CVE-2022-23305 и CVE-2022-23302, выявленным в 2022 год, семь лет после окончания технического обслуживания.

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

Тревожным фактом является то, что 3.8% приложений используют Log4j2 2.17.0, который был исправлен против Log4Shell, но содержит CVE-2021-44832, еще одну серьезную уязвимость удаленного выполнения кода.

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

Крис Энг, директор по исследованиям Veracode, подчеркивает следующее:

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

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

Apache Software Foundation (ASF) активно уведомляет последующие проекты о необходимости срочного обновления, но результаты отчета показывают, что все еще существуют приложения, в которых не реализованы необходимые исправления.

Отчет Veracode был основан на данных сканирования более 38,000 90 приложений за 15-дневный период с 15 августа по 4 ноября. Приложения использовали версии Log1.1j от 3.0.0 до 1 альфа-3,866 в XNUMX различных организациях.

Наше исследование также показало, что, как только разработчики получают предупреждение об уязвимой библиотеке посредством сканирования, они исправляют ее относительно быстро: 50 процентов уязвимостей устраняются в целом за 89 дней, за 65 дней для уязвимостей высокой степени серьезности и за 107 дней для уязвимостей средней степени серьезности.

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

наконец, если вы интересно узнать об этом большеПриглашаю вас посетить оригинальную статью в блоге veracode. Ссылка такая.


Оставьте свой комментарий

Ваш электронный адрес не будет опубликован. Обязательные для заполнения поля помечены *

*

*

  1. Ответственный за данные: AB Internet Networks 2008 SL
  2. Назначение данных: контроль спама, управление комментариями.
  3. Легитимация: ваше согласие
  4. Передача данных: данные не будут переданы третьим лицам, кроме как по закону.
  5. Хранение данных: база данных, размещенная в Occentus Networks (ЕС)
  6. Права: в любое время вы можете ограничить, восстановить и удалить свою информацию.