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

Традиционный аудио/видео эпизод по итогам июльского Microsoft Patch Tuesday

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

Традиционный аудио/видео эпизод по итогам июльского Microsoft Patch Tuesday. В этом месяце получилось и уязвимости разобрать, и доработать Vulristics. 😇 В августе буду в основном всякими образовательными инициативами заниматься. 🤫 Следите за обновлениями. 🙂

------

Hello everyone! This episode will be about Microsoft Patch Tuesday for July 2023, including vulnerabilities that were added between June and July Patch Tuesdays.

Vulristics improvements
00:11 Works faster
01:31 Microsoft ADVs
02:45 Comments Table

TOP
04:09 Remote Code Execution – Microsoft Office (CVE-2023-36884)
05:06 Security Feature Bypass – Windows SmartScreen (CVE-2023-32049)
05:48 Security Feature Bypass – Microsoft Outlook (CVE-2023-35311)
06:37 Elevation of Privilege – Windows Error Reporting Service (CVE-2023-36874)
07:16 Elevation of Privilege – Windows MSHTML Platform (CVE-2023-32046)

Other RCEs
08:10 Remote Code Execution – Windows Active Directory Certificate Services (AD CS) (CVE-2023-35350)
09:01 Remote Code Execution – Microsoft Message Queuing (CVE-2023-32057, CVE-2023-35309)
09:44 Remote Code Execution – Windows Routing and Remote Access Service (RRAS) (CVE-2023-35365, CVE-2023-35366, CVE-2023-35367)
10:24 Remote Code Execution – Windows Layer-2 Bridge Network Driver (CVE-2023-35315)
10:57 Remote Code Execution – Microsoft SharePoint (CVE-2023-33134, CVE-2023-33157, CVE-2023-33159, CVE-2023-33160)
11:42 Remote Code Execution – Windows Pragmatic General Multicast (PGM) (CVE-2023-35297)

🎞 Video
🎞 Video2 (for Russia)
📘 Blogpost
🗒 Vulristics report

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

Про историю Vulnerability Management-а

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

Про историю Vulnerability Management-а. Иногда люди говорят публично что-то странное, но делают это настолько уверенно, что сам начинаешь в себе сомневаться. Вдруг они лучше знают? Ну или может ты их не так понял? Вот, например, посмотрел ролик "Traditional Vulnerability Management is Dead!" с Stefan Thelberg, CEO Holm Security. Это те ребята, которые считают, что без встроенного Антифишинга VM уже не VM.

В начале Stefan Thelberg заявляет про историю Vulnerability Assessment-а (Vulnerability Management-а) буквально следующее:

1. Оригинальная идея Vulnerability Assessment-а появилась в гайдлайнах NIST-а.
2. Прошло 20 лет и появились первые Vulnerability Assessment продукты.
3. Большая часть Vulnerability Assessment продуктов родились из опенсурсного проекта OpenVAS.
4. Один из наиболее распространенных продуктов на рынке, Nessus, это коммерческий форк OpenVAS.
5. Прошло ещё несколько лет и около 2000-го появилось несколько больших компаний: Rapid7, Tenable, Qualys.

То, что VA/VM родился из каких-то публикаций NIST-а не проверишь особо, организация в 1901 году основана, вполне вероятно что-то и было в 80х. Но заявление, что сначала был OpenVAS, а потом Nessus это очень странно. Первая версия The Nessus Project вышла в 1998 как GPL проект. Первая версия XSpider (тогда Spider) также появилась в 1998, а в 2000 он стал публично доступным. Компания Qualys была основана в 1999, Rapid7 в 2000, Tenable в 2002, Positive Technologies в 2002. Проект OpenVAS (GNessUs) появился не раньше 2005-го как форк последней опенсурсной версии Nessus-а, т.к. сам Nessus с 2005 года стал проприетарным продуктом Tenable.

Вот и думай теперь, то ли Stefan Thelberg говорит о том, о чем понятия не имеет. То ли он как-то странно называет OpenVAS-ом оригинальный Nessus 1998-го года. Но даже говорить, что другие VM продукты родились из Nessus-а или OpenVAS-а более чем странно, как минимум потому что другие продукты (Qualys, Rapid7 Nexpose, XSpider/MaxPatrol) не используют и не использовали NASL-скрипты, которые составляют основу Nessus. Может, конечно, у самих Holm Security движок это OpenVAS и они всех по себе меряют, не знаю. 😏

Немного про остальной ролик. Само обоснование почему традиционный VM уже не живой это отличный пример борьбы с "соломенным чучелом". Определяют "традиционный VM" так, как удобно. Что он, дескать, не поддерживает новые технологии (облака, IoT, SCADA). Добавляют свой спорный тезис, что обучение пользователей через Антифишинг это тоже обязательная часть VM. И дальше получившееся удобное "соломенное чучело" атакуют. Хотя чего бы "традиционному VM-у" не поддерживать все типы активов, которые в организации есть - непонятно. Да и какой-то проблемы прикрутить к VM-у Антифишинг, если так уж хочется, тоже нет.

