Архив за месяц: Июль 2026

Июльский Linux Patch Wednesday

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

Июльский Linux Patch Wednesday

Июльский Linux Patch Wednesday. Всего 2017 уязвимостей (539 в ядре Linux и 504 в Chromium). Для сравнения, в июне было 1888 уязвимостей. Снова новый рекорд. При этом в следующем месяце тоже, скорее всего, будет рекорд, т.к. за 2,5 недели до августовского LPW там уже 1704 уязвимости. 🤷‍♂️ Но давайте пока разберёмся с июльским. Для одной уязвимости есть признак эксплуатации в реальных атаках:

🔻 RCE - Gogs (CVE-2025-8110). Gogs - это self-hosted веб-сервис для работы с Git-репозиториями, похожий по назначению на GitHub или GitLab. Злоумышленник может добиться удалённого выполнения кода за счёт манипуляции файлом .git/config с использованием обходов через символические ссылки (symbolic link bypasses) и внедрения команды через sshCommand. Доступно множество эксплоитов на GitHub. Уязвимость была добавлена в CISA KEV.

Ещё для 178 уязвимостей есть публичные эксплоиты или признаки их наличия, но пока нет признаков эксплуатации в реальных атаках. Для сравнения, в прошлом месяце таких уязвимостей было 109. Среди них можно выделить:

🔸 RCE - NGINX (CVE-2026-42533). NGINX - это веб-сервер и программное обеспечение для обработки сетевых запросов, которое часто используется как обратный прокси (reverse proxy), балансировщик нагрузки и шлюз для веб-приложений. Неаутентифицированный злоумышленник может проэксплуатировать эту уязвимость для удалённого выполнения кода, отправляя специально сформированные HTTP-запросы.

🔸 RCE - libssh2 (CVE-2026-55200). libssh2 - это библиотека на языке C, реализующая протокол SSH-2 и позволяющая приложениям устанавливать защищённые SSH-соединения, выполнять команды и передавать файлы через SFTP/SCP. Удалённый злоумышленник может отправлять специально сформированные SSH-пакеты с чрезмерно большими значениями packet_length, что приводит к повреждению памяти в куче и позволяет добиться удалённого выполнения кода.

🔸 RCE - Linux Kernel "RefluXFS" (CVE-2026-64600). Атакующий с обычной локальной учётной записью может использовать уязвимость для перезаписи защищённых файлов на диске и получения привилегий root на уязвимых системах, включая инсталляции с SELinux в режиме Enforcing. Фактически уязвимость позволяет сделать пароль пользователя root пустым.

🔸 RCE - Gogs (CVE-2025-64111). Из-за недостаточно полного исправления для CVE-2024-56731 всё ещё существует возможность изменять файлы в каталоге .git и добиться удалённого выполнения кода. Судя по коду эксплоита, для эксплуатации требуется аутентификация.

🔸 CodeInj - MediaWiki (CVE-2026-58025). MediaWiki - это свободная веб-платформа с открытым исходным кодом для создания и управления вики-сайтами, на которой работает Wikipedia и другие проекты с совместным редактированием контента. Атакующий с правами importupload или import (по умолчанию: группа sysop) может создать вредоносный XML-файл импорта, содержащий сериализованные PHP-объекты в полях params, что приводит к созданию произвольных объектов и потенциальному удалённому выполнению кода через цепочки гаджетов.

🔸 RCE - FFmpeg (CVE-2026-8461). FFmpeg - это свободный набор библиотек и утилит для обработки аудио- и видеоданных. Уязвимость записи за пределы буфера (out-of-bounds write) в библиотеке libavcodec проекта FFmpeg, в частности в декодере MagicYUV, позволяет вызвать отказ в обслуживании и в некоторых случаях может быть использована для удалённого выполнения кода.

🔸 RCE - 7-Zip (CVE-2026-14266). 7-Zip - это бесплатный архиватор с открытым исходным кодом, который позволяет создавать и распаковывать архивы различных форматов, включая собственный формат 7z, ZIP, RAR и другие. Специально сформированные данные, сжатые с использованием формата XZ, могут вызвать переполнение буфера в куче. Атакующий может использовать эту уязвимость для выполнения кода в контексте текущего процесса.

