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

О правильном понимании термина "exposure" ("экспозиция") в контексте Exposure Management (Управление Экспозициями) и Continuous Threat Exposure Management (CTEM, Непрерывное Управление Экспозициями с учётом Угроз)

О правильном понимании термина exposure (экспозиция) в контексте Exposure Management (Управление Экспозициями) и Continuous Threat Exposure Management (CTEM, Непрерывное Управление Экспозициями с учётом Угроз)

О правильном понимании термина "exposure" ("экспозиция") в контексте Exposure Management (Управление Экспозициями) и Continuous Threat Exposure Management (CTEM, Непрерывное Управление Экспозициями с учётом Угроз). Я решил вернуться к этому вопросу, более-менее подробно описать историю использования термина "exposure", а также обосновать, почему я считаю корректным определять термин "exposure" как "уязвимость в широком смысле". Сделаю я это на основе своих выступлений и дискуссий на конференциях Security Summit, Территория Безопасности и Периметр, а также семинаре компании "Киберпротект", проходивших этой весной.

Повторюсь, что у меня к термину "exposure" отношение непростое. Был период, когда он мне категорически не нравился, и я выступал против его использования. Но постепенно, как в знаменитой книге Дейла Карнеги, я перестал беспокоиться и научился с ним жить. 🙂

🎓 (НЕ)Использование в академической ИБ

Когда мы говорим об уязвимостях ("vulnerability"), мы обычно понимаем под этим ошибки программного обеспечения, "баги", которые злоумышленники могут использовать для реализации своих зловредных целей. Всё у чего есть CVE или БДУ идентификатор - это уязвимость. При этом если посмотреть формальное определение уязвимости, то оно окажется гораздо более широким. У ФСТЭК это "слабость актива или управления, эксплуатация которой приведёт к реализации одной или нескольких угроз" (ISO/IEC 27000:2014) или "Недостаток (слабость) программного (программно-технического) средства или информационной системы в целом, который (которая) может быть использована для реализации угроз безопасности информации" (ГОСТ Р 56545-2015). В глосарии NIST самое популярное определение уязвимости, используемое в 17 документах, звучит так: "слабость в информационной системе, процедурах обеспечения безопасности системы, внутренних контролях или реализации, которая может быть эксплуатирована или задействована источником угрозы".

А откуда взялось "exposure"? Это слово очень многозначное как в самом английском языке, так и при переводе на русский. В зависимости от контекста его могут переводить как подвергание, выставление, выставка, местоположение, обнажение, вид и т.д.

В академической информационной безопасности термин "exposure" практически не используется. Если термин "vulnerability", согласно глоссарию NIST встречается в 39 документах, то термин "exposure" только в двух:

🔹 В документе NIST SP 800-161r1-upd1 Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations под "exposure" понимается "степень, в которой организация и/или заинтересованная сторона подвержена риску".

🔹 В документе NISTIR 8286 Integrating Cybersecurity and Enterprise Risk Management (ERM) под "exposure" понимается "комбинация уровней вероятности и воздействия для риска".

Несмотря на низкую академическую востребованность, термин "exposure" в настоящее время активно используется индустриальной ИБ-экосистемой (Gartner, крупные вендоры, консалтинговые и платформенные игроки), но в иных смыслах.

⚙️ Эпоха Tenable

Одним из главных популяризаторов термина стала компания Tenable, которая с 2017 года начала продвигать концепт "Cyber Exposure" как "новую развивающуюся дисциплину управления и измерения современной поверхности атаки, позволяющую точно понимать и снижать киберриски" (Tenable Delivers Record Results in Q2 and the First Half of 2017). Однако при описании этого "Cyber Exposure" они используют термин "exposure", не определяя его. 🤷‍♂️ "Cyber Exposure также обеспечивает непрерывную видимость того, где активы защищены, а где они находятся в состоянии exposure и в какой степени, а также приоритизирует устранение проблем на основе критичности актива для бизнеса и степени выраженности exposure". Себя Tenable начали называть "Cyber Exposure company".

Также в 2017 году Tenable представили Cyber Exposure ecosystem - интеграционную экосистему, объединяющую инструменты безопасности и IT (ServiceNow, AWS, Splunk и другие) для сквозного управления киберриском за счёт обмена данными, автоматического обнаружения активов и ускорения приоритизации и устранения уязвимостей на всей современной поверхности атаки.

