sasha-meteor
Midle Weight
- Депозит
- $-127
Множество приложений, использующих библиотеку Apache Log4j, используют версии, уязвимые перед различными проблемам, включая нашумевшую уязвимость Log4Shell (CVE-2021-44228), хотя с момента ее обнаружении и исправления прошло уже больше двух лет.
Напомним, что в середине декабря 2021 года разработчики Apache Software Foundation выпустили экстренное обновление безопасности, исправляющее 0-day-уязвимость (CVE-2021-44228) в популярной библиотеке журналирования Log4j, входящей в состав Apache Logging Project. Срочность объяснялась тем, что ИБ‑специалисты уже начали публиковать в открытом доступе PoC-эксплоиты, объясняя, что использовать баг можно было удаленно, причем для этого не требовались особые технические навыки.
Проблема была назвала Log4Shell и, разумеется, атаки на нее не заставили себя ждать. Вскоре уязвимость стала одной из наиболее используемых хакерами, ведь злоумышленники начали искать в интернете любые Java-приложения, которые могли использовать библиотеку Log4j, и тестировали на них эксплоиты.
К проблеме Log4Shell было привлечено много внимания, так как ее широкий охват и простота использования заинтересовали множество злоумышленников. Однако теперь аналитики Veracode пишут, что обширная кампания по уведомлению сопровождающих затронутых проектов и системных администраторов оказалось не слишком успешной.
Дело в том, что, согласно собранным в период с 15 августа по 15 ноября данным, проектов с уязвимыми версиями Log4j все еще остается очень много. Так, специалисты Veracode собрали данные за 90 дней от 3 866 организаций, которые используют 38 278 приложений, зависящих от Log4j с версий от 1.1 до 3.0.0-alpha1.
Из этих приложений 2,8% используют Log4J версий от 2.0-beta9 до 2.15.0, которые напрямую уязвимы для Log4Shell.
Еще 3,8% используют Log4j 2.17.0, которая не уязвима для Log4Shell, но подвержена RCE-проблеме CVE-2021-44832, которая была исправлена в версии 2.17.1.
Наконец, 32% используют Log4j версии 1.2.x, поддержка которой завершилась еще в августе 2015 года. Эти версии уязвимы ко множеству серьезных проблем, включая такие баги, как CVE-2022-23307, CVE-2022-23305 и CVE-2022-23302.
В общей сложности Veracode обнаружила, что около 38% приложений используют небезопасные версии Log4j.
Постоянное использование устаревших версий библиотек свидетельствует о наличии системной проблемы, которую в Veracode объясняют желанием разработчиков избежать ненужных сложностей.
Так, по данным исследователей, 79% разработчиков предпочитают вообще не обновлять сторонние библиотеки после их первоначального включения в кодовую базу, чтобы не нарушить функциональность. При этом в 65% случаев обновления опенсорсных библиотек содержат лишь незначительные изменения и исправления, которые вряд ли могут привести к функциональным проблемам.
Более того, исследование показало, что на устранение уязвимостей высокой степени серьезности у 50% проектов уходит более 65 дней. При этом потребуется в 13,7 раз больше времени, чтобы исправить хотя бы половину бэклога в случае нехватки персонала, и более семи месяцев, в случае недостаточной информированности.
© https://xakep.ru/2023/12/12/log4shell-stats/
Напомним, что в середине декабря 2021 года разработчики Apache Software Foundation выпустили экстренное обновление безопасности, исправляющее 0-day-уязвимость (CVE-2021-44228) в популярной библиотеке журналирования Log4j, входящей в состав Apache Logging Project. Срочность объяснялась тем, что ИБ‑специалисты уже начали публиковать в открытом доступе PoC-эксплоиты, объясняя, что использовать баг можно было удаленно, причем для этого не требовались особые технические навыки.
Проблема была назвала Log4Shell и, разумеется, атаки на нее не заставили себя ждать. Вскоре уязвимость стала одной из наиболее используемых хакерами, ведь злоумышленники начали искать в интернете любые Java-приложения, которые могли использовать библиотеку Log4j, и тестировали на них эксплоиты.
К проблеме Log4Shell было привлечено много внимания, так как ее широкий охват и простота использования заинтересовали множество злоумышленников. Однако теперь аналитики Veracode пишут, что обширная кампания по уведомлению сопровождающих затронутых проектов и системных администраторов оказалось не слишком успешной.
Дело в том, что, согласно собранным в период с 15 августа по 15 ноября данным, проектов с уязвимыми версиями Log4j все еще остается очень много. Так, специалисты Veracode собрали данные за 90 дней от 3 866 организаций, которые используют 38 278 приложений, зависящих от Log4j с версий от 1.1 до 3.0.0-alpha1.
Из этих приложений 2,8% используют Log4J версий от 2.0-beta9 до 2.15.0, которые напрямую уязвимы для Log4Shell.
Еще 3,8% используют Log4j 2.17.0, которая не уязвима для Log4Shell, но подвержена RCE-проблеме CVE-2021-44832, которая была исправлена в версии 2.17.1.
Наконец, 32% используют Log4j версии 1.2.x, поддержка которой завершилась еще в августе 2015 года. Эти версии уязвимы ко множеству серьезных проблем, включая такие баги, как CVE-2022-23307, CVE-2022-23305 и CVE-2022-23302.
В общей сложности Veracode обнаружила, что около 38% приложений используют небезопасные версии Log4j.
Постоянное использование устаревших версий библиотек свидетельствует о наличии системной проблемы, которую в Veracode объясняют желанием разработчиков избежать ненужных сложностей.
Так, по данным исследователей, 79% разработчиков предпочитают вообще не обновлять сторонние библиотеки после их первоначального включения в кодовую базу, чтобы не нарушить функциональность. При этом в 65% случаев обновления опенсорсных библиотек содержат лишь незначительные изменения и исправления, которые вряд ли могут привести к функциональным проблемам.
Более того, исследование показало, что на устранение уязвимостей высокой степени серьезности у 50% проектов уходит более 65 дней. При этом потребуется в 13,7 раз больше времени, чтобы исправить хотя бы половину бэклога в случае нехватки персонала, и более семи месяцев, в случае недостаточной информированности.
© https://xakep.ru/2023/12/12/log4shell-stats/