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

В блоге компании Sysdig вышел пост о первой хорошо задокументированной агентной ransomware-кампании JADEPUFFER

В блоге компании Sysdig вышел пост о первой хорошо задокументированной агентной ransomware-кампании JADEPUFFER. Суть там в следующем. Первоначальный доступ злоумышленники получили через опубликованный в Интернет сервер Langflow (платформа для создания и развертывания AI-агентов и workflow), проэксплуатировав уязвимость CVE-2025-3248. Эта уязвимость позволяет удалённому неаутентифицированному атакующему с помощью специально сформированного HTTP-запроса выполнить на сервере произвольный код. Далее злоумышленники запустили адаптивную и полностью автоматизированную кампанию, дошли до целевой системы и пошифровали базу данных продакшена. 🤖🤷‍♂️ При компрометации базы эксплуатировалась уязвимость обхода аутентификации в Nacos (CVE-2021-29441). Nacos - платформа для динамического обнаружения сервисов, управления конфигурациями и администрирования сервисов.

Эксперты Sysdig приводят следующие аргументы в пользу того, что эти действия выполнялись полностью автоматически:

🔻 Все полезные нагрузки доставлялись через RCE-уязвимость в Langflow в виде Python-кода, закодированного в Base64. Декодированные полезные нагрузки содержат большое количество комментариев, объясняющих, почему выполняется каждое действие. Там есть приоритизация целей по "окупаемости" (Return on Investment), определение "самой крупной" базы данных и описание назначения каждого шага. Люди обычно не добавляют комментарии к каждой команде вида python3 -c, а LLM делают это по умолчанию.

🔻 Слишком быстрая диагностика и исправление ошибок. Например, за 30-50 секунд был пройден полный цикл от неудачной попытки входа до диагностики причины ошибки, исправления кода и успешной аутентификации.

🔻 Во время атаки LLM читала обычный текст, найденный в системе, и принимала решения на его основе, а не просто искала совпадения по шаблонам. Такое поведение повторялось даже в разных сессиях с интервалом в несколько недель.

Ну и более 600 осмысленных пейлоадов, выполненных за короткий промежуток времени… Не очень похоже на человека с фиксированным набором утилит. 😉

Мораль? Если не будете детектировать и устранять уязвимости, мисконфигурации и прочие экспозиции, то вас рано или поздно взломают и пошифруют. Это произойдёт с нечеловеческой скоростью и эффективностью и не потребует от злоумышленника особой квалификации. 👾👻

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

Нам нужна национальная мобильная ОС

1 комментарий

Нам нужна национальная мобильная ОС. Соглашусь с Игнатием Цукергохером, что в плане мобильных ОС дело пахнет керосином и нужно что-то срочно предпринимать. Apple удалила из App Store национальный мессенджер MAX, после чего были удалены и другие приложения VK. Вслед за этим появились новости о предупреждении Apple от ФАС и возможном штрафе до 4 млрд рублей. Вряд ли Apple устранит "дискриминацию российских поисковых систем и обеспечит предустановку отечественного ПО на устройствах с iOS до 15 июля 2026 года". 🙄 Да и в то, что Эппл Рус выплатит штраф, тоже верится с трудом. Есть основания полагать, что идёт постепенная эскалация, результатом которой будет запрещение мобильных устройств Apple (в каком-то виде) и дальнейшее снижение их функциональности в России, реализованное как со стороны купертинцев, так и со стороны РКН.

Казалось бы, чего нам переживать за Apple и эплофилов? Есть же устройства на Android. Но там Google тоже переходит к гиперцентрализации и вводит обязательную регистрацию авторов приложений. У тех, кто не пройдёт верификацию (или у тех, кто будет неугоден по каким-то причинам 😉), приложения будут заблокированы на каждом Android-устройстве по всему миру. Речь не только о приложениях из Play Store, а вообще обо всех приложениях. Продвинутые пользователи смогут установить произвольную APK, но для этого придётся пройти пляски с бубном из 9 пунктов, один из которых - "Подождите 24 часа". Чистой воды издевательство. Закручивать гайки начнут с сентября 2026 года.

Ну и в целом, когда Дуров говорил, что без собственной операционной системы "все приложения на смартфонах - "национальные" или "иностранные" - остаются уязвимыми для точечной слежки и цензуры со стороны США через бэкдоры и магазины приложений iOS и Android", он был прав.

Как по мне, появление в широкой продаже устройств с отечественной мобильной операционной системой возможно только в случае повторения того же финта, что и с национальным мессенджером МАКС:

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

🔻 Особый статус национальной мобильной операционной системы (НМОС) должен быть закреплён в законе РФ.

🔻 В закрытом режиме должен быть выбран конкретный исполнитель, у которого есть наработки и компетенции, чтобы развивать НМОС.

🔻 Производители устройств должны быть директивно простимулированы производить устройства на НМОС, а ритейл - их продавать. Хочешь быть на рынке и не иметь проблем - участвуй в продвижении НМОС.

