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

Выпустил новую англоязычную видяшечку

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

Выпустил новую англоязычную видяшечку. Так получилось, что за последний год мой англоязычный блог (а вместе с ним и ютюб канал, и подкаст) окончательно свёлся к ежемесячным обзорам Microsoft Patch Tuesday. 🤷‍♂️🤦‍♂️ А остальной контент оседал только в моих телеграмм-каналах @avleonovcom и @avleonovrus. В основном, конечно, в русскоязычном. Постараюсь эту тенденцию переломить. Теперь буду выпускать один англоязычный эпизод по итогам месяца без особого фокуса на Patch Tuesday. Так должно быть поадекватнее и повеселее. 🙂

Подумывал делать эпизоды и на русском тоже, но решил не браться, т.к. получается двойная работа. Автоматический перевод яндекс-браузером могу порекомендовать только для смеха (например, отдельностоящее "CVЕ" распознает как "CV" и переводит как "резюме"). Но планирую тащить новости из канала на обсуждение в Прожектор по ИБ. Так что русскоязычные видяшки тоже в каком-то виде будут. 🙂
___

Hello everyone! This month I decided NOT to make an episode completely dedicated to Microsoft Patch Tuesday. Instead, this episode will be an answer to the question of how my Vulnerability Management month went. A retrospection of some kind.

GitHub exploits and Vulristics
00:44 PoC in Github
02:19 Vulristics vulners-use-github-exploits-flag

VM vendors updates
04:39 Qualys First-Party Application Risk Detection and Remediation
06:18 Tenable ExposureAI
07:23 SC Awards and Rapid7

Vulnerabilities
09:04 Anglo-Saxon vulnerability lists AA23-215A
12:32 August Microsoft Patch Tuesday
14:40 WinRAR Extension Spoofing (CVE-2023-38831)
15:16 Juniper RCE (CVE-2023-36844)

📘 Blogpost
🎞 Video
🎞 Video2 (for Russia)

Почему участники багбаунти нашли в прошлом году 65 тысяч уязвимостей, а CVE зарегистрировано за это время только 25 тысяч?

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

Почему участники багбаунти нашли в прошлом году 65 тысяч уязвимостей, а CVE зарегистрировано за это время только 25 тысяч?

Почему участники багбаунти нашли в прошлом году 65 тысяч уязвимостей, а CVE зарегистрировано за это время только 25 тысяч? Подсмотрел занимательный вопрос в канале Алексея Лукацкого.

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

С другой стороны, есть мобильные приложения, которые тоже часто попадают в скоуп багбаунти. А у мобильного приложения уже есть версия и пользователи могут использовать разные версии мобильного приложения. И, получается, для мобильных приложений уже может быть смысл заводить CVE.

В принципе, ничего не мешает сделать багбаунти программу вообще для любых приложений. Например, на hackerone есть багбаунти для Chrome/Chromium. И для этих уязвимостей Google заводит CVE. Ничего не запрещает самому вендору заводить CVE под найденные в рамках багбаунти уязвимости кроме нежелания этого вендора.

И не сказать, что это требует каких-то особенных усилий со стороны вендора, т.к. сама багбаунти платформа может заводить CVE уязвимости для своих клиентов. В списке CVE Numbering Authority (CNA) есть 11 организаций типа "Bug Bounty Provider", включая Bugcrowd, HackerOne, ZDI:

"Provides CVE IDs for its customers as part of its bug bounty and vulnerability coordination platform"

В общем, уязвимостей меньше, потому что не для всех уязвимостей есть смысл заводить CVE. А для тех уязвимостей, для которых смысл есть, CVE идентификаторы не заводят, т.к. сам вендор уязвимого продукта этого не хочет. 🤷‍♂️ А сам исследователь хоть и может добиться заведения CVE идентификатора помимо воли вендора, но это не массовая история.

PS: хороший вопрос для собеседования VM-щиков 😉

Ещё про PoC in GitHub

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

Ещё про PoC in GitHub

Ещё про PoC in GitHub. Вот я написал, что CVE-2023-36884 там есть. Но если присматриваться, то всё не так радужно. 😐 Давайте разберём.

❌ Maxwitat/CVE-2023-36884-Scripts-for-Intune-Remediation-SCCM-Compliance-Baseline - скрипт для ремедиации
❌ deepinstinct/Storm0978-RomCom-Campaign - IOC-и
❌ zerosorai/CVE-2023-36884 - утилита для ремедиации
❌ tarraschk/CVE-2023-36884-Checker - скрипт для детектирования уязвимости
❌ or2me/CVE-2023-36884_patcher - утилита для ремедиации
❌ ToddMaxey/CVE-2023-36884 - скрипт для ремедиации
❌ ridsoliveira/Fix-CVE-2023-36884 - скрипт для ремедиации
❌ raresteak/CVE-2023-36884 - информация для ремедиации

Пока нет там никакого POC-а. 🤷‍♂️

Т.е. "PoC in GitHub" было бы уместнее называть "CVE mentions in GitHub". Упоминания CVE-шек он подсветит, но контекст, разумеется, не покажет. Дальше только ручной анализ или какая-то хитрая автоматизированная классификация находок.

Посмотрел на гитхабе репозиторий PoC in GitHub

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

Посмотрел на гитхабе репозиторий PoC in GitHub

Посмотрел на гитхабе репозиторий PoC in GitHub. Там содержатся результаты автоматизированного поиска эксплоитов для CVE уязвимостей на GitHub. В настоящий момент там PoC-и для 4484 CVE идентификаторов. Выборочно проверил, вроде ок. Например, RCE уязвимость Office (CVE-2023-36884) из последнего Patch Tuesday там есть.

