Архив рубрики: Темы

Про Endpoint Vulnerability Detection

Про Endpoint Vulnerability Detection

Про Endpoint Vulnerability Detection. Поделюсь некоторыми соображениями, болями и хотелками по поводу отечественных средств детектирования уязвимостей инфраструктуры.

1. Если брать только ОС-и, то основная боль детектирования уязвимостей это Windows и macOS. Особенно Windows: и по KBшкам, и для Third-Party. Я верю, что в какой-то перспективе от этого в российском энтерпрайзе откажутся, но пока оно есть и требует поддержки. С Linux, особенно в той части детектов, которые обычно реализуют VM-вендоры, детект только по бюллетеням безопасности и версиям пакетов, можно сказать, терпимо.
2. Архитектура и интерфейсы управления отечественных VM решений (я намеренно не буду никого конкретного называть, считайте, что это в среднем по больнице) это просто беда. Трудно развертывать, трудно эксплуатировать, трудно дебажить. Лучше бы этого переусложненного безобразия не было вовсе. 😔
3. Функциональности по детектированию уязвимостей, которая есть в бесплатном ScanOVAL ФСТЭК в принципе было бы достаточно, если бы он не был специально ограничен с точки зрения автоматизации работы. Понятно почему ограничен - забесплатно и так очень круто, тут вопросов нет. Но если бы был, допустим, сканер аналогичный ScanOVAL, но позволяющий запускаться в неинтерактивном режиме с возможностью подложить ему OVAL-контент (или в другом формате - не важно) и получить результаты детектирования - это был бы отличный продукт, за который можно было бы платить вменяемые деньги. Поддержание работы движка и наполнение контента это тяжёлая, важная и трудоемкая работа, это должно финансироваться, тут тоже без вопросов. Я бы топил за такое. Назовем такой класс продуктов, например, Local Vulnerability Scanner.
4. Допустим у нас есть консольная сканилка из предыдущего пункта. Как должно выглядеть вменяемое взаимодействие агента и сервера? Максимально просто и прозрачно для конечного пользователя (№*?@%#$🤬💪)!!! Агент на устройстве должен периодически брать адрес сервера (обычного web-сервера, REST API) из текстового конфига, спросить у сервера "есть у тебя новый контент?", если есть, то скачать его, запустить детект и залить результаты детекта на сервер. Всё! Это тривиально запиливается на скриптах за неделю. И агентная часть, и серверная. И дебажится в случае непоняток ручным выполнением тех же самых запросов с таргет-хоста. И агентная обвязка, и сервер это вообще может быть опенсурс. Вменяемому клиенту все эти интерфейсные красивости, на которые VM-вендоры палят столько ресурсов либо вообще не нужны, либо абсолютно второстепенны.

Сомневаюсь я, конечно, что кто-то из VM-вендоров прислушается и выпустит базовое решение для детекта уязвимостей а-ля ScanOVAL, но с возможностями для автоматизации. Или, что возможности автоматизации добавят непосредственно в ScanOVAL. Или, что агентное сканирование сделают по-человечески, нормально и прозрачно. Но высказываться в эту сторону, имхо, нужно. А то так и продолжим терпеть с улыбочкой всю эту лютую дичь. 😬

Ещё про Confluence

Ещё про Confluence
Ещё про Confluence

Ещё про Confluence. В тикете для CVE-2023-22508 активно спрашивают, будет ли фикс для 7.13.x. Почему вдруг именно для 7.13? Потому что это LONG TERM SUPPORT релиз, который 2 года должен получать:

- Critical security bug fixes
- Critical bug fixes
- All other security bug fixes, whenever possible

Но проблема в том, что этот релиз 2 года назад был выпущен и у него совсем скоро EOL (17 Aug 2023). Поэтому, если вы до сих пор на 7.13, задумайтесь о миграции. В идеале не на следующий LTS (7.19), а на что-нибудь не от Atlassian.

Сегодня пишут про 2 RCE уязвимости в Atlassian Confluence (Data Center & Server), хотя бюллетень вышел ещё неделю назад

Сегодня пишут про 2 RCE уязвимости в Atlassian Confluence (Data Center & Server), хотя бюллетень вышел ещё неделю назад

Сегодня пишут про 2 RCE уязвимости в Atlassian Confluence (Data Center & Server), хотя бюллетень вышел ещё неделю назад.

CVE-2023-22505. Уязвимы версии с 8.0.0, пофикшено с 8.3.2, 8.4.0.
CVE-2023-22508. Уязвимы версии с 7.4.0, пофикшено с 8.2.0.

В NVD забавное генеренное описание на основе CVSS:

"allows an authenticated attacker to execute arbitrary code which has high impact to confidentiality, high impact to integrity, high impact to availability, and no user interaction"

"позволяет аутентифицированному злоумышленнику выполнять произвольный код, который сильно влияет на конфиденциальность, сильно влияет на целостность, сильно влияет на доступность и не требует взаимодействия с пользователем"

В том же бюллетене есть RCE уязвимость CVE-2023-22506 в Atlassian Bamboo (инструмент непрерывной интеграции и развертывания).

Интересный кейс с атакой на Mobile Device Management-решение

Интересный кейс с атакой на Mobile Device Management-решение

Интересный кейс с атакой на Mobile Device Management-решение. Вчера вышли патчи для эксплуатируемой уязвимости обхода аутентификации CVE-2023-35078 в Ivanti Endpoint Manager Mobile. Ivanti EPMM (он же MobileIron Core) - это программный движок для управления мобильными устройствами, который позволяет устанавливать политики для мобильных устройств, приложений и контента.

Уязвимость затрагивает все поддерживаемые версии Ivanti EPMM/MobileIron Core. Удаленный злоумышленник может использовать определенные вызовы API без аутентификации, с помощью которых получить доступ к личной информации (имена, номера телефонов и другие данные о мобильных устройствах). Злоумышленник также может внести изменения в конфигурацию, в том числе создать учетную запись администратора EPMM.

Уязвимость использовалась в атаках на 12 норвежских министерств. По данным Shodan наружу торчат 2900 порталов MobileIron, по большей части в США, Германии, Великобритании и Гонконге.

Немного доработал отчёты Vulristics и перегенирил отчёт для июльского Microsoft Patch Tuesday

Немного доработал отчёты Vulristics и перегенирил отчёт для июльского Microsoft Patch TuesdayНемного доработал отчёты Vulristics и перегенирил отчёт для июльского Microsoft Patch Tuesday

Немного доработал отчёты Vulristics и перегенирил отчёт для июльского Microsoft Patch Tuesday. Теперь видно уязвимости какой критичности были упомянуты в каждом из источников комментариев. VM-вендоры (Qualys, Tenable, Rapid7) упоминают большее число уязвимостей в обзорах. Как и Dark Reading. A Sophos, например, только самый-самый ТОП. ZDI на самом деле тоже много уязвимостей упоминают, но большую часть просто перечисляют в табличке с минимумом полей - такое я игнорирую.

Также во все таблицы добавил колонку All (A) с общим количеством уязвимостей для продукта, типа уязвимостей или источника комментариев.

На какие вопросы должен ответить Vulnerability Intelligence

На какие вопросы должен ответить Vulnerability Intelligence

На какие вопросы должен ответить Vulnerability Intelligence. Допустим у нас есть трендовая уязвимость, о которой все пишут. Вот я посмотрел в свой автоматический канал с новостями @avleonovnews, сегодня пишут про code injection в Citrix NetScaler ADC и RCE в Apache OpenMeetings. От Vulnerability Intelligence решения хочется ответы на следующее:

1. У нас этот уязвимый продукт вообще используется? А где именно? И не только в проде, не только в HQ, во всех дочерних компаниях и т.д.
2. Можем мы получить полный список потенциально уязвимых активов? Что нужно сделать, чтобы его получить?
3. Все эти потенциально уязвимые активы покрыты VM-ом? Что нужно сделать, чтобы были покрыты все?
4. Наш VM умеет детектировать уязвимости для таких продуктов и детектируется ли эта конкретная уязвимость? Как будем детектить эту уязвимость, если нет (альтернативные утилиты, вручную и т.д.)?

Иными словами, делать все те базовые вещи, обеспечивающие адекватность VM-а.

Зачем нужен Vulnerability Intelligence, если уже есть Vulnerability Management?

Зачем нужен Vulnerability Intelligence, если уже есть Vulnerability Management?

Зачем нужен Vulnerability Intelligence, если уже есть Vulnerability Management? Затем, что в вашем VM-е всегда будут не все уязвимости, которые по факту есть в вашей инфраструктуре 😏:

1. VM охватывает не все активы, потому что зачастую покрытие VM-ом как-то специально не контролируется. Или контролируется только в рамках каких-то конкретных типов хостов (Windows десктопы/серверы, Linux серверы, Cisco и т.д.), а в реальности инфраструктура оказывается гораздо разнообразнее.
2. Возможности VM-решений по детектированию уязвимостей ограничены. В лучшем случае вы получите от вендора список поддерживаемых ОС/продуктов/устройств, но достаточно ли этого для вашей инфраструктуры кроме вас никто не скажет. Скорее всего недостаточно и где-то ваше VM-решение детектировать уязвимости не сможет. Или детекты уязвимостей будут появляться с задержкой (если генерация детектов не автоматизирована полностью).

Vulnerability Intelligence должен эти проблемы подсветить и компенсировать.