Архив рубрики: Уязвимости

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

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

Joint advisory AA22-279A (2/4)

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

Joint advisory AA22-279A (2/4)

Joint advisory AA22-279A (2/4)

1. Уязвимые софты.

Если смотреть на список уязвимых софтов, то часть из них очевидно должны были попасть в этот репорт. В последнее время было очень много публикаций об использовании уязвимостей этих софтов в реальных атаках:

Apache HTTP Server
Apache Log4j2
GitLab
Microsoft Exchange
Confluence Server
Zoho ManageEngine ADSelfService Plus
Pulse Connect Secure

По софтам из другой группы тоже были публикации об атаках, но кажется они более нишевые и меньше воспринимаются как цели для злоумышленников (а зря):

BIG-IP
Citrix Application Delivery Controller
VMware vCenter
Cisco HyperFlex HX

И наконец есть достаточно экзотичные софты и продукты, видимо отражающие специфику американского IT:

Sitecore Experience Platform (XP)
Hikvision Web Server
Apache APISIX
Buffalo WSR

Joint advisory AA22-279A (3/4)

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

Joint advisory AA22-279A (3/4)

2. Vulristics определил все уязвимости как уязвимости наивысшего уровня критичности (Urgent). Для всех уязвимостей нашлись публичные эксплоиты.

При этом если смотреть по CVSS, то там такое:

All vulnerabilities: 20
Critical: 16
High: 4
Medium: 0
Low: 0

Если вы используете CVSS для приоритизации, не забывайте про уязвимости уровня High.

"Skybox Security представляют первое в отрасли решение SaaS для Security Policy и Vulnerability Management в гибридных средах"

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

"Skybox Security представляют первое в отрасли решение SaaS для Security Policy и Vulnerability Management в гибридных средах". Норм заголовок. Первое! Вот в Qualys и Tenable удивятся. У них-то не было SaaS решений для Security Policy и Vulnerability Management. И облака они оказывается не поддерживают. 😏 Бессмысленный и беспощадный маркетинг.

На что можно обратить внимание:

1. Skybox продолжают фокусироваться на сетевой доступности: "hybrid network modeling, path analysis, and automation".
2. Очередная модная аббревиатура от Gartner - Cyber Asset Attack Surface Management (CAASM) пошла в дело. В прошлый раз у нас тут проскакивал EASM.
3. Делают акцент на интеграции со сторонними API (150 интеграции) и рекомендациях по настройке ("automatically provides remediation options").
4. "Первое в отрасли решение для автоматического сопоставления уязвимостей с типом вредоносного ПО… программы-вымогатели, Remote Access Trojans (RAT), ботнеты, майнеры криптовалюты, трояны". Витает в воздухе тема, но публичных адекватных мапингов CVE на малварь пока нет. Поэтому хорошая дополнительная фича для коммерческих решений.

Отзывы клиентов, конечно, милота.

"They were getting burned out. So, this has changed at least one of my engineers' lives. He actually said it over and over, 'This is the best thing that's ever happened to me.' Had it been anyone else, I doubt we would have kept anyone in that position for long." – Information Security Manager, Financial Services Organization

День Рождения не был на праздник похож, был скучным, был грустным, безрадостным…

А как собственно изменилась работа с уязвимостями в 2022 году?

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

А как собственно изменилась работа с уязвимостями в 2022 году? Возвращаясь к названию исследования Positive Technologies. Как я вижу.

