Архив метки: log4shell

В начале августа Qualys представили новые возможности по анализу уязвимостей самописных (First-Party) и опенсурсных приложений

1 комментарий

В начале августа Qualys представили новые возможности по анализу уязвимостей самописных (First-Party) и опенсурсных приложенийВ начале августа Qualys представили новые возможности по анализу уязвимостей самописных (First-Party) и опенсурсных приложенийВ начале августа Qualys представили новые возможности по анализу уязвимостей самописных (First-Party) и опенсурсных приложений

В начале августа Qualys представили новые возможности по анализу уязвимостей самописных (First-Party) и опенсурсных приложений.

Вот, допустим, есть у вас в организации самописная софтина. Её пилят ваши разрабы. Естественно на основе опенсурса. Возможно ваши апсеки периодически проверяют её SAST-ом/DAST-ом и детектят-исправляют уязвимости. Но ваше VM-решение об этой софтине не знает и, соответственно, уязвимости для неё не детектирует. Более того, даже если вы знаете, что версии этой софтины уязвимых софтов. Причём какие-то софты явно забыли и VM-решения в таких софтах Log4Shell не продетектируют. Как и в вашей доморощенной софтине, которая также использует Log4j. Получается такое детектить надо не от софта, а непосредственно от либы, jar-ники искать и анализировать каким-то сторонним решением. И эта активность тоже, получается идёт мимо вашего дорогущего VM-а. Плохо это? Плохо. Зачем VM брали-то тогда! 🙄😁

Что предлагает Qualys. Во всяком случае то, что я понял из достаточно пространной видяшки и поста.

1. Custom Assessment and Remediation (CAR), о котором я раньше уже писал. Это механизм для добавления собственных скриптовых детектов, в том числе на PowerShell и Python. Написали свой скрипт детекта (например по версиям, которые вам апсеки сказали), добавили в Qualys - получили уязвимые хосты. Такие уязвимости будут иметь QID и с ними можно работать как с уязвимостями, которые продетектил сам Qualys.

2. Runtime Software Composition Analysis (SCA). Это композиционный анализ. Во время сканирования на наличие уязвимостей детектируется не только сам софт и его версия, но и используемые этим софтом библиотеки.

"SCA сканирует уязвимости в компонентах с открытым исходным кодом, разработанных для Java, Go, .Net, Python, Node JS, Rust, Ruby, PHP и других. Добавление SCA расширяет возможности сканирования VMDR, добавляя более 13 000 новых сигнатур, охватывающих более 11 000 CVE."

Фактически это сводится к тому, что Qualys Agent бегает по файловой системе и ищет/анализирует файлики библиотек (в т.ч. Log4j). Это не супер-новшество. Такие детекты я давно видел в Microsoft Defender for Endpoint. Видимо это становится обязательной фичой.

В общем, VM-вендоры, присмотритесь к кейсам! Клиенты VM-вендоров, задавайте им неудобные вопросы! 😉

На днях вышел бюллетень CISA про эксплуатацию уязвимости Log4Shell (CVE-2021-44228) в некоторой американской государственной организации

Добавить комментарий

На днях вышел бюллетень CISA про эксплуатацию уязвимости Log4Shell (CVE-2021-44228) в некоторой американской государственной организации. В pdf бюллетене приводится подробное описание атаки. Ознакомился. Мне, конечно, было наиболее интересно собственно про Log4Shell и начальную эксплуатацию.

1. В какой организации произошел инцидент? Непонятно. Это одна из FCEB organizations. Это может быть всем известная NASA, а может быть какая-нибудь Commission of Fine Arts. Но по большей части организации в списке выглядят критично.

2. Когда нашли? В апреле 2022. Предположительное время компрометации - февраль 2022 года.

3. Как нашли? Через ретроспективный контроль трафика с помощью CISA-вской EINSTEIN IDS. Увидели ip-адрес ранее засветившийся в атаках использующих Log4Shell.

4. Как известно Log4Shell (CVE-2021-44228 заведена 10.12.2021) касается кучи продуктов, а что именно поломали? VMware Horizon. Патч вышел 16.12.2021. Детект у Tenable для этой уязвимости (без аутентификации) вышел 07.01.2022. CISA требовали зафиксить все Log4Shell уязвимости до 24.12.2021.

5. Исходя из таймлайна, в сроки CISA (7 дней по факту) уложиться было мало реально. Причем это нужно было сделать ещё до появления нормальных детектов. Но то, что не уложились даже за 1-2 месяца вплоть до успешной атаки злоумышленников это конечно неслабое нарушение. И раз такое в принципе было возможно, CISA видимо не особо контролирует VM процесс в подопечных FCEB организациях, а сроки устранения, которые они спускают через свой Known Exploited Vulnerabilities Catalog видимо по факту не выдерживаются.

Классная была задумка в NVD добавлять лейблы к ссылкам

Добавить комментарий

Классная была задумка в NVD добавлять лейблы к ссылкам

Классная была задумка в NVD добавлять лейблы к ссылкам. Чтобы сразу было видно на какой объект ссылаются: почтовая рассылка, бюллетень вендора, бюллетень третьих лиц, патч, а самое ценное - эксплоит. То есть можно было бы только на основе NVD делать достаточно неплохую приоритизацию уязвимостей. Но реальность, к сожалению, грустнее:

1. На простановку лейблов всем так-то пофигу. На скриншоте log4shell. Для части ссылок на packetstorm проставлено, что это эксплоиты. Для части нет. Может это на самом деле не эксплоиты? Да нет, все верно, я обкликал и проверил. Просто ошибка операциониста, который ссылку добавлял.
2. Заинтересован ли кто-то быстро добавить в NVD ссылку на эксплоит, когда он появляется в паблике? Да видимо не особо. Разве что для очень громких уязвимостей.
3. Это общая беда, но в описании CVE могут писать про один тип уязвимости, допустим RCE, а эксплоит будет демонстрировать другую уязвимость, допустим DoS.

Выводы? Спасибо, что хотя бы так и бесплатно. 🙂 Но исключительно на данные из NVD лучше не полагаться.