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

В CISA KEV, каталоге эксплуатируемых уязвимостей, появилась новая колонка, отвечающая за использование уязвимости в атаках шифровальщиков

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

В CISA KEV, каталоге эксплуатируемых уязвимостей, появилась новая колонка, отвечающая за использование уязвимости в атаках шифровальщиков

В CISA KEV, каталоге эксплуатируемых уязвимостей, появилась новая колонка, отвечающая за использование уязвимости в атаках шифровальщиков. Колонка называется "Known to be Used in Ransomware Campaigns". Возможные значения: Known и Unknown. Сейчас там 184 уязвимости, которые Known. В JSON-выгрузке также есть это поле. Неплохо, но хотелось бы, конечно, не только флажок, но и подробности какие именно шифровальщики эксплуатируют уязвимости.

Также CISA завели новую страничку с мисконфигурациями, которые используются в атаках шифровальщиков. Пока там только таблица с сервисами, использование которых может быть небезопасно (RDP, FTP, TELNET, SMB, VNC). Но, возможно, эта тема разовьётся во что-то более интересное.

Первоначальные намётки по открытому фиду с уязвимостями - проект Vulrectory (пока пустой)

2 комментария

Первоначальные намётки по открытому фиду с уязвимостями - проект Vulrectory (пока пустой). По этому проекту хотелось бы в идеале получить обновляемый фид со всеми уязвимостями из NVD и БДУ, содержащий некоторые дополнительные поля, чтобы его можно было использовать как единственный источник данных в Vulristics. Сейчас если с помощью Vulristics приоритизировать, допустим, 100 CVE, то утилита будет делать запросы по каждой из этих CVE к различным источникам (как к бесплатным, так и к платному - Vulners), а затем комбинировать и анализировать данные. Таким образом, будут использоваться наиболее свежие данные, но генерация полного отчета займет довольно много времени. А за большое количество запросов бесплатные источники могут и побанить. Если же будет свой источник с уже подготовленными данными, который можно будет локально выкачать к себе, то можно будет запросто строить отчеты по десяткам тысяч уязвимостей без каких-либо внешних запросов. Сразу появится множество применений:

1. Оценка и приоритизация продетектированных уязвимостей (как для отдельных хостов, так и для инфраструктуры в целом!).
2. Оценка расхождений в результатах детектирования уязвимостей VM-продуктами и слепых пятен в базах знаний (детектов) VM-продуктов.
3. Vulnerability Intelligence - анализ всего входящего потока уязвимостей. Возможно с фокусом только на тех продуктах, которые используются в организации и без привязки к детектам в VM-решении.

В общем, как только можно будет работать с готовыми данными в оффлайне, всё сразу становится гораздо интереснее и удобнее. 😉

Какие дополнительные поля нужны Vulristics:

• Название уязвимого софта. Планирую переиспользовать детект продуктов по ключевым словам на основе описания CVE, который сейчас используется в Vulristics. Но лучше добавить ещё детект на основе CPE и парсинг генеренных описаний уязвимостей "имя софта> тип уязвимости>" (как у Microsoft). Также имя софта можно напрямую забирать из БДУ.
• Тип уязвимости. Планирую переиспользовать детект типа уязвимости по ключевым словам на основе описания CVE, который сейчас используется в Vulristics. Но лучше добавить ещё детектирование на основе CWE. Но это на крайний случай, т.к. к простановке CWE идентификаторов в NVD были вопросы.
• Наличие эксплоита. Если мы хотим, чтобы Vulrectory был бесплатным, то придется видимо ограничиться ссылками на эксплоиты из NVD и флажком "Наличие эксплойта" из БДУ. 🤷‍♂️ В Vulners их будет, конечно, гораздо больше (как вариант делать платную PRO версию?). Возможно есть какие-то открытые базы с признаками наличия эксплоитов на том же GitHub-е - нужно ресерчить.
• Признак эксплуатации вживую. Тут также видимо придется ограничиться бесплатным источником - CISA KEV и ресерчить наличие открытых источников по фактам эксплуатации.

В рамках этого же проекта можно для уязвимостей отображать не только CVSS, но и вектор/скор OSOKA (только Базовые и Эксплуатационные метрики, конечно). 🙂

В общем, пока какие-то такие мысли. Как вам?

VM-вендоры не умеют детектировать уязвимости, которые эксплуатируются шифровальщиками

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

VM-вендоры не умеют детектировать уязвимости, которые эксплуатируются шифровальщиками

VM-вендоры не умеют детектировать уязвимости, которые эксплуатируются шифровальщиками. Прочитал отчёт "Index Update Q1 2023 RANSOMWARE Through the Lens of Threat and Vulnerability Management" по данным Securin и Ivanti. Товарищи анализируют информацию об уязвимостях, которые используются 356 шифровальщиками.

