Архив рубрики: Темы

Выпустил блогопост и видяшку по апрельскому Micorosoft Patch Tuesday Vulristics для англоязычного канала и блога

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

Выпустил блогопост и видяшку по апрельскому Micorosoft Patch Tuesday Vulristics для англоязычного канала и блога. По сравнению с первыми впечатлениями добавились Microsoft Word RCE (CVE-2023-28311) с эксплоитом и Windows Pragmatic General Multicast (PGM) RCE (CVE-2023-28250) похожая на QueueJumper RCE в MSMQ. Также добавил много RCE в Windows DNS Server, но что-то определенное по ним сказать сложно.

Critical
00:50 Elevation of Privilege - Windows Common Log File System Driver (CVE-2023-28252)
01:44 Remote Code Execution - Microsoft Word (CVE-2023-28311)

Other
02:18 Remote Code Execution - Microsoft Message Queuing (CVE-2023-21554) (QueueJumper)
03:17 Remote Code Execution - Windows Pragmatic General Multicast (PGM) (CVE-2023-28250)
04:05 Lots of CVEs Remote Code Execution – Microsoft PostScript and PCL6 Class Printer Driver (CVE-2023-24884, CVE-2023-24885, CVE-2023-24886, CVE-2023-24887, CVE-2023-24924, CVE-2023-24925, CVE-2023-24926, CVE-2023-24927, CVE-2023-24928, CVE-2023-24929, CVE-2023-28243)
04:24 Lots of CVEs Remote Code Execution – Windows DNS Server (CVE-2023-28254, CVE-2023-28255, CVE-2023-28256, CVE-2023-28278, CVE-2023-28305, CVE-2023-28306, CVE-2023-28307, CVE-2023-28308)
04:32 Remote Code Execution - DHCP Server Service (CVE-2023-28231)

Video: https://youtu.be/aLt5k18jOwY
Video2 (for Russia): https://vk.com/video-149273431_456239123
Blogpost: https://avleonov.com/2023/04/28/microsoft-patch-tuesday-april-2023-clfs-eop-word-rce-msmq-queuejumper-rce-pcl6-dns-dhcp/
Vulristics report: https://avleonov.com/vulristics_reports/ms_patch_tuesday_april2023_report_with_comments_ext_img.html

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

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

Год с великого исхода западных вендоров: судьба специалиста. С трудом уже верится, но раньше в РФ было возможно строить 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. В принципе и по ощущениям оно как-то так же.

Про сканер уязвимостей в Yandex Cloud

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

Про сканер уязвимостей в Yandex Cloud

Про сканер уязвимостей в Yandex Cloud. На днях были новости, что Yandex открыл доступ к своему сканеру уязвимостей. Из этих новостей было не очень понятно что за сканер, для чего сканер. Но я нашел первоисточник - блогопост на сайте Яндекс Клауда.

1. Речь о сканере для Docker-образов, интегрированный в сервис Yandex Container Registry. Это аналог Aqua Trivy, Clair, Falco, Docker scan. Ну и моего Scanvus-а. 🙂 И видимо имеется ввиду Сканер уязвимостей описанный в документации, поддерживающий Alpine, CentOS, Debian, Redhat, Ubuntu в качестве ОС, на которых могут быть собраны пользовательские Docker-образы.

2. В чем преимущество: "Чтобы использовать сканер уязвимостей Yandex Cloud, не требуется выделять дополнительную инфраструктуру, обслуживать её, заниматься разворачиванием и поддержкой продукта или глобально менять процесс выкладки кода. "

3. Описание сканера частично понятно, детект по пакетам: "по результатам сканирования образа пользователь получает отчёт об уязвимостях, обнаруженных в конкретных пакетах ОС, и о версиях этих пакетов с исправлениями, если такие имеются". А то, что понимается под "сканер уязвимостей с использованием статического анализа" - загадочно.

4. Уровни сканирования: реестра целиком и выбранных репозиториев. Сканирование отдельных образов и фильтрации по тегам пока нет, но обещают.

5. Сколько стоит: "Первые шесть первичных и шесть последующих сканирований бесплатны. Начиная с седьмого раза нужно будет платить: за каждое первичное — 13,2 рубля, а за последующее — 7,2 рубля."

Ещё раз про EPSS Probability и EPSS Percentile

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

Ещё раз про EPSS Probability и EPSS Percentile

Ещё раз про EPSS Probability и EPSS Percentile. В одной соцсеточке для профессионального общения от компании Microsoft меня увещевают отказаться от ереси и все-таки использовать EPSS Probability в Vulristics вместо EPSS Percentile. 🙂 Кажется имеет смысл продолжить тему.

1. Про разницу между Probability и Percentile, как их понимать и интерпретировать, есть подробная статья на официальном сайте. Вопрос: можно ли как-то получить из EPSS уровни критичности а-ля CVSS Base Score. Ответ: нет, нельзя. "По этим причинам EPSS в настоящее время не группирует результаты EPSS с использованием ярлыков" ("For these reasons, EPSS does not currently bin EPSS scores using labels"). В своём праве.