🔸 MemCor - Linux Kernel (CVE-2026-53359). Фактически это уязвимость KVM. KVM (Kernel-based Virtual Machine) - это встроенная в ядро Linux технология виртуализации, которая позволяет запускать несколько изолированных виртуальных машин на одном физическом сервере. Уязвимость типа KVM escape позволяет виртуальной машине выйти из изоляции и выполнить код на хосте в среде KVM/x86. Она может эксплуатироваться как на процессорах Intel, так и AMD.

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

Вчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. Баумана

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

Вчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. Баумана

Вчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. Баумана. Альма-матер, конечно, растёт и хорошеет. Первое, что удивило на подходе, - автомобильное движение возле Главного Здания (ГЗ) стало гораздо менее оживлённым, потому что дорогу сузили до одной полосы в каждую сторону. Переходить дорогу теперь стало безопасно, поэтому и светофоры убрали. Такую урбанистику я одобряю. 👍

Новые корпуса рядом с ГЗ поражают масштабом и архитектурой. 😮 Когда я подходил, моросил дождик. То, что площадь между корпусами закрыта навесом, было очень в тему. 😇 Новые корпуса рядом с ГЗ - это небольшая часть. Посмотрите на фотографии макета: везде, где горит свет, это всё теперь Бауманка. 😎

Само мероприятие проходило в студенческом коворкинге Т-Банка, что мне было отдельно приятно, учитывая, сколько долгих и счастливых лет я проработал в Тиньке.

Кроме меня, в качестве экспертов в мероприятии приняли участие Дмитрий Калинин и Аркадий Никифоров из Бастион. Дмитрий руководит департаментом по работе с уязвимостями информационных систем, а Аркадий руководит разработкой инструментов кибербезопасности. Вела мероприятие Олеся Томах с кафедры ИУ-10 МГТУ. В аудитории было около 25 ребят, окончивших 7-8 класс.

Мы начали с рассказа про Positive Technologies и Бастион, и о своих ролях в этих компаниях. Затем обсудили в интерактивной форме разнообразные темы из мира Информационной Безопасности:

🔹 Что такое Vulnerability Management, чем отличается CVE и CWE;
🔹 Важность своевременной установки обновлений безопасности;
🔹 Контроль сетевого периметра (на ярком примере взлома казино через аквариум 😅);
🔹 Zero-click уязвимости мобильных устройств;
🔹 Какую информацию могут собрать умные колонки, пылесосы и камеры в автомобилях.

Много времени уделили вопросу применения искусственного интеллекта в ИБ. Эта тема сейчас, безусловно, волнует всех независимо от возраста. 💯

Также поотвечали в блиц-режиме на вопросы об учёбе и работе.

Время в оживлённой беседе пролетело незаметно. Ребята на интенсиве собрались хорошие, заряженные. Надеюсь, многие из них свяжут свою жизнь с Информационной Безопасностью.

Спасибо большое организаторам за приглашение поучаствовать!

Разбор VM-ной вакансии от R-Vision "Инженер-аналитик по выявлению уязвимостей"

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

Разбор VM-ной вакансии от R-Vision Инженер-аналитик по выявлению уязвимостей

Разбор VM-ной вакансии от R-Vision "Инженер-аналитик по выявлению уязвимостей". Давненько не было у меня постов в этой рубрике. Но вот попалась вакансия в R-Vision, которая очень характерна для VM-вендоров. Я и сам на похожей позиции начинал свой путь в Vulnerability Management. 😇

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

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

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

🔻 Заниматься разработкой и формированием экспертизы (технические стандарты безопасности и информация по уязвимостям) в области информационной безопасности для продуктов компании;

И наконец, нужно написать скрипт, который будет автоматически генерировать правила детектирования уязвимостей:

🔻 Автоматизировать процессы по формированию экспертизы ИБ;

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

Обратите внимание, что выше было про "технические стандарты безопасности". Это про харденинг. На вход аналитику подаётся стандарт по безопасному конфигурированию какого-то продукта (например, от CIS, ФСТЭК или самого вендора продукта). Задача аналитика - разработать для каждого требования автоматическую проверку конкретной инсталляции продукта на соответствие этому требованию. Пока накидываешь проверки, волей-неволей разбираешься и с безопасным конфигурированием. 👍

Все разработанные проверки будут работать в рамках конкретного решения (видимо, R-Vision VM, но возможно, что и не только), поэтому соискателю неизбежно придётся:

