Архив рубрики: Уязвимость

Не пора ли создать российский аналог CISA KEV?

Не пора ли создать российский аналог CISA KEV?

Не пора ли создать российский аналог CISA KEV? Я, конечно, не в курсе технических подробностей недавних инцидентов в крупных отечественных компаниях, но что-то подсказывает, что без эксплуатации известных критичных уязвимостей, незапатченных своевременно, там не обошлось.

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

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

На сайте Positive Technologies вышла новость о внедрении MaxPatrol VM на предприятии и "Уральская сталь" (Оренбургская область)

На сайте Positive Technologies вышла новость о внедрении MaxPatrol VM на предприятии и Уральская сталь (Оренбургская область)

На сайте Positive Technologies вышла новость о внедрении MaxPatrol VM на предприятии и "Уральская сталь" (Оренбургская область). Работы проводил системный интегратор Wone IT. Крутой у них нейминг, yep. 🔥😅

В новости самое интересное - это описание этапов внедрения VM-продукта:

🔹 Инсталляция MPVM, конфигурация компонентов, первоначальная настройка, разработка типовых документов и технического задания.

🔹 Аудит и категоризация имеющихся IT-активов. "Создана база данных и автоматизирован импорт информации из различных ресурсов, включая внешние каталоги и другие ИБ-решения".

🔹 Редактирование встроенных правил и политик управления выявленными уязвимостями, фильтрация незащищённых активов, разработка пользовательских виджитов и дашбордов.

🔹 Разработка документации с пояснениями, регламентами и руководствами для администраторов и операторов системы.

🔹 Опытно-тестовая эксплуатация.

На Хабре вышел мой отчёт по трендовым уязвимостям первой половины 2025 года

На Хабре вышел мой отчёт по трендовым уязвимостям первой половины 2025 года

На Хабре вышел мой отчёт по трендовым уязвимостям первой половины 2025 года. С начала 2025 года до 30 июня мы отнесли к трендовым 37 уязвимостей. А за весь 2024 год - 74 уязвимости. Похоже, что в этом году к трендовым будет отнесено примерно столько же уязвимостей, что и в прошлом году. 🤔 А судя по затишью в прошлом и этом месяце, может, и поменьше.

🔻 Для 30 уязвимостей есть зафиксированные признаки эксплуатации в атаках, для 7 - публичные эксплоиты (но пока нет признаков эксплуатации).

🔻 По типам уязвимостей большая часть - это выполнение произвольного кода (15), и повышение привилегий (13).

🔻 22 трендовые уязвимости касаются продуктов Microsoft (59 %). Остальные вендоры: 7-Zip, MDaemon, Zimbra, CommuniGate, Roundcube, Erlang, Fortinet, Palo Alto Networks, Apache, Kubernetes, VMware.

🗒 Полный отчёт Vulristics

Июльский Linux Patch Wednesday

Июльский Linux Patch Wednesday

Июльский Linux Patch Wednesday. В этот раз 470 уязвимостей, чуть меньше, чем в июне. Из них 291 в Linux Kernel. Для одной уязвимости есть признаки эксплуатации вживую (CISA KEV):

🔻 SFB - Chromium (CVE-2025-6554)

Ещё для 36 (❗️) уязвимостей доступны публичные эксплоиты или имеются признаки их существования. Из них можно выделить:

🔸 RCE - Redis (CVE-2025-32023), pgAdmin (CVE-2024-3116), Git (CVE-2025-48384)
🔸 EoP - Sudo (CVE-2025-32462, CVE-2025-32463)
🔸 PathTrav - Tar (CVE-2025-45582)
🔸 XSS - jQuery (CVE-2012-6708)
🔸 SFB - PHP (CVE-2025-1220)
🔸 DoS - LuaJIT (CVE-2024-25177), Linux Kernel (CVE-2025-38089)
🔸 MemCor - DjVuLibre (CVE-2025-53367)

🗒 Полный отчёт Vulristics

Иногда общение стоит минимизировать

Иногда общение стоит минимизировать

Иногда общение стоит минимизировать. Главная проблема в работе с уязвимостями - это НЕ сами уязвимости. Это необходимость постоянно общаться с людьми, которые этого общения не хотят и которым ты не нравишься. 🫩 Это актуально и при пушинге устранения уязвимостей в инфраструктуре, и при сдаче-приёмке уязвимостей, найденных в ходе багбаунти.

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

➡️ В качестве примера рекомендую ознакомиться с эпичной историей, как Игорь Агиевич сдавал уязвимость в блокчейне Hyperledger Fabric (CVE-2024-45244). Имхо, вместо общения в такой ситуации было бы достаточно скинуть вендору ресёрч и PoC, выждать 3 месяца, зарегать CVE и, без особых рефлексией, сделать full disclosure. 🤷‍♂️😈

Нетрадиционное использование комплаенс-сканирования

Нетрадиционное использование комплаенс-сканирования

Нетрадиционное использование комплаенс-сканирования. Как правило, комплаенс-сканирование в организации преследует две цели:

🔹 Удостовериться, что настройки сетевых хостов удовлетворяют регуляторным требованиям.

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

Иногда эти цели совпадают, иногда не особо. 😉 Но есть и третья цель:

🔻 Удостовериться, что настройки хостов позволяют средствам защиты информации работать адекватно.

В качестве примера можно привести статью моего коллеги по PT ESC, Романа Чернова, о настройке аудита на Linux-хостах таким образом, чтобы данных было достаточно для надёжного детектирования инцидентов SIEM-ом.

Как можно видеть на схеме, отслеживать корректность настроек логирования в Linux не так-то просто. 😱 Но эту задачу можно решать автоматизированно с помощью комплаенс-сканов MaxPatrol HCC. 😉

Кибероружие следует сдавать государству

Кибероружие следует сдавать государству

Кибероружие следует сдавать государству. Продолжу накидывать аргументы за централизацию репортинга уязвимостей через государственного регулятора. Давайте проведём аналогию между уязвимостями и оружием. Идея не нова, термин "cyberweapon" употребляется десятки лет.

Если человек идёт по дороге и видит, допустим, пистолет, что он вправе с ним легально сделать? Может ли он его использовать по своему усмотрению? Может ли он его продать? Может ли он его вывезти за пределы страны?

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

Тогда почему сейчас считается нормальным передавать уязвимости ("кибероружие") разработчикам ПО из недружественных стран? Вместо использования этой важной информации во благо нашей страны? Как по мне, это следует изменить.