1. Раньше было страшно не успеть обновиться и получить инцидент с эксплуатацией уязвимости. Теперь ещё страшно обновиться и получить кирпич или бэкдор, потому что вендор решил прогнуться под геополитику. Эти страхи борются. Сейчас ситуация несколько стабилизировалась и первый страх побеждает. Что завтра будет неизвестно.
2. Замена ПО на стабильное (отечественное) выглядит как избавление от второго страха и возврат к более простому и надежному процессу. VM-щики могут этому способствовать, но их слово вряд ли будет решающим. Более значима позиция регуляторов, бизнеса и IT.
3. Переход на стабильное (отечественное) ПО совсем не обязательно будет простым с точки зрения VM. Есть сомнения в зрелости вендоров ПО. Заводят ли они уязвимости своих продуктов в БДУ? Выпускают ли бюллетени безопасности? Если не будет идентификаторов уязвимостей и бюллетеней, значит не может быть адекватной поддержки в VM решениях. Хотелось бы, чтобы регуляторы обращали на это внимание и выдвигали такие требования к сертифицированным решениях и решениям находящимся в реестрах.
4. С VM-решениями стало хуже. Западные вендоры официально ушли, продолжать использовать их решения теоретически можно, но сложно и они становятся менее эффективны с учетом перехода организаций на стабильное (отечественное) ПО, которое в западных VM-решениях не поддерживается. Для приобретения VM решения доступно сейчас 3-4 опции и стоимость у них отнюдь не как у Nessus Professional. Нужно раскошеливаться или проявлять изобретательность. А скорее и то, и другое.
5. Регуляторы начали уделять гораздо больше внимания исправлению уязвимостей в организациях. С информированием стало на порядок лучше. Не удивлюсь, если скоро мы увидим ещё и жесткий публичный ататат за неисправление уязвимостей, о которых было проинформировано, приведшее к серьезным инцидентам. С одной стороны ответственность растет, а с другой стороны и обосновывать важность VM-а становится гораздо проще.

Прочитал исследование Positive Technologies "Как изменилась работа с уязвимостями в 2022 году"

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

Прочитал исследование Positive Technologies Как изменилась работа с уязвимостями в 2022 году

Прочитал исследование Positive Technologies "Как изменилась работа с уязвимостями в 2022 году". Впечатления не очень. Компания мне родная. Особенно команда VM. Но тут вопросы не к ним, а к авторам этого исследования.

1. Мое мнение, что любая публикация про Vulnerability Management в России это здорово. Особенно если это исследование, а не рекламный проспект. Это порождает дискуссию, подсвечивает проблемные места и в конечном итоге улучшает качество продуктов и конкурентоспособность отечественных VM компаний.
2. В данном случае методология исследования вызывает вопросы. Публичный опрос на "сайте Positive Technologies, интернет-порталах, посвященных ИБ, в социальных сетях, тематических чатах и Telegram-каналах" с интерпретацией результатов автором отчета это не то, что хотелось бы видеть. Это делать дешево и просто, но при этом напрочь теряется контекст.
3. Формулировки вопросов странные. "Какие продукты вы используете для управления уязвимостями?" Множественный выбор. 43% "используют решения open-source". – Петька, приборы! – 20! – Чё "20"?! – А чё "приборы"? О чем здесь речь? Сканируют ли сетку nmap-ом? Используют опенсурсные утилиты для детекта уязвимостей? OpenVAS? OpenSCAP/Wazuh? Есть что-то достаточно хорошее опенсурсное для сканирования Windows? Может это не про детект, может просто результаты детекта в опенсурсный Faraday складывают?
4. Варианты ответов неполные. На вопрос "Где вы ищете информацию о новых уязвимостях?" получили аномалию, что БДУ ФСТЭК используют больше чем NVD. Переходим на отечественные источники! Как тебе такое Илон Маск?! Но в вариантах ответа нет важного в нашей стране источника данных об уязвимостях - бюллетеней регуляторов. Они как раз и содержат ссылки на БДУ. Может результаты показывают не то, что люди БДУшный фид анализируют, а то, что они реагируют на рассылки регуляторов и лезут потом в БДУ?
5. Формулировки выводов странные. "Проблемы с организацией патч-менеджмента остаются у каждого десятого респондента." А у 90% нет проблем с организацией патч-менеджмента? Все автоматом патчится-тестится, VM не нужен, расходимся?
6. Вопросы "как быстро вы это делаете ?" - просто песня. Это как, извините, в анекдоте про разницу в размерах у жителей в Вилариба и Вилабаджо. В одной деревне измеряли, а в другой опрашивали. Абстрактные уязвимости на абстрактных активах исправляются за какое-то время. Получили, что 75% опрошенных закрывают критически опасные уязвимости на важных активах за неделю и меньше! А в месяц укладываются 90%! При этом на фултайме VM-ом практически никто не занимается. "Какой процент рабочего времени занимают задачи специалиста по ИБ, связанные с VM?" Свыше 75% процентов только у 4% опрошенных. Удивительно!
7. Раздел "Какими возможностями должно обладать VM-решение для вашей компании?" норм. Важные фичи перечислены. Есть некое лукавство, очень уж они похожи на фичи и бэклог MaxPatrol VM, но это ладно. Если бы весь опрос был преимущественно в эту сторону и опрашиваемые могли предлагать свои варианты, то это могло быть любопытно.

