Основы Интернет - технологий.

Множество приложений, использующих библиотеку 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 раз больше времени, чтобы исправить хотя бы половину бэклога в случае нехватки персонала, и более семи месяцев, в случае недостаточной информированности.