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

Ещё один пример того, что NIST и MITRE не справляются с ведением базы уязвимостей

Ещё один пример того, что NIST и MITRE не справляются с ведением базы уязвимостей

Ещё один пример того, что NIST и MITRE не справляются с ведением базы уязвимостей. И американским регуляторам, включая CISA, видимо наплевать.

Mozilla Foundation Security Advisory 2022-09
Announced March 5, 2022
CVE-2022-26486: Use-after-free in WebGPU IPC Framework

Эта уязвимость есть в CISA Known Exploited Vulnerabilities Catalog. Значит эта критичная уязвимость эксплуатируется в реальных атаках.

Но если вы попробуете перейти по ссылке на CVE-2022-26486, например из той же CISA KEV, на сайт на NVD, то вы увидете "CVE ID Not Found". В MITRE аналогично: "RESERVED". Статус 9 месяцев не менялся (и видимо не поменяется). Что-то где-то пошло не так.

Могли бы CISA попушить NIST, MITRE или Mozilla, чтобы с этой критичной CVE навели порядок? Запросто. Но они это не делают. Им видимо норм ссылаться в никуда.

А вот в БДУ ФСТЭК для CVE-2022-26486 видим вполне адекватное описание с CVSS и всем, что нужно. ФСТЭК молодцы. 👍

На днях вышел бюллетень 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 видимо по факту не выдерживаются.

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: на основании чего принимается решение

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: на основании чего принимается решениеПро SSVC и конкретно про недавно вышедший SSVC Guide от CISA: на основании чего принимается решение

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: на основании чего принимается решение.

В первой части определили, что SSVC это по сути опросник. Задаем значения некоторых параметров связанных с уязвимостью, получаем в результате решение по уязвимости (Track, Track*, Attend, Act).

В документе процесс принятия решения визуализируется в виде дерева по которому мы идем и в итоге получаем итоговое значение. Поэтому "параметры" там именуются как "точки принятия решения" ("decision points"). Типа приходим на такую развилку и решаем куда дальше идти. Кажется никакой смысловой нагрузки это не несет, а только запутывает. Поэтому для меня это будут просто "параметры".

Итак, параметры следующие:

1. (State of) Exploitation - (Состояние) Эксплуатации
2. Automatable - Автоматизируемость
3. Technical Impact - Техническое Воздействие
4. Mission Prevalence and Public Well-Being Impact - Целевая Распространенность (понимаю, что так себе перевод, но это хитро вводится, будем разбираться позже) и Воздействие на Общественное Благополучие

Часть из них могут принимать 2 значения, часть 3 значения. Значения "фиг его знает" умышленно нет. Когда выбрать значения сложновато "CISA определяет значение, которое является наиболее разумным предположением, основанным на предыдущих событиях" ("the most reasonable assumption based on prior events"). "Такой подход требует надежных исторических данных, и будущие события могут со временем изменить эти предположения." Что за события и исторические данные имеются ввиду сказать сложно. Подозреваю, что все же имеет место быть традиционный "пол, палец, потолок". Если есть идеи, напишите в комментах.

Всего 36 комбинаций параметров и все они представлены на 10-й странице SSVC Guide от CISA.
Каждый из этих параметров заслуживает детального рассмотрения и медитации, что я и планирую далее по этой теме делать.

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: решения по уязвимостям

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: решения по уязвимостям.

Идея там в следующем: а давайте на основе некоторого опросника (да, очередного) будем определять что нам делать с конкретной уязвимостью. Какие это могут быть решения:

1. Отслеживать (Track). В настоящее время каких-то особых действий по уязвимости не требуется. Организация продолжает отслеживать новую информацию по уязвимости и проводить её переоценку. CISA рекомендуют устранять такие уязвимости в рамках стандартных сроков обновления.

2. Внимательно отслеживать (Track*). Уязвимость содержит определенные характеристики, которые могут потребовать более тщательного мониторинга изменений. CISA рекомендуют устранять такие уязвимости в рамках стандартных сроков обновления.