🔻 Взаимодействовать с продуктовыми командами с целью улучшения работы продуктов.

Какие скиллы нужны для этой работы? Ну, очевидно, что нужно уметь как-то кодить:

🔸 Знание Git, Python - ваши хорошие друзья;

Очевидно, что соискатель не должен бояться консоли и должен +- быть в курсе, что из себя представляет современная IT-инфраструктура:

🔸 Наличие навыков администрирования Windows, Linux систем;
🔹 Опыт администрирования сетевого и иного оборудования;

Чёткого ТЗ на такой позиции ждать не приходится. Придётся много копать самому, поэтому:

🔸 Способность работать самостоятельно, но и в команде.

Очевидно, было бы неплохо, чтобы соискатель на старте понимал, экспертизу для какого решения он делает. Поэтому желателен:

🔹 Опыт проведения работ по инструментальному анализу защищенности или опыт работы с одним из сканеров безопасности (Nessus, Nexpose, Qualys, Max Patrol, OpenVas, RedCheck, nmap);
🔹 Навыки работы с режимом "Комплаенс" для оценки соответствия;

Тут не могу не поправить коллег, что MaxPatrol пишется в одно слово, и не "OpenVas", а OpenVAS. 😉

Также было бы неплохо, чтобы и про уязвимости соискатель тоже что-то знал:

🔹 Знание актуальных угроз и уязвимостей на Windows/ Linux платформах;
🔹 Опыт применения методологий по описанию, приоритизации и устранению уязвимостей (CVE, CVSS, VPR, OWASP);

Хотя, честно говоря, увидеть в списке сплошь проприетарный Tenable VPR (Vulnerability Priority Rating) было неожиданно. Интересно, что именно имеют в виду под OWASP. OWASP Top 10? 🤔 И в случае R-Vision странно, что в этом списке нет OVAL.

А в этом пункте коллеги намекнули на внутреннюю кухню:

🔹 Понимание принципов работы инструментов автоматизации (Apache Airflow);

Интересно было бы послушать, как именно они Apache Airflow используют при создании VM-ной экспертизы. 😉

VM-ный миф № 5: некоторые уязвимости инфраструктуры можно вообще не устранять

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

VM-ный миф № 5: некоторые уязвимости инфраструктуры можно вообще не устранять

VM-ный миф № 5: некоторые уязвимости инфраструктуры можно вообще не устранять. Сейчас на Западе очень популярна тема Вульнпокалипсиса (Vulnpocalypse). Этот термин обозначает ситуацию, когда скорость обнаружения уязвимостей и появления эксплойтов для них начинает значительно превосходить скорость выпуска обновлений безопасности вендорами ПО и скорость установки этих обновлений их клиентами. В принципе, это уже сейчас похоже на правду: количество CVE растёт настолько быстро, что NVD отказались от анализа всех CVE. Microsoft Patch Tuesday вырос примерно со 100 исправляемых уязвимостей в месяц до 500+. Аналогично, каждый месяц обновляются рекорды по числу уязвимостей в отчётах Linux Patch Wednesday.

Причиной этого обычно называют развитие технологий искусственного интеллекта. И с этим можно отчасти согласиться: ИИ действительно значительно упростил поиск уязвимостей и разработку инструментов для их эксплуатации. Но, на мой взгляд, настоящая причина такого количества уязвимостей - не в ИИ, а в качестве ПО. Десятилетиями вендоры ПО писали ОЧЕНЬ плохой код. Их цель была одна - реализовать как можно больше фич за наименьшее время и наименьшие деньги. Если разработку можно было отдать на аутсорс в страны с максимально дешёвой рабочей силой и низкой культурой разработки - её отдавали. Если можно было взять бесплатный код, непонятно кем написанный и выложенный в открытый доступ (я про open source) - его использовали. В результате мы имеем то, что имеем: огромное количество уязвимостей в этом коде.

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

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

При этом имеет место довольно занимательная ситуация. Покупать продукты клиенты готовы, а выполнять рекомендации вендоров ПО по устранению уязвимостей в купленных продуктах (устанавливать обновления, менять конфигурацию и применять другие меры защиты) они НЕ ГОТОВЫ. И ищут "индульгенции", чтобы этого не делать.

