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

Получил неофициальное разъяснение от ФСТЭКа по поводу использования методики оценки уровня критичности уязвимостей

Получил неофициальное разъяснение от ФСТЭКа по поводу использования методики оценки уровня критичности уязвимостей. Это по вопросу расчета Iinfr, который я вчера поднимал:

"Изначально задумывалось, что уязвимость оценивается для всей ИС. Но, поскольку это не прописано в методике явно, то допускаются оба сценария оценки."

Т.е. основной вариант 1 (единый Iinfr для всей инфраструктуры/информационной системы, через максимизацию значения показателей) но можно использовать и 1, и 2 (считаем Iinfr независимо для каждого уязвимого актива).

Microsoft выпустили статью об атаках с использованием RCE уязвимости в JetBrains TeamCity (CVE-2023-42793)

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

Microsoft выпустили статью об атаках с использованием RCE уязвимости в JetBrains TeamCity (CVE-2023-42793). Статья про то, что злоумышленники делают после компрометации серверов TeamCity и будет интересна скорее SOC-оводам. Но это хороший повод вспомнить об уязвимости, которую я здесь не подсвечивал.

TeamCity это один из самых популярных CI/CD-серверов. Учитывая, что JetBrains были по большей части российской компаний до своего недавнего исхода, в РФ продукты JetBrains используются более чем широко.

JetBrains узнали об уязвимости в начале сентября и оперативно выпустили обновление и плагин для старых версий. 21 сентября JetBrains выложили подробное описание уязвимости, после чего быстро появились рабочие эксплоиты. Сейчас даже модуль для Метасплоита есть. Атаки, о которых пишут MS, начались с начала октября.

В общем, полный набор для супер-критичной уязвимости. Исправляйте, если ещё нет. 🙂

🟥 PT относит уязвимость к трендовым с 26 сентября.

В официальном канале PT вышел рекламный ролик курса по Управлению Уязвимостями

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

В официальном канале PT вышел рекламный ролик курса по Управлению Уязвимостями. По сюжету злобный хацкер старается сломать инфраструктуру, но у него ничего не получается, т.к. для организации с выстроенным VM-процесом страшные зловреды превращаются в банан. 🍌🙂 В инфраструктуре, которая регулярно патчится особенно не развернёшься. 🤷‍♂️

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

Так что рекомендую записаться и пройти курс. Как минимум его бесплатную вводную часть. Ну а в идеале выбить у руководства бюджет на полноценный месячный курс. Не зря же я там участвовал. 😉

Старт 29 октября.

Вопрос по поводу практического применения методики оценки уровня критичности уязвимостей ФСТЭК

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

Вопрос по поводу практического применения методики оценки уровня критичности уязвимостей ФСТЭК. Наверное у каждого, кто пробовал применять методику возникал вопрос. Ну хорошо, Iinfr зависит от типа уязвимого актива. А что делать, если у меня разные типы активов (хостов) подвержены данной CVE/БДУ уязвимости? Например, у меня уязвимость Windows, которая детектируется и на десктопах, и на серверах. Какое тогда значение показателя K выбирать? Или, например, у меня уязвимости подвержены и хосты на периметре, и глубоко во в внутрянке. Тоже непонятно какое значение показателя P выбирать.

Кажется, что здесь могут быть два основных подхода:

1. Единый Iinfr для всей инфраструктуры, через максимизацию значения показателей. То есть если уязвимость есть на десктопах и серверах, то берём значение K для серверов. Если есть хоть один уязвимый хост на периметре, то берем P для средств доступных из Интернет.

✅ Плюс: в итоге получаем один уровень критичности V для уязвимости, этакий "улучшенный CVSS" и используем его так, как использовали бы CVSS.

⛔ Минус: получается, что этот максимизированный V будет аффектить все активы и задавать требования по оперативности исправления. Если у нас уязвимость на 100 десктопах и одном сервере, то будьте любезны пофиксить её на десктопах с той же срочностью, что и на сервере. Ну или сначала пофиксить на сервере, и потом пересчитать Iinfr и, соответственно, V. Получим меньшую критичность и более комфортные сроки устранения уязвимости.

