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

Мартовский Microsoft Patch Tuesday

Мартовский Microsoft Patch Tuesday

Мартовский Microsoft Patch Tuesday. 77 CVE, из которых 20 были добавлены в течение месяца. В этот раз целых 7 уязвимостей с признаками эксплуатации вживую:

🔻 RCE - Windows Fast FAT File System Driver (CVE-2025-24985)
🔻 RCE - Windows NTFS (CVE-2025-24993)
🔻 SFB - Microsoft Management Console (CVE-2025-26633)
🔻 EoP - Windows Win32 Kernel Subsystem (CVE-2025-24983)
🔻 InfDisc - Windows NTFS (CVE-2025-24991, CVE-2025-24984)
🔻 AuthBypass - Power Pages (CVE-2025-24989) - в веб-сервисе Microsoft, можно игнорить

Уязвимостей с публичными эксплоитами нет, есть ещё 2 с приватными:

🔸 RCE - Bing (CVE-2025-21355) - в веб-сервисe Microsoft, можно игнорить
🔸 SFB - Windows Kernel (CVE-2025-21247)

Среди остальных можно выделить:

🔹 RCE - Windows Remote Desktop Client (CVE-2025-26645) and Services (CVE-2025-24035, CVE-2025-24045), MS Office (CVE-2025-26630), WSL2 (CVE-2025-24084)
🔹 EoP - Windows Win32 Kernel Subsystem (CVE-2025-24044)

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

Следующее мероприятие, на котором я планирую выступить - форум "ТЕРРИТОРИЯ БЕЗОПАСНОСТИ 2025: все pro ИБ" 3 апреля

Следующее мероприятие, на котором я планирую выступить - форум ТЕРРИТОРИЯ БЕЗОПАСНОСТИ 2025: все pro ИБ 3 апреля

Следующее мероприятие, на котором я планирую выступить - форум "ТЕРРИТОРИЯ БЕЗОПАСНОСТИ 2025: все pro ИБ" 3 апреля. В рамках технологической панели "А ты точно умеешь это детектировать? Правила детекта уязвимостей" у меня будет 20-минутный доклад "Уровни сравнения качества детектирования уязвимостей".

О чём расскажу:

🔹 Зачем нужно заниматься оценкой качества детектирования уязвимостей и как это связано с БОСПУУ.

🔹 Примеры публичных сравнений качества детектирования. Спасибо Алексею Лукацкому за напоминание про сравнение Principled Technologies 2019 года. 👍 Оказывается у меня был про него содержательный пост в англоязычном канале. 😇 Ну и про сравнение PentestTools (2024) и Securin (2023) тоже добавлю.

🔹 Уровни сравнения: просто по CVE, по CVE с учётом метода детекта, практическое сравнение на стендах. Возможно какие-то ещё? 🤔

Если у кого есть что вкинуть по теме, пишите в личку - буду рад пообщаться. И до встречи на Территории Безопасности!

Разбор VM-ной вакансии: Старший инженер по управлению уязвимостями в Авито

Разбор VM-ной вакансии: Старший инженер по управлению уязвимостями в Авито

Разбор VM-ной вакансии: Старший инженер по управлению уязвимостями в Авито. Буду периодически комментировать VM-ные вакансии, чтобы отслеживать, что сейчас востребовано, и помогать их закрывать. 😉

🔹 VM-ная часть вакансии выглядит стандартно: развивать и автоматизировать VM-процесс, взаимодействовать с владельцами сервисов, составлять базовые требования ИБ, использовать сканеры, понимать CVSS/CVE.

🔹 Linux-овая часть интригует. Нужно знать Puppet и придётся "администрировать ИТ-инфраструктуру на базе Linux". В сочетании с "развивать инструменты для поиска, анализа и устранения уязвимостей ИТ-инфраструктуры" можно предположить, что у них есть самописные детектилки уязвимостей с инвентаризацией на основе Puppet и то, что VM-щики непосредственно занимаются патчингом и харденигом.

🔹 По поводу "внедрять и администрировать системы защиты информации" могут быть вопросики. Советовал бы уточнять список СЗИ на собесе, чтобы не пришлось заниматься чем-то непрофильным. 😉

Про уязвимость Elevation of Privilege - Windows Storage (CVE-2025-21391)

Про уязвимость Elevation of Privilege - Windows Storage (CVE-2025-21391)

Про уязвимость Elevation of Privilege - Windows Storage (CVE-2025-21391). Уязвимость из февральского Microsoft Patch Tuesday. Windows Storage - это стандартный компонент, отвечающий за хранение данных на компьютере. В случае успешной эксплуатации, злоумышленник получает возможность удалять произвольные файлы. И, согласно исследованию ZDI, злоумышленник может использовать эту возможность для повышения своих прав в системе.

Для уязвимости сразу были признаки эксплуатации вживую, но насколько масштабными были зафиксированные атаки всё ещё неизвестно.

Про уязвимость Elevation of Privilege - Windows Ancillary Function Driver for WinSock (CVE-2025-21418)