И находят! 🙂 Есть Vulnerability Management (Exposure Management)-вендоры, которые в своём маркетинге транслируют, что "нужно устранять только 1-3% уязвимостей". Только купите их решение, и они вам этот минимальный список уязвимостей покажут. 🔮 Это, конечно, безответственное шарлатанство, потому что супер-критичные уязвимости появляются из общего пула всех неустранённых уязвимостей. И появляются ВНЕЗАПНО! Сегодня уязвимость может не представлять особого интереса, а завтра стать супер-критичной из-за появления публичного эксплоита или обнаружения признаков эксплуатации уязвимости в реальных атаках. Если бы в компании своевременно устранили эту уязвимость по рекомендации вендора ПО, эта супер-критичная уязвимость им бы не была страшна, но, доверившись недобросовестному VM/EM-вендору, вместо планового устранения они получают ещё один "пожар", который может привести к серьёзному инциденту. Таким образом, вместо экономии ресурсов получается бесконечный забег по граблям.

Попытки заранее прогнозировать, какие уязвимости станут супер-критичными, предпринимаются, но их эффективность, мягко говоря, не впечатляет. Например, тот же EPSS частенько показывает высокую вероятность появления эксплоита там, где всё потом годами глухо, и показывает всё по нулям там, где есть и эксплоиты, и атаки. 🥴 С уязвимостями, у которых есть подробные публичные разборы, эксплоиты и контекст от исследователей прогнозирование более-менее работает. Но для большинства уязвимостей, например для тысяч уязвимостей в ядре Linux, такой информации просто нет. Поэтому и утверждать, что конкретную уязвимость можно игнорировать на основе куцего описания из NVD, абсолютно неадекватно и непрофессионально.

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

Определять, какая проблема ПО требует устранения, может только вендор ПО. Только вендор ПО обладает всей полнотой информации. Если вендор ПО выпустил обновление безопасности для продукта, бюллетень безопасности, завёл CVE для уязвимости, это значит, что он считает проблему требующей устранения. И раз обновление вышло - будьте любезны уязвимость устранять. Пока вы пользуетесь софтом, который собирают из очень плохого кода, никакой "серебряной пули", позволяющей отказаться от бесконечного потока исправлений, быть не может. А значит, необходимо смириться с этим и инвестировать в процесс устранения уязвимостей, чтобы он был быстрым, предсказуемым и максимально автоматизированным.

У Антона Чувакина, в прошлом главного идеолога Gartner по Vulnerability Management, недавно вышел блогпост, в котором он предлагает провести мысленный эксперимент:

"Представьте, что завтра утром вы просыпаетесь, и благодаря настоящему волшебству любую уязвимость в ваших системах, приложениях и операционных системах можно устранить всего за 15 минут после выхода исправления. Мечта стала реальностью.

Теперь самое интересное - попробуйте разобраться, как это стало возможным.

Какие фундаментальные изменения должны были произойти в вашей инфраструктуре, чтобы такое 15-минутное окно стало реальностью?

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

Приведет ли это всю компанию к 15-минутному циклу установки исправлений? Скорее всего, нет, особенно если речь идет об устаревших системах. Но это даст вам четкую, практическую дорожную карту для модернизации вашей ИТ-инфраструктуры."

Ну а стратегически хотелось бы, чтобы безнаказанный выпуск дырявого ПО, предполагающий постоянный патчинг, когда-нибудь прекратился. И чтобы компании-клиенты стали использовать продукты от вендоров, которые инвестируют не только в поиск уязвимостей, но и в безопасную разработку кода по принципу secure by design. Да, такие решения стоили бы гораздо дороже. Но если продукт по факту имеет меньше уязвимостей и реже требует экстренных обновлений, его эксплуатация становится значительно проще и безопаснее. "Жаль только - жить в эту пору прекрасную. Уж не придется - ни мне, ни тебе." © 😉

Архитектура Kaspersky Vulnerability Management 1.0

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

Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0

Архитектура Kaspersky Vulnerability Management 1.0. Две недели назад, 16 июля, прошёл вебинар Kaspersky, на котором представили решение Kaspersky Vulnerability Management 1.0. В этом посте хотелось бы рассмотреть первую часть вебинара, посвящённую архитектуре. Позже планирую разобрать и часть с демо, и блок ответов на вопросы.

