Архивы автора: Александр Леонов

Об авторе Александр Леонов

Привет! Меня зовут Александр. Я специалист по Управлению Уязвимостями. Подробнее обо мне можно и моих проектах можете прочитать здесь. Приглашаю подписаться на мой канал @avleonovrus "Управление Уязвимостями и прочее" в MAX или в Telegram. Вы можете обсудить мои посты или задать вопросы в группе ВКонтакте. And I invite all English-speaking people to another Telegram channel @avleonovcom.

История о том, как 15-летний школьник с помощью ChatGPT нарушил работу анимешной стриминговой платформы, весьма показательна

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

История о том, как 15-летний школьник с помощью ChatGPT нарушил работу анимешной стриминговой платформы, весьма показательна. Киберполиция Токио арестовала 15-летнего ученика первого класса старшей школы из города Токородзава (префектура Сайтама) по подозрению "в воспрепятствовании деятельности компании путём обмана". По версии следствия, парень массово отменил подписки на сервис Bandai Channel примерно для 46 800 учётных записей, что нарушило работу компании.

Bandai Channel (バンダイチャンネル) - японский стриминговый сервис аниме, принадлежащий Bandai Namco Filmworks. Он работает с 2002 года и предлагает по подписке или за отдельную плату тысячи аниме-сериалов, фильмов и OVA. Сервис ориентирован главным образом на пользователей в Японии.

Подозреваемый признал вину и заявил: "У меня не было личной неприязни к компании".

Следствие утверждает, что школьник, используя ChatGPT, проанализировал логику работы сервиса, обнаружил уязвимость в системе и написал программу, которая автоматически отправляла ложные запросы на отмену подписок. Атака продолжалась 4 ноября прошлого года с 17:00 до 20:46. После того как компания обнаружила вредоносную активность и заблокировала доступ по IP, подросток около 30 раз менял свой IP-адрес и продолжал отправлять вредоносные запросы. 🤪

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

Тут возникает вопрос: если инцидент произошёл ещё в ноябре прошлого года, почему школьника задержали только сейчас? В оригинальной новости упоминается, что в июне этого года того же школьника уже арестовывали по подозрению в нарушении закона о запрете несанкционированного доступа к чужим учётным записям. Возможно, в июне правоохранители проверили его компьютер и обнаружили следы атаки на Bandai Channel.

Тут можно сказать следующее:

🔻 С современными ИИ-сервисами (а тем более с автономными агентами) реализовывать полноценные атаки могут даже школьники без какой-либо вменяемой мотивации. Аргумент "Да кому мы нужны, чтобы нас ломать?" уже вообще не работает. Кому ломать всегда найдётся. Единственный вариант - постоянно повышать уровень защиты, чтобы реализация атак становилась всё сложнее и дороже.

🔻 Следите за своими детьми. Парень пару часиков помаялся ерундой и нажил себе проблемы на ровном месте. Если вы не объясните доходчиво своим детям, что можно делать, а что является очень даже уголовно наказуемым, то они запросто во что-нибудь такое вляпаются.

На сайте Positive Technologies вышло исследование "Рынки монетизации уязвимостей"

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

На сайте Positive Technologies вышло исследование "Рынки монетизации уязвимостей". Сделаю краткую выжимку.

Основная идея: уязвимости - это ценный ресурс, представляющий интерес как для специалистов по кибербезопасности, так и для злоумышленников. Поэтому вокруг уязвимостей сформировались параллельные рынки монетизации.

⚖️ Легальный рынок

Багбаунти является основным легальным способом монетизации уязвимостей. Компании выплачивают исследователям вознаграждения за найденные уязвимости в системах, продуктах и сервисах. Основной фокус багбаунти-программ составляет внешняя поверхность атаки: веб-приложения, API и корпоративная инфраструктура. 96% исследователей работают с веб-приложениями, а с ОС и ПО - лишь 38%. Чаще всего выявляют XSS, ошибки контроля доступа и конфигураций.

Компании могут запускать собственные программы или использовать платформы вроде HackerOne, Bugcrowd и Standoff Bug Bounty. Стоимость размещения компаний на платформе составляет около 1 млн ₽ в год в России и 15 000 - 50 000 $ за рубежом. Размер выплат зависит от критичности уязвимости. Максимальные вознаграждения за отдельные типы уязвимостей достигают 2,4 млн ₽.

🌫️ Серый рынок

Серый рынок монетизации уязвимостей занимает промежуточное положение между легальными багбаунти-программами и теневыми площадками. Исследователи передают данные об уязвимостях посредникам или специализированным компаниям, а дальнейшее использование информации часто остается непрозрачным. Как правило, брокеров интересуют эксплоиты для 0-day-уязвимостей, стоимость которых может достигать 2,5 млн $.

🚫 Нелегальный рынок

Теневые форумы представляют нелегальный рынок уязвимостей. 0-day уязвимости там ценятся выше всего и они чаще всего выставляются на продажу: 49% всех объявлений. Объявления о продаже 1-day уязвимостей встречаются реже и составляют 11% от общего числа. В 38% объявлений речь идёт не о продаже, а о покупке данных о конкретной уязвимости.

Наиболее востребованы уязвимости удаленного выполнения кода (RCE) и повышения привилегий (LPE), на которые приходится 43% и 25% объявлений о продаже уязвимостей соответственно. Основные цели: интернет сервисы (36%) и корпоративное ПО (33%).

Стоимость уязвимостей определяется их эксплуатационной ценностью. Наибольший интерес представляют редкие и сложные для обнаружения уязвимости с высоким потенциалом применения. В 47% объявлений цена на уязвимости не указывается. Цена 0-day уязвимостей на чёрном рынке может быть до 20 раз выше, чем в багбаунти-программах.

На этом рынке также активно развивается сервисная модель. Уже около 7% объявлений об услугах связаны с покупкой или продажей услуг по эксплуатации уязвимостей в программном обеспечении. При этом 0-day уязвимости упоминаются в 40% таких объявлений, что подтверждает их высокую востребованность.

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

💡 Рекомендации

Компаниям следует сочетать технические и аналитические меры защиты: использовать багбаунти для непрерывного поиска уязвимостей, кибериспытания для проверки реальных сценариев атак и threat intelligence для мониторинга угроз и теневых площадок.

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

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

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

В блоге компании 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).