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

25 лет CVE: кто базу CVEшек анализировал, тот в цирке не смеётся

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

25 лет CVE: кто базу CVEшек анализировал, тот в цирке не смеётся

25 лет CVE: кто базу CVEшек анализировал, тот в цирке не смеётся. В январе 1999 года Дэвид Э. Манн и Стивен М. Кристи опубликовали статью "К единому перечислению уязвимостей" ("Towards a Common Enumeration of Vulnerabilities"), в которой предлагалось создать лист Common Vulnerability Enumeration, CVE (заметьте, в оригинале никаких "экспозиций" 😉), целью которого было бы:

🔻 нумеровать и различать все известные уязвимости
🔻 назначать стандартное уникальное имя каждой уязвимости
🔻 существовать независимо от множественных точек зрения на то, что такое уязвимость
🔻 являться публично "открытым", распространяемым без ограничений

В октябре 1999 года корпорация MITRE представила первый CVE лист, в котором была 321 запись. За 25 лет их количество перевалило за 250 000 идентификаторов (без Rejected). Количество новых CVE каждый год ставит рекорды, в этом году ожидается больше 35 000. В основном такой бешеный прирост обеспечивают организации со статусом CNA, которых уже 221. Они, получив заветный статус, могут заводить CVE на любую дичь. Хоть весь свой багтреккер пихать, как Linux Kernel. 😏

Во многом из-за такого прироста (ну и из-за приколов американской бюрократии) процесс по анализу уязвимостей в NIST NVD в 2024 году дал масштабный сбой, фактически остановился. Несмотря на все меры (включая финансовые), он так толком и не восстановился. NVD месяц от месяца анализирует значительно меньше CVE, чем получает от CVEorg. Бэклог на анализ растёт, и составляет 19 174 CVE. 🫣

Не такая беда, что база замусорена и не анализируется в должной степени. Настоящая беда в том, что она при этом ещё и неполна. Серьёзные уязвимости, обнаруженные российскими или китайскими исследователями могут не приниматься из-за каких-то геополитических соображений и они фиксируются только в национальных базах уязвимостей. 🤷‍♂️

Вот такой итог 25 лет. Вместо единой нейтральной базы пришли к стремительно растущему недоанализированному огороженному западному мусорному полигону. В котором приходится всем миром копаться, потому что ничего лучше всё равно нет. 🙄 Круто, чё. С юбилеем!

CVE-идентификаторы с пробелом в OVAL-контенте RedOS

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

CVE-идентификаторы с пробелом в OVAL-контенте RedOS

CVE-идентификаторы с пробелом в OVAL-контенте RedOS. В ходе подготовки отчёта по октябрьскому Linux Patch Wednesday обнаружил, что у меня откуда-то лезут невалидные CVE-идентификаторы с пробелом в конце. Источником оказался OVAL-контент RedOS (7.6 мб). По находится 115 таких проблемных ссылок на CVE. Вряд ли это ошибки при ручном заполнении, видимо ошибка в последних версиях генератора OVAL-контента.

Если вы используете OVAL-контент RedOS, обратите внимание, что такое может быть и потенциально может аффектить Vulnerability Management процесс.

Просьба коллегам из РЕД СОФТ пофиксить проблему и накрутить тесты, что используемые CVE-идентификаторы матчатся регуляркой.

Upd. Коллеги из РЕД СОФТ быстро отреагировали и проблему исправили. 🙂👍

Microsoft будут заводить CVEшки для уязвимостей своих облачных сервисов

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

Microsoft будут заводить CVEшки для уязвимостей своих облачных сервисов

Microsoft будут заводить CVEшки для уязвимостей своих облачных сервисов. Казалось бы, ну была уязвимость в какой-то облачной CRM-ке, они её зафиксили сразу для всех, никаких действий со стороны клиентов не требуется. Толку-то на это CVE заводить? 🤔