Участники вебинара:

🔹 Мария Погребняк - отвечает за развитие бизнеса Vulnerability Management в "Лаборатории Касперского";
🔹 Максим Лызаев - presale, стоял у истоков продукта;
🔹 Дмитрий Волошин - presale, опыт в vulnerability management, в команде VM около полугода.

В декабре вышла бета-версия продукта, которую протестировали партнёры и заказчики - часть их замечаний успели учесть в первом релизе.

Начали с контекста, почему решение выпустили именно сейчас: уже пять лет как минимум треть атак идёт через уязвимости, и это стабильно первое место в рейтинге векторов атак. После 2022 года российский VM-рынок сильно изменился и пополнился новыми вендорами. Последние два года заказчики Kaspersky просили у компании собственное VM-решение.

Заявленные ключевые преимущества:

🔻 Инвентаризация и управление активами - зрелая развитая функциональность за счёт бесшовной интеграции с Kaspersky Security Center; заказчики, уже использующие KSC, отмечают простоту инвентаризационного этапа;

🔻 Несколько способов сканирования - агентный способ (считается преимуществом и более мощным методом) и сетевой скан (альтернатива там, где агент использовать невозможно или не нужно) - охват инфраструктуры с обеих сторон;

🔻 Работа с ошибками конфигураций как с уязвимостями - предустановленные профили ФСТЭК и международные бенчмарки; одна из функциональностей, давшая больше всего положительной обратной связи от партнёров и заказчиков;

🔻 Patch management - функциональность уже была в endpoint-продукте; преимущество в процессной составляющей - возможность пропатчить некоторый перечень ПО, убрав "фоновый шум".

Общая архитектура. Продукт работает в паре с KSC. Для коммерческого релиза VM 1.0 нужен KSC для Linux версии 16.3. VM устанавливается рядом - на том же сервере либо на отдельном. Сам VM (Vulnerability Management) - это несколько сервисов и собственная база данных: у KSC своя база, у VM своя. Используются агенты, подчинённые KSC. Агенты могут устанавливаться на Linux и на Windows - ограничений нет, но версия агентов также должна быть 16.3. У KSC есть веб-консоль. Чтобы добавить в неё разделы, касающиеся VM, устанавливается отдельный плагин.

Сценарий агентного сканирования. Агенты собирают информацию с конечных устройств: список установленного ПО, данные об операционной системе - и отправляют её на сервер по расписанию и по триггеру (триггером служит установка или удаление ПО на устройстве). Эта информация накапливается на сервере, где по расписанию, заданному администратором, запускается отдельная задача. Она сверяет полученные данные с базами уязвимостей и формирует результат, который отображается в консоли и отчётах. Этот сценарий можно назвать асинхронным: агенты отправляют информацию в своём темпе, а задача анализа на сервере работает по расписанию администратора. На практике это означает, что если устройство было доступно вчера, а сегодня офлайн - например, сотрудник ушёл в отпуск - и в тот же день в базах появились новые уязвимости, система всё равно найдёт их на этом устройстве, поскольку данные о нём уже сохранены на сервере. Второй вывод: запуск задачи на сервере не влияет на производительность конечных устройств. Задачу можно запускать хоть каждый час - она работает только с данными, уже имеющимися на сервере, независимо от состояния агентов. Передача списка ПО и данные об ОС занимают килобайты, поэтому нагрузка на сеть и вычислительные ресурсы минимальна и, скорее всего, останется незаметной.

Декларируемые преимущества агентного сканирования:

🔸 Если заказчик уже использует endpoint-агент "Лаборатории Касперского", это тот же агент - к нему просто добавляется функциональность управления уязвимостями. Именно поэтому внедрение простое: основной движок в инфраструктуре компании уже есть.

🔸 Агент передаёт на сервер сканирования данные о том, какие настройки на рабочей станции закрыты, какой порт закрыт или какое ПО "заблокировано". Благодаря этому в сводке уязвимостей не появляются уязвимости для "ПО, к которому нет доступа". Такие детали снижают число ложных срабатываний и делают итоговую картину более точной. Мой комментарий: Это интересный момент. По сути, продукт каким-то образом по умолчанию фильтрует детектируемые уязвимости по дополнительному набору критериев. Какие именно это критерии и насколько такое поведение корректно - нужно будет разбираться отдельно, поэтому здесь ждём подробностей. 😉

