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

Детект типа уязвимости по CWE в Vulristics

Детект типа уязвимости по CWE в Vulristics

Детект типа уязвимости по CWE в Vulristics. Теперь Vulristics может детектировать тип уязвимости не только по ключевым словам (выражениям), но и по CWE идентификаторам из NVD. Для каждого типа уязвимости в Vulristics можно указать набор соответствующих CWE идентификаторов. Некоторые CWE идентификаторы я уже таким образом смапил на типы уязвимостей Vulristics. Но, разумеется, не все. Всего CWE идентификаторов больше 600! Буду добавлять их по мере необходимости.

Кроме того, я сделал следующие изменения в детектах типов уязвимостей в Vulristics:

🔹 Добавил новый тип уязвимости Incorrect Calculation для массовых некритичных уязвимостей, которые не связаны с памятью (и поэтому не попадают в Memory Corruption). Например, "Divide By Zero" или "Integer Overflow". Фактически такие уязвимости являются просто багами, т.к. из описания непонятно как злоумышленник может их эксплуатировать. Если они приводят к падению приложения или к RCE, то почему бы про это не написать? А если не приводят, то в чём тогда беда? Как по мне, лучше бы для таких проблем вообще не заводили CVE. Но по факту их заводят. И особенно часто для Linux. Поэтому и детектировать тип для таких "уязвимостей" приходится. Теперь они будут валиться в Incorrect Calculation с относительно невысокой критичностью (такой же как у Memory Corruption).
🔹 Меня начали подбешивать Path Traversal уязвимости, которые по факту дают злоумышленнику возможность читать и писать произвольные файлы. 🤷‍♂️ Поэтому для таких уязвимостей буду использовать типы Arbitrary File Reading (уже была) и Arbitrary File Writing (новая).
🔹 Подкрутил веса для типов уязвимостей. Логика такая: чем более конкретен тип и чем более понятно как этот тип уязвимости может использоваться злоумышленником, тем больше вес. Но вещь это, конечно, крайне субъективная и я её, скорее всего, буду подкручивать ещё много раз. В моменте выглядит так:

Remote Code Execution 1.0
Code Injection 0.97
XXE Injection 0.97
Command Injection 0.97
Authentication Bypass 0.95
Arbitrary File Writing 0.95
Security Feature Bypass 0.90
Elevation of Privilege 0.85
Information Disclosure 0.83
Arbitrary File Reading 0.83
Cross Site Scripting 0.8
Open Redirect 0.75
Path Traversal 0.7
Denial of Service 0.7
Memory Corruption 0.5
Incorrect Calculation 0.5
Spoofing 0.4
Tampering 0.3
Unknown Vulnerability Type 0

Сейчас кажется, что XSS и Open Redirect низковаты. Но, с другой стороны, они в большей степени на социалку завязаны, так что может и норм. 🤔 В любом случае, тип уязвимости хоть и влияет достаточно сильно на итоговую критичность, но в меньшей степени чем наличие эксплоита и признак эксплуатации вживую.

Кроме детектирования типа уязвимости по CWE, я также оптимизировал сочетание детектирования имени уязвимого продукта по CPE и по ключевым словам (выражениям). Если кратко, то сначала приоритет отдается имени продукта непосредственно заданному в источнике данных, затем имени продукта определенному эвристически из шаблонного описания (для Microsoft), затем имени продукта определенному по ключевым словам (выражениям), затем имени продукта определенному по идентификаторам CPE. В CPE-детектах отдаём наивысший приоритет первому идентификатору типа a (application), если его нет, то h (hardware), если и его нет, то о (operating system).

Для демонстрации я перегенерил последние Linux Patch Wednesday отчёты:

🗒 Ноябрьский LPW
🗒 Декабрьский LPW

Довёл их практически до идеального состояния. Название продукта и тип уязвимости НЕ детектируются только для заглушек "This candidate has been reserved…" и уязвимостей с таким странным описанием, что даже ручной их разбор весьма затруднен.

В общем, праздничные дни прошли весьма плодотворно, доволен. 😇

NVD включили заднюю в вопросе отключения CVE-фидов

NVD включили заднюю в вопросе отключения CVE-фидов

NVD включили заднюю в вопросе отключения CVE-фидов. Раньше обещали отключить генерацию архивов, содержащих JSON-файлы со всеми CVE-шками, 15 декабря 2023. Теперь пишут, что отключать пока не будут и по сути признают то, что:

🔹 массовая выгрузка CVE-шек оказалась нужна множеству потребителей
🔹 актуальная версия API-шки эффективно делать это не позволяет

Будут улучшать возможности массовой выгрузки данных из NVD через API, а пока этого не сделают, оставят генерацию файликов с выгрузками как есть.

Ура-ура, маленькая победа здравого смысла! 🎉

Это внушает небольшую надежду на то, что активности по фактическому ограничению доступа к данным NVD были вызваны не сознательной политикой, а обычной глупостью.