2. То, что они генерят в виде EPSS Probability, "вероятности эксплуатации", это просто очень маленькие цифири из нейронки, которые непонятно как сравнивать адекватно. Они даже в тех примерах, которые я рассматривал, маленькие. EPSS-ники сами об этом пишут в статье "Например, как пользователи должны интерпретировать общую важность (overall importance) уязвимости с вероятностью 0,212? Или, по-другому, как мы должны думать о сравнении относительной разницы в угрозе между вероятностью 0,115 и 0,087? Да, одна больше другой, но насколько больше? Насколько велика разница в угрозе первой уязвимости по сравнению со второй?" Для прошлого Patch Tuesday EPSS Probability для всех уязвимостей, была между 0 и 0.2 (0-20%). Даже для уязвимостей с отмеченной эксплуатацией в CISA KEV! Это с каким же весом мне надо брать эти значения, чтобы они хоть как-то влияли на итоговый скор? 🙂

3. Ну да, EPSS Percentile это результат ранжирования уязвимостей по EPSS Probability, величина искусственная и зависит от общего числа CVE. И она меняется со временем, так же как и EPSS Probability. Ну так и в чем проблема? EPSS Percentile это тоже какая-то искусственная величина из нейронки полученная. По EPSS Percentile хотя бы видно как эта нейронка оценивает конкретную уязвимость относительно всех остальных. То, что нам собственно и надо. 😉 И тут более-менее понятно, есть 0.8-1, то критично, а если 0-0.2 это фигня какая-то. Ну, в идеале. Потому что на практике, как я уже подсвечивал, бывают странности.

Добавил учёт EPSS в Vulristics

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

Добавил учёт EPSS в VulristicsДобавил учёт EPSS в Vulristics

Добавил учёт EPSS в Vulristics. EPSS стал ещё одним источником данных, т.е. команда для анализа набора CVE будет выглядеть так: 

$ python3 vulristics.py --report-type "cve_list" --cve-project-name "New Project" --cve-list-path "analyze_cve_list.txt" --cve-comments-path "analyze_cve_comments.txt" --cve-data-sources "ms,nvd,epss,vulners,attackerkb" --rewrite-flag "True"

Добавление нового источника задача несложная. Сделал по аналогии с NVD. Однако возник вопрос: какое именно значение EPSS использовать. Было 2 варианта:

1. Probability - вероятность наблюдения эксплуатации уязвимости в течение следующих 30 дней ("probability of observing exploitation activity in the next 30 days").

2. Percentile - значение показывающее насколько вероятность наблюдения эксплуатации данной CVE уязвимости больше чем для всех других CVE уязвимостей. Например, вероятность EPSS, равная всего 0,10 (10%), находится примерно на уровне 88-го процентиля, что означает, что 88% всех CVE имеют более низкую оценку ("For example, an EPSS probability of just 0.10 (10%) rests at about the 88th percentile — meaning that 88% of all CVEs are scored lower").

В итоге опытным путем пришел к тому, что Probability слишком малы, а также мало различаются, поэтому лучше использовать Percentile.

Я перегенерил отчет для апрельского MS Patch Tuesday.

1. Старый отчет без EPSS
2. Новый отчет с EPSS

Выглядит довольно неплохо, но со странностями. Так наиболее критичная Elevation of Privilege - Windows Common Log File System Driver (CVE-2023-28252), которая присутствует в CISA KEV почему-то имеет очень низкий EPSS. 🤷‍♂️ Поэтому результат нейронки это, конечно, хорошо, но здравый смысл терять не нужно. 😉

Насчёт количества CVEшек в NVD и БДУ ФСТЭК

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

Насчёт количества CVEшек в NVD и БДУ ФСТЭК. Годы летят и обычно не задумываешься насколько быстро растет реестр NVD CVE. А ведь там действительно 212793 идентификаторов на текущий на текущий момент. 😱 Я вполне помню момент, когда их было 50к. 🙂

Что, реально так много? Не ошибка? Нет, похоже всё правильно: 


$ for i in `seq 2002 2023`; do wget https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-$i.json.zip; done
$ zcat nvdcve-1.1-*  | grep '"ID" : "CVE-[0-9]*-[0-9]*"' | sort | uniq | wc -l
212793

Для интереса посмотрел, а сколько ссылок на CVE есть в БДУ ФСТЭК: 


$ wget --no-check-certificate https://bdu.fstec.ru/files/documents/vulxml.zip
$ unzip vulxml.zip
$ cat export/export.xml | egrep -o "CVE-[0-9]*-[0-9]*" | sed 's/\/identifier>//g' | sort | uniq | wc -l
37757

Можем видеть, что сильно меньше. О причинах судить не берусь, но точно можно сказать, что воспринимать БДУ просто как downstream NVD неправильно. Туда попадает, мягко говоря, не всё, что есть в NVD. В прочем, в NVD тоже есть не всё, что есть в БДУ.