2. Считаем Iinfr независимо для каждого уязвимого актива. То есть сколько у нас активов (или групп однотипных активов), столько у нас будет Iinf и, соответственно, V.

✅ Плюс: получаем атомарность, практически избавляемся от неоднозначности.

⛔ Минус: это уже будет не "улучшенный CVSS", нельзя будет сказать, а какова критичность этой CVE/БДУ, т.к. для каждого уязвимого актива она может отличаться. В прочем, с CVSS может быть та же история, если активно подкручивать Temporal часть вектора для каждого актива (на практике я правда такое не встречал).

А как правильно? 🧐 Видится, что можно жить и с первым, и со вторым вариантом. Но было бы здорово получить разъяснения ФСТЭК о том, как оно изначально задумывалось, и на это уже ориентироваться.

Upd. Получил неофициальное разъяснение от ФСТЭК. Задумывался первый вариант, но можно оба.

Выпустил отчёт по октябрьскому Linux Patch Wednesday!

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

Выпустил отчёт по октябрьскому Linux Patch Wednesday! Первый! 🥳 Результатом доволен. Топ выглядит адекватно и соответствует тому, что я подсвечивал в канале.

1. Memory Corruption - Chromium (CVE-2023-5217). Это уязвимость в библиотеке libvpx, которая была самой критичной и в октябрьском Microsoft Patch Tuesday. Есть PoC на гитхабе и признаки эксплуатации вживую.
2. Remote Code Execution - GNU C Library (CVE-2023-4911). Это Qualys Looney Tunables. Давно есть PoC, но признаков эксплуатации вживую пока нет.
3. Denial of Service - Golang Go (CVE-2023-29409). Есть PoC. Vulristics определил софт как TLS, т.к. в описании уязвимости CVE никакого намека на Go. 🤷‍♂️
4. Denial of Service - HTTP/2 protocol (CVE-2023-44487). Также был в MSPT.
…
14. Memory Corruption - Curl (CVE-2023-38545). Для этой уязвимости появились PoC-и на Github.

Остальное без эксплоитов и признаков эксплуатации вживую.

🗒 Vulristics report

По Privilege Escalation в Cisco IOS XE (CVE-2023-20198), о которой вчера писал, прям паника в ИБшных СМИ пошла

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

По Privilege Escalation в Cisco IOS XE (CVE-2023-20198), о которой вчера писал, прям паника в ИБшных СМИ пошла. Товарищи из Vulnerability Intelligence компании VulnCheck выпустили скрипт для проверки Cisco IOS XE на компрометацию и начали сканировать выдачу Shodan/Censys с устройствами Cisco. В этой выдаче где-то 140000 хостов. И вот они заявили журналисту из Bleeping Computer, что где-то половину хостов просканили и где-то 10000 устройств с имплантом обнаружили. То есть не просто уязвимых, а уже взломанных. А сколько их всего будет сложно даже предположить. 🍿

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

Очередная Privilege Escalation c CVSS 10, на этот раз в Cisco IOS XE (CVE-2023-20198)

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

Очередная Privilege Escalation c CVSS 10, на этот раз в Cisco IOS XE (CVE-2023-20198). Как и в случае с Confluence, это значит полную компрометацию актива неаутентифицированным злоумышленником.

"Cisco известно об активной эксплуатации ранее неизвестной уязвимости в функции веб-интерфейса Cisco IOS XE, когда его выставляли в Интернет или в ненадежные сети. Эта уязвимость позволяет удаленному злоумышленнику, не прошедшему аутентификацию, создать учетную запись в уязвимой системе с уровнем привилегий 15. Затем злоумышленник может использовать эту учетную запись для получения контроля над уязвимой системой." 🤷‍♂️

Есть IOCи, патчей нет. Рекомендуют клиентам отключать функцию HTTP-сервера во всех системах доступных из Интернет.

Cisco IOS XE - усовершенствованная версия Cisco IOS, построенная на базе Linux, которую Cisco представила в 2008 коду в продуктах ASR и Catalyst.

Александр В. Леонов

Управление Уязвимостями и прочее