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

Добрался наконец до итогов 2023 года от Qualys Threat Research Unit

Добрался наконец до итогов 2023 года от Qualys Threat Research UnitДобрался наконец до итогов 2023 года от Qualys Threat Research UnitДобрался наконец до итогов 2023 года от Qualys Threat Research UnitДобрался наконец до итогов 2023 года от Qualys Threat Research UnitДобрался наконец до итогов 2023 года от Qualys Threat Research UnitДобрался наконец до итогов 2023 года от Qualys Threat Research UnitДобрался наконец до итогов 2023 года от Qualys Threat Research UnitДобрался наконец до итогов 2023 года от Qualys Threat Research UnitДобрался наконец до итогов 2023 года от Qualys Threat Research UnitДобрался наконец до итогов 2023 года от Qualys Threat Research Unit

Добрался наконец до итогов 2023 года от Qualys Threat Research Unit. Пост вышел 19 декабря и обновлен в последний раз 4 января.

1. Основная группа уязвимостей, о которой они рассказывают это "уязвимости с высоким риском и боевым (weaponized) эксплоитом". Таких уязвимостей они выделили в 2023 году 206.
🔹 Подчеркивают, что количество таких уязвимостей значительно меньше количества уязвимостей с PoC-ом (7033) и тем более общего количества CVE уязвимостей (26447).
🔹 Подчеркивают, что только примерно половина (109) таких уязвимостей была в CISA KEV. На другие 97 тоже необходимо обращать внимание. Причина понятна: тормоза в CISA KEV.
🔹 Утверждают, что 25% таких уязвимостей начали эксплуатировать вживую в первый день, а 75% за 19 дней. Поэтому фиксить такие уязвимости нужно не быстро, а очень быстро.

2. Все эти 206 уязвимостей не выкладывают. Поэтому к полноте или избыточности списка не прикопаешься. 😉
🔹 Указывают тот же ТОП-10 уязвимостей, что и в конце сентября:

CVE-2023-0669
CVE-2023-20887
CVE-2023-22952
CVE-2023-23397
CVE-2023-24880
CVE-2023-27350
CVE-2023-28252
CVE-2023-2868
CVE-2023-29059
CVE-2023-34362

Добавив к ним ещё 2:

CVE-2023-0699
CVE-2023-35036

Учитывая, что CVE-2023-0699 упоминается в контексте использования группировкой LockBit, а LockBit как раз использовали CVE-2023-0669, то выглядит это как ошибка-опечатка, но судить не берусь. 😉
🔹 Для уязвимостей указывают группы софтов:

Operating System (57)
Networking Infrastructure (40)
Other (23)
Continuous Integration Software (16)
Desktop Application (13)
Enterprise Software (10)
Web Browser (8)
Management Software (7)
Content Management System (5)

🔹 Также указывают типы уязвимостей:

Security Feature Bypass
Remote Code Execution
Privilege Escalation
Input Validation and Parsing
Buffer Manipulation

Количество уязвимостей каждого типа можно оценить только по графику: 60 RCE-шек, остальных типов от 14 до 20.

3. Также они смапили эти 206 уязвимостей на MITRE ATT&CK Tactics & Techniques.

Exploitation of Remote Services T1210 (Enterprise)
Exploitation of Remote Services T0866 (ICS)
Exploit Public Facing Application T1190 (Enterprise)
Exploit Public Facing Application T0819 (ICS)
Exploitation for Privilege Escalation T1068/T1404 (Enterprise/Mobile)
Other T1499.004, T1133, T1189, T0890, T1204.001, T1428, T1203

Получили, что 70% касаются так или иначе эксплуатации сервисов (T1210, T0866, T1190, T0819). Ещё 12% подъема привилегий (T1068/T1404).

4. Основные тезисы в статье:
🔹 исправляйте критичные эксплуатабельные уязвимости как можно быстрее
🔹 детектируйте уязвимости не только на хостах с агентами, но также используйте активное сканирование и анализ трафика
🔹 используйте продвинутые способы приоритизации уязвимостей на нейронках (Qualys TruRisk), а если денег нет, то учитывайте CISA KEV, EPSS и наличие эксплоита

Анализ уязвимостей с помощью Vulristics

К сожалению, 206 заветных уязвимостей не показали, поэтому анализировать толком нечего. 🤷‍♂️ Но по 12 указанным CVE-шкам я выпустил отчёт Vulristics:

🗒 Qualys 2023 Threat Landscape Year in Review 12 CVEs

Похожи эти уязвимости на самые ТОП-овые уязвимости 2023 года?

Если говорить применительно к России, то лишь в самой небольшой части. Потому что в наших широтах PaperCut NG, GoAnywhere MFT, MOVEit Transfer, Barracuda ESG и SugarCRM распространены не особо. Но это имхо. 🙂

Детект типа уязвимости по 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 Годом! Всем здоровья, счастья и интересных задачек! Ура! 🎄🎉

ИБшники радостно перекидывают друг другу pdf-ку с новогодним поздравлением якобы от НКЦКИ, оформленным под бюллетень безопасности

ИБшники радостно перекидывают друг другу pdf-ку с новогодним поздравлением якобы от НКЦКИ, оформленным под бюллетень безопасностиИБшники радостно перекидывают друг другу pdf-ку с новогодним поздравлением якобы от НКЦКИ, оформленным под бюллетень безопасностиИБшники радостно перекидывают друг другу pdf-ку с новогодним поздравлением якобы от НКЦКИ, оформленным под бюллетень безопасности

ИБшники радостно перекидывают друг другу pdf-ку с новогодним поздравлением якобы от НКЦКИ, оформленным под бюллетень безопасности. Хотя на safe-surf такого бюллетеня с поздравлением нет. 🧐 Не буду утверждать, что конкретно эта pdf-ка зловредная. Но выглядит как идеальная тема для атаки на российских ИБшников, пока они на расслабоне. ИБшник, бди!

Upd. По поводу данного конкретного кейса пишут, что pdf-ка прилетела в почтовой рассылке с правильного адреса, а safe-surf выкладывает всё с задержкой. 😉 Так что панику не разводим, но как возможный сценарий атаки учитываем.

Надёжная позиция, которой стоит держаться при общении с 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-системе) легко накидает вам в панамку аргументов почему злоумышленнику сделать это будет крайне сложно. И вы, как неспециалист, будете иметь бледный вид. 🌝

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