В Log4j выявлена еще одна уязвимость — возможность обхода недавнего патча

В Log4j выявлена еще одна уязвимость — возможность обхода недавнего патча

В Log4j выявлена еще одна уязвимость — возможность обхода недавнего патча

Кураторам проекта Apache Log4j вновь пришлось латать свой фреймворк для Java-приложений: оказалось, что защиту от атаки, получившей известность как Log4Shell, можно обойти при некоторых кастомных настройках журналирования. Разработчики устранили и эту уязвимость — в сборках 2.16.0 (для Java 8 и выше) и 2.12.2 (для Java 7, пока бета).

Поскольку патч для CVE-2021-44228 оказался неполным, проблеме присвоили отдельный идентификатор — CVE-2021-45046. Эксплойт вероятен для любого из прежних выпусков Log4j версии 2 и при определенных условиях позволяет вызвать состояние отказа в обслуживании (DoS).

Степень опасности уязвимости оценена как умеренная (3,7 балла по CVSS). Ветки 1.х утилиты ей не подвержены. Поскольку корнем зла оказался JAR-файл log4j-core, приложения, использующие только log4j-api, тоже вне зоны риска.

Исследователи из LunaSec отметили, что при использовании Log4j выпусков ниже 2.15 уязвимость CVE-2021-45046 может послужить новым вектором атаки Log4Shell, поэтому пользователям рекомендуется установить сборку 2.16.0.

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

57% компаний не знают свою инфраструктуру, поэтому дольше расследуют атаки

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

Для 33% компаний именно анализ логов и поиск индикаторов компрометации остаются самым трудоемким этапом реагирования. А в организациях с численностью свыше 5000 сотрудников этот показатель достигает 42%.

При этом далеко не все компании вообще знают, что происходит в собственной инфраструктуре. Исследование показало, что 57% организаций не проводят полную инвентаризацию и классификацию ИТ-активов. Из-за этого расследования затягиваются, а поиск источника атаки превращается в настоящий квест.

Еще одна хроническая болезнь отрасли — нехватка кадров. Более половины участников исследования признались, что специалистов по информационной безопасности попросту не хватает. Особенно остро проблема ощущается в компаниях с численностью от 250 до 1000 сотрудников, где на кадровый дефицит указали 70% респондентов.

С автоматизацией тоже все непросто. Хотя 52% компаний уже используют SIEM-системы, специализированные инструменты активного реагирования — XDR, SOAR, EDR и NDR — внедрены значительно реже. В результате многие процессы по-прежнему выполняются вручную.

Чаще всего автоматизируют самые очевидные действия: блокировку IP-адресов и доменов (49%), отключение учетных записей (46%) и изоляцию зараженных устройств (35%).

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

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

RSS: Новости на портале Anti-Malware.ru