Архив за месяц: Октябрь 2025

От детектирования уязвимостей к валидации экспозиций

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

От детектирования уязвимостей к валидации экспозицийОт детектирования уязвимостей к валидации экспозиций

От детектирования уязвимостей к валидации экспозиций. На прошлой неделе Qualys представили новую функциональность TruConfirm класса Automated Exposure Validation. Их платформа Qualys ETM позволяет производить оценку критичности и приоритизацию уязвимостей в инфраструктуре. Причём уязвимости не обязательно должны быть продетектированы с помощью Qualys (на скриншоте в источниках уязвимостей видны Nessus и MS Defender for Endpoint). Независимо от способа детектирования, TruConfirm может определить является ли уязвимость (в широком смысле слова - экспозиция) эксплуатабельной на конкретном хосте. Если эксплуатабельность подтверждается, это является фактором приоритизации. Если нет, Qualys обещает показывать какие именно СЗИ блокируют эксплуатацию.

Технически эта функциональность работает через выполнение safecheck-ов на основе эксплоитов. Пока непонятно, это только "пентестовые" сейфчеки или эксплуатабельность EoP на хосте тоже могут проверить. 🤔 Но заход интересный. 👍

По поводу сообщений об утечках данных отечественных компаний и организаций

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

По поводу сообщений об утечках данных отечественных компаний и организаций

По поводу сообщений об утечках данных отечественных компаний и организаций. В том числе и о сегодняшней бредовой якобы утечке из MAX. 🤦‍♂️ У меня подход универсальный:

1. Пока утечка НЕ ПОДТВЕРЖДЕНА официально (здесь и далее: самой компанией, регуляторами или правоохранительными органами), я считаю эту информацию ЦИПСОшным фейком. Тех, кто злорадно распространяет такую неподтверждённую информацию как истину в последней инстанции, я считаю ЦИПСОшными пособниками, заслуживающими, как минимум, порицания. 👎🤬 Дел с ними стараюсь не иметь.

2. Если есть официальное ОПРОВЕРЖЕНИЕ утечки, я ему верю и считаю тему закрытой. Как по сегодняшнему кейсу с MAX-ом [1,2].

3. Если есть официальное ПОДТВЕРЖДЕНИЕ утечки, это, безусловно, печально. 😔 Необходимо разбираться в причинах и продвигать меры, чтобы такое не повторялось. Злодеи должны быть найдены и наказаны. Это лишнее напоминание о необходимости наращивать оборонительный и наступательный киберпотенциал, потому что враг не дремлет.

Интересным образом развивается кейс с компрометацией американского IT/ИБ-вендора F5

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

Интересным образом развивается кейс с компрометацией американского IT/ИБ-вендора F5

Интересным образом развивается кейс с компрометацией американского IT/ИБ-вендора F5. Раньше недопустимыми при атаке на вендора считались события, дающие злоумышленнику непосредственный доступ в инфраструктуру клиентов. Например, через добавление зловредной функциональности в дистрибутивы или обновления продуктов.

В данном случае, несмотря на длительное присутствие атакующих в инфраструктуре F5 (почти 2 года!), об этом пока не сообщают. 😏 Зато на Западе наконец-то обратили внимание на то, что раньше не считалось особенно критичным: злоумышленники получили доступ к открытым задачам на устранение уязвимостей в продуктах F5, наверняка вместе с PoC-ами. 🤦‍♂️🎰 Злодеи, безусловно, используют эту информацию по зиродеям в атаках на инсталляции F5 по всему миру (269 тысяч IP-адресов!). 😱🤷‍♂️

Конечно, F5 выпустили экстренные патчи для 44 уязвимостей, но, наверняка, исправили далеко не всё. К тому же, злоумышленники получили доступ и к исходному коду F5, что облегчит им поиск новых уязвимостей. 😉

Обратил внимание на оценки параметра TTE (Time-to-Exploit) для уязвимостей в свежем пресс-релизе BIZONE и Сбера

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

Обратил внимание на оценки параметра TTE (Time-to-Exploit) для уязвимостей в свежем пресс-релизе BIZONE и Сбера

Обратил внимание на оценки параметра TTE (Time-to-Exploit) для уязвимостей в свежем пресс-релизе BIZONE и Сбера.

Утверждается, что:
🔻 "За последние 2,5 года показатель Time-to-Exploit стал равен менее 40 дней"
🔻 "За последние пять лет Time-to-Exploit сократился в 20 раз"
🔻 "Более 60% уязвимостей хакеры начинают эксплуатировать в течение первых дней после публикации, а иногда и после нескольких часов"