В отчёте утверждается, что есть 18 уязвимостей, эксплуатируемых шифровальщиками, которые не детектируются сканерами уязвимостей ТОПовых VM-вендоров (Tenable, Rapid7 и Qualys):

CVE-2010-1592
CVE-2012-3347
CVE-2013-0322
CVE-2013-2618
CVE-2013-3993
CVE-2015-2551
CVE-2015-7465
CVE-2017-15302
CVE-2017-18362
CVE-2017-3197
CVE-2017-3198
CVE-2017-6884
CVE-2019-16647
CVE-2019-16920
CVE-2019-5039
CVE-2019-9081
CVE-2020-36195
CVE-2021-33558

Эти уязвимости эксплуатируются 59 группировками шифровальщиков, среди которых Hive, Qlocker, QNAPCrypt и UEFI.

От меня: когда я призываю к открытости баз знаний VM-вендоров, я имею ввиду именно это. Любой VM-вендор умеет детектировать только часть из всех известных уязвимостей. Кто может сказать, что тех уязвимостей, которые он умеет детектировать, достаточно и в его слепой зоне точно нет ничего критичного? Вот имеем пример, когда исследователи, получив доступ к базам знаний (детектов) VM-вендоров, подтвердили проблему с полнотой. И это мы берём самый-самый топ критичных уязвимостей и самых крутых международных VM-вендоров.

Разумеется, сравнение по детектируемым CVE идентификаторам это далеко не идеальный способ обнаружить проблемы с полнотой, но это простой способ и какое-то представление он даёт. Поэтому, призываю всех пушить отечественных VM-вендоров, чтобы информация о детектируемых уязвимостях была публичной и общедоступной для стороннего анализа. Ну или хотя бы доступной регуляторам, чтобы регуляторы сами контролировали адекватность баз знаний (детектов) VM-вендоров.

В отчёте также есть критика CVSS, NVD и CISA KEV из-за некорректного учёта эксплуатируемых шифровальщиками CVE:

• 30% CVE не имеют CVSS v2 или v3 в NVD
• 2 CVE имеют severity Low, 57 Medium в NVD
• 2 CVE находятся в статусе Rejected в NVD (CVE-2015-2551 и CVE-2019-9081)
• только 68% CVE содержатся в CISA KEV, требуется добавить ещё 131

По итогам выступления на Positive Customer Day

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

По итогам выступления на Positive Customer Day. Всё прошло вполне удачно. Спасибо большое коллегам из Positive Technologies за приглашение! Кажется это был мой первый доклад на "бумажную" тему. Хоть я, в основном, делал акценты на технические сложности при реализации методик, но всё равно. Оказалось, что у "бумажных" докладов своя специфика. Были вопросы в духе: почему регулятор написал документ так, а не иначе? Почему он что-то учёл, а что-то решил не учитывать? Зачем регулятор вообще выпустил тот или иной документ? Раньше я с таким не сталкивался и даже впал в лёгкий ступор. Можно, конечно, что-то фантазировать на эту тему, но такие вопросы явно не по адресу. 😅

В целом же, по итогам Q&A для себя сформулировал следующее:

1. В методику оценки критичности уязвимостей неплохо было бы добавить учёт использования уязвимости в реальных атаках (аналог CISA KEV) и вероятности появления эксплоита для неё (аналог EPSS)
2. В руководство по построению процесса управления уязвимостями было бы неплохо добавить:
2.1. Требования к актуальности данных об обнаруженных уязвимостях, например максимально допустимую периодичность сканирования. Не должно быть возможности сканировать раз в квартал и делать какие-то выводы на основе этого.
2.2. Требования к полноте покрытия активов. Не должно быть активов (хостов, софтов, сетевых устройств и т.д.), которые не покрываются средствами детектирования уязвимостей. Должен быть какой-то процесс подтверждения, что VM-решение умеет детектировать уязвимости для всех активов в организации. Если есть какой-то актив, для которого автоматическое детектирование уязвимостей не производится, нужно с этим что-то делать. Как минимум подсветить.
2.3. Требования к оценке качества детектирования уязвимостей. Ситуация, когда несколько средств детектирования анализируют один и тот же актив и выдают совершенно разные наборы уязвимостей ненормальная. Если так происходит, значит в каких-то решениях реализована неправильная логика и такие решения нельзя использовать в процессе управления уязвимостями ("мусор на входе - мусор на выходе"). Следует ли из этого, что должен быть процесс сертификации средств детектирования уязвимостей, такой как для PCI ASV или SCAP сканеров? Возможно.