Но в Microsoft считают, что это требуется для большей прозрачности, а новые правила CNA (CVE Numbering Authorities) требуют заводить уязвимости, которые могут нанести существенный вред, независимо от того требуется ли клиентам совершать какие-то действия для устранения уязвимостей или нет. 🤷‍♂️ Microsoft обещают помечать такие уязвимости отдельно, как например CVE-2024-35260 "The vulnerability documented by this CVE requires no customer action to resolve". В CVEorg тоже будет специальный tag.

Нужно или не нужно заводить уязвимости облачных сервисов как CVE - вопрос спорный. Но то, что из-за этой практики количество идентификаторов в CVEorg/NVD станет прирастать гораздо быстрее - факт. 🤷‍♂️

Идея на миллион хамстер-коинов

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

Идея на миллион хамстер-коинов

Идея на миллион хамстер-коинов. 🐹😅 Делаем сайт/апп, на котором можно тапать CVE-шки. Но тапать будет иметь смысл не все CVE, а только те, у которых в течение следующей недели должен появиться подтверждённый эксплоит или признак эксплуатации вживую.

🪙 Когда такой признак или эксплоит действительно появляется, отсыпать коинов тем, кто за последнюю неделю тапал на эту уязвимость. Соразмерно количеству тапов, критичности уязвимости и т.п.

📈 А на основе анализа этих тапов делать прогнозы по эксплуатабельности уязвимостей. С помощью AI естественно.

Уверен, что работать такое будет всяко лучше EPSS и гадалкам по соцсетям. 😅

После продолжительного перерыва выпустил англоязычную видяшку и блогопост

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

После продолжительного перерыва выпустил англоязычную видяшку и блогопост. Разбираю там то, что произошло за последние 3 месяца. В первую очередь в плане улучшений Vulristics. Во вторую - смотрю какие были интересные уязвимости в Microsoft Patch Tuesday, Linux Patch Wednesday и из остальных. Ну и подвожу итоги 2023, а также намечаю направления работы на 2024.

Из занимательного:

🔻 Подсветил 7 уязвимостей из Microsoft Patch Tuesday, для которых за последние 3 месяца появились PoC-и/эксплоиты. Как правило это совсем не те уязвимости, на которые указывали VM-вендоры в своих обзорах. 😏
🔻 В Linux Patch Wednesday за последние 3 месяца было 90 уязвимостей с PoC-ами/эксплоитами (и это не считая тех, про которые известно, что они в активной эксплуатации). 🙈

Постараюсь по англоязычным блогопостам с видяшками вернуться в ежемесячный режим. 😇 Формат хоть и муторный, но полезный.

———

November 2023 – January 2024: New Vulristics Features, 3 Months of Microsoft Patch Tuesdays and Linux Patch Wednesdays, Year 2023 in Review

Hello everyone! It has been 3 months since the last episode. I spent most of this time improving my Vulristics project. So in this episode, let’s take a look at what’s been done.

Also, let’s take a look at the Microsoft Patch Tuesdays vulnerabilities, Linux Patch Wednesdays vulnerabilities and some other interesting vulnerabilities that have been released or updated in the last 3 months. Finally, I’d like to end this episode with a reflection on how my 2023 went and what I’d like to do in 2024.

New Vulristics Features
00:32 Vulristics JSON input and output
02:37 CPE-based vulnerable product names detection
04:16 CWE-based vulnerability type detection

3 Months of Vulnerabilities
07:03 Linux Patch Wednesday
11:22 Microsoft Patch Tuesdays
13:59 Other Vulnerabilities

16:14 About the results of 2023
18:45 What about 2024?

📘 Blogpost
🎞 VKVideo

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

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

Выпустил новую англоязычную видяшечку. Так получилось, что за последний год мой англоязычный блог (а вместе с ним и ютюб канал, и подкаст) окончательно свёлся к ежемесячным обзорам 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-щиков 😉