3. Уделять внимание (Attend). Уязвимость требует внимания со стороны нижнего уровня менеджмента (organization's internal, supervisory-level individuals). Необходимые действия могут включать запрос помощи или информации об уязвимости, приводить к публикации внутренних и/или внешних нотификаций об уязвимости. CISA рекомендуют устранять такие уязвимости быстрее стандартных сроков обновления.

4. Действовать (Act). Уязвимость требует внимания со стороны нижнего уровня менеджмента и ТОПов (organization's internal, supervisory-level and leadership-level individuals). Необходимые действия включают запрос помощи или информации об уязвимости, а также публикацию внутренних и/или внешних нотификаций об уязвимости. Как правило, внутренние группы встречаются и договариваются как будут реагировать на эту уязвимость, а затем выполняют согласованные действия. CISA рекомендуют устранять такие уязвимости как можно скорее.

Относительно американских уровней менеджмента я не особо в курсе, а гуглится там противоречивое, но в целом оно как-то так.

Как я понимаю о чем это вообще

Кажется во многих организациях, если не во всех, есть чатики безопасников, куда кидаются уязвимости для обсуждения. И там уже сообща решается вопрос стоит ли подрываться и оперативно фиксить уязвимость, или оно в регулярном процессе само зафиксится. Очевидно какие-то уязвимости не особо критичные и вряд ли будут эксплуатироваться в реальных атаках (множество вариаций Meltdown и Spectre например). По каким-то с ходу непонятно, но выглядит подозрительно и надо бы за ними приглядывать (недавняя SQLite RCE CVE-2022-35737). Какие-то очевидно нужно оперативно брать в работу, т.к. явно опасно и в целом понятно как устранять (какая-нибудь очередная RCE в Exchange или AD). А для некоторых уязвимостей нужно на ТОПов выходить, запускать их отдельными треками и патчить пожарном режиме (Log4Shell, MS17-010).

В принципе процесс это знакомый и естественный. Но так сразу и не скажешь по какому принципу в таком чатике принимаются решения по конкретной уязвимости, "экспертная оценка" во всей красе. И цель SSVC, насколько я могу судить, этот процесс несколько формализовать.

В следующей части начнем разбираться на основании чего решение принимается. И т.к. недавняя ФСТЭКовская "Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств" тоже +- про это, хотя и реализация совсем другая, напрашивается некоторое сравнение / размышление как мы до жизни такой дошли. Stay tuned.

Новое чтиво на выходные по нашей теме от американцев из CISA "Stakeholder-Specific Vulnerability Categorization Guide", то есть руководство по классификации уязвимостей для конкретных заинтересованных сторон

Новое чтиво на выходные по нашей теме от американцев из CISA "Stakeholder-Specific Vulnerability Categorization Guide", то есть руководство по классификации уязвимостей для конкретных заинтересованных сторон.

"Целью SSVC является помощь в определении приоритетности устранения уязвимости на основе воздействия, которое ее эксплуатация может оказать на конкретную организацию (организации)."

Ознакомимся 🙂

Joint advisory AA22-279A (4/4)

Joint advisory AA22-279A (4/4)

3. Продетектированные типы уязвимостей.

Remote Code Execution
Command Injection
Arbitrary File Reading
Authentication Bypass
Path Traversal

Как видим все уязвимости очевидно критичные за исключением одного "Path Traversal":

Path Traversal - Citrix Application Delivery Controller (CVE-2019-19781)

Описание уязвимости не оставляет никаких возможностей для детектирования другого типа:

"An issue was discovered in Citrix Application Delivery Controller (ADC) and Gateway 10.5, 11.1, 12.0, 12.1, and 13.0. They allow Directory Traversal".

Этот же тип указывается в отчете AA22-279A: Citrix ADC CVE-2019-19781 Path Traversal

И только в описании эксплоита мы можем видеть, что это по факту RCE: "This tool exploits a directory traversal bug within Citrix ADC (NetScalers) which calls a perl script that is used to append files in an XML format to the victim machine. This in turn allows for remote code execution."

Что ж, это очередное напоминание о том, что жестко фильтроваться по типу уязвимости нельзя и доверять описанию из nvd тоже нельзя. Тип уязвимости может уточняться со временем, а изменения в NVD никто не вносит.

В части случаев Vulristics может помочь более точно определить тип уязвимости:

AA22-279A: Apache HTTP Server CVE-2021-41773 Path Traversal
Vulristics: Remote Code Execution - Apache HTTP Server (CVE-2021-41773)

Почему? Потому что в описании "If CGI scripts are also enabled for these aliased pathes, this could allow for remote code execution."

Но конечно Vulristics это не серебряная пуля и кроме ручного разбора публикаций об уязвимостях и эксплоитах тут ничего не придумаешь.

Также не могу не указать, что ещё для части уязвимостей Vulrisitcs определил типы уязвимостей более корректно в соответствии с описанием:

AA22-279A: GitLab CE/EE CVE-2021-22205 Remote Code Execution
Vulristics: Command Injection - GitLab (CVE-2021-22205) - Urgent [947]
"… which resulted in a remote command execution."

AA22-279A: Sitecore XP CVE-2021-42237 Remote Code Execution
Vulristics: Sitecore Experience Platform (XP) (CVE-2021-42237)
"… it is possible to achieve remote command execution on the machine."

AA22-279A: VMware vCenter Server CVE-2021-22005 Arbitrary File Upload
Vulristics: Remote Code Execution - VMware vCenter (CVE-2021-22005)
"…may exploit this issue to execute code on vCenter Server by uploading a specially crafted file."

AA22-279A: F5 Big-IP CVE-2022-1388 Remote Code Execution
Vulristics: Authentication Bypass - BIG-IP (CVE-2022-1388)
… undisclosed requests may bypass iControl REST authentication"

AA22-279A: Apache HTTP Server CVE-2021-41773 Path Traversal
Vulristics: Remote Code Execution - Apache HTTP Server (CVE-2021-41773)
"… this could allow for remote code execution."

AA22-279A: Apache CVE-2022-24112 Authentication Bypass by Spoofing
Vulristics: Remote Code Execution - Apache APISIX (CVE-2022-24112)
"… is vulnerable to remote code execution."

AA22-279A: Buffalo WSR CVE-2021-20090 Relative Path Traversal
Vulristics: Authentication Bypass - Buffalo WSR (CVE-2021-20090)
"… allow unauthenticated remote attackers to bypass authentication."

Поэтому не спешите доверять типу уязвимости из CISA Known Exploited Vulnerabilities Catalog и учитывать его при приоритизации.