К 2019 году у Tenable "Cyber Exposure" уже используется как измеряемая модель киберриска: в Tenable Lumin они вводят Cyber Exposure Score, который объединяет вероятность эксплуатации уязвимостей и критичность активов, позволяет количественно оценивать уровень "exposure", сравнивать его во времени и между организациями и использовать это для приоритизации устранения рисков и принятия риск-ориентированных решений.

Таким образом, можно сказать, что до начала 2020-х годов термин "exposure" в рамках материалов Tenable не имел единого фиксированного самостоятельного определения и использовался как "плавающий" термин-оболочка, которому в разных контекстах придавались различные значения: от обозначения новой дисциплины управления и измерения киберриска, до общей подверженности риску, состояния уязвимости активов, степени их "открытости" атаке, агрегированного риска (с учётом вероятности и ущерба), интеграции уязвимостей и конфигураций в единую модель, а также количественного скоринга для ранжирования и приоритизации устранения проблем. 🤯

Читать далее

Про уязвимость Cross Site Scripting - Microsoft Exchange (CVE-2026-42897)

Про уязвимость Cross Site Scripting - Microsoft Exchange (CVE-2026-42897)

Про уязвимость Cross Site Scripting - Microsoft Exchange (CVE-2026-42897). Уязвимость была исправлена 14 мая вне регулярных Microsoft Patch Tuesday. Неправильная нейтрализация входных данных при генерации веб-страницы (CWE-79, "межсайтовый скриптинг") в Microsoft Exchange Server позволяет неавторизованному злоумышленнику осуществить атаку с подменой (spoofing) по сети. Фактически это означает, что удалённый злоумышленник может отправить пользователю специально сформированное электронное письмо. Если пользователь откроет это письмо в Outlook Web Access (OWA) и будут выполнены определённые условия взаимодействия, произвольный JavaScript-код может быть выполнен в контексте браузера пользователя. В результате злоумышленник может получить контроль над почтовым ящиком пользователя, используя активную пользовательскую сессию.

👾 Для этой уязвимости эксперты Microsoft сразу указали признаки эксплуатации вживую. Уязвимость была добавлена в CISA KEV 15 мая.

⚒️ Публичный эксплойт для уязвимости был опубликован на GitHub также 15 мая.

⚙️ Первоначально для устранения уязвимости предлагали использовать меры митигации, распространяемые через службу Exchange Emergency Mitigation (EM) или с помощью скрипта Exchange on-premises Mitigation Tool (EOMT). Обновления безопасности для Microsoft Exchange Server Subscription Edition RTM, а также Exchange Server 2016 и 2019, устраняющие уязвимость, были выпущены практически через месяц, 9 июня. Эксперты Microsoft рекомендовали оставить включёнными меры митигации и после установки патча, поскольку они обеспечивают дополнительный уровень защиты. Однако применение этих мер митигации может вызывать проблемы (например, ошибки при печати календаря и отображении изображений в OWA).

⚠️ Обратите внимание, что Exchange Server 2016 и 2019, срок поддержки которых уже завершился, также подвержены этой уязвимости. Обновления безопасности для Exchange Server 2016 и 2019, выпущенные в период с мая по октябрь 2026 года, доступны только клиентам, участвующим во втором этапе программы Extended Security Update (ESU).

Автоматическая генерация рекомендаций по устранению уязвимостей в облачном DAST-сканере приложений PT BlackBox с помощью нового ИИ-помощника PT Naira от Positive Technologies

Автоматическая генерация рекомендаций по устранению уязвимостей в облачном DAST-сканере приложений PT BlackBox с помощью нового ИИ-помощника PT Naira от Positive TechnologiesАвтоматическая генерация рекомендаций по устранению уязвимостей в облачном DAST-сканере приложений PT BlackBox с помощью нового ИИ-помощника PT Naira от Positive TechnologiesАвтоматическая генерация рекомендаций по устранению уязвимостей в облачном DAST-сканере приложений PT BlackBox с помощью нового ИИ-помощника PT Naira от Positive TechnologiesАвтоматическая генерация рекомендаций по устранению уязвимостей в облачном DAST-сканере приложений PT BlackBox с помощью нового ИИ-помощника PT Naira от Positive Technologies

Автоматическая генерация рекомендаций по устранению уязвимостей в облачном DAST-сканере приложений PT BlackBox с помощью нового ИИ-помощника PT Naira от Positive Technologies.