🔻 При появлении устройств с НМОС в продаже необходимо агрессивно навязывать их потребителям. Устройство с НМОС в кармане должно быть таким же атрибутом лояльности, как портрет президента в кабинете. На публике каждого чиновника должны видеть только со смартфоном с НМОС.

🔻 Бизнесы, у которых есть мобильные приложения, должны в первую очередь обеспечить их работу в НМОС. Определённые важные типы приложений должны работать только под НМОС.

Какая именно мобильная ОС должна стать национальной? Как по мне, непринципиально. Их сейчас в России достаточно много: Аврора, РЕД ОС М, РОСА Мобайл, Astra Linux Mobile, Alt Mobile, KasperskyOS for Mobile, kvadraOS и другие.

Из личного опыта могу сказать только то, что у меня есть смартфон на Авроре - Fplus R570E, который я купил в 2023 году. Это единственное устройство на Авроре, которое можно было официально купить физику. Казалось бы, флагман и показатель потенциала платформы для обычных потребителей, но последняя версия ОС для Fplus R570E (5.1.6) вышла в октябре прошлого года. А 3 последние версии ОС для этого смартфона выпущены не будут. ОМП показывает пальцем на Fplus, а у Fplus с прошлого года проблемы, им не до этого. Их гендиректора в июне этого года вообще признали банкротом. Не то чтобы я пожалел о покупке Fplus R570E - опыт был прикольный, но веры в то, что ОМП может достойно поддерживать НМОС, у меня поубавилось. 🤷‍♂️ Да и заставлять российские компании, у которых уже есть приложения под Android и iOS, портировать их под Аврору, ИМХО, как-то слишком.

Более логичным выглядит вариант на базе AOSP без гуглосервисов. Из отечественных AOSP-based ОС наиболее адекватной и живой выглядит РЕД ОС М.

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

О правильном понимании термина "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 не имел единого фиксированного самостоятельного определения и использовался как "плавающий" термин-оболочка, которому в разных контекстах придавались различные значения: от обозначения новой дисциплины управления и измерения киберриска, до общей подверженности риску, состояния уязвимости активов, степени их "открытости" атаке, агрегированного риска (с учётом вероятности и ущерба), интеграции уязвимостей и конфигураций в единую модель, а также количественного скоринга для ранжирования и приоритизации устранения проблем. 🤯

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

Каналу @avleonovrus "Управление Уязвимостями и прочее" сегодня исполнилось 4 года

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

Каналу @avleonovrus "Управление Уязвимостями и прочее" сегодня исполнилось 4 года. Я календарь переверну и снова 3 июля. 🙂 Как 3 июля 2022 года я написал первый пост про необходимость скорейшей девестернизации российского IT, так и продолжаю, помимо основной темы про уязвимости и их детектирование, гнуть свою линию. За здоровый IT-лоялизм, за признание явных успехов, за поддержку наших в беде, за повышение наступательного киберпотенциала страны. Позиция эта довольно непопулярная. Особенно в недозаблокированной соевой ТэГэшечке, где в почёте бессовестный популизм и оголтелое критиканство, направленное против любых государственных инициатив. 🫠🤷‍♂️

Однако для меня очередной год писательства прошёл весьма успешно. Посты выпускал более-менее регулярно. Количество подписчиков ТГ-канала перевалило за психологически/юридически значимую отметку в 10к и достигло уже 11 600+. ТГ-канал получил почётный статус A+ и я зарегистрировал канал @avleonovrus в национальном мессенджере MAX. Там уже больше 500 подписчиков! 🔥 Просмотры/посещения на сайте avleonov.ru также выросли за год в 3-4 раза. Спасибо большое всем тем, кто подписан, читает, лайкает, комментирует и делится постами! 🙏

Я собираюсь и дальше проживать свою лучшую жизнь и с удовольствием делиться с вами своими мыслями про Управление Уязвимостями и прочее. 😇 В первую очередь планирую писать о том, что непосредственно связано с моей работой и моими около-VMными проектами (обзоры Microsoft Patch Tuesday, Linux Patch Wednesday, трендовых уязвимостей, VM-ных продуктов и изменений регуляторики), во вторую - о том, что происходит в мире Vulnerability Management-а и кажется мне по каким-то причинам важным или любопытным, а в третью - обо всём остальном, о чём посчитаю нужным: от ситуации со смартфончиками до семейного отдыха и ХудЛита. Потому что могу! 😉

А вот всерьёз заниматься развитием своего "личного бренда", стремиться к безудержному росту количества подписчиков любыми средствами, превращаться в желтушное недо-СМИ, транслирующее 24/7 нейрослопные пересказы новостей с претенциозной популистской подачей, я как-то не планирую. 😅🤷‍♂️

Погнали в следующий год!

Про уязвимость 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.

🤖 Для каждой найденной уязвимости в интерфейсе 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?