Критикуешь - предлагай. Кажется правильным изменить методологию. Не опрашивать всех подряд. Работать адресно с людьми, которые специализируются на VM-е. Собрать экспертную группу. В рамках этой экспертной группы отобрать человек 50. Провести с ними полноценные интервью минут на 30. Задавать примерно те же вопросы, но получить развернутые ответы, а не выбор вариантов из опросника. В чем трудности VM-а? Что работает, что не работает? Спрашивать о фиксах конкретных актуальных уязвимостей, например Log4Shell или ProxyShell, как с ними справлялись? Как устроен процесс патчинга? Как патчатся неудобные активы: BIOS/UEFI, прошивки устройств и т.п.? Да, такие ответы будет сложнее и дороже анализировать. Но будет видна более-менее реальная картина. Возможно какие-то best practices можно будет сформулировать. Ну и вопросы, а затем и результаты, неплохо бы с экспертной группой провалидировать, чтобы исключить откровенные странности и ляпы.

Сейчас начинают потихоньку разгонять [1, 2] по поводу уязвимости macOS CVE-2022-32910

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

Сейчас начинают потихоньку разгонять [1, 2] по поводу уязвимости macOS CVE-2022-32910

Сейчас начинают потихоньку разгонять [1, 2] по поводу уязвимости macOS CVE-2022-32910. Прочитал исследование. Может я что-то не понял, но похоже из мухи слона делают. Описание-то прямо страшное: "Jamf Threat Labs recently discovered a new macOS vulnerability in Archive Utility that could lead to the execution of an unsigned and unnotarized application without displaying security prompts to the user, by using a specially crafted archive". Можно подумать, что скачал пользователь архив, кликнул по нему случайно и всё, похачен.

На самом деле там пишут про вот этот механизм macOS:

"Когда архив загружается из Интернета, он будет содержать расширенный атрибут com.apple.quarantine. Этот расширенный атрибут укажет macOS, что файл был загружен из удаленного источника и должен быть проверен, прежде чем будет разрешено его выполнение. Когда утилита архивирования извлекает архив, она применяет атрибут карантина ко всем извлеченным элементам. Это обеспечивает соответствующее распространение атрибута карантина и проверку Gatekeeper-ом любых открытых исполняемых файлов".

И вот простановку атрибута com.apple.quarantine (и проверку Gatekeeper) исследователи научились обходить.

"Когда пользователь загружает и запускает такой архив, он будет открыт Archive Utility в следующем виде. [картинка] Как мы видим, приложение не имеет атрибута карантина и, следовательно, будет обходить все проверки гейткипера, позволяя выполняться unnotarized a и/или неподписанным двоичным файлам."

То есть пользователь должен скачать архив и запустить оттуда зловредное приложение и тогда ему не дадут по рукам встроенные механизмы безопасности. Но возможно дадут по рукам какие-то другие механизмы безопасности.

В общем, уязвимость это? Уязвимость. Критикал ли это, который нужно срочно патчить? Ну вроде нет. Возможно повод научиться искать подобные архивы в почте.