🤖 Для каждой найденной уязвимости в интерфейсе PT BlackBox Scanner предусмотрена отдельная карточка (описание уязвимости, затронутый URL, технические детали и общие рекомендации по исправлению). Теперь в этой карточке в разделе "Как исправить?" появилась кнопка "Получить рекомендацию Positive LLM". При нажатии система начинает собирать контекст, связанный с обнаруженной проблемой: тип уязвимости, особенности целевого веб-приложения, характеристики обнаруженного технологического стека. На основе этих и других данных PT BlackBox Scanner формирует специализированный промпт и отправляет его в PT Naira. Во время генерации модель анализирует собранный контекст и формирует рекомендации с учётом особенностей конкретного приложения.

📋 Генерация рекомендаций занимает 5-7 секунд, встроена прямо в процесс анализа уязвимостей и не требует отдельного общения с ИИ-помощником. В результате пользователь получает пошаговую инструкцию: что именно настроено неправильно, почему это может быть опасно и как исправить проблему.

☁️ Сам помощник PT Naira работает в облаке Positive Technologies как SaaS-решение. Т.к. PT BlackBox Scanner работает в том же облаке, интеграция включается буквально за 20 секунд. Все данные об уязвимостях клиентов остаются под контролем Positive Technologies и не передаются третьим лицам или внешним LLM.

Также PT Naira уже интегрировали с MaxPatrol SIEM версии 27.6 и выше для объяснения событий безопасности. В планах расширение списка продуктов Positive Technologies, с которыми работает PT Naira.

Как считаете, какие функции Vulnerability Management-решений можно было бы улучшить с помощью интеграции с PT Naira?

Июньский Linux Patch Wednesday

Июньский Linux Patch Wednesday

Июньский Linux Patch Wednesday. Всего 1888 уязвимостей (324 в ядре Linux, и aж 728 в Chromium ❗️). Для сравнения, в мае было 1638 уязвимостей. Рост не такой внушительный, как с апреля по май, но всё равно новый рекорд поставлен. Для одной уязвимости есть признак эксплуатации вживую:

🔻 RCE - Chromium (CVE-2026-11645). Chromium - это веб-браузер с открытым исходным кодом, служащий основой для многих современных браузеров, включая Google Chrome, Microsoft Edge, Brave, Opera и Vivaldi. Публично доступный модуль Metasploit эксплуатирует уязвимость в JavaScript-движке V8 браузера. Она срабатывает при использовании специфической конструкции кода, вызывающей type confusion между внутренними объектами V8, что приводит к выходу за границы памяти. Успешная эксплуатация уязвимости может привести к удаленному выполнению кода в контексте процесса браузера.

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

🔸 EoP - Linux Kernel "CIFSwitch" (CVE-2026-46243). Эта уязвимость позволяет злоумышленнику подделывать описания ключей аутентификации CIFS ("forge CIFS authentication key descriptions"), эксплуатировать механизм запроса ключей ядра ("kernel's key request mechanism") и получать права root.

🔸 EoP - Linux Kernel "PinTheft" (CVE-2026-43494). При успешной эксплуатации управление передаётся SUID-исполняемому файлу с перезаписанной первой страницей памяти ("hands off to the discovered SUID binary with an overwritten first page"), что позволяет получить root-овый шелл.

🔸 RCE - Apache ActiveMQ (CVE-2026-42588). ActiveMQ - это брокер сообщений с открытым исходным кодом, написанный на Java. Для эксплуатации уязвимости нужна учётка ActiveMQ Web Console. Однако по умолчанию используется учётная запись admin/admin.

🔸 InfDisc - Squid "Squidbleed" (CVE-2026-47729). Squid - это кэширующий прокси-сервер с открытым исходным кодом. Из-за данной уязвимости FTP-парсер Squid считывает информацию за пределами буфера памяти, переходя в область, где могут сохраниться неочищенные данные HTTP-запросов предыдущего пользователя.

🔸 AuthBypass - Nextcloud (CVE-2026-45156). Nextcloud - это платформа с открытым исходным кодом для совместной работы с контентом. Отсутствие проверки подписи ("missing signature verification") в User OIDC позволяет вредоносному центру ID4me ("malicious ID4me authority") выдавать себя за любого пользователя.

🔸 XSS - Nextcloud (CVE-2025-59788). Уязвимость в доступном извне ("reachable") каталоге с примерами files_pdfviewer в Nextcloud позволяет злоумышленникам выполнять произвольный JavaScript-код в контексте браузера пользователя посредством специально сформированного PDF-файла, передаваемого в viewer.html.

