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

На днях вышел бюллетень 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 и учитывать его при приоритизации.

Joint advisory AA22-279A (1/4)

Joint advisory AA22-279A (1/4)

Пожалуй хватит общих слов, давайте про уязвимости. 🙂 Очередная двадцатка уязвимостей от CISA, NSA и FBI. Joint cybersecurity advisory (CSA) AA22-279A. Не могут американцы просто выпустить список "20 уязвимостей через которые чаще всего ломают американские организации". Обязательно нужно вставить геополитику и указать на какую-то страну. Поэтому вопрос атрибуции атак оставляю без комментариев.

Но сами такие списки люблю по ряду причин:

1) Они показывают на какие CVE нужно обратить внимание. Это самое очевидное. Заметили такое в инфраструктуре - бегите исправлять.
2) Они показывают софты, за которыми нужно следить в первую очередь. А ваш сканер уязвимостей должен хорошо эти софты поддерживать.
3) Они показывают группы софтов, за которыми нужно следить в первую очередь. Обычно это то, что доступно широкому кругу пользователей или что неудобно обновлять.
4) Они показывают типы уязвимостей, на которые нужно обращать внимание в первую очередь.
5) Такие листы уязвимостей относительно компактные, их даже руками можно разобрать.

Не могу не отметить, насколько халтурно выполнен репорт. Описание уязвимостей подтянули автоматом с NVD. Включая такое: "Microsoft Exchange Server remote code execution vulnerability. This CVE ID differs from CVE-2021-26412, CVE-2021-26854, CVE-2021-26855, CVE-2021-26858, CVE-2021-27065, and CVE-2021-27078". Могли бы потрудиться и написать уникальный текст по каждой из 20 CVE-шек, ну правда. Joint advisory от трех серьезных организаций, но кажется всем настолько наплевать.

Исходный список:

1) Apache Log4j CVE-2021-44228 Remote Code Execution
2) Pulse Connect Secure CVE-2019-11510 Arbitrary File Read
3) GitLab CE/EE CVE-2021-22205 Remote Code Execution
4) Atlassian CVE-2022-26134 Remote Code Execution
5) Microsoft Exchange CVE-2021-26855 Remote Code Execution
6) F5 Big-IP CVE-2020-5902 Remote Code Execution
7) VMware vCenter Server CVE-2021-22005 Arbitrary File Upload
8) Citrix ADC CVE-2019-19781 Path Traversal
9) Cisco Hyperflex CVE-2021-1497 Command Line Execution
10) Buffalo WSR CVE-2021-20090 Relative Path Traversal
11) Atlassian Confluence Server and Data Center CVE-2021-26084 Remote Code Execution
12) Hikvision Webserver CVE-2021-36260 Command Injection
13) Sitecore XP CVE-2021-42237 Remote Code Execution
14) F5 Big-IP CVE-2022-1388 Remote Code Execution
15) Apache CVE-2022-24112 Authentication Bypass by Spoofing
16) ZOHO CVE-2021-40539 Remote Code Execution
17) Microsoft CVE-2021-26857 Remote Code Execution
18) Microsoft CVE-2021-26858 Remote Code Execution
19) Microsoft CVE-2021-27065 Remote Code Execution
20) Apache HTTP Server CVE-2021-41773 Path Traversal

Я конечно не отказал себе в удовольствии загнать список CVE-шек в свой Vulristics, чтобы посмотреть как он справится и подтюнить его при необходимости.

$ python3.8 vulristics.py --report-type "cve_list" --cve-project-name "AA22-279A" --cve-list-path joint_cves.txt --cve-data-sources "ms,nvd,vulners,attackerkb" --cve-comments-path comments.txt --rewrite-flag "True"

Отчет здесь: https://avleonov.com/vulristics_reports/aa22-279a_report_with_comments_ext_img.html

Дальше будут некоторые комментарии про то, что в итоге получилось.