Про уязвимость Elevation of Privilege - Windows Ancillary Function Driver for WinSock (CVE-2025-21418)

Про уязвимость Elevation of Privilege - Windows Ancillary Function Driver for WinSock (CVE-2025-21418). Уязвимость из февральского Microsoft Patch Tuesday. AFD.sys - это системный драйвер Windows, критически важный для процессов сетевого взаимодействия. Он предоставляет низкоуровневую функциональность для WinSock API, позволяя приложениям взаимодействовать с сетевыми сокетами.

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

По описанию эта уязвимость очень похожа на прошлогоднюю уязвимость CVE-2024-38193, которая активно эксплуатировалась злоумышленниками из группировки Lazarus.

Расширенный поиск по web-уязвимостям в Vulners

Расширенный поиск по web-уязвимостям в Vulners

Расширенный поиск по web-уязвимостям в Vulners.

🔻 Vulners теперь размечает значимые параметры в описании CVE уязвимостей и эксплоитов. 🤖 Например, по описанию "Code injection vulnerability in config/config_invt1.php due to improper handling of the PASSOx parameter" он автоматически определяет, что это веб-уязвимость и выделяет parameter запроса "PASSOx", url "config/config_invt1.php", position "request body" и cwe "CWE-94" (Code Injection). Эти параметры видны на странице описания уязвимости и в JSON (блок webApplicability).

🔻 По этим параметрам можно искать уязвимости в поисковом интерфейсе Vulners (бесплатно 🆓) и через API. Например, все вебные уязвимости или уязвимости с "php" в урле.

А зачем это может понадобиться?

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

И наоборот

🔹 Для размеченных уязвимостей Vulners можно проверить не доступны ли их пути в сервисах на вашем периметре.

В общем, прикольная фича. 😉👍🔥

Обновление хостов с прикладом: альтернативное мнение

Обновление хостов с прикладом: альтернативное мнение

Обновление хостов с прикладом: альтернативное мнение. Пришёл комментарий от подписчика к VM-ной задачке про 2 подразделения и обновление хостов с развёрнутыми приложениями. С любезного разрешения выкладываю текст полностью. 🙂

"Имея опыт работы с обоих сторон ("общей инфры" и админа приклада — как раз того самого Postgres), хотел бы заметить следующее. Всё же обновлением ОС должна заниматься команда, которая заведует ОС и обще-инфраструктурными сервисами, крутящимися на хостах. А админы прикладного ПО — должны следить за своим ПО.

Но все вместе они — должны согласовывать свои действия.

На хосте, помимо условного постгреса, может крутиться много всякого другого. О чём "прикладные админы" могут знать, но не факт, что могут этим грамотно управлять и правильно оценить последствия обновления пакетов. Пример навскидку — на хосте наверняка будут установлены агенты систем мониторинга — как ИТ-шного, так и ИБ-шного. И передать на админов условного постгреса ответственность за обновление хоста со всем этим набором… А "прикладники" точно должны этим заниматься? 😊 Тогда как мимо линуксовых админов установка, настройка и эксплуатация всех этих дополнительных сервисов на хостах с прикладом точно не пройдёт.

По опыту банка, в котором я работал — хосты обновляли линуксовые админы, а "прикладные" — только тот приклад, который в их зоне ответственности. Пакеты, относящиеся к прикладу, ставились на hold сразу при установке приклада, и их обновление было невозможно при обновлении хоста.

Ну и само собой, обновления сначала выполнялись на тестовых средах, чтобы понять, не приедут ли какие-то обновы зависимостей, которые могут сломать приклад. Если не приедут — хост смело обновлялся отдельно, а приклад — отдельно. Если зависимости ломали приклад — либо пакеты зависимостей дополнительно замораживались, либо, если это ломало остальное обновление — обновление откладывалось до ̶л̶у̶ч̶ш̶и̶х̶ ̶в̶р̶е̶м̶ё̶н̶ тех пор, пока приклад не сможет это поддержать. В тестировании, само собой, участвовали обе команды — и "хостовая" и "прикладная". Но на проде, при использовании этой схемы, их работы по обновлению, по большей части происходили независимо."

У такой схемы, безусловно, есть свои преимущества. И она весьма удобна админам, т.к. они занимаются профильными задачками, а непонятной им фигнёй не заморачиваются. Но вот VM-щику такая совместная работа и размытие ответственности невыгодны, т.к. ему придётся частенько "тыкать палочкой" две (а возможно и более) команды, которые будут показывать друг на друга. 😑 Критичные уязвимости не будут устраняться с формулировкой "обновление отложено". А кто будет нести ответственность в случае, если уязвимость будет проэксплуатирована в течение этого "отложенного" периода непонятно. Видимо предполагается, что нести ответственность будет сам VM-щик. 😏 Так что VM-щикам топить за такую схему я бы не советовал.

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

В любом случае, главное, чтобы обновления ставились и уязвимости устранялись (желательно с соблюдением SLA). А как именно это происходит и чьими силами не так уж важно. 😉