🔸 XSS - Roundcube (CVE-2026-48849). Roundcube - это бесплатный веб-клиент электронной почты с открытым исходным кодом. Отсутствие очистки поля темы ("unsanitized subject field") при восстановлении значения черновика может привести к хранимой XSS/HTML/CSS-инъекции в общих почтовых ящиках.

🔸 DoS - ImageMagick (CVE-2026-46522). ImageMagick - это бесплатное ПО с открытым исходным кодом для редактирования и обработки цифровых изображений. Из-за отсутствия проверки в декодере MIFF ("missing check in the MIFF decoder") специально сформированный файл может вызывать бесконечный цикл, приводящий к исчерпанию ресурсов процессора ("CPU exhaustion").

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

Kaspersky пишут о PowerShell-скрипте, который угоняет сессии Telegram и предоставляет злоумышленникам доступ к аккаунтам без пароля и кодов подтверждения, и рекомендуют своевременно обновлять приложения и операционную систему

Kaspersky пишут о PowerShell-скрипте, который угоняет сессии Telegram и предоставляет злоумышленникам доступ к аккаунтам без пароля и кодов подтверждения, и рекомендуют своевременно обновлять приложения и операционную систему

Kaspersky пишут о PowerShell-скрипте, который угоняет сессии Telegram и предоставляет злоумышленникам доступ к аккаунтам без пароля и кодов подтверждения, и рекомендуют своевременно обновлять приложения и операционную систему. Исследователи обнаружили на Pastebin вредоносный PowerShell-скрипт, замаскированный под "обновление телеметрии Windows". Зловред был предназначен для кражи данных сессий виндового клиента Telegram. В коде находились токен Telegram-бота, ID чата и ссылки на папку tdata, где Telegram хранит ключи аутентификации ("authorization keys"). После запуска скрипт собирал информацию о системе, закрывал Telegram Desktop, архивировал содержимое tdata, отправлял архив злоумышленникам через Telegram-бота и затем удалял этот архив для сокрытия следов. Используя эти данные, атакующие могли получить полный контроль над аккаунтом жертвы без пароля и кода подтверждения.

При этом эксперты не обнаружили признаков фактической передачи данных и считают, что скрипт находился на стадии прототипа. На это указывает и то, что Telegram-бот использовал временное имя afhbhfsdvfh_bot и откровенное описание "Telegram attacker". Это к слову о том, что может скрываться за левым ботом, маскирующимся под название Телеграм-канала. По мнению исследователей, злоумышленники уже тестировали инструмент, но ещё не успели развернуть его для масштабных атак.

Основными каналами распространения таких PowerShell-скриптов выступают вредоносные почтовые вложения, эксплуатация уязвимостей, заражённое ПО и методы социальной инженерии, поэтому:

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

Также для защиты Telegram-аккаунта:

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

Продолжая комментарии к статье Ведомостей про роль ИИ в поиске новых уязвимостей, следует отметить следующее: не так страшно детектирование zero-day уязвимостей с помощью ИИ, сколько вепонизация n-day (или уже скорее n-hour 😉) уязвимостей с помощью ИИ

Продолжая комментарии к статье Ведомостей про роль ИИ в поиске новых уязвимостей, следует отметить следующее: не так страшно детектирование zero-day уязвимостей с помощью ИИ, сколько вепонизация n-day (или уже скорее n-hour 😉) уязвимостей с помощью ИИ

Продолжая комментарии к статье Ведомостей про роль ИИ в поиске новых уязвимостей, следует отметить следующее: не так страшно детектирование zero-day уязвимостей с помощью ИИ, сколько вепонизация n-day (или уже скорее n-hour 😉) уязвимостей с помощью ИИ. Т.е. использование ИИ для разработки эксплоитов на основе патчей и публичной информации об уязвимостях. Новую неизвестную уязвимость нужно ещё понять, где искать. А найдя, придумать вменяемый сценарий атаки с эксплуатацией этой уязвимости. Это работа на удачу, своего рода золотоискательство или, вспоминая Маяковского: "…та же добыча радия. В грамм добыча, в годы труды. Изводишь единого слова [уязвимости] ради тысячи тонн словесной руды [проверенного кода и неподтвердившихся гипотез эксплуатации]." Конечно, в случае использования ПО с открытым кодом задача анализа упрощается. Но всё равно найти что-то стоящее весьма непросто. Поэтому, кстати, я противник того, чтобы результаты этой добычи бесконтрольно утекали за рубеж.

Другое дело, когда уязвимость уже известная, с присвоенным CVE, вендорским описанием, признанной критичностью и выпущенным патчем. Тут задача серьёзно упрощается.