🔸 Агент не требует передачи учётных данных, поскольку уже работает под достаточно привилегированной учётной записью на конечном устройстве - передавать креды по сети не нужно. При атаках хакеры в первую очередь охотятся за учёткой сканера, работающего под админскими правами. В случае агентного сканирования единой учётной записи нет - у каждой рабочей станции своя учётка, поэтому этот риск снимается.

Читать далее →

VM-ный миф № 4: можно значительно улучшить процесс Управления Уязвимостями, если найти правильные слова для руководства

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

VM-ный миф № 4: можно значительно улучшить процесс Управления Уязвимостями, если найти правильные слова для руководства

VM-ный миф № 4: можно значительно улучшить процесс Управления Уязвимостями, если найти правильные слова для руководства. Довольно часто поступают вопросы в духе: "как аргументированно обосновать необходимость выстраивания полноценного процесса Vulnerability Management в организации, а не выборочного устранения отдельных находок сканера?" Когда от руководства при этом звучат возражения вроде "у нас были инциденты только через фишинг, а не через эксплуатацию уязвимостей", "построение процесса требует новой штатной единицы и бюджета", "безусловный патчинг создаст огромные трудозатраты" и т.д.

Нет, ну в целом можно посоветовать использовать методологию результативной кибербезопасности и вместе с руководителем определить, что именно "болит" в организации - какие недопустимые события (слив критичных данных, кража денег, остановка бизнес-процессов, для реального сектора вплоть до техногенных катастроф) могут реализовать злоумышленники на целевых активах. Суть в том, что затраты на выстраивание процесса будут несопоставимо меньше потенциальных потерь от инцидента, способного обрушить прибыль компании на 30-40%, вынудить сокращать штат или закрыться. На возражение "нас ломали только через фишинг, а не через уязвимости" можно объяснить, что попав внутрь через фишинг, злоумышленник продвигается к важным системам именно через уязвимости. Можно предложить пентест, чтобы оффенсив-специалисты показали реальность проблем на практике. Для компаний, подпадающих под требования регулятора, можно апеллировать к нормативке, требующей постоянного выявления и устранения уязвимостей.

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

На то, что ТОП-менеджмент организации может чего-то там не понимать, я бы тоже не вёлся. 😏 Люди, добравшиеся до этого уровня - как правило, умные, циничные и с отличным кругозором. Во всяком случае CIO и CTO. А уж тем более ваш родной CISO. Всё они понимают: и про атаки, и про уязвимости, и про возможный ущерб. Поэтому если VM-ная тема в организации недофинансируется и фактически саботируется - значит, всех всё устраивает. 😉 На этом сознательно экономят, рассчитывая на то, что:

🔻 VM-щик из подручного материала соберёт что-то похожее на работающий процесс и будет носиться как белка-истеричка, поддерживая его и затыкая собой дыры; 🤪

🔻 в случае инцидента сам же VM-щик и станет крайним. F 🫡

Поэтому, ИМХО, если руководство организации принципиально не готово выделять ресурсы на VM и насаждать его сверху, углубляться в разъяснения нерационально. "Если надо объяснять, то не надо объяснять". © Не хотят ТОПы работающего VM-процесса - значит, его не будет. Хотят пройти через критичный киберинцидент прежде чем внедрять базовые ИБ-процессы - значит, будет так. Плетью обуха не перешибёшь. VM-щику в такой организации вместо отчаянного евангелизма лучше потратить время на что-то более полезное. Резюме обновить например. 😉 А если смена работы не вариант - как минимум осознавать положение вещей, границы своих возможностей и стараться самому не подставляться почём зря.

Июльский Microsoft Patch Tuesday

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

Июльский Microsoft Patch Tuesday

Июльский Microsoft Patch Tuesday. На второй неделе июля я был в отпуске в Санкт-Петербурге, потом навалились другие задачки, поэтому выпускаю обзор только сейчас. Но лучше поздно, чем вообще никогда. Особенно учитывая, какой в этот раз необычный MSPT. 😉 Всего 571 уязвимость, почти в 3 раза (❗️) больше, чем в июне. Есть 4 уязвимости с признаком эксплуатации в реальных атаках:

🔻 RCE - Microsoft SharePoint (CVE-2026-58644). Злоумышленник с правами не ниже владельца сайта (Site Owner) может внедрить и удаленно выполнить произвольный код на сервере SharePoint.

🔻 RCE - Microsoft SharePoint (CVE-2026-50522). Описание уязвимости аналогично CVE-2026-58644. По данным ZDI, уязвимость CVE-2026-50522 была успешно продемонстрирована на Pwn2Own Berlin. Несмотря на это, Microsoft указывает статус Exploit Maturity как "Unknown", хотя исследователи уже предоставили компании рабочий эксплойт. Это еще раз показывает, что не стоит полностью полагаться на оценки вендоров ПО и лучше самостоятельно оценивать риски. Если у вас есть серверы SharePoint, доступные из Интернет, рекомендуется как можно скорее протестировать и установить обновление, устраняющее уязвимость.

🔻 EoP - Microsoft SharePoint Server (CVE-2026-56164). Уязвимость в Microsoft Office SharePoint позволяет неаутентифицированному злоумышленнику удаленно повысить свои привилегии. Microsoft рекомендует включить интерфейс антивирусного сканирования AMSI на сервере и установить режим проверки тела запросов (Request Body Scan) в значение Full для снижения риска эксплуатации уязвимости.

🔻 EoP - Active Directory Federation Services (CVE-2026-56155). Недостаточная гранулярность управления доступом (CWE-1220) в Active Directory Federation Services (AD FS) позволяет авторизованному злоумышленнику локально повысить свои привилегии. Успешная эксплуатация этой уязвимости может позволить злоумышленнику получить права администратора.

Есть ещё 8 уязвимостей с публичным эксплоитом:

🔸 EoP - Windows User Interface Core (CVE-2026-50454). Уязвимость, связанная с обходом относительного пути (Relative Path Traversal, CWE-23) позволяет авторизованному злоумышленнику локально повысить свои привилегии. В случае успешной эксплуатации этой уязвимости злоумышленник может получить привилегии уровня SYSTEM. PoC эксплоита запускается из обычного процесса без повышенных привилегий, принадлежащего локальному администратору, и открывает интерактивную командную строку с правами NT AUTHORITY\SYSTEM.

🔸 EoP - Windows WalletService (CVE-2026-49176). Неправильное управление привилегиями (CWE-269) позволяет авторизованному злоумышленнику локально повысить свои привилегии. PoC-эксплойта запускает командную строку с правами SYSTEM.

🔸 RCE - Microsoft Message Queuing Queue Manager (CVE-2026-54992). Существующий PoC эксплоита демонстрирует отказ в обслуживании (DoS), а не выполнение кода.

🔸 EoP - Windows Narrator Braille (CVE-2026-58635). Согласно описанию Microsoft, злоумышленник, успешно проэксплуатировавший эту уязвимость, сможет выполнить произвольный код в контексте безопасности учётной записи NT AUTHORITY\Network Service. Однако в описании PoC-а эксплоита сообщается, что непривилегированный злоумышленник сможет получить права NT AUTHORITY\SYSTEM.

🔸 EoP - Windows Cloud Files Mini Filter Driver (CVE-2026-58613). Использование памяти после её освобождения (use after free, CWE-416) в драйвере Windows Cloud Files Mini Filter Driver позволяет авторизованному злоумышленнику локально повысить свои привилегии. В случае успешной эксплуатации этой уязвимости атакующий может получить привилегии SYSTEM. Подробности эксплуатации описаны в отчёте Talos Vulnerability Report TALOS-2026-2426.

🔸 InfDisc - Windows Win32k (CVE-2026-50416). Злоумышленник, успешно проэксплуатировавший эту уязвимость, потенциально может прочитать небольшие фрагменты памяти кучи (heap memory). В описании PoC-а эксплоита упоминаются вкладки Chrome, Discord, Explorer, Spotify и окна в системном трее. Но похоже перехватывать пароли с помощью этой уязвимости не получится.

🔸 InfDisc - Windows Kernel (CVE-2026-50475). Чтение данных за пределами буфера (buffer over-read, CWE-126) в ядре Windows позволяет авторизованному злоумышленнику локально раскрыть конфиденциальную информацию. Подробности эксплуатации описаны в отчёте Talos Vulnerability Report TALOS-2026-2443.