Год с великого исхода западных вендоров: судьба специалиста

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

Год с великого исхода западных вендоров: судьба специалиста. С трудом уже верится, но раньше в РФ было возможно строить IT/ИБ системы, используя западные решения. 🙂 Более того, это был абсолютный мейнстрим. Как следствие, сотрудники российских компаний естественным образом развивались в крутых специалистов по продуктам Microsoft, Oracle, CISCO, PaloAlto, AWS, Tenable/Qualys/Rapid7 и т.д. 😉 Собирали комплекты вендорских сертификатов, выстраивали красивые CV-шки.

Безусловно, в этом была своя прелесть. Ты используешь те же решения, что и крупные компании во всем развитом мире, твои скилы также востребованы в общемировом масштабе. А значит релокация туда, где лучше, выглядит как вполне себе план Б (а у кого-то и как план А). Минусом шла привязка к западным вендорам и их судьбе в России. Но что с ними сделается-то? 😏

Однако оказалось, что сделаться может много чего и очень быстро. И перед российскими специалистами по решениям западных вендоров всерьез встал выбор:

- продолжать делать то, что делали, а значит релоцироваться туда, где можно продолжать строить системы на западных решениях;
- остаться и строить системы на тех решениях, которые остались/появились в РФ;
- остаться, перестать строить системы и принять участие в копировании западных решений.

Релокация это всегда мероприятие на любителя. Тем более сейчас, когда "жить на 2 страны" стало совсем не так просто и комфортно. Переезд на запад теперь выглядит скорее как дорога в один конец.

Остаться и развиваться в чем-то другом это и потеря конкурентных преимуществ, и необходимость быстро учиться новому, и переход в новый локальный контекст. Опыт с Яндекс Клауд и Астра Линукс безусловно менее универсален, чем с AWS и RHEL. 🙂 Это нужно осознать и принять.

Никого не осуждаю, у всех свои ситуации. Но милей мне, безусловно, оставшиеся. Мы в одной лодке, выгребем. 🛶 🙂

Доли мирового (Device) Vulnerability Management рынка на 2021 год по версии IDC

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

Доли мирового (Device) Vulnerability Management рынка на 2021 год по версии IDC

Доли мирового (Device) Vulnerability Management рынка на 2021 год по версии IDC. Сам отчет "Worldwide Device Vulnerability Management Market Shares, 2021: The Stakes Are High" (Ставки высоки!) вышел в декабре 2022 года и вы могли насладиться этими чарующими 13 страницами уже тогда за какие-то жалкие $4,500.00. 😏 Однако Tenable начали хвастаться своим первым местом в нем только сегодня. Видимо потому, что им только сегодня разрешили выложить бесплатный отрывок, включающий разделы: резюме, доля рынка, кто повлиял на год, контекст рынка, приложение и дополнительная информация. Почитаем, порефлексируем, прокомментируем. Пока же можно констатировать то, что большая тройка не поменялась, это всё ещё: Tenable, Qualys и Rapid7. В принципе и по ощущениям оно как-то так же.

Борьба со "слепыми пятнами" в базе знаний VM-решения от Qualys

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

Борьба со "слепыми пятнами" в базе знаний VM-решения от Qualys. Это и будет примером для п.3 из прошлого поста. Модуль называется Qualys Custom Assessment and Remediation (CAR). Идея следующая. Для детектирования уязвимостей Qualys использует в первую очередь легковесные "облачные агенты". Почему бы не дать возможность выполнять пользовательские скрипты на хостах посредством этих агентов? И эти скрипты связывать с идентификаторами уязвимостей и мисконфигураций (QIDs, CIDs), так чтобы с результатами этого кастомного детектирования можно было работать в рамках общего VM/CM процесса. Это в Qualys и сделали.

Причем это позиционируется не как компенсация для дырявой базы знаний Qualys, а как решение отдельной задачи "tactical security workflow". Т.е. это когда вам нужно добавить детект по-быстрому, а не ждать, когда он появится в VM-решении. А ещё для всяких самописных приложений ("custom in-house applications"), для которых иначе детектов вообще не было бы. В общем, трансформируют компенсацию недостатков в конструктив и позитив - мудро.

Скрипты можно писать на PowerShell, Python, Lua, Perl и Shell. Есть встроенная Script Testing Sandbox для тестирования перед запуском на хостах. Есть ролевая модель доступа к скриптам. Планируют интеграцию со сторонними репозиториями, включая Github, для упрощения разработки. Можно автоматизировать работу через API.

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

В целом, прикольная штука и кажется всем VM-вендорам есть смысл присмотреться. Из минусов, пока это касается только хостов с установленными агентами. Про сетевые устройства, например, никто не говорит. Хотя теоретически тоже можно было бы добавить возможность выполнения кастомных скриптов активным сканером.

Выпустил свои размышлизмы о том, что такое Zero Day уязвимость как отдельный эпизод с видяшкой на английском

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

Выпустил свои размышлизмы о том, что такое Zero Day уязвимость как отдельный эпизод с видяшкой на английском. На русском было тут.