Колядка про Vulnerability Management "Пропатчите уязвимость"

Колядка про Vulnerability Management "Пропатчите уязвимость". 🙂 Наигрывал сегодня разные новогодние и рождественские песенки, и мне пришла в голову идея, что "We Wish You a Merry Christmas" с требованием инжирного пудинга отличное описывает процесс пушинга исправления критичных уязвимостей.

Что, в общем, и накидал по-быстрому. Подозреваю, что это первая песня, которая упоминает "НКЦКИ". 😅

Поздравляю всех с наступающим Новым 2024 Годом! Всем здоровья, счастья и интересных задачек! Ура! 🎄🎉

Надёжная позиция, которой стоит держаться при общении с IT об установке обновлений безопасности

Надёжная позиция, которой стоит держаться при общении с IT об установке обновлений безопасности

Надёжная позиция, которой стоит держаться при общении с IT об установке обновлений безопасности.

1. То, о чём мы говорим, это сетевой актив (= есть адрес IPv4/IPv6)?

2. У этого сетевого актива есть вендор (вендоры), отслеживающий появление уязвимостей и выпускающий обновления безопасности? Если да, то обновления безопасности должны своевременно тестироваться и устанавливаться. Это требования от вендоров, регуляторов и здравого смысла (cyber hygiene). На всех уровнях: hardware, OS, application. Если такого вендора (вендоров) нет, то актив неподдерживаемый и для него должен быть план вывода из эксплуатации.

3. Процесс Управления Уязвимостями нужен для отслеживания своевременной установки обновлений безопасности. Если актив не поддерживается средствами детектирования уязвимостей необходимо либо искать новые средства, либо выводить актив из эксплуатации.

Когда IT согласны с 3 пунктами можно обсудить какие у них есть проблемы с обновлениями и как им с этим помочь.

Вчера в канале k8s (in)security был прикольный пример как в реальности может выглядеть игра в докажи-покажи

Вчера в канале k8s (in)security был прикольный пример как в реальности может выглядеть игра в докажи-покажи

Вчера в канале k8s (in)security был прикольный пример как в реальности может выглядеть игра в докажи-покажи. Автор приводит аргументы из которых должно следовать, что на хостах, где крутится кластер Kubernetes необязательно обновлять пакеты ОС. Предлагается эти аргументы опровергнуть, а также привести сценарии атаки и модель нарушителя. Для большей заманухи ИБшников это называется "риск ориентированный подход". 🙂

Игра выглядит соблазнительной и кажется, что можно легко выиграть через контраргумент:

"Никто не знает всех уязвимостей Kubernetes, возможно злоумышленнику получится провалиться из контейнера на уровень хостовой ОС и начать эксплуатировать её уязвимости".

Однако хороший специалист по Куберу (как и другой сложной IT-системе) легко накидает вам в панамку аргументов почему злоумышленнику сделать это будет крайне сложно. И вы, как неспециалист, будете иметь бледный вид. 🌝

Единственный способ не проиграть шулеру - не садиться играть по его правилам. 🃏😉

Закончил обучение на курсе "Управление Уязвимостями" от Inseca

Закончил обучение на курсе Управление Уязвимостями от Inseca

Закончил обучение на курсе "Управление Уязвимостями" от Inseca. В целом, ожидания оправдались. 🙂 Опишу то, что понравилось и то, что можно было бы улучшить.

1. Практические домашние работы. 👍 Их было 11 штук. С учётом того, что курс шёл 6 недель, получалось в среднем 2 работы в неделю. Они рассчитаны max на 1-2 часа, так что делать по вечерам было комфортно.

Большая часть домашних работ строилась вокруг 3 стендов в VirtualBox:

🔻 Виртуалка с Kali на которую нужно было поставить Nessus Essentials
🔻 Виртуалка с необновлённым Windows уязвимая к EternalBlue
🔻 Виртуалка с необновлённой Ubuntu и развёрнутым DWVA

Работы были такие:

🔹 Развернём сканер уязвимостей
🔹 Проэксплотируем EternalBlue с помощью Metasploit, забёрем хэши и побрутим их
🔹 Посканим виртуалки в режиме "чёрного ящика"
🔹 Настроем учётки на виртуалках и посканируем их с аутентификацией
🔹 Посканим DVWA Nessus-ом и Acunetix-ом и посмотрим разницу
🔹 Выгрузим уязвимости из Nessus через API, обогатим отчёты данными по эксплоитам и активной эксплуатации
🔹 Пофиксим уязвимости через обновление или отключение уязвимых сервисов, проверим, что они не детектируются или не эксплуатируются

Ещё 2 работы не были завязаны на стенды. В одной нужно было составить CVSS Base Vector-ы по описаниям уязвимостей. В другой нужно было по версии софта найти уязвимости (поиск по CPE), а затем выделить для них эксплуатабельные (эта задачка хорошо решалась с помощью Vulristics 😉).