Ещё в выступлении я, среди прочего, позволил себе предположить, что подход Positive Technologies к VM-у (который я лично всячески поддерживаю), предполагающий процесс регулярного безусловного патчинга инфраструктуры не особенно сочетается с руководством ФСТЭК по построению процесса управления уязвимостями, т.к. это руководство требует тестирования обновлений для open-source и нероссийского софта по методике ФСТЭК перед установкой. Т.е. процесс регулярного безусловного патчинга может и быть, но кажется момент с тестированием обновлений должен быть определен: тестируем/не тестируем, если тестируем, то чьими силами и в каком объёме.

Про CVE_Prioritizer и Vulristics

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

Про CVE_Prioritizer и Vulristics

Про CVE_Prioritizer и Vulristics. Несколько раз за последние месяцы натыкался на посты про CVE_Prioritizer. Но сегодня появился повод прокомментировать.

"CVE_Prioritizer is a powerful tool that helps you prioritize vulnerability patching by combining CVSS, EPSS, and CISA's Known Exploited Vulnerabilities. It provides valuable insights into the likelihood of exploitation and the potential impact of vulnerabilities on your information system."

Прикольная утилита, но, имхо, мой Vulristics приоритизирует покруче. 🙂 Он учитывает не только CVSS, EPSS и CISA KEV, но и тип уязвимости, распространенность софта, информацию об эксплоитах (из многих паков на Vulners) и атаках из AttackersKB.

И CVE_Prioritizer, и Vulristics для каждой уязвимости в динамике выполняют запросы к внешним источникам. Только у CVE_Prioritizer таких источников только 2 и поэтому он отрабатывает быстрее. Кроме того, Vulristics каждый раз в динамике определяет наименование софта и тип уязвимости по описанию. Это медленная операция. А в случае использования Vulners в качестве источника, всё это ещё и стоит денег 💸 (хотя лично мне не стоит, т.к. у меня ресерчерская лицензия - спасибо ребятам из Vulners!❤️). Так что с помощью Vulristics достаточно удобно оценивать 100-200 уязвимостей за раз (как в MS Patch Tuesday), а оценивать больше не особо рационально. 🙁

Что с этим можно сделать? Если заранее формировать полный (и желательно бесплатный/общедоступный 😉) фид по всем уязвимостям, чтобы Vulristics строил отчёт по готовым данным, это было бы гораздо быстрее и эффективнее. В этом случае можно было бы приоритизировать уязвимости хоть для всей инфраструктуры разом. У меня есть в некоторых долгосрочных планах этим заняться. Кто хочет поучаствовать - всегда welcome! 🙂

По поводу предыдущей картинки, вынесу из комментов в ВК

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

По поводу предыдущей картинки, вынесу из комментов в ВК.

1. В другом качестве картинки нет, стащил из аккаунта Nucleus в соцсеточке, на сайте у них не нашел. 🤷‍♂️ Но это просто статистика по второй колонке из CISA KEV.

2. "Возможно большее количество уязвимостей говорит о большей распространенности и большем числе продуктов вендора. А Linux - здесь наверное только linux kernel?" Да, Linux это только Linux Kernel, а Microsoft это все продукты Microsoft, включая Windows Kernel. Но то, что продукты Microsoft наиболее активно атакуются - факт. Отказ от продуктов Microsoft поднимет защищённость хотя бы по логике "если у вас нет собаки, её не отравит сосед". 🙂

3. "Как эппл и адоб умудрились заслужить столько?" У Adobe основной генератор дырок это PDF reader. Apple macOS, к сожалению, достаточно популярная десктопная ОС, для неё регулярно находят критичные RCE уязвимости. В основном в ядре и WebKit. Средств администрирования и защиты информации для macOS меньше и они не так развиты. Поэтому, имхо, устройства Apple в инфраструктуре это даже большая проблема, чем продукты Microsoft.

Nucleus Security нарисовали красивую картинку по CISA KEV уязвимостям

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

Nucleus Security нарисовали красивую картинку по CISA KEV уязвимостям

Nucleus Security нарисовали красивую картинку по CISA KEV уязвимостям. Навели статистику по вендорам. К статистике наведенной по всем уязвимостям из NVD я отношусь обычно скептически - непонятно то ли у вендора такие дырявые продукты, то ли вендор наоборот ответственно подходит к уязвимостям в своих продуктах и заводит CVE на каждый чих. Здесь же рассматриваются только уязвимости с признаками эксплуатации в реальных атаках, просто так в CISA KEV не попадают. Поэтому вполне справедливо будет сделать вывод: если у вас инфраструктура на продуктах Microsoft, то уровень риска у вас соответствует этому громадному кружку, а если на Linux, то гораздо меньшему кружку (его так сразу и не заметишь). Выпиливайте у себя Microsoft! Хотя бы стратегически двигайтесь в этом направлении. Тоже касается и других больших кружков: CISCO, Apple, Oracle, Adobe. Google выпилить скорее всего не получится - это вездесущий Chromium. 🙂