🔹 Понятно, где искать. Очевидно, там, где вендор исправляет что-то патчем.

🔹 Понятно, что нужно получить в результате. То, о чём вендор сообщил в описании уязвимости.

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

Естественно, этим занимаются не только исследователи watchTowr Labs. 😏 Тем более, что ИИ-агенты значительно упрощают процесс вепонизации, а то и полностью его автоматизируют. Как сообщает Денис Макрушин, стоимость автономной разработки эксплоита сейчас может составлять даже меньше 3 долларов. И ведь прогресс в ИИ пока не останавливается! Разработанные эксплойты могут выкладываться исследователями в паблик ради самопиара и общественного блага (ну, как они его себе видят), а могут и не выкладываться, а, например, продаваться на чёрном рынке. 😈 А затем эти эксплоиты будут использоваться в атаках на организации, пока их не спалят и факт эксплуатации уязвимости не станет подтверждённым. И всё это бесконечно повторяется для всё новых и новых уязвимостей. It's the circle of life and it moves us all

Что вся эта движуха означает для простого VM'щика? Нарратив, который двигали многие VM-вендоры: "Патчьте только 3% уязвимостей, которые мы вам подсветим, а на остальные просто забейте", с самого начала выглядел булшитненько и безответственно, а в условиях ускорения и удешевления вепонизации n-day-уязвимостей и подавно. Аргументов, что любая уязвимость может внезапно выстрелить и привести к инциденту, значительно прибавилось. А значит, нужно стремиться к приоритизированному устранению всех уязвимостей, что создаёт значительную нагрузку на IT, особенно если IT-инфраструктура организации не была изначально рассчитана на непрерывную установку и тестирование обновлений безопасности. 🤷‍♂️ То, что VM-щик сможет запросто влиять на изменение инфраструктуры организации - сценарий более чем оптимистичный, на который не стоит всерьёз рассчитывать. Но агитировать за такие архитектурные изменения и стараться заводить задачи на устранение всех выявленных уязвимостей - святая обязанность VM-щика. Делай, что должен, и будь, что будет.

Обнаружил, что при поиске по фразе "Управление Уязвимостями и прочее" в Telegram находится не только мой канал, но и бот с тем же названием, к которому я никакого отношения не имею!

Обнаружил, что при поиске по фразе Управление Уязвимостями и прочее в Telegram находится не только мой канал, но и бот с тем же названием, к которому я никакого отношения не имею!

Обнаружил, что при поиске по фразе "Управление Уязвимостями и прочее" в Telegram находится не только мой канал, но и бот с тем же названием, к которому я никакого отношения не имею! Идентификатор бота совпадает с идентификатором моего канала "avleonovrus" с добавлением "bot" на конце. И да, Telegram позволяет кому угодно использовать названия существующих каналов в имени ботов - никаких ограничений нет. 😐🤦‍♂️ На аватарке в боте логотип моего работодателя - Positive Technologies и слова "4 недели", "онлайн", "свидетельство".

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

Зловредных сценариев использования этого бота может быть масса, поэтому, пожалуйста, будьте бдительны!

🔻 У меня нет никаких публичных интерактивных ботов в Telegram или где-то ещё и заводить я их не планирую.

🔻 Все мои чаты и каналы перечислены на моём сайте. В Telegram это @avleonovrus, @avleonovlive, @avleonovcom, @avleonovchat, @avleonovnews. Остальное ко мне отношения не имеет!

🔻 Я никогда никому не пишу с просьбой дать деньги в долг и не участвую в сборах средств. Никогда не пишу с просьбой "оказать содействие" кому-то.

🔻 Если я вам пишу (или ещё кто-то - тут универсально) и у вас закрадываются малейшие подозрения, обязательно просите подтверждение через альтернативный канал связи. 🙏 Например, написать с корпоративного email. Я абсолютно точно отнесусь к этому нормально и буду это всячески приветствовать. Увести акк могут у кого угодно, всегда лучше лишний раз перестраховаться. А чтобы отсечь аккаунты-клоны, обращайте внимание на дату создания аккаунта и страну регистрации, участие в общих закрытых группах.

Я уже обратился в службу поддержки Telegram с просьбой заблокировать этого левого бота, но ответа пока нет и я не особо верю, что это сработает. Да и зарегать ещё сотню аналогичных ботов для злодеев большого труда не составит. Telegram в этом отношении совершенно незащищён. Поэтому спасение утопающих - дело рук самих утопающих. Будьте осторожны и предупредите коллег!