🔸 EoP - Azure Spring Apps (CVE-2026-50338). Злоумышленник, успешно проэксплуатировавший данную уязвимость, может получить повышенные привилегии. Если верить автору PoC-а эксплоита, речь идёт об уязвимости, позволяющей обойти аутентификацию между издателями (cross-issuer authentication bypass) в ресурсном сервере Spring Cloud Azure B2C.

Из остальных уязвимостей можно выделить:

🔹 RCE - Windows Remote Desktop Protocol (CVE-2026-56190). Для эксплуатации этой уязвимости не нужны авторизация и взаимодействие с пользователем. Причина проблемы - использование неинициализированного ресурса (CWE-908). Специально подготовленный RDP-трафик может вызвать ошибку, которая в некоторых случаях позволяет злоумышленнику выполнить код. RDP-серверы часто становятся целью атак, поэтому стоит проверить, какие системы доступны из Интернет, и в первую очередь обратить внимание на них.

🔹 RCE - Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central (On Premises) (CVE-2026-55944). Уязвимость можно эксплуатировать, отправив специально подготовленный запрос на вход в уязвимый сервер Dynamics NAV или Business Central. Это приводит к обработке недоверенных данных и может позволить злоумышленнику выполнить код. Для эксплуатации не требуется взаимодействие с пользователем или аутентификация.

🔹 EoP - Microsoft Windows VMSwitch (CVE-2026-57092). Это уязвимость типа use-after-free, которая позволяет злоумышленнику с низкими привилегиями получить полный контроль над хост-системой через границу виртуальной машины ("across a VM boundary"). Эксперты ZDI сообщали, что похожий эксплойт был продемонстрирован на ESXi во время Pwn2Own Berlin, однако проблема не ограничивается только ESXi. Если в ваших системах Hyper-V используется VMSwitch (что, скорее всего, так), рекомендуется как можно быстрее проверить и установить исправление.

🔹 Spoofing - Microsoft Exchange (CVE-2026-55008). Злоумышленник может отправить специально подготовленное письмо, которое выполнит JavaScript-код при открытии в OWA. Для атаки не нужны ни вложения, ни макросы - достаточно просто открыть письмо. Если в вашей организации используется OWA, лучше как можно скорее проверить и установить исправление.

🔹 RCE - Windows DHCP Server (CVE-2026-50518, CVE-2026-56159, CVE-2026-48564, CVE-2026-50370), Windows DHCP Client (CVE-2026-54128), Windows Message Queuing Service (MSMQ) (CVE-2026-50447), Windows Admin Center (WAC) (CVE-2026-56196), Windows FTP Service (CVE-2026-49172), Windows GDI+ (CVE-2026-50380), Windows Server Network driver (CVE-2026-56188), Microsoft Exchange (CVE-2026-55005), Windows Active Directory Domain Services (CVE-2026-49178), Windows Remote Desktop Client (CVE-2026-50474), Windows Remote Desktop Client (CVE-2026-54990, CVE-2026-58594), Windows TCP/IP (CVE-2026-54999), Windows Print Spooler (CVE-2026-58608), Windows Reliable Multicast Transport Driver (RMCAST) (CVE-2026-54982, CVE-2026-54995), Microsoft SQL Server (CVE-2026-54117), Microsoft Copilot (CVE-2026-48561).

🔹 SFB - Microsoft SharePoint Server (CVE-2026-55040).

🔹 EoP - Windows Server Update Service (WSUS) (CVE-2026-50444), Active Directory Certificate Services (CVE-2026-54121).

Есть и довольно курьёзная уязвимость:

🔹 RCE - Game: Age of Empires II: Definitive Edition (CVE-2026-50663). 😃 Уязвимость обхода относительных путей (Relative Path Traversal) в игре Age of Empires II: Definitive Edition позволяет неаутентифицированному злоумышленнику выполнять код по сети. Age of Empires II - это культовая стратегия в реальном времени от Microsoft, действие которой происходит в средневековую эпоху. Игроки развивают выбранные цивилизации, управляют ресурсами, исследуют технологии и командуют армиями в исторических кампаниях и многопользовательских сражениях. Definitive Edition включает улучшенную графику, обновлённое звуковое сопровождение и дополнительный контент. Если до сих пор играете в это - обязательно обновитесь. 😉

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