Распределение по годам:

CVE-1999-*: 4
CVE-2000-*: 4
CVE-2001-*: 10
CVE-2002-*: 14
CVE-2003-*: 6
CVE-2004-*: 9
CVE-2005-*: 7
CVE-2006-*: 13
CVE-2007-*: 18
CVE-2008-*: 21
CVE-2009-*: 22
CVE-2010-*: 25
CVE-2011-*: 27
CVE-2012-*: 39
CVE-2013-*: 64
CVE-2014-*: 128
CVE-2015-*: 144
CVE-2016-*: 185
CVE-2017-*: 323
CVE-2018-*: 407
CVE-2019-*: 504
CVE-2020-*: 684
CVE-2021-*: 747
CVE-2022-*: 739
CVE-2023-*: 340

Растёт общее число CVE-шек, растет и число эксплуатабельных CVE-шек. ⤴️ При этом никто не даёт гарантии, что PoC-и рабочие и что там нет рикролов или малварей. Будьте осторожны.

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

Американская микроблоггинговая площадка с птичкой перестаёт быть местом для сбора релевантной инфы по CVE-шкам

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

Американская микроблоггинговая площадка с птичкой перестаёт быть местом для сбора релевантной инфы по CVE-шкам

Американская микроблоггинговая площадка с птичкой перестаёт быть местом для сбора релевантной инфы по CVE-шкам.

1. В конце июня - начале июля количество сообщений с CVE сократилось с 1272 в рабочий день до 333 в рабочий день. А если не считать ботов, то, в среднем, с 500 в день до 66 в день. Видимо ИБ-шники куда-то мигрировали. Хотя возможно и просто сезонное.
2. Возможность бесплатного экспорта сообщений (в т.ч. с CVE-шками) убрали. 🤷‍♂️

Имхо, это очень даже позитивно. Нечего пользоваться замусоренными мейнстримными соцсеточками для обсуждения ИБ-вопросов, нужно формировать что-то специализированное, а-ля Peerlyst.

HTML код в NVD CVE description

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

HTML код в NVD CVE description

HTML код в NVD CVE description. Работаю сейчас над оптимизациями для детектирования уязвимого продукта и типа уязвимости по текстовому описанию в Vulristics. В процессе обнаружил вот такое. Спасибо, конечно, что не

Первоначальные намётки по открытому фиду с уязвимостями - проект Vulrectory (пока пустой)

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

Первоначальные намётки по открытому фиду с уязвимостями - проект Vulrectory (пока пустой). По этому проекту хотелось бы в идеале получить обновляемый фид со всеми уязвимостями из NVD и БДУ, содержащий некоторые дополнительные поля, чтобы его можно было использовать как единственный источник данных в Vulristics. Сейчас если с помощью Vulristics приоритизировать, допустим, 100 CVE, то утилита будет делать запросы по каждой из этих CVE к различным источникам (как к бесплатным, так и к платному - Vulners), а затем комбинировать и анализировать данные. Таким образом, будут использоваться наиболее свежие данные, но генерация полного отчета займет довольно много времени. А за большое количество запросов бесплатные источники могут и побанить. Если же будет свой источник с уже подготовленными данными, который можно будет локально выкачать к себе, то можно будет запросто строить отчеты по десяткам тысяч уязвимостей без каких-либо внешних запросов. Сразу появится множество применений:

1. Оценка и приоритизация продетектированных уязвимостей (как для отдельных хостов, так и для инфраструктуры в целом!).
2. Оценка расхождений в результатах детектирования уязвимостей VM-продуктами и слепых пятен в базах знаний (детектов) VM-продуктов.
3. Vulnerability Intelligence - анализ всего входящего потока уязвимостей. Возможно с фокусом только на тех продуктах, которые используются в организации и без привязки к детектам в VM-решении.

В общем, как только можно будет работать с готовыми данными в оффлайне, всё сразу становится гораздо интереснее и удобнее. 😉

Какие дополнительные поля нужны Vulristics:

• Название уязвимого софта. Планирую переиспользовать детект продуктов по ключевым словам на основе описания CVE, который сейчас используется в Vulristics. Но лучше добавить ещё детект на основе CPE и парсинг генеренных описаний уязвимостей "имя софта> тип уязвимости>" (как у Microsoft). Также имя софта можно напрямую забирать из БДУ.
• Тип уязвимости. Планирую переиспользовать детект типа уязвимости по ключевым словам на основе описания CVE, который сейчас используется в Vulristics. Но лучше добавить ещё детектирование на основе CWE. Но это на крайний случай, т.к. к простановке CWE идентификаторов в NVD были вопросы.
• Наличие эксплоита. Если мы хотим, чтобы Vulrectory был бесплатным, то придется видимо ограничиться ссылками на эксплоиты из NVD и флажком "Наличие эксплойта" из БДУ. 🤷‍♂️ В Vulners их будет, конечно, гораздо больше (как вариант делать платную PRO версию?). Возможно есть какие-то открытые базы с признаками наличия эксплоитов на том же GitHub-е - нужно ресерчить.
• Признак эксплуатации вживую. Тут также видимо придется ограничиться бесплатным источником - CISA KEV и ресерчить наличие открытых источников по фактам эксплуатации.

В рамках этого же проекта можно для уязвимостей отображать не только CVSS, но и вектор/скор OSOKA (только Базовые и Эксплуатационные метрики, конечно). 🙂

В общем, пока какие-то такие мысли. Как вам?