Учитывая, что сейчас добавляется более 40к+ новых CVE в год и для большей части из них эксплоиты не появляются никогда, эти утверждения должны касаться не всех уязвимостей, а некоторой выборки. 😉

Поэтому я уточнил у коллег из SBER X-TI методику расчёта.

Для всех уязвимостей брали:
👾 De - дату начала эксплуатации в атаках из CISA KEV и собственной аналитики
📰 Dp - дату публикации из MITRE
Считали TTE = De - Dp

При расчёте среднего TTE учитывали только CVE, попадающие под фильтры:
🔍 рассматриваемый год содержится в CVE-ID
✂️ TTE = 365
✂️ Год De >= Год Dp

Октябрьский Linux Patch Wednesday

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

Октябрьский Linux Patch Wednesday

Октябрьский Linux Patch Wednesday. В октябре Linux вендоры начали устранять 801 уязвимость, чуть больше, чем в сентябре. Из них 546 в Linux Kernel. Для одной уязвимости есть признаки эксплуатации вживую:

🔻 EoP - VMware Tools (CVE-2025-41244). Уязвимость эксплуатируется с октября 2024 года и для неё доступны публичные эксплоиты. Согласно описанию, для эксплуатации требуется VMware Aria Operations.

Ещё для 39 уязвимостей доступны публичные эксплоиты или имеются признаки их существования. Можно выделить:

🔸 RCE - Redis (CVE-2025-49844 - RediShell, CVE-2025-46817), OpenSSH (CVE-2025-61984), 7-Zip (CVE-2025-11001, CVE-2025-11002)
🔸 EoP - FreeIPA (CVE-2025-7493), Asterisk (CVE-2025-1131)
🔸 SQLi - MapServer (CVE-2025-59431)
🔸 SFB - authlib (CVE-2025-59420)
🔸 MemCor - Binutils (CVE-2025-11082 и ещё 7), Open Babel (CVE-2025-10995 и ещё 6)

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

Контроль качества базы уязвимостей R-Vision VM и задействованные группы специалистов

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

Контроль качества базы уязвимостей R-Vision VM и задействованные группы специалистовКонтроль качества базы уязвимостей R-Vision VM и задействованные группы специалистов

Контроль качества базы уязвимостей R-Vision VM и задействованные группы специалистов. Завершаю накидывать по итогам вебинара.

🔬 Качество детектирования уязвимостей проверяют на 700+ стендах. С конкурентами сравниваются (упомянули Nessus, Rapid7 Nexpose). Есть дежурные, которые отрабатывают по false positive ошибкам.

🌐 Покрытие базы уязвимостей можно посмотреть на публичном портале, обновляемом раз в 2 недели.

👂 В новой версии R-Vision VM можно будет искать по базе уязвимостей.

Развитием базы уязвимостей занимается 4 группы специалистов:

👷‍♂️ Инженеры - занимаются развитием исследовательской лаборатории.

🧪 Аналитики и Исследователи - разбирают эксплоиты и логику детектирования. Аналитики фокусируются на режиме Аудит, а Исследователи на режиме Пентест.

👨‍💻 Разработчики - занимаются разработкой движка детектов.

Общее число специалистов около 30.

Бонус: несколько моментов из QA сессии

Вчера прочитал свою третью и заключительную лекцию "Управление уязвимостями в соответствии с методическими требованиями регуляторов и лучшими практиками" в рамках магистерской программы ИТМО

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

Вчера прочитал свою третью и заключительную лекцию Управление уязвимостями в соответствии с методическими требованиями регуляторов и лучшими практиками в рамках магистерской программы ИТМО

Вчера прочитал свою третью и заключительную лекцию "Управление уязвимостями в соответствии с методическими требованиями регуляторов и лучшими практиками" в рамках магистерской программы ИТМО.

🇷🇺 Начали с разбора руководства ФСТЭК по организации процесса управления уязвимостями в органе (организации). Рассмотрели структуру, роли участников и операции. Затем перешли к методике оценки уровня критичности уязвимостей ФСТЭК (версия этого года). Подробно разобрали, как рассчитывается уровень и как он определяет сроки устранения уязвимостей. По устранению рассмотрели рекомендательный алгоритм НКЦКИ и методику тестирования обновлений ФСТЭК. Коснулись методики оценки показателя защищённости ФСТЭК и требований по управлению уязвимостями в 117 приказе ФСТЭК.

🌎 Международные best practices рассмотрели на основе PCI DSS 4.0.1. Упомянул и руководство NCSC.

👻 Закончил рассказом о реалиях VM-процесса на основе БОСПУУ и о методах саботажа со стороны IT [1, 2].