➡️ Вопрос: можно ли проделать такие учебные активности самостоятельно? Конечно. Но это искать надо, а тут уже готовые стенды, подробно описанные методички (кроме подзадачек со звёздочкой), проверка преподавателем. Сервис. 🙂

Как видно из описания работ, упор на практическое детектирование, приоритизацию и исправление уязвимостей. Без привязки к решениям VM-вендоров.

2. Вебинары-семинары. 👍 Их было 5 штук. Проходили по субботам в 12:00. Длительность около 1,5 часов. Дмитрий Топорков рассказывал нам какую-то тему, касающуюся текущего модуля и в процессе можно было задавать вопросы, дискутировать, обмениваться опытом. Один вебинар был с Давидом Ордяном из Metascan, я о нём уже писал подробнее. Получалось лампово, посещал эти онлайн-созвоны с удовольствием.

3. Тьюторство. 👍 Каждую неделю в телегу скидывали табель с принятыми заданиями и посещёнными вебинарами. При открытии модуля скидывали оповещение с темой модуля и количеством домашек. За три дня до дедлайна оповещение, что надо домашку сдавать. Оповещения о вебинарах за день и за час. Вроде мелочи, а забота приятна. 😇 Ну и Дмитрий очень оперативно домашки проверял. 🔥

4. Контент. 👌 Большая часть контента - текст. Скринкасты в основном были доп. материалом для практических занятий. Я к текстовому контенту хорошо отношусь, т.к. его удобнее быстро просматривать. Тексты качественные. Не скажу, что по содержанию для меня были какие-то откровения, но лишний раз перечитать было прикольно. Тем, кто видит подобный контент в первый раз, должно быть интересно. Порог входа небольшой, всё разжёвывается подробно.

5. Что улучшить? 🤔 Исходя из концепции, что это базовый вендерно-нейтральный курс с фокусом на низкоуровневую работу с уязвимостями напрашивается следующее:

🔹 Добавить лабу для работу с опенсурсным решением, на котором можно построить процесс управления уязвимостями, например, Faraday Security или DefectDojo
🔹 Выделить больше времени на разбор веб-уязвимостей DVWA
🔹 Добавить про анализ безопасности конфигураций, например с помощью OpenSCAP

В целом, неплохо бы дать более цельное представление как строить VM-процесс в организации с использованием конкретных тулов. Но как курс для старта вполне норм. 👍

Спасибо коллегам из Inseca за предоставленный доступ к курсу!

PS: Также мне подарили термокружку Inseca. 😅 Я в одном из Прожекторов отмечал, что термокружки очень уж часто дарят. Но эта кружка прям норм. 🔥 Добротная, прорезиненная где надо, без каких-то ненужных наворотов. Вещь! Передаривать не буду, оставлю себе. За кружку тоже спасибо! 🙂

Про определение имени уязвимого продукта по CPE в Vulristics

Про определение имени уязвимого продукта по CPE в Vulristics

Про определение имени уязвимого продукта по CPE в Vulristics. Для тех, кто не в курсе, моя утилита, кроме прочего, решает задачку получения для CVE-шки описательной строки "тип уязвимости - уязвимый продукт". В итоге пришёл к выводу, что хоть метод определения имени уязвимого продукта по CPE хорош своей скоростью и универсальностью, но в качестве основного он не годится.

Проблема не в самих CPE, а в том как их используют в NVD: иногда для CVE их слишком много, иногда их вообще нет, иногда они нерелевантные. Возьмём, для примера, Log4Shell (CVE-2021-44228). Согласитесь, что для этой уязвимости было бы неплохо в качестве уязвимого продукта получить Apache Log4j2 или хотя бы Apache Log4j. И он там даже есть в виде a:apache:log4j. Но в общем случае автоматически выделить именно этот CPE идентификатор среди десятков других, связанных с этой CVE, задача такая себе. 🤷‍♂️ Теоретически это можно было бы делать, если бы была какая-то иерархия CPE, анализируя которую можно было бы понять, что a:apache:log4j имеет больший приоритет, т.к. это уязвимая либа, которую использую другие уязвимые продукты. Но этого нет. Тот же официальный CPE dictionary это просто перечень CPE идентификаторов со ссылками на сайты вендоров и прочие сайты без какого-либо дополнительного полезного контекста.

Поэтому основным способом определения имени уязвимого продукта остаётся анализ текстового описания по ключевым словам. Несмотря на все недостатки в виде относительно долгого времени работы (которое увеличивается с увеличением количества описанных продуктов и, соответственно, ключевых слов), фолсов первого и второго рода, необходимости наполнять базу продуктов ручками и т.п. Разумеется с возможными оптимизациями там, где это возможно (например, для генеренных описаний уязвимостей Microsoft).

А детект по CPE оставить на случай, когда анализ текстового описания ничего не дал и лучше попробовать показать хоть что-то, чем Unknown Product.