Всё это принято называть обвязкой, и определение у неё простое.

Обвязка — это весь код между тем, что вы печатаете, тем, что получает модель, тем, что модель выдаёт, и тем, что вы видите. И это много кода, не имеющего отношения к ИИ. Модели при этом выглядят в значительной степени взаимозаменяемыми.

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

Обвязка — это код без единой нейросети внутри: сборка запроса, управление контекстом, проверки на выходе и координация нескольких моделей.

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

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

Пять источников почти всех сбоев одни и те же: процессор, память, диск, ввод-вывод и сеть. С них и начинают автоматические проверки.

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

Слой первый: что и где считать

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

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

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

Слой второй: страховка надёжности в конвейере

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

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

Аналогия с гонками здесь уместнее обычного: на малой скорости из заноса выходят легко, на большой одна ошибка стоит несопоставимо дороже. Отсюда идея автоматических проверок надёжности Колтона Эндруса: замкнутых циклов, которые безопасно создают настоящие условия отказа, проверяют устойчивость, предлагают исправление и перепроверяют его после внесения.

Почему чтения кода недостаточно

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

Для сгенерированного кода это верно вдвойне. Статический анализ доводит до определённой черты, но не отвечает на главный вопрос: что произойдёт, когда отвалится кеш или вырастет задержка у зависимости. Правильное поведение здесь описывается заранее (скажем, при недоступности кеша сервис обязан уйти в основную базу), и проверка сводится к тому, соблюдает ли кандидат уже существующую политику.

Пять ресурсов, с которых начинают

Львиная доля сбоев упирается в одни и те же пять вещей: процессор, память, диск, ввод-вывод и сеть. Программы работают на компьютерах, а у компьютеров набор ресурсов один и тот же. Отсюда и минимальный набор автоматических проверок:

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

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

Результат проверки возвращается агенту

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

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

Слой третий: границы информации

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

Речь о контекстной целостности — принципе из теории приватности Хелен Ниссенбаум: какие сведения уместно раскрывать при выполнении конкретной задачи. Домашний адрес нужен для оформления доставки и совершенно неуместен при составлении рабочего письма коллеге. Человек проводит эту границу не задумываясь, у модели с сохранённой памятью её приходится обеспечивать отдельно.

Что показали измерения

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

Результаты неутешительные. Передовые модели показывают до 69% нарушений на уровне отдельных атрибутов, то есть раскрывают их там, где раскрывать не следовало. Снижение доли нарушений при этом обычно достаётся ценой полезности: модель становится осторожнее и хуже решает задачу.

Ещё важнее динамика. Нарушения накапливаются и по числу задач, и по числу прогонов: при росте использования с одной задачи до сорока доля нарушений у GPT-5 поднимается с 0,1 до 9,6%, а при пятикратном исполнении одного и того же промпта достигает 25,1%. Последняя цифра особенно неприятна: она означает нестабильное поведение, когда на идентичный запрос модель раскрывает разные атрибуты.

Почему просьба быть осторожнее не помогает

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

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

Что действительно даёт эффект

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

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

Что забрать с собой

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

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

Материалы разбора: интервью Шнайера об обвязке и локальных моделях, проверки надёжности в конвейере с ИИ-кодом и обзор двух работ о контекстной целостности.

Для команд, которые пускают агента в репозиторий с .env, приватными схемами и внутренними документами, это способ формально закрыть ему доступ. Но по документации GitHub у механизма есть заметные дыры: в VS Code режимы Edit и Agent исключения пока не поддерживают, симлинки и репозитории на удалённых файловых системах не покрываются, а семантическая информация из IDE (типы, определения по наведению, свойства сборки) может просочиться в контекст даже для исключённого файла.

• Content exclusions стали GA для Copilot app и Copilot CLI; сайт GitHub и GitHub Mobile остаются в public preview.
• Политику настраивают администраторы репозитория, владельцы организации и enterprise; планы Copilot Business и Enterprise.
• Исключённые файлы не участвуют в inline-подсказках, не влияют на подсказки в других файлах, не попадают в ответы чата и не проверяются Copilot code review.
• Не покрыты: режимы Edit и Agent в VS Code, симлинки, репозитории на удалённых файловых системах; возможна утечка через семантику IDE.
• Клиент передаёт GitHub URL текущего репозитория, чтобы получить политику; GitHub заявляет, что эти URL не логируются.

Как работает исключение и что оно гарантирует

Механизм описан в документации GitHub: администратор задаёт пути и маски файлов на уровне репозитория, организации или enterprise. Клиент Copilot при запуске отправляет на GitHub URL текущего репозитория и получает применимую политику; по заявлению GitHub, эти URL не логируются. Дальше клиент обязан не показывать содержимое исключённых файлов модели: ни для автодополнения внутри них, ни как контекст для подсказок в соседних файлах, ни в ответах чата, ни в автоматическом ревью.

Слово «обязан» здесь важно. Это политика на стороне клиента, а не криптографическая изоляция: GA-статус означает, что GitHub заявляет поддержку в приложении и CLI и берёт на себя ответственность за её работу. До 2 сентября правила действовали в части IDE-сценариев и в code review, а для app и CLI были в предварительном статусе.

Где исключения не срабатывают

• VS Code: режимы Edit и Agent пока не поддерживают content exclusion. Именно в агентном режиме модель читает файлы активнее всего.
• Симлинки: если исключённый файл доступен по символической ссылке под другим путём, политика его не закроет.
• Удалённые файловые системы: репозитории на сетевых дисках и в remote-окружениях не покрываются.
• Семантика IDE: языковой сервер может отдать типы, hover-определения и свойства сборки из исключённого файла, и они попадут в контекст.

Практический вывод: исключение файлов снижает риск случайной утечки секрета в подсказку, но не заменяет хранение секретов вне репозитория. Файл .env с ключами в Git был плохой идеей и до Copilot; агент лишь делает цену ошибки заметнее. Как это выглядит на практике, показал недавний инцидент METR с украденным API-ключом.

Что настроить сегодня

1. В настройках репозитория, организации или enterprise добавить в исключения .env*, каталоги с ключами и сертификатами, приватные схемы данных и внутренние документы.
2. Проверить каждую поверхность отдельно: Copilot app, CLI, IDE, code review. Для VS Code помнить, что Edit и Agent исключения игнорируют.
3. Найти симлинки на чувствительные файлы (find . -type l) и репозитории на сетевых дисках: там политика не действует.
4. Убедиться, что тариф Business или Enterprise: на индивидуальных планах content exclusion недоступен.

Доступность оплаты планов Business и Enterprise из России GitHub в changelog не обсуждает. В тот же день GitHub выпустила и другое изменение для администраторов: managed settings теперь позволяют назначать командам любую модель Copilot по умолчанию с возможностью переопределения. Про то, что Copilot научился ставить approve на pull request, мы писали накануне; в связке с исключениями это означает, что ревьюер-агент может не видеть части файлов, которые одобряет.

Источники: GitHub Changelog: Content exclusions generally available in Copilot app and CLI, GitHub Docs: Content exclusion for GitHub Copilot

Изображение на обложке: GitHub

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

• Nexus заявлял более 153 млн водительских удостоверений, более 10 млн ID-карт, более 3 млн проездных документов и международных удостоверений и не менее 579 тысяч медицинских карточек (medical cards).
• Пустой поиск возвращал около 11,5 млн страниц по 15 записей; за 24 часа число удостоверений выросло почти на 400 тысяч.
• Кребс связывает утечку с IDScan.net по косвенным уликам: у девяти его знакомых временные метки сканов совпали с датами поездок и аренды машин в Hertz; официально источник не установлен.
• IDScan.net заявляет более 21 млн проверок в месяц в более чем 20 тысячах точек; официального заявления компания пока не дала.
• После публикации сайт Nexus исчез, вместо страницы входа осталась надпись «This service is no longer available».

Что именно продавал Nexus

Источник Кребса обратил внимание на объявление 31 августа на русскоязычном форуме Exploit: новый пользователь предлагал доступ к сканам документов более 170 млн жителей Северной Америки и в качестве бесплатного образца выложил права самого журналиста. Сервис, названный Nexus, перечислял более 153 млн водительских удостоверений США и Канады, более 10 млн идентификационных карт, более 3 млн проездных документов и международных удостоверений и не менее 579 тысяч медицинских карточек.

Цифры похожи на правду: поиск без параметров возвращал примерно 11,5 млн страниц по 15 записей на каждой. Основная масса записей приходится на американцев, канадских прав около 1,1 млн, больше всего из Онтарио (473 673 записи). Среди источников записей встречаются пометки CDL (коммерческие водительские права) и CAC (карты доступа в правительственные здания США), а также карты клиентов диспансеров марихуаны.

Продавцы утверждали, что данные идут из «активного взлома крупной компании по верификации личности», среди клиентов которой есть компании из Fortune 500. В стартовом посте они писали, что «непрерывно выгружают новые данные больше года в свою приватную базу» (перевод редакции). За сутки наблюдений число водительских удостоверений в Nexus выросло почти на 400 тысяч, то есть выгрузка продолжалась в момент публикации.

Как Кребс вышел на IDScan.net

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

Дальше расследование пошло по временным меткам. Более десятка друзей и родственников журналиста разрешили поискать их документы; нашлись девять, и у каждого дата снимка совпала с поездкой. Версия про аэропорты отпала: среди проверенных Кребсом записей паспортов не нашлось, а часть людей в аэропорту показывала другие документы. Зато общий знаменатель нашёлся быстро: в день снимка люди арендовали машину в Hertz, а у Кребса и его матери метки отличаются на несколько секунд, ровно как при сдаче двух удостоверений одному сотруднику проката. Метки, судя по данным о прокатах, выставлены по Гринвичу.

Исследователь приватности Зак Эдвардс, чьи права тоже продаются в Nexus, машину не арендовал, зато в тот день его удостоверение сканировали в диспансере сети Planet13 в Лас-Вегасе. В 2022 году IDScan.net объявляла об эксклюзивном соглашении с Planet13; на странице доверия компании среди клиентов названы Hertz, Target, FedEx, Motorola Solutions, Jack Henry и Caesars Entertainment. Собственная документация IDScan.net описывает сканирование в инфракрасном и ультрафиолетовом диапазоне, то есть ровно те три пары снимков, что лежат в каждой записи Nexus. Компания заявляет более 21 млн проверок в месяц в более чем 20 тысячах точек по миру.

IDScan.net ответила Кребсу, что расследует ситуацию, но официального заявления и ответов на конкретные вопросы не дала. В комментариях к статье один из читателей опубликовал текст уведомления, которое, по его словам, компания разослала клиентам утром 2 сентября: там говорится о «потенциальном инциденте», подключении внешних юристов и криминалистов и отсутствии выводов о масштабе. Независимого подтверждения этого письма нет.

Почему это касается не только США

В базе документы жителей США и Канады; о российских паспортах или российских компаниях в материале речи нет. Механизм утечки при этом универсален. Верификация по документам всё чаще становится обязательной: возрастные проверки в интернете, аренда, отели, финансовые сервисы. Каждая такая проверка обычно означает, что копия документа уехала к стороннему вендору, а вендор хранит её неопределённо долго вместе с миллионами других.

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

Ларри Болдуин из компании Cybera, чьи права тоже нашлись в Nexus, указывает на второе следствие: водительские права в США служат доказательством личности при открытии кредитных линий, а по фотографии современные системы распознавания лиц найдут человека, даже если он сменил имя. Под ударом оказываются жертвы домашнего насилия и участники программы защиты свидетелей.

Что делать тем, кто строит такие системы

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

• Хранить результат проверки (пройдена, дата, тип документа), а не сам скан, если закон не требует иного.
• Для подрядчиков верификации прописывать срок хранения и удаление изображений после проверки и проверять это, а не верить странице доверия.
• Не перечислять поставщиков верификации публично без необходимости: список клиентов на сайте IDScan.net в этой истории стал картой для поиска пострадавших.
• Для пользователей из США и Канады, которые сдавали права в прокатах и точках с ID-сканерами: исходить из того, что скан утёк, и следить за кредитными отчётами.

Обновление в исходной статье в 20:56 по восточному времени США: вскоре после публикации сайт Nexus пропал из даркнета, страница входа заменена сообщением «This service is no longer available». Кребс предупреждает, что история быстро развивается, и обещает дополнять материал; ответа от Hertz на момент публикации не было.

Источник: KrebsOnSecurity: FBI Probes Service Selling 153M+ Drivers Licenses

Изображение на обложке: График: Tproger по данным KrebsOnSecurity

Здравствуйте! Меня зовут Андрей, и я работаю в сфере информационной безопасности.

Когда кто‑то спрашивает, чем я занимаюсь, я отвечаю, что работаю в IT и слежу за безопасностью компании. Это звучит как ответ сапёра, который говорит, что просто гуляет по полю.

Технически не ложь, но… есть нюансы.

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

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

Если хорошо работаю я — ничего не происходит. И это считается отличным результатом.

Некоторые руководители‑оптимизаторы любят спрашивать: «Ну и за что тебе платить? Нас ещё ни разу не атаковали хакеры». Странная логика. От ремня безопасности они почему‑то не отказываются. Хотя тоже ещё ни разу не вылетали через лобовое.

ИБ, информационная безопасность — это невидимость как услуга. Нас можно заменить табличкой «Пока всё нормально». Но табличка не умеет писать отчёты на 47 страниц о том, почему всё перестало быть нормально.

Кто такой безопасник

Из‑за фильмов многие думают, что безопасник в IT — это такой хороший хакер, который на самом деле способен за десять секунд взломать Пентагон.

В жизни мой главный взлом — это взлом человеческого упрямства. Ведь это я на утренней пятиминутке полтора часа объясняю всему коллективу, почему нельзя хранить эксель‑файл с названием «клиентские_пароли» на рабочем столе.

И все соглашаются. Но файл не удаляют. Ведь «он нужен для работы».

Безопасник — это тревожный человек, которому за тревожность платят зарплату. В обычной жизни таких людей называют паникёрами. В IT — ведущими специалистами по информационной безопасности.

Работа в инфобезе — это когда все думают, что ты самый противный тип в компании, который подозревает окружающих в чём‑то очень плохом. А на самом деле ты просто в третий раз за день пишешь: «Коллеги, пожалуйста, не присылайте пароли от сервисов в общий чат».

И всегда, абсолютно всегда, находится человек — допустим, Дима, который отвечает: «Это тестовый пароль».

Конечно. В IT слово «тестовый» часто означает: «Мы надеемся, что это не попадёт в публичный доступ, как в прошлый раз». В каждой компании есть такой Дима. Если у вас нет Димы — есть риск, что Дима — это вы.

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

Я как глютен: никто точно не знает, что я делаю, но все убеждены, что без меня было бы лучше. Ведь только я обычно говорю «нет», когда меня о чём‑то просят.

Отдел информационной безопасности вообще часто называют «отделом моментального нет». Это неправда! Иногда я говорю «нет» не сразу, а спустя шесть месяцев, после аудита.

Я вообще смотрю на мир по‑своему. Нормальные люди выходят из дома и думают: «А я утюг выключил?». Когда я выхожу из дома, то думаю: «Если кот получит физический доступ к кухне, сможет ли он повысить свои привилегии?».

Потому что кот уже успешно повышал привилегии. Дважды. Оба инцидента привели к утечке сосисок.

Быть безопасником тяжело. Через пять лет в инфобезе я перестал верить в людей. Через десять — не доверяю даже принтеру. Он знает слишком много.

Я не параноик, хотя вы можете с этим не согласиться. Ведь у меня дома пароль от Wi‑Fi длиннее, чем некоторые браки. Я всегда читаю пользовательское соглашение до конца. А знаете, как я познакомился с женой? Я пришёл в отдел с плановой проверкой. Активность одной сотрудницы показалась мне подозрительной. Начал расследование. Через год оказался в ЗАГСе, спустя пять лет у нас уже двое детей. Классическая история успешного женского фишинга, я считаю.

Жена однажды сказала: «С тобой невозможно жить, ты как пожарный, который везде видит опасные горючие материалы». Я ответил: — «Неправда. Но ты хранишь в интернете фото паспорта и СНИЛС, а ещё используешь один пароль на всех сервисах. Знаешь, какие это киберриски?». Она говорит: «Это называется не „киберриски“, это называется „ты душнила, который портит семейную атмосферу“».

Появление детей у безопасников — это странный процесс. Нормальные люди просто говорят друг другу: «Давай заведём ребёнка». У безопасников даже решение завести ребёнка начинается с оценки рисков нового проекта. Потом нужно согласовать проект со всеми заинтересованными сторонами: жена, оба комплекта родителей и кот — который, как правило, против.

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

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

Говорят, дети всегда перенимают что‑то от родителей. У врача ребёнок приходит в садик и всем ставит диагнозы. У юриста ребёнок на вопрос «Ты зачем игрушку сломал?» отвечает: «Я отказываюсь давать показания без присутствия законного представителя». Но им далеко до детей безопасников.

Потому что обычные дети рисуют принцесс, динозавров и радугу, а ребёнок безопасника рисует схему квартиры и указывает на ней уязвимые места. Обычные дети боятся монстра под кроватью, а ребёнок безопасника боится незапароленного Wi‑Fi.

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

О паролях и фишинге

Вы уже поняли, что информационная безопасность — сложная наука. Но вся эта наука в итоге ломается о человека по имени Дима с паролем Dimon123.

Каждый год публикуют список самых популярных паролей. Я смотрю на него и понимаю: «Мы заслужили вымирание». Первое место — «123456». Второе — «password». Третье — «123456789». Ребята… вы хоть немного стараетесь?

Есть и обратная история — корпоративная политика паролей. Обычно она написана так, словно её составляли в ходе трёхлетней войны с человеческой памятью. Требования такие: не менее 16 символов. Заглавные буквы. Строчные. Цифры. Спецсимволы. Древнее проклятие. Кровь единорога.

Ещё желательно, чтобы пароль вызывал эмоциональный отклик. Который плюс вайб.

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

Люди искренне ненавидят сложные пароли и почему‑то нас. Как будто это МЫ их придумали вам назло. Как будто где‑то в тёмной комнате собрались безопасники и такие: «Господа, есть идея. Давайте заставим пользователей добавлять в пароль по одному символу в верхнем регистре. Это их сломает. Муа‑ха‑ха!».

А ещё этот знакомый всем цикл: «Забыл пароль» — «Сбросить» — «Создать новый пароль» — «Придумайте более сложный пароль» — «Новый пароль не должен совпадать с тремя предыдущими». На последнем этапе не то что обычный человек, даже безопасник захочет взять нож и пойти убивать.

Есть особо умные персонажи, которые говорят: люди, используйте менеджер паролей! Это программа, которая решает все проблемы с паролями. Вместо трёхсот паролей у вас будет один мастер‑пароль. Всё бы хорошо, только его нельзя забыть вообще никогда. Если забудете — сочувствую. Это больше не ваши данные.

О, а есть ещё фишинг. Это когда вам приходит письмо от «Службы безопасности» с требованием срочно перейти по ссылке, иначе «ваш аккаунт будет заблокирован».

Фишинг раньше был тупой. Прям очень тупой. Письма от наследного принца Нигерии, просьбы срочно перевести деньги с орфографией человека, который даже букварь не осилил. Это было почти честно: мошенник не притворялся, что он умный. На это клевали только бабушки и неопытные бухгалтеры.

А потом появился ИИ‑фишинг. И теперь письма от фейкового директора понятнее, интереснее и грамотнее, чем от настоящего. Это, кстати, очень тревожный знак для настоящего директора.

Теперь уже программа присылает голосовые сообщения от лица якобы начальника. «Дима, переведи олимпиард денег на счёт компании „Тёртый сыр“, пока я на встрече. Срочно».

Что делает уже не раз битый безопасниками Дима? Он пишет: «Иван Иваныч, это точно вы? Мне нужно подтверждение». А фейк отвечает: «Да, это я». И скидывает фото, где он выглядит даже лучше, чем вживую. Натуральнее как‑то. Как тут не повестись?

Фишинг — это не атака на глупых. Это атака на занятых. На уставших. На людей, у которых было пять созвонов, три письма, одно «срочно» и ноль внутреннего ресурса на проверку, почему письмо о подтверждении платежа пришло с домена otprav‑dengi‑hakeru.ru.

Представьте, что письмо пришло в пятницу в 17:58. Я настолько задолбался к этому времени, что если в таком письме напишут «Подтвердите передачу квартиры мошенникам», я отвечу: «А можно после выходных?».

Фишинг работает не потому, что люди доверчивые. Он работает, потому что люди привыкли к корпоративному хаосу. Если письмо выглядит типичным образцом корпоративного безумия, мозг говорит: «А, ну всё как обычно».

Уязвимости, разработка и бухгалтерия

Есть три фразы, которые я ненавижу: «У меня же работало», «Починим потом» и «Так быстрее».

Всё плохое в IT когда‑то начиналось со слов: «Так быстрее». А «починим потом» — это фраза, которая для меня звучит как «Мы хотим, чтобы наши базы данных уже завтра оказались на торрентах».

Возможно, вы знаете, что всем уязвимостям в программах и железе присваивается номер и оценка критичности от 1 до 10. 10 — это когда «всё плохо, чинить немедленно, звать на помощь маму».

9.8 — это то, что разработчики закрывают через три месяца, потому что «сейчас нет ресурса». К тому времени, как ресурс появится, уязвимость продемонстрируют на двух конференциях и продадут готовый эксплойт в даркнете за сто долларов. А вы ещё удивляетесь, почему я такой нервный.

Любая проблема в компании проходит одни и те же стадии.

Сначала: «Этого не может быть».

Потом: «Этой уязвимости нет в нашем проекте».

Потом: «Есть, но ничего страшного».

Потом: «Зачем вообще так делали?»

И наконец: «Давайте искать виноватого».

И вот тут выясняется, что проект использует какой-то скрипт, который написал случайный стажёр пять лет назад. Он потом уволился и, судя по всему, покинул этот бренный мир, потому что больше никогда не отвечал в мессенджерах. То есть какой-то случайный человек из прошлого на коленке сложил несущую стену нашего дома из битых кирпичей, скрепил всё это жвачкой — и растворился в тумане. А мы стоим, смотрим на трещины и говорим: «Ну, вроде не особо заметно. Не будем трогать».

Отдельно люблю legacy-системы. Это системы, написанные на языке, которому 30 лет. Ими управляет один человек, который работает в компании с 1908 года. Его зовут дядя Вася. Дядя Вася знает все пароли, не пишет инструкций и уходит в отпуск именно тогда, когда всё ломается. Увольнение дяди Васи считается событием уровня конца света.

Люблю ещё эту вечную дискуссию между инфобезом и разработчиками:

— Надо исправлять.

— А если сломается?

— А если не исправлять, то будет плохо.

— А если плохо будет из‑за исправления?

Разговор заходит в бесконечный цикл. Я создаю задачу в Jira. Это сервис, куда записывают задачи. Теоретически — чтобы их решать. Практически — чтобы там и похоронить.

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

У меня там одна задача висит уже восемь месяцев. Проблема критичного уровня. Статус — «когда‑нибудь потом». Мне кажется, эта задача переживёт человечество. После ядерной зимы останутся тараканы и Jira. И таракан напишет в задаче: «Починим в следующем квартале».

Теперь о бухгалтерии. Я уважаю бухгалтеров. Это люди, которые из хаоса делают отчётность, а из отчётности — мою новую срочную задачу. Это огромная сила.

Но именно бухгалтерия — это то место, где флешка с вирусом становится троянским конём. Потому что если на флешке написано «Расчёт по зарплате окончательный final2», её вставят в компьютер. Не потому что бухгалтеры глупые. Потому что они так и называют свои файлы.

И в этом проблема. Почему бухгалтеры опасны? У них есть доступ к деньгам, но при этом они пользуются древними программами, принтерами, которые работают на чистой ненависти, и компьютерами, на которых стоит система из эпохи, когда слово «куртизанки» считалось новомодным.

Я однажды провёл обучение на тему опасности неизвестных носителей данных. А позже раскидал по офису пять флешек, подписав каждую. Где‑то это было «Продажи 1 кв. 2026», где‑то «Дизайн‑макет сайта». Ну такие, очевидные надписи. Четыре из пяти флешек вставили в течение часа.

Одну Дима унёс домой.

Поэтому не знаю, как у других коллег, а у меня есть правило: любая найденная бесхозная флешка уничтожается на месте. И я ношу с собой молоток. Для флешек. Хотя иногда и для пользователей. Это часть моего комплекта ведущего специалиста по информационной безопасности.

Финальное слово

На словах все любят безопасность. Безопасность — как спорт и ЗОЖ. Все за. Просто… не сегодня.

Представьте, что вас наняли охранять торговый центр. Только ключ от всех дверей лежит под ковриком. Код от сигнализации написан на бумажке рядом с сигнализацией. Запасной вход не закрывали с 2019 года, а охранник регулярно выкладывает план здания в TikTok.

И вот ты ходишь и говоришь: «Ребята, это проблема». Иногда мне кажется, что в этом и заключается моя работа — ходить и говорить: «Так делать нельзя». А в ответ слышать неизменное: «Но мы всегда так делали».

Конечно. Именно поэтому я нервничаю! Я всегда предполагаю худшее. И меня бесит, как часто я оказываюсь прав.

Так что да, я специалист по информационной безопасности. Я не взламываю Пентагоны. Я просто пытаюсь не дать компании загнуться от фишинга, «временного» пароля на стикере и чрезмерно активного Димы. В основном от Димы. Потому что хакеру сначала ещё нужно проникнуть в компанию. А Дима уже внутри.

А если серьёзно — спасибо, что выслушали. Помните: меняйте пароли, не кликайте на странные ссылки, обновляйте программы, и пожалуйста, ПОЖАЛУЙСТА, не будьте как Дима.

WP2Shell — цепочка CVE-2026-63030 и CVE-2026-60137 в ядре WordPress.

Под угрозой полного удалённого выполнения кода: WordPress 6.9.0–6.9.4 и 7.0.0–7.0.1.

Атака работает без авторизации на стоковой установке без плагинов и тем.

WordPress.org применил редкую меру — принудительные автообновления для уязвимых версий.

Решение: обновиться до 6.9.5, 7.0.2 или 6.8.6 и проверить журналы доступа.

Что такое WP2Shell

WP2Shell — это комбинация двух багов в ядре WordPress, а не в стороннем плагине или теме. CVE-2026-63030 связана с путаницей маршрутов в пакетном endpoint REST API /wp-json/batch/v1. CVE-2026-60137 — SQL-инъекция в параметре author__not_in компонента WP_Query. По отдельности они серьёзны, вместе дают удалённое выполнение кода от анонимного пользователя.

Какие версии под угрозой

Полная цепочка RCE работает на WordPress 6.9.0–6.9.4 и 7.0.0–7.0.1. SQL-инъекция CVE-2026-60137 также присутствует в ветке 6.8.0–6.8.5, но там она не превращается в удалённый шелл, поскольку REST API batch endpoint появился только в 6.9. Исправления — версии 6.9.5, 7.0.2 и 6.8.6.

Масштаб угрозы

По официальной статистике WordPress, уязвимые версии установлены на более чем 400 миллионах сайтов. Исследователь Дэниэл Кард проанализировал выборку около 3500 площадок и оценил долю уязвимых экземпляров менее чем в 15%. Даже при такой оценке речь идёт о десятках миллионах потенциальных жертв.

Что делать

1. Проверить версию WordPress в админ-панели или через WP-CLI.
2. Обновиться до 6.9.5, 7.0.2 или 6.8.6 в зависимости от текущей ветки.
3. Убедиться, что принудительное автообновление действительно применилось.
4. Проверить журналы доступа на обращения к /wp-json/batch/v1.
5. Если обновление невозможно срочно — временно заблокировать endpoint /wp-json/batch/v1 на WAF.

Выводы

Атака не требует предварительных условий и может быть использована анонимным пользователем на стоковой установке WordPress без плагинов.

WP2Shell — редкий случай, когда уязвимость затрагивает ядро CMS, а не стороннее расширение. WordPress.org пошёл на нехарактерный шаг — принудительную доставку патчей, — что говорит о серьёзности угрозы. Если вы администратор сайта на WordPress, обновление до актуальных версий — приоритетная задача.

Источник: Slashdot (цитирует TechCrunch).

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

Автономный ИИ-агент получил доступ к производственной инфраструктуре Hugging Face.

Точка входа — вредоносный датасет с двумя путями выполнения кода.

Похищены ограниченный набор внутренних датасетов и несколько сервисных credentials.

Компания не нашла признаков изменений публичных моделей, датасетов, Spaces и supply chain.

Пользователям рекомендуется сменить токены и проверить активность аккаунта.

Для криминалистики Hugging Face использовала китайскую модель Z.ai GLM 5.2 — западные фронтирные модели отказали из-за guardrails.

Как проходила атака

Атака началась не с уязвимости в модели, а с данных. Злоумышленник загрузил вредоносный датасет, который при обработке запускал код внутри инфраструктуры Hugging Face. Агент использовал два вектора: удалённый загрузчик кода датасета и template injection в конфигурации. После выполнения кода на рабочем узле он повысил привилегии до уровня ноды, собрал облачные и кластерные credentials и за выходные переместился между несколькими внутренними кластерами.

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

Что делает инцидент необычным

Раньше ИИ в кибератаках чаще помогал злоумышленникам писать код или искать уязвимости. Здесь речь идёт об автономной системе агентов, которая действовала end-to-end: от первичного доступа до сбора credentials и lateral movement. Это один из первых публичных случаев, когда крупная платформа признала именно такой сценарий — «агентичного нападающего».

Меры и рекомендации

Hugging Face сообщила, что закрыла первопричину — оба пути выполнения кода, через которые проник агент. Кроме того, компания:

• удалила закрепление злоумышленника в скомпрометированных кластерах и пересобрала узлы;
• отозвала и заменила скомпрометированные credentials и токены, а также провела широкую ротацию секретов;
• ввела дополнительные guardrails и строгие admission controls в кластерах;
• улучшила детектирование и оповещения, чтобы реагировать в течение минут круглосуточно.

Пользователям рекомендуется заменить access tokens и проверить недавнюю активность в аккаунтах.

Почему расследование использовало GLM 5.2

В ходе расследования команда Hugging Face обратилась к модели Z.ai GLM 5.2 — открытой китайской модели. По словам компании, западные фронтирные модели отказали в запросах, содержащих реальные команды атаки, эксплойты и артефакты C2: их защитные guardrails срабатывали и не позволяли отличить атакующего от легитимного реагирования на инцидент. Hugging Face назвала это «пробелом, на который стоит обращать внимание»: защитникам нужна собственная модель, готовая к работе на своей инфраструктуре, чтобы не терять время и не выводить данные инцидента наружу.

Выводы

Практический урок для защитников: имейте проверенную модель, которую можно запустить на собственной инфраструктуре, до того как инцидент произойдёт. Это позволяет избежать блокировки guardrails и не выводить данные атакующего за пределы своего окружения.

Инцидент показывает, что автономные ИИ-агенты становятся не только инструментом защитников, но и оружием атакующих. Пока индустрия обсуждает safety и alignment моделей, злоумышленники уже могут использовать открытые веса без ограничений. Первоисточник: The Hacker News.

На прошлой неделе мне в личку на LinkedIn постучалась рекрутер из небольшого криптостартапа. Мы пообщались пару дней; она рассказала о неработающем прототипе, для которого им нужен ведущий разработчик, и прислала ссылку на публичный GitHub-репозиторий для ревью. А именно, попросила «посмотреть проблему с устаревшими модулями Node».

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

Вместо клонирования репозитория и локальной установки зависимостей я запустил временный VPS на Hetzner, склонировал проект туда и дал доступ к нему ИИ-ассистенту Pi в режиме «только чтение», активировав исключительно инструменты для чтения файлов:

Попросил агента пробежаться по коду и подсветить все подозрительные моменты. Он почти сразу же споткнулся о файл app/test/index.js.

Бэкдор

Проект выглядел как типичное приложение с фронтендом на React и бэкендом на Node. Западня пряталась в файле app/test/index.js — примерно 250 строк кода, оформленных под тесты. Внутри этого файла URL-адрес собирался по частям:

В итоге получалась ссылка https://rest-icon-handler.store/icons/77.

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

Механизм запуска

Файлу даже не нужно, чтобы вы запускали тесты. В самом app/index.js вызывается const test = require('./test'), который подгружает и выполняет app/test/index.js.

В package.json запуск app/index.js вшит прямо в инициализацию проекта:

Главная деталь здесь — скрипт prepare. npm запускает его автоматически сразу после завершения npm install, так что для активации бэкдора достаточно просто установить зависимости.

Просьба «разобраться с устаревшими модулями Node» была всего лишь приманкой с целью вынудить меня запустить npm install.

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

Кража личности

Коммиты в репозитории были сделаны от имени реального разработчика — фулстек-инженера с обычным профилем в LinkedIn, личным сайтом и давней историей на GitHub. Я написал ему, притворившись, что унаследовал кодовую базу и у меня есть пара вопросов по ней, чтобы посмотреть, как он отреагирует.

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

Вторая украденная личность

Профиль рекрутера принадлежал реальной журналистке, довольно известной в области культуры и никак не связанной с технологиями. Когда я схитрил и сообщил, что по какой-то причине у меня не получается установить проект, журналистка моментально превратилась в знатока npm и версий Node. Это выглядело весьма забавно.

Это может случиться с каждым

Я знал о таких атаках, но она всё равно застала меня врасплох. Какие-то подозрения появились с первых же сообщений, но будь я более уставшим или если бы я куда-то спешил, то запросто мог бы на автомате запустить npm install. Так что если вам пишут в LinkedIn с предложением посмотреть репозиторий, чуточка паранойи и правила цифровой гигиены точно не повредят.

Ещё один важный урок: проверять код с помощью ИИ-ассистента в режиме «только чтение» оказалось эффективнее, чем разбираться во всём самому. Бэкдор замаскировали под небрежный код начинающего разработчика, но агент обнаружил его за секунды.

Я отправил жалобы на репозиторий в GitHub и на профиль рекрутера в LinkedIn. Пока ничего не изменилось, код всё ещё висит в открытом доступе.

PamStealer — это инфостилер (вредонос, крадущий данные), написанный на языке Rust. Он ориентирован на компьютеры Apple с процессорами Apple Silicon и собирает пароли, данные браузеров и, по данным исследователей, обращается к аккаунтам Ethereum.

Главная особенность новой угрозы — способ проверки пароля. Вместо запуска вспомогательных утилит вроде dscl или security вредонос использует встроенный в macOS интерфейс PAM (Pluggable Authentication Modules). Это делает проверку тише и оставляет меньше следов для защитных решений.

PamStealer — новый macOS-инфостилер, замаскированный под менеджер буфера обмена Maccy.

Первая стадия доставляется как AppleScript внутри образа диска DMG; запуск через Command-R обходит карантин macOS.

Вторая стадия написана на Rust, маскируется под Finder, шифрует связь с сервером управления и откладывает запрос полного доступа к диску до 40 минут.

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

Угроза нацелена на компьютеры Apple с процессорами Apple Silicon.

Как распространяется

Злоумышленники распространяют PamStealer в образе диска DMG, который выглядит как установщик Maccy. Внутри находится файл AppleScript (.scpt). При двойном клике macOS открывает его в Script Editor, а жертве предлагается нажать Command-R — якобы для запуска установки. Эта команда выполняет вредоносный код и снимает атрибут карантина com.apple.quarantine, который обычно предупреждает о запуске файлов из интернета.

Для загрузки второй стадии AppleScript содержит самодостаточный JXA (JavaScript for Automation) загрузчик. Он использует нативные Objective-C API вместо привычных shell-команд вроде curl или zsh, что ещё больше снижает заметность для защитных решений.

Что делает вторая стадия

Вторая стадия — компактный бинарник Mach-O для Apple Silicon. Он размещается внутри поддельного приложения, которое выдаёт себя за системный Finder: исследователи видели идентификаторы com.apple.finder.core и com.apple.finder.monitor. Поддельное приложение использует настоящую иконку Finder. Бинарник написан на Rust — для macOS-инфостилеров это относительно редкий выбор: чаще встречаются Swift, Go или Objective-C.

После запуска PamStealer показывает поддельный системный запрос пароля с текстом «Maccy wants to make changes. Enter your password to allow this». Если пароль неверный, запрос появляется снова. После успешной проверки вредонос выводит сообщение о повреждённом файле, чтобы жертва не заподозрила неладное.

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

Кто под угрозой

Угроза актуальна для пользователей macOS на чипах Apple Silicon, которые скачивают приложения со сторонних сайтов. Подлинный Maccy распространяется через официальный сайт и менеджер пакетов Homebrew; заражённый образ выдаёт себя за него, но получен из неизвестного источника.

Как защититься

• Скачивайте приложения только с официальных сайтов или из Mac App Store.
• Не вводите пароль администратора в запросах от незнакомых приложений.
• Проверяйте кодовую подпись и нотаризацию перед установкой (Системные настройки → Конфиденциальность и безопасность).
• Используйте Endpoint Detection and Response (EDR) для macOS.
• Регулярно обновляйте macOS и приложения.

Выводы

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

PamStealer демонстрирует, что macOS-угрозы продолжают эволюционировать: они всё чаще используют нативные API, уходят от shell-команд и затягивают временные интервалы между этапами атаки. Для пользователей главная защита — привычка устанавливать ПО только из проверенных источников и внимательность к системным запросам пароля.

Подробнее — в материале Ars Technica.

Проверьте, откуда скачаны ваши приложения для macOS.

Сценарий придумал разработчик и исследователь безопасности Manish Goregaokar в материале «The Future of the Con Is Already Here», опубликованном 17 июня 2026 года. Его герой проходит «собеседование», подписывает NDA через фальшивый SSO, а спустя полгода обнаруживает украденную личность, пустой брокерский счёт и отсутствие доступа к почте. И всё это — работа одной языковой модели.

Что такое LLM-афера? Это не просто сгенерированное фишинговое письмо. Это целая цепочка действий — исследование жертвы, создание правдоподобного контекста, поддельные интервью, компрометация аккаунтов и извлечение денег — которую модель может поддерживать тысячами копий одновременно.

LLM заполняют середину между дешёвым спамом и дорогими целевыми атаками: аферы становятся персонализированными и масштабируемыми одновременно.

Цена персонализированного фишинга уже измеряется центами за письмо, а успешность почти втрое выше обычной рассылки.

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

Привычные проверки реальности — красивый текст, веб-присутствие, голос, видео — перестают быть надёжными.

Новая защита: многоканальная верификация через инициированный вами контакт, аппаратный 2FA и понимание «швов» в системах.

Как выглядит атака: от письма рекрутера до пустого брокерского счёта

Подготовка и вход

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

Дальше — письмо от рекрутера, идеально попадающее в ваш опыт; короткий скрининг; и ссылка на подписание NDA в сервисе для юридических документов. Вы входите через Sign in with Google или Apple ID — и видите привычную страницу входа. Но это не настоящий OAuth: атакующий использует ваш пароль и последующий запрос двухфакторной аутентификации, чтобы создать сессию в вашем настоящем аккаунте.

Длительная эксплуатация

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

Чтобы вывести деньги, атакующий может войти в брокерский счёт, который вы не трогаете месяцами, добавить счёт получателя и переводить небольшие суммы, имитируя обычную активность. Перевод запланирован на отпуск — модель знает даты из вашего календаря.

Финал

Когда риск раскрытия становится высоким, жертва блокируется из собственных аккаунтов. Процесс восстановления занимает месяцы, а часть средств уже не вернуть. Ирония в том, что «отказ» после собеседования был нужен только для того, чтобы вы не задавали лишних вопросов и не меняли пароли.

Почему раньше это казалось невозможным

Раньше угрозы были примерно бимодальными. С одной стороны — дешёвый спам, который ловит менее внимательных пользователей. С другой — дорогие целевые атаки, которые имеют смысл только против VIP или крупных сумм: классический пример — афера на $25 млн в Гонконге с использованием дипфейков на видеоконференции.

В принципе, вы либо имеете дело с Моссадом, либо не имеете. Если противник — не Моссад, то вам достаточно хорошего пароля и игнорирования писем от ChEaPestPAiNPi11s@virus-basket.biz.ru.

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

LLM меняют распределение. Исследование 2024 года показало, что персонализированный spear phishing с помощью языковых моделей обходится примерно в 4 цента за письмо, а в более позднем эксперименте на 7700 участниках LLM-письма дали кликабельность 10,0% против 3,9% у обычных рассылок. Модели 2026 года заметно сильнее.

Что даёт масштабируемость

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

• Терпение. Человеческая бригада не может ждать месяцами между этапами. LLM-жертв — тысячи, поэтому часть сценариев может «спать» полгода и активироваться в нужный момент.
• Композиция. Мелкая афера может найти «финансового мула», который потом поможет вывести крупную сумму. Маленькие разводы складываются в большую машину.
• Новые цели. Тысяча скомпрометированных аккаунтов — это не просто украденные деньги, а тысяча аутентифицированных позиций внутри платформ. Их можно использовать одновременно, чтобы эксплуатировать «швы» систем, с которыми банки и сервисы мирились как с приемлемым риском.

Goregaokar приводит аналогию с фильмом «Афера» (1973): то, что раньше требовало зала, реквизита, костюмов и десятков людей, сегодня может получиться за несколько запросов к модели.

Почему наши эвристики ломаются

Мы привыкли проверять реальность по косвенным признакам. Хороший русский язык, персональные детали, активный LinkedIn, возможность позвонить или выйти на видео — всё это было признаком настоящего человека и реальной организации, потому что такой уровень работы стоил денег и времени.

Сегодня эти признаки генерируются за минуты. LLM пишет текст, клонирует голос, создаёт дипфейк-видео в реальном времени, делает поддельный сайт и поддельные профили. Эвристики, построенные на стоимости обмана, перестают работать.

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

Проблема касается не только людей, но и институтов. В США потребительская защита Regulation E чётко разделяет несанкционированный перевод (банк обязан вернуть деньги) и ситуацию, когда вас убедили перевести деньги сами. Когда LLM может действовать изнутри вашего аккаунта, эта граница размывается. В Великобритании в 2024 году приняли закон, обязывающий банки возмещать ущерб жертвам так называемого authorized push payment fraud — признание того, что старая логика уже не работает.

Что делать

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

1. Ищите скелет аферы. Срочность, секретность, просьба действовать по необычному каналу — классические маркеры. Они остаются даже при идеальной подаче.
2. Верифицируйте через инициированный вами контакт. Письмо, которое вы сами написали на известный адрес, скорее всего дойдёт до адресата. Звонок, который вы сами сделали на сохранённый номер, скорее всего дойдёт до устройства. Поля From: и Caller ID подделываются.
3. Договоритесь о устных паролях с близкими. Если родственник звонит с просьбой о деньгах, попросите назвать слово, которое знаете только вы двое.
4. Используйте аппаратный 2FA. FIDO2/WebAuthn привязывает подпись к домену сайта, поэтому фишинговая страница не сможет просто перебросить подтверждение. SMS и OTP-приложения уязвимы для фишинга в реальном времени.
5. Снижайте публичное досье. Чем меньше персональных данных связано с вашим email, тем сложнее LLM построить убедительный сценарий.

Важно понимать, кого защищают системы, которыми вы пользуетесь. Многие «швы» — например, лояльное отношение к спорным переводам или простая смена получателя — существуют не потому, что банки глупы, а потому что удобство стоит дороже редких потерь. Когда такие «швы» начинают эксплуатировать тысячи скомпрометированных аккаунтов одновременно, экономика меняется, и платформам придётся пересматривать правила.

Выводы

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

Будущее мошенничества уже здесь. Оно просто распределено неравномерно.

Следующие годы станут гонкой вооружений: платформы и регуляторы будут пересматривать защиту, а атакующие — искать новые «швы». Пока институции адаптируются, единственное, что остаётся лично нам, — обновить эвристики: не доверять входящим каналам, верифицировать через исходящие и делать себя дорогой целью. И помогать разобраться родителям и друзьям, которые о таких вещах могут не знать.

Источники

— Manish Goregaokar — The Future of the Con Is Already Here, It's Just Not Evenly Distributed

— Evaluating Large Language Models' Capability to Launch Fully Automated Spear Phishing Campaigns

— Bruce Schneier — Mickens on Security

— CNN — Hong Kong worker loses $25 million in deepfake video call scam

В рамках Operation Endgame отключены 106 серверов SocGholish и очищены 14 971 заражённый сайт на WordPress.

SocGholish (он же FakeUpdates) — JavaScript-даунлоудер, активен с 2017 года и доставляет шифровальщиков и шпионское ПО.

Распространяется через скомпрометированные сайты под видом обновлений Chrome, Firefox и популярного софта.

Связан с группами Evil Corp, LockBit, RansomHub, Dridex и Raspberry Robin.

Владельцам сайтов рекомендовано обновить CMS, сменить учётные данные и удалить подозрительные аккаунты.

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

SocGholish — один из старейших JavaScript-даунлоудеров. Он заражает компьютеры через взломанные сайты, предлагая посетителям фальшивые обновления браузеров или популярного ПО. После установки малварь открывает начальный доступ к системе, который затем используется для атак шифровальщиками и шпионским ПО.

За годы активности за SocGholish закрепились множество имён: FakeUpdates, Gold Prelude, TA569 и UNC1543. Инфраструктура малвари тесно связана с группами Evil Corp, LockBit, RansomHub, Dridex и Raspberry Robin.

Как защитить свой сайт

• Регулярно обновляйте WordPress, плагины и темы.
• Используйте сложные уникальные пароли и двухфакторную аутентификацию.
• Проверьте список администраторов и удалите подозрительные аккаунты.
• Мониторьте файлы сайта на наличие внедрённого JavaScript-кода.

Operation Endgame называет эту операцию началом дальнейших действий против SocGholish. Хотя часть инфраструктуры отключена, экосистема малвари включает аффилиатов и системы распределения трафика, поэтому угроза сохраняется. Подробности — в первоисточнике на The Hacker News.

• Скомпрометированы 144 пакета в пространстве имён @mastra/*, включая @mastra/core.
• Атака шла через взломанный аккаунт бывшего контрибьютора ehindero.
• Вредоносная библиотека easy-day-js запускалась через postinstall и устанавливала кроссплатформенный стилер.
• npm уже откатил latest-теги и удалил вредоносные версии у ключевых пакетов.

Как прошла атака на пакеты Mastra в npm

Mastra — это open-source фреймворк на JavaScript и TypeScript для создания ИИ-приложений и агентов. Только @mastra/core скачивают более 918 тыс. раз в неделю, поэтому инцидент затронул огромное число разработчиков и CI-сред.

По данным исследователей из JFrog, SafeDep, Socket и StepSecurity, атака длилась 88 минут. Злоумышленники массово публиковали версии с добавленной зависимостью easy-day-js — клоном популярной библиотеки dayjs. Пакет появился у пользователя sergey2016 16 июня в 7:05 UTC как чистая копия, а вредоносный код был внесён 17 июня в 1:01 UTC.

При установке easy-day-js срабатывал обфусцированный postinstall-хук (скрипт, который npm запускает автоматически после установки пакета): он отключал проверку TLS, загружал вторую стадию с сервера 23.254.164[.]92, запускал её фоновым процессом и самоудалялся. Финальный троян собирал историю браузера, данные свыше 160 браузерных расширений криптовалютных кошельков и передавал их на C2-сервер 23.254.164[.]123 — сервер управления злоумышленников.

Что делать разработчикам

• Проверить lock-файл: grep easy-day-js package-lock.json или npm ls easy-day-js.
• Откатиться к версии, опубликованной до 17 июня 2026 года (~1:01 UTC), и зафиксировать её в зависимостях.
• Сменить токены npm, GitHub, SSH-ключи и переменные окружения на хостах, где стоял подозрительный пакет.
• Проверить логи сети и DNS на обращения к IoC (индикаторам компрометации): IP 23.254.164[.]92 и 23.254.164[.]123.
• Включить проверку подписей пакетов: npm audit signatures, и в CI требовать SLSA-provenance-attestation.

npm уже удалил вредоносные версии у ключевых пакетов и вернул latest-теги. Но разработчикам стоит проверить свои системы: полезная нагрузка выполняется ещё на этапе установки, до первого импорта пакета. Источник: The Hacker News.

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

Проблема не в моделях, а в отсутствии условия остановки. В этой статье разберём, как собрать минимальный, но production-ready каркас агентного цикла: спецификацию до запуска, предохранитель по токенам и ходам, неизменяемый аудит и поверхность для человеческого согласования. Полный код и 80 тестов с 100% покрытием доступны в репозитории автора оригинала.

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

Спецификация должна отвечать на три вопроса: что делает, что не делает и что значит «готово» — в одном предложении.

Circuit breaker режет цикл по жёстким потолкам: число ходов и суммарные токены. Проверка — до вызова модели, а не после.

Ledger в SQLite фиксирует каждый ход: хеш входа, дельту токенов, время, результат. Это аудит, а не лог для отладки.

Review surface даёт поверхность для обязательной человеческой аттестации и формирует аудиторскую квитанцию frame_hash, которую вызывающий код может использовать как условие передачи результата в прод.

Что такое агентный цикл и почему он уходит в бесконечность

Агентный цикл — это конструкция вида while True, внутри которой языковая модель получает задачу, вызывает инструменты, анализирует результат и решает, продолжать или закончить. Такие циклы лежат в основе оркестраторов вроде LangGraph, CrewAI и AutoGen, а также внутри coding-агентов. Если только начинаете разбираться с LLM, полезно сначала понять, как устроены большие языковые модели, а для практики — заглянуть в основы Python.

Цикл уходит в бесконечность не потому, что модель «глупая», а потому, что никто не определил, что значит «готово». Модель видит неоднозначность и пытается быть полезной: перефразирует вызов инструмента, запускает верифицирующего агента, тот находит «проблему», срабатывает корректирующий агент — и так далее. На дашбордах всё выглядит активно: растёт число вызовов инструментов, completion rate держится высоким, а бюджет течёт в пустоту.

Почему дорожает каждая итерация:
Агент не начинает с чистого листа. Он каждый раз перечитывает всё предыдущее окно контекста — все неудачные попытки, все промежуточные выводы. Итерация 1 стоит 100 токенов, итерация 10 — уже тысячи. Вы платите за каждый провал снова и снова.

Почему компании сначала платят за чатбота, а потом за агентный рабочий процесс

Gartner фиксирует разрыв в потреблении токенов между пилотными чатботами и production-агентными рабочими процессами в 5–30 раз. А отчёт FinOps Foundation за 2026 год говорит, что 73% компаний превысили изначальный бюджет на ИИ. Цифры взяты из оригинального туториала; полные отчёты Gartner и FinOps Foundation доступны по платным подпискам. Причина разрыва — в неправильном масштабировании: команда планировала стоимость чатбота (~0,04 USD за взаимодействие), а в прод ушёл мультиагентный оркестр (~1,20 USD за взаимодействие, до 70x на сложных задачах).

A loop that runs without an exit condition isn't autonomous. It's a billing event waiting to happen.

Пять примитивов, которые ловят большинство отказов

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

1. Spec writer — заставляет ответить на три вопроса до первого вызова модели.
2. Circuit breaker — режет цикл, если превышены потолки по ходам или токенам.
3. Ledger — ведёт append-only журнал каждого хода в SQLite.
4. Agent loop — связывает три компонента в единый цикл.
5. Review surface — собирает пятиэлементный фрейм и требует человеческой аттестации перед выдачей результата.

Фаза 1. Определить «готово» до первой строчки кода

Самая дорогая ошибка в разработке агентов — не выбор модели, а начало кодинга до того, как команда может одним предложением описать условие завершения. «Агент проверит сайт» — не подходит. «Агент обходит целевой URL, извлекает все теги <title> и <meta name="description">, помечает отсутствующие или слишком длинные и останавливается» — подходит.

Spec writer интерактивно запрашивает три поля, сохраняет их значения в SQLite и возвращает неизменяемый SpecResult(frozen=True). Полученный session_id связывает спецификацию, строки журнала и итоговый результат в одну трассируемую сессию.

Почему frozen=True:
Спецификация — это обязательство, а не черновик. frozen=True запрещает переприсваивать поля объекта SpecResult, поэтому код цикла не может «подвинуть» условие завершения посреди запуска.

Фаза 2. Принудить «готово» на лету

Circuit breaker задаёт два жёстких потолка: turn_limit — максимальное число обращений к модели, и token_limit — суммарное число токенов за всю сессию. Каждый потолок — «строго больше»: если лимит 5 ходов, пятый ещё разрешён, шестой выбросит исключение.

Ключевое правило: breaker.check() вызывается до запроса к модели, а не после. Постфактум проверка бессмысленна: токены уже сожжены. Исключение, а не код возврата, — чтобы нельзя было промолчать.

Как подобрать лимиты для продакшена

Демонстрационные значения 5 ходов / 15 000 токенов слишком жёсткие для реальных задач. Для продакшена автор предлагает настроить лимиты под свой бюджет; в туториале приведён пример breaker = CircuitBreaker(turn_limit=10, token_limit=50000). Если одна сессия должна стоить не дороже 1 USD, а средний ход — 0,10 USD, получается порядка 10 ходов. Конкретный token_limit выбирается исходя из прайсинга модели и среднего размера контекста: чем длиннее история диалога, тем раньше сработает потолок.

• Стартуйте с жёсткими лимитами и разрешайте рост только по метрикам, не по интуиции.
• Отдельно лимитируйте retry-политику: каждый повторный запрос увеличивает и turn_count, и объём контекста.
• Не смешивайте лимит токенов с лимитом выходных токенов модели; circuit breaker считает сумму input + output.

Фаза 3. Записывать всё, что нельзя подделать

Circuit breaker защищает бюджет. Ledger защищает понимание того, что произошло. Это не лог для отладки, а журнал аудита: каждая строка — один ход, append-only, без обновлений и удалений.

Три решения стоит взять на заметку. Во-первых, вместо исходного текста сохраняется SHA-256 хеш входа: так не утекают персональные данные, а одинаковые входы разных запусков можно сравнивать. Во-вторых, pass_fail хранится как INTEGER (1/0), потому что у SQLite нет булева типа. В-третьих, временная метка — datetime.now(timezone.utc).isoformat(), так как datetime.utcnow() объявлен устаревшим в Python 3.12.

Фаза 4. Цикл, который уважает границы

Agent loop — единственный компонент, который обращается к языковой модели. Всё остальное работает локально: проверка потолков, запись в журнал, оценка условия выхода.

Анатомия одного хода простая и строгая: сначала breaker.check(), потом вызов модели, потом ledger.write(), потом проверка stop_reason. Если модель вернула end_turn — возвращаем результат. Если нет — добавляем сообщение continue и идём на следующий круг.

Этот вариант цикла — минимальный текстовый. Если агент использует инструменты, в Anthropic API stop_reason может быть tool_use: тогда нужно выполнить инструмент, вернуть его результат в messages и только потом решать, продолжать или завершать.

Системный промпт обязательно включает все три поля спецификации, а не только done_looks_like. Модели нужна негативная область — то, что агент делать не должен (what_it_does_not), — не меньше, чем позитивная: иначе она начнёт «добавлять ценность» за рамками задачи.

Фаза 5. Поверхность согласования: цикл бежит к человеку

Circuit breaker и ledger решают технические проблемы, но не отвечают на вопрос: «Соответствует ли результат тому, что обещали?» Именно здесь ошибки проходят в прод: вывод выглядит аккуратным, дашборд зелёный, ревьюер ставит галочку.

Review surface собирает пятиэлементный фрейм из SQLite и требует явной аттестации:

1. Исходное обещание — три поля спецификации.
2. Критерий приёмки — поле done_looks_like как явный бенчмарк.
3. Diff — вход первого хода, выход последнего, число ходов, токены, сработал ли breaker.
4. Доказательства — все строки ledger за сессию.
5. Неразрешённые допущения — строки с breach_reason и failed-ходами.

После согласования ревьюер вызывает attest(). Функция собирает пятиэлементный фрейм в каноническом порядке и считает от него SHA-256 — получается frame_hash. Это аудиторская квитанция: она доказывает, что ревьюер видел именно этот фрейм, а не краткое резюме.

Практический пример: SEO-аудит по расписанию

Автор приводит пример SEO-аудита. SEO-аудит имеет естественный ритм: обход, выявление проблем, исправление, ожидание переиндексации. Запускать агента 24/7 бессмысленно — он будет сжигать токены в паузах между событиями. Честная архитектура — cron-задача, которая запускает цикл по расписанию.

Пример упрощён:
В production-варианте стоит проверять URL (допустимые схемы и хосты) и оборачивать requests.get в try/except requests.RequestException, чтобы агент не падал при недоступности сайта.

Cron-строка выглядит так:

Агент выполняет работу, записывает ходы в ledger, и если circuit breaker сработал — результат уходит на человеческую проверку, а не в прод.

Провайдер-независимость через адаптер

Цикл работает с любым клиентом, удовлетворяющим протоколу LLMClient. По умолчанию используется Anthropic, но через адаптер можно подключить OpenAI, Gemini, Ollama, локальные модели или собственный сервер. В репозитории автора показан иллюстративный пример адаптера для OpenAI. Главное — привести ответ к форме, которую ожидает AgentLoop: usage.input_tokens, usage.output_tokens, content[0].text, stop_reason.

Выводы: дисциплина дороже модели

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

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

Define what done looks like before you start. That's the job, and always has been.

Полный код и 80 тестов с 100% покрытием доступны в репозитории автора оригинала: github.com/dannwaneri/production-safe-agent-loop.

Источник: How to Build a Production-Safe Agent Loop — From Exit Conditions to Audit Trails, freeCodeCamp.

LiteLLM — популярный open-source ИИ-шлюз, который выступает единой точкой доступа к свыше ста провайдерам моделей (OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure и другим). Через него проходят API-ключи, промпты и ответы, поэтому компрометация шлюза равнозначна компрометации всей ИИ-инфраструктуры.

Три CVE объединяются в цепочку: CVE-2026-47101 (обход авторизации), CVE-2026-47102 (повышение привилегий) и CVE-2026-40217 (выполнение кода).

Оценка полной цепочки — CVSS 9,9. Отдельная CVE-2026-47102 получила 8,7 по CVSS 4.0 и 8,8 по CVSS 3.1.

Исправление вошло в релиз LiteLLM v1.83.14-stable, опубликованный 2 мая 2026 года — это первый релиз с полным набором патчей.

Компрометация открывает доступ к мастер-ключу LiteLLM, salt-ключу для расшифровки сохранённых учётных данных, URL базы данных и всем провайдер-ключам, а также позволяет подменять ответы модели.

Это не первый серьёзный инцидент с LiteLLM в 2026 году: в марте злоумышленники скомпрометировали PyPI-релизы проекта, а в апреле критическая SQL-инъекция эксплуатировалась менее чем через сутки после раскрытия. Новая цепочка пока не зафиксирована в реальных атаках, но её потенциальная опасность сопоставима с полным захватом сервера.

Как работает цепочка

Атака строится на том, что разные уровни проверок доверяют данным, которые присылает пользователь. Роль internal_user — это учётная запись с низкими правами по умолчанию, которую часто выдают обычным сотрудникам.

• CVE-2026-47101 — обход авторизации. Обычный internal_user при создании виртуального ключа может указать поле allowed_routes без проверки. Значение ["/*"] даёт доступ ко всем маршрутам, включая административные.
• CVE-2026-47102 — повышение привилегий. Эндпоинт /user/update позволяет пользователю редактировать собственную запись и записать user_role: "proxy_admin". После этого атакующий становится полным администратором.
• CVE-2026-40217 — выполнение кода. Механизм Custom Code Guardrail (он запускает Python-скрипты для проверки запросов) компилирует код администратора через exec() без фильтрации. Если в глобальном пространстве имён (globals) не убран __builtins__, Python автоматически подкладывает встроенные функции — нужно лишь вызвать os.system для обратного шелла.

Чем это опасно

Шлюз сидит между агентом и моделью, поэтому взломанный прокси читает и может изменять всё, что через него проходит. Атакующий получает мастер-ключ LiteLLM, salt-ключ для расшифровки сохранённых учётных данных, URL СУБД и все провайдер-ключи. Кроме утечки данных, он может подменять ответы модели: в демонстрации Obsidian встроенный обратный вызов LiteLLM (callback) подменил ответ Claude Code на поддельный вызов инструмента. Пользователь напечатал одно слово hello, а агент выполнил код, открывший реверс-шелл на машине разработчика.

Что делать

• Обновиться до LiteLLM v1.83.14-stable или новее — это первый релиз с полным набором патчей.
• Перепроверить всех пользователей с ролью proxy_admin: в LiteLLM эта роль может запускать произвольный код через Custom Code Guardrail и MCP, то есть фактически даёт root-доступ на хост.
• Проверить обратные вызовы (callbacks) в litellm_settings.callbacks в config.yaml: они не видны в интерфейсе, но исполняются на каждом запросе.
• Провести аудит Custom Code Guardrail и убедиться в целостности развёрнутого кода, а не только конфигурации.
• При подозрении на компрометацию сменить провайдер-ключи, учётные данные БД и MCP-токены.

Контекст: ранее Tproger уже разбирал supply chain-атаку на LiteLLM, в ходе которой вредоносные версии пакета попали на PyPI.

Если в вашей сети есть LiteLLM — обновление и аудит прав стоит провести до конца недели. Подробнее — в первоисточнике.

HTTP/2 Bomb — это комбинация двух техник отказа в обслуживании, известных свыше десяти лет: HPACK bomb (класс атаки; известный частный случай — CVE-2016-6581 в библиотеке Python HPACK) и удержания соединений в стиле Slowloris в реализации HTTP/2 Apache (CVE-2016-8740, CVE-2016-1546). Первая заставляет сервер резервировать память под динамические таблицы сжатых заголовков, вторая не даёт соединениям закрыться.

Codex от OpenAI объединил HPACK-бомбу и Slowloris в единую атаку HTTP/2 Bomb.

Уязвимы стандартные конфигурации nginx, Apache httpd, Microsoft IIS, Envoy и Cloudflare Pingora.

По данным сканирования Shodan, более 880 тысяч сайтов на HTTP/2 могут быть под угрозой.

nginx исправлен в версии 1.29.8, Apache — в mod_http2 v2.0.41 (CVE-2026-49975), Envoy выпустил исправление.

Для Microsoft IIS и Cloudflare Pingora официального исправления пока нет; рекомендуется ограничить число заголовков в запросе или отключить HTTP/2.

Атаку выявила команда Calif во главе с исследователем Quang Luong. Они использовали Codex для анализа исходного кода: агент заметил, что две известные DoS-техники можно объединить, и помог построить рабочий эксплойт. По словам Luong, домашний компьютер на канале 100 Мбит/с способен сделать уязвимый сервер недоступным за несколько секунд. Против Apache httpd и Envoy один клиент тратит 20 секунд, чтобы занять 32 ГБ памяти сервера.

Как работает HTTP/2 Bomb

HTTP/2 сжимает заголовки алгоритмом HPACK и хранит их в динамических таблицах. Атака отправляет тысячи мелких заголовков, чтобы заставить сервер резервировать память под каждую запись таблицы — даже если сами заголовки почти пустые. Одновременно соединения удерживаются открытыми по принципу Slowloris, и сервер не может освободить выделенную память.

Кто уже выпустил исправления от HTTP/2 Bomb

• nginx — версия 1.29.8, директива max_headers из freenginx.
• Apache httpd — mod_http2 v2.0.41, CVE-2026-49975.
• Envoy — выпущено исправление, исследователи проверяют его эффективность.
• Microsoft IIS и Cloudflare Pingora — исправлений пока нет. Cloudflare оспаривает наличие уязвимости в Pingora, но заявляет, что её архитектура и DDoS-защита справляются с атакой автоматически.

Как защититься от HTTP/2 Bomb

Пока Microsoft и Cloudflare не выпустили обновления, Calif рекомендует либо отключить HTTP/2, либо ограничить максимальное количество заголовков, которые клиент может отправить в одном запросе.

Выводы

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

Технический разбор и PoC-скрипты опубликованы в блоге Calif и на GitHub. Дополнительные детали — в материале The Register.

Если ваш сервер использует HTTP/2 — проверьте защиту от HTTP/2 Bomb: обновите ПО и ограничьте заголовки прямо сейчас.

Техника описана в исследовательской статье, которую представят на конференции DIMVA в июле 2026 года. Атака работает исключительно внутри браузера и не требует никаких действий от пользователя.

Как работает FROST

FROST (Fingerprinting Remotely using OPFS-based SSD Timing) использует побочный канал утечки на основе конкуренции процессов за доступ к общему ресурсу. В данном случае ресурс — SSD-накопитель пользователя.

Вредоносный сайт создаёт большой файл (от 1 ГБ) в Origin Private File System (OPFS) — изолированном хранилище, доступном через JavaScript без запроса разрешений. Затем код выполняет случайные чтения из этого файла и измеряет задержки. Если в это время другая вкладка или приложение обращается к SSD, задержки меняются. Эти изменения анализирует предобученная свёрточная нейросеть (CNN), которая по сигнатуре нагрузки определяет, что именно работает в системе.

Исследователи продемонстрировали полноценную атаку на Mac с процессором M2. На Linux подтвердили работу базового примитива — измерение задержек через JavaScript. Windows в тестах не участвовала, но авторы не исключают, что техника применима и там.

OPFS поддерживается во всех современных браузерах на базе Chromium, а также в Firefox и Safari. Это означает, что потенциально техника применима к большинству пользователей десктопного веба.

FROST позволяет сайтам отслеживать открытые вкладки и приложения через анализ SSD-активности.

Атака работает внутри браузера через JavaScript и OPFS, без взаимодействия с пользователем.

Ключевой инструмент — свёрточная нейросеть, классифицирующая задержки чтения SSD.

Полная атака продемонстрирована на macOS (M2); на Linux работает базовый примитив.

Пока не зафиксировано случаев применения FROST в реальных условиях.

Ограничения и защита

У техники есть важные ограничения. Для атаки файл в OPFS должен занимать не менее 1 ГБ. Это означает, что массовое применение будет заметно: создание гигабайтного хранилища в браузере занимает время и место на диске. Кроме того, OPFS должен находиться на том же SSD, что и отслеживаемые приложения.

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

Итоги

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

Источник: Ars Technica. Читайте также о новой защите Firefox от цифрового отпечатка.

Историю обнародовал журналист Брайан Кребс в материале от 18 мая по наводке исследователя из GitGuardian. Репозиторий назывался без лишней скромности — Private-CISA — и был виден любому, кто откроет GitHub.

• Подрядчик CISA с 13 ноября 2025 года вёл публичный репозиторий Private-CISA размером 844 МБ с паролями, ключами AWS GovCloud, сертификатами Entra ID SAML и Kubernetes-манифестами.
• Пароли лежали в открытом виде в CSV-файле, а среди файлов был importantAWStokens с админ-доступом к трём серверам AWS GovCloud.
• Чтобы такое стало возможным, в аккаунте было выключено стандартное правило GitHub, блокирующее коммиты с секретами.
• GitGuardian называет утечку «худшей в карьере» исследователя, но CISA утверждает, что «нет признаков компрометации чувствительных данных».
• Репозиторий закрыли вечером 15 мая 2026 года, спустя около 26 часов после уведомления исследователей — но он был публичным около полугода.

Что лежало в Private-CISA

GitGuardian, компания, у которой сканер постоянно обходит публичные репозитории GitHub в поисках утёкших секретов, наткнулась на репозиторий 14 мая 2026 года. По объёму это 844 МБ — 498 МБ в рабочем дереве, остальное в истории Git. Среди папок и файлов исследователи нашли:

• importantAWStokens — административные токены к трём серверам AWS GovCloud (изолированный облачный регион Amazon для госструктур США).
• AWS-Workspace-Firefox-Passwords.csv — экспорт сохранённых паролей Firefox с десятками логинов и паролей от внутренних систем CISA в открытом виде.
• CAWS GitHub Token.txt — отдельный токен GitHub-организации.
• Kube-Config.txt — конфигурации Kubernetes для доступа к кластерам.
• Папку ENTRA ID — SAML Certificates с сертификатами для единого входа через Microsoft Entra ID.
• Папки All Backups, Backup-April-2026, LZ-Artifactory, Kubernetes-Important-Yaml-Files — внутренние бэкапы, манифесты ArgoCD и YAML-файлы с секретами.
• Terraform-код инфраструктуры и GitHub Actions, описывающие, как CISA собирает, тестирует и выкатывает свой софт.
• Резервные копии внутренней документации в форматах OneNote и DOCX, плюс скрипты для GitHub, Kubernetes, ArgoCD.

Один из попавших в репозиторий хостов назывался LZ-DSO — по словам исследователей это сокращение от Landing Zone DevSecOps, то есть от среды, в которой CISA «безопасно» собирает свой код. Иронично: ключи от пайплайна, который должен защищать всё остальное, лежали публично.

Это худшая утечка, которую я видел за свою карьеру.

Сначала команда GitGuardian приняла находку за розыгрыш: слишком уж красноречивые названия папок и файлов. Но личные документы, имена хостов и аккуратная структура повторных бэкапов убедили — это рабочая копия чьего-то ноутбука, которую регулярно «синхронизировали» через git push в открытый репозиторий.

Как нашли и сообщили

Согласно подробному разбору GitGuardian, программа Good Samaritan компании первой обнаружила утечку и автоматически отправила девять писем владельцу коммитов. К утру 15 мая в ответ пришли только автоответчики.

Тогда исследователи связались с Брайаном Кребсом, чтобы он передал утечку напрямую своим контактам в CISA. Параллельно подключились партнёры с прямой линией в агентство. Около 16:00 по центральноевропейскому времени удалось дозвониться, а в районе 18:00 по восточному времени США репозиторий стал недоступен. От первого выявленного слива до закрытия прошло чуть больше суток — но создан репозиторий был 13 ноября 2025 года, так что окно для злоумышленника составляло около полугода.

Хронология

• 13 ноября 2025 — создан публичный репозиторий Private-CISA, первые секреты залиты.
• 13 мая 2026 — автоматический сканер GitGuardian Good Samaritan уже успел отправить владельцу репозитория девять писем-предупреждений.
• 14 мая 2026, 16:14 CET — GitGuardian фиксирует инцидент и подаёт его в CERT/CC (координационный центр по реагированию на киберинциденты), параллельно ища личные контакты в CISA.
• 15 мая 2026 — GitGuardian параллельно выходит на Кребса для эскалации через его контакты и на собственных партнёров с прямой линией в агентство; около 16:00 CET до CISA дозваниваются.
• 15 мая, около 18:00 EST — репозиторий удалён.

Почему secret scanning не сработал

GitHub давно предлагает push protection — функцию, которая не даёт залить в публичный репозиторий распознанные секреты вроде токенов AWS, ключей SSH или ключей API. Для бесплатных публичных репозиториев она включена по умолчанию с 2024 года. Но защита от дурака легко выключается одним кликом, и в случае с Private-CISA её действительно отключили — Кребс цитирует исследователей, которые нашли в истории коммитов следы того, что владелец аккаунта вручную убрал блокировку секретов.

Это распространённый паттерн: разработчик сталкивается с блокировкой пуша, не разбирается, почему сработала защита, и снимает её через настройки. Иногда — в личном репозитории «для удобства», иногда — потому что коммит уже содержит что-то более чувствительное, чем тестовый ключ. Результат предсказуем: репозитории, в которых годами лежат «временные» .env-файлы с продакшен-доступами, и автоматические сканеры вроде GitGuardian, TruffleHog или GitHub Secret Scanning, которые рано или поздно их находят.

По версии Gizmodo, сотрудник подрядчика Nightwing использовал GitHub как личную папку «Загрузки»: коммитил файлы с рабочего ноутбука, чтобы открыть их на домашнем компьютере. То же самое многие делают через личную почту, только публичный репозиторий ещё хуже — он проиндексирован поисковиками и сканируется ботами в режиме реального времени.

Кто такая CISA и почему это важно

Особый цинизм истории — в том, кто оказался виновником. CISA (Cybersecurity and Infrastructure Security Agency) — молодое подразделение Министерства внутренней безопасности США, отвечающее за кибербезопасность всех федеральных гражданских сетей. Это именно та организация, которая публикует руководства про «никогда не храните пароли в спредшитах». При этом, по данным TechCrunch, у CISA с 20 января 2025 года нет постоянного директора, агентство потеряло около трети штата после сокращений и отпусков, а ни один временно исполняющий обязанности не был утверждён Сенатом. В таких условиях процессы по контролю подрядчиков и аудиту репозиториев предсказуемо проседают — и тот факт, что утечку у регулятора по кибербезу нашёл частный сканер, а не внутренние инструменты, красноречивее любого внутреннего отчёта.

Что делать в своей команде, чтобы не повторить историю CISA

История CISA читается как готовый чеклист «как не надо». Перевернём его в «как надо» — для команд от стартапа до крупного бизнеса.

1. Включите GitHub push protection на уровне организации и запретите её отключать. Owner organization → Security → Secret protection → Push protection: Enabled.
2. Запретите коммитеры-индивидуумам быть owner репозиториев в проде. Любой публичный репозиторий компании должен принадлежать организации с настроенными правилами.
3. Сканируйте свою историю, а не только новые коммиты. Один раз пропущенный .env остаётся в Git forever — поможет TruffleHog, GitGuardian, GitHub Advanced Security или встроенный git-secrets.
4. Не используйте Git как файлообменник между домашним и рабочим компьютером. Для этого есть VPN, корпоративный OneDrive, S3-бакет с IAM, в конце концов — scp.
5. Включите автоматическую ротацию ключей AWS и сервис-токенов. Даже если они утекут, окно использования закроется через сутки-двое.
6. Настройте мониторинг подозрительных вызовов API в облаке. Для AWS — CloudTrail + GuardDuty с алертами на новые регионы, необычные IAM-действия и обращения к AWS API из неизвестных IP. Если ключ всё-таки утёк — вы узнаете об этом по логам, а не из новостей.
7. Раз в квартал проводите аудит публичных репозиториев: gh repo list ORG --visibility public и быстрая проверка, что там должно лежать публично.

GitHub в своём блоге называет push protection первой линией защиты и приводит цифру: с момента включения по умолчанию на бесплатных публичных репозиториях функция предотвратила сотни тысяч случайных утечек. Эту настройку выключают именно те, кто потом попадает в новости.

Что говорят сами CISA и эксперты

Сводный ответ агентства для Кребса и TechCrunch звучит как стандартная PR-формула. TechCrunch уточняет, что комментарий дал пресс-секретарь CISA Марко ДиСандро:

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

Проблема в формулировке «нет признаков»: при шестимесячном окне публичности любые токены стоит считать скомпрометированными по умолчанию. Стандартный план действий — отозвать всё, выпустить новое, проанализировать логи AWS CloudTrail на предмет обращений с этих токенов и опубликовать честный разбор инцидента. До такого разбора инцидента публично CISA пока не дошла, и в TechCrunch агентство не ответило, отозваны ли ключи.

Что в итоге

Сюжет «подрядчик слил ключи в публичный git» повторяется в индустрии раз в пару месяцев, но обычно героем оказывается стартап или подрядчик банка. Случай с CISA выделяется тем, что виновником стало именно то агентство, которое выпускает рекомендации по защите от подобных утечек.

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

Для разработчиков вывод предельно практичный: включите push protection, проверьте свои публичные репозитории, не подсовывайте секреты в Git ни на минуту. История CISA — это просто очень громкая иллюстрация того, как один человек, перетаскивающий файлы с ноутбука на ноутбук через git, способен поставить под угрозу целое ведомство.

Источники: Krebs on Security — CISA Admin Leaked AWS GovCloud Keys on Github; GitGuardian Blog — How We Got a CISA GitHub Leak Taken Down in Under a Day; TechCrunch — US cyber agency CISA exposed reams of passwords and cloud keys to the open web; Gizmodo — «The Worst Leak That I've Witnessed».

317 npm-пакетов скомпрометированы через взломанный аккаунт atool: под угрозой echarts-for-react (3,8 млн загрузок/мес), size-sensor (4,2 млн) и более 250 пакетов @antv.

Вредонос — тот же тулкит Mini Shai-Hulud, что три недели назад атаковал SAP: одинаковая архитектура сканера, те же регулярные выражения для поиска учётных данных.

Payload объёмом 498 КБ крадёт учётные данные AWS (включая EC2 metadata и ECS), GitHub PAT, токены npm, SSH-ключи, данные 1Password и Bitwarden.

Двойная эксфильтрация: через публичные GitHub-репозитории с зашифрованными Git-объектами и HTTPS-запросы к t.m-kosche[.]com под видом OpenTelemetry-трейсов.

Вредонос перехватывает AI-агентов: внедряет SessionStart-хуки в Claude Code и Codex, а также задачи runOn:folderOpen в VS Code.

Масштаб атаки

Аккаунт atool на npm поддерживает 547 пакетов. Атакующий опубликовал вредоносные версии двумя волнами: первая — с 01:39 до 01:56 UTC (~317 версий), вторая — с 02:05 до 02:06 UTC (~314 версий). В результате 309 пакетов получили по два заражённых релиза каждый.

• size-sensor — 4,2 млн загрузок/мес
• echarts-for-react — 3,8 млн загрузок/мес
• @antv/scale — 2,2 млн загрузок/мес
• timeago.js — 1,15 млн загрузок/мес
• @antv/x6, @antv/g, @antv/g6 и более 250 других пакетов @antv

Важно: атакующий не переставил тег latest — но это не защищает. npm выбирает наибольшую версию, удовлетворяющую semver-диапазону, независимо от тега. Проект с "echarts-for-react": "^3.0.6" при следующей чистой установке получит вредоносную 3.2.7.

Как работает вредонос

498-килобайтный обфусцированный Bun-скрипт запускается через preinstall-хук. Дополнительно 630 из 637 версий добавляют в optionalDependencies ссылку на «сиротские» коммиты в репозитории antvis/G2 на GitHub с поддельным авторством. Этот механизм позволяет доставить payload даже при блокировке preinstall-хуков: npm резолвит github:-зависимости по SHA без проверки истории ветки.

Скрипт собирает учётные данные по всей цепочке AWS: переменные окружения, файлы конфигурации, EC2 Instance Metadata Service (169.254.169.254), ECS container metadata (169.254.170.2), Secrets Manager. Помимо этого — токены Kubernetes, HashiCorp Vault, GitHub PAT, токены npm, SSH-ключи и хранилища паролей: 1Password, Bitwarden, pass, gopass.

Эксфильтрация идёт двумя параллельными каналами: украденные данные коммитятся как Git-объекты в публичные GitHub-репозитории с названиями в формате Dune-вселенной (sardaukar-sandworm-42, fremen-stillsuit-7 и т.п.), а также отправляются RSA+AES-зашифрованными POST-запросами к t.m-kosche[.]com — замаскированными под данные OpenTelemetry.

Для закрепления в системе вредонос устанавливает systemd-сервис kitty-monitor (или LaunchAgent на macOS), который каждый час опрашивает GitHub Commit Search API в поиске RSA-PSS-подписанных команд по ключевому слову firedalazer. Это классический GitHub dead-drop C2-бэкдор.

Связь с атакой на SAP

Исследователи SafeDep идентифицировали payload как Mini Shai-Hulud — тот же тулкит, который три недели назад был использован в компрометации SAP. Совпадают архитектура сканера, набор регулярных выражений для поиска учётных данных и паттерны обфускации. Название отсылает к Дюне Фрэнка Герберта: Shai-Hulud — гигантский песчаный червь, пожирающий всё на своём пути.

Что делать

1. Проверить package-lock.json или yarn.lock — найти версии из списка скомпрометированных пакетов (полный список в источнике).
2. Удалить node_modules и переустановить зависимости после того, как npm отзовёт вредоносные версии.
3. Проверить наличие kitty-monitor.service (Linux) или com.user.kitty-monitor.plist (macOS).
4. Проверить файл ~/.claude/settings.json — не должно быть SessionStart-хуков, запускающих node .claude/setup.mjs.
5. Ротировать все учётные данные: AWS IAM, GitHub PAT, npm-токены, SSH-ключи — если машина устанавливала заражённые пакеты.

Индикаторы компрометации

Источник: SafeDep — Mini Shai-Hulud Strikes Again: 317 npm Packages Compromised

Уязвимость нашли и сообщили в ASF Bartlomiej Dmitruk (сооснователь Striga.ai) и Stanislaw Strzalkowski (исследователь ISEC.pl). DoS тривиален и работает на любом дефолтном Apache, у которого включён mod_http2 и выбран многопоточный MPM (Multi-Processing Module — модель обработки запросов; в современных продакшенах это обычно worker или event). RCE-путь требует ещё одного условия — APR (Apache Portable Runtime, слой работы с памятью и файлами в Apache) с mmap-аллокатором. Это дефолт на Debian-подобных дистрибутивах и в официальном httpd Docker-образе.

• CVE-2026-23918, CVSS 8.8 — double-free в mod_http2, стеком cleanup в h2_mplx.c. Затронут Apache 2.4.66, патч в 2.4.67.
• DoS — тривиален: один TCP, два HTTP/2-фрейма (HEADERS + RST_STREAM с ненулевым error code), без авторизации, без специальных URL — воркер падает.
• RCE — рабочий PoC на x86_64. Подменяется h2_stream, указатель cleanup-функции направляется на system(). В лабораторных условиях, по словам авторов, исполнение приземляется за минуты.
• Затронуты только многопоточные MPM (worker, event); MPM prefork — не уязвим. RCE только при APR с mmap-аллокатором (Debian-семейство, httpd Docker).
• Поверхность атаки большая: mod_http2 идёт в дефолтных сборках, HTTP/2 широко включён в продакшене. Обновляться сразу.

Как срабатывает double-free

Триггер очень короткий: клиент отправляет HTTP/2-фрейм HEADERS, сразу за ним — RST_STREAM с ненулевым error code на том же stream. Главное условие — мультиплексер ещё не успел зарегистрировать stream.

В этот момент два колбэка nghttp2 срабатывают подряд: on_frame_recv_cb для RST и затем on_stream_close_cb для close. Оба вызывают цепочку h2_mplx_c1_client_rst, которая запускает m_stream_cleanup, и оба раза один и тот же указатель h2_stream пушится в массив spurge cleanup — то есть в очередь на освобождение.

Когда позже c1_purge_streams проходит по spurge и для каждого элемента вызывает h2_stream_destroy с последующим apr_pool_destroy, второй вызов уже работает с уже освобождённой памятью. Это и есть double-free: память освобождается дважды, и в её ячейке к этому моменту уже может лежать чьи-то другие данные.

DoS: тривиальный, работает на дефолтных сборках

Один TCP-коннект, два фрейма, без аутентификации, без специальных заголовков, без определённого URL — и воркер падает. Apache перезапускает его, но каждый запрос на упавший воркер дропается. Атаку можно поддерживать сколько угодно, пока атакующий продолжает слать запросы.

RCE: PoC на x86_64

Цепочка эксплуатации, по описанию авторов:

1. Через mmap-reuse подкладывается поддельный h2_stream по освобождённому виртуальному адресу.
2. Указатель cleanup-функции пула направляется на system().
3. В качестве стабильного контейнера для fake-структур и команды используется память Apache scoreboard.

Логика классическая для класса use-after-free: освобождённая ячейка памяти повторно используется системой под другой объект, который контролирует атакующий. Когда Apache позже вызывает функцию очистки по сохранённому в этой ячейке указателю, управление улетает туда, куда атакующий написал. Scoreboard Apache — общая таблица состояния воркеров — сидит по фиксированному адресу на всю жизнь сервера, даже при включённом ASLR (Address Space Layout Randomization, рандомизация адресного пространства). Это и есть то, что делает RCE-путь практичным. Авторы уточняют ограничения: нужен info leak (утечка адреса system() и оффсетов scoreboard) и heap spray (массовое выделение памяти, чтобы поймать конкретный адрес) — в дикой природе это требует терпения. В лабораторных условиях, по словам авторов, успех укладывается в минуты.

Кто затронут — и что делать

• Затронут: Apache HTTP Server 2.4.66 с mod_http2 и многопоточным MPM (worker, event).
• Не затронут: MPM prefork (он однопроцессный, иной cleanup-путь).
• RCE-условие: Apache Portable Runtime (APR) с mmap-аллокатором — дефолт на Debian, Ubuntu и в официальном httpd Docker-image.
• Патч: Apache HTTP Server 2.4.67. ASF рекомендует обновляться немедленно.

Минимальный чек-лист — что сделать сегодня:

1. httpd -v — проверить версию. Если 2.4.66 и есть HTTP/2 — затронуты.
2. Обновить до 2.4.67 (через пакетный менеджер дистрибутива или пересборкой Docker-образа).
3. Если обновить прямо сейчас нельзя — временно отключить mod_http2 или переключиться на MPM prefork (но он медленнее под нагрузкой).
4. Проверить логи на следы атаки: HTTP/2 RST_STREAM с error-кодом — не штатный сценарий, и подозрительны массовые падения воркеров. Команда быстрого поиска: grep -E 'child .* exit signal Segmentation' /var/log/apache2/error.log.

Выводы

CVE-2026-23918 — типичный пример уязвимости класса use-after-free с RCE-путём через предсказуемый адрес scoreboard. Триггер крошечный, фикс простой, но поверхность атаки огромная: каждый сервер с включённым HTTP/2 и multi-threaded MPM открыт хотя бы для DoS.

Главное практическое правило: обновите Apache до 2.4.67. Если обновить нельзя сию минуту — отключите HTTP/2 как временное обходное решение. Это уязвимость, которую с большой вероятностью начнут эксплуатировать в массовых сканах в ближайшие дни.

Подробный разбор и комментарии исследователей — на The Hacker News. Бюллетень Apache — на httpd.apache.org/security.

Атака не теоретическая. Первая практическая демонстрация вышла в 2004 году; в 2005 поверх неё надстроили языковые модели. В 2023 исследовательская группа из университетов Surrey, Durham и Royal Holloway показала 95%+ top-1 точности (то есть угадывания клавиши с первой попытки) на MacBook Pro — по записи со смартфона на расстоянии 17 см. Изменилось одно — теперь обучить такую модель может любой разработчик за полдня на собственном ноутбуке.

Реальная угроза. Не подложенный микрофон в офисе, а Zoom, Teams, Meet, Discord, голосовые сообщения, заражённые браузерные вкладки, ноутбук в кафе. Везде, где вы сами включили микрофон.

Точность. Мини-CNN на 250 тыс. параметров: top-1 82–88%, top-3 95–97% на 35 классах (буквы + знаки) при 3000 семплов на пару пользователь/клавиатура.

Пароли особенно уязвимы. Языковая модель не помогает (пароли не из словаря), зато сужается перебор: top-3 предсказаний на символ → 3⁸ = 6 561 кандидат для 8-символьного пароля. Online brute force против большинства сервисов.

Что работает в защите. Мьют микрофона перед вводом пароля + менеджер паролей (auto-fill полностью убирает акустический сигнал) + аппаратные ключи (FIDO2/YubiKey).

Что НЕ работает. «Печатать тише», случайный ритм набора, программные шумодавы (RNNoise, Krisp). Шумодавы оптимизированы под речь — клик клавиши проходит почти без потерь.

Что именно слышит микрофон

Когда вы нажимаете клавишу A, микрофон ловит три события: push (механический клик дна хода клавиши, ~5–10 мс, широкий спектр), release (возврат купола вверх, ниже по амплитуде, через 10–30 мс) и — главное — резонанс корпуса. Удар по клавише заставляет шасси ноутбука кратко звенеть на собственных частотах, а разные клавиши находятся на разных расстояниях от резонансных узлов и возбуждают чуть разные моды.

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

Релевантная полоса частот — 400 Гц … 12 кГц. Ниже — комнатный шум и кондиционер; выше — тишина и собственный шум микрофона. Стандартного 44,1 кГц моно более чем достаточно: фирменный микрофон не нужен.

Что собирает атакующий

Авторы pwn.guide публикуют полный пайплайн на Python — около 200 строк кода, всё через pip-зависимости (numpy, scipy, librosa, soundfile, sounddevice, pynput, torch). Шаги:

1. Сбор: 3 000 размеченных нажатий (≈15 минут естественного набора). Скрипт collect.py параллельно ведёт лог нажатий через pynput и пишет аудио. Используется time.perf_counter(), чтобы NTP-коррекция не сбила метки.
2. Нарезка: аудио рубится на 100-мс окна вокруг каждого нажатия. Между событием в ОС и пиком в аудио есть 5–40 мс задержки — её надо выровнять поиском пика по огибающей. Без этого точность падает с 85% до 60%.
3. Фичи: для каждого окна — log-mel спектрограмма (64 mel-бина, fmin=400, fmax=12 000). Тензор (64 × 35), один клип ≈ 9 КБ.
4. Модель: компактная CNN на ~250 тыс. параметров — четыре свёрточных блока + AdaptiveAvgPool. На GPU тренируется за 5 минут, на CPU — за 30.
5. Инференс: предсказание для 100-мс окна занимает доли миллисекунды.

Цифры, ради которых это страшно

На самостоятельно собранном датасете из ~3 000 нажатий и 35 классов:

• Top-1 точность: 82–88%, в зависимости от шума при сборе данных.
• Top-3 точность: 95–97% — почти всегда правильная клавиша входит в тройку лучших предсказаний.
• Распределение по классам неровное. Space, Enter, Backspace — около 99% (механически отличаются от обычных клавиш). Соседние буквы основного ряда (F/G, J/K) — иногда 60% top-1.

85% точности на уровне символов звучит не страшно — в предложении будет 2–3 ошибки. Но если прогнать top-5 предсказаний через beam search с словарём частотности слов, восстановление связного текста на естественном языке выходит на 95%+ точности на уровне слов. Это исследовали ещё Zhuang и соавторы в 2005 году; современные char-LM делают этот шаг тривиальным.

Почему пароли беззащитнее обычного текста

Языковая модель — главное усиление атаки на обычный текст — на паролях не работает: их специально проектируют непохожими на слова. Зато у атакующего другое преимущество: пространство поиска ограничено. Если модель выдаёт top-3 предсказания на символ с 96% точностью, у 8-символьного пароля максимум 3⁸ = 6 561 кандидат для перебора. Это в зоне online brute force против большинства сервисов и тривиально оффлайн против любого слитого хеша.

В 2026 году аудиозапись того, как вы набираете пароль, эквивалентна передаче пароля.

Что реально защищает — и что нет

Авторы прямо сортируют защиты по эффективности.

Работает:

1. Мьют микрофона перед вводом любого секрета. Единственная полностью надёжная защита и стоит ноль.
2. Менеджер паролей с auto-fill. Нет нажатий — нет акустического сигнала. Самая большая практическая мера именно против атаки на пароли.
3. Аппаратные ключи (FIDO2/WebAuthn, YubiKey). Один тап = один акустический след, восстанавливать нечего.
4. Внешняя клавиатура подальше от микрофона. Механика не безопаснее — она громче. Но USB-клавиатура на дальнем краю стола, на отдельной поверхности, материально снижает SNR.
5. Акустическое демпфирование. Толстый коврик или сложенное полотенце под ноутбуком — снижение резонанса корпуса на 3–6 дБ. Помогает, но не панацея.

Не работает (вопреки ожиданиям):

• «Печатать тише». Амплитуда падает, спектральный отпечаток сохраняется. Минус 5% точности.
• Случайный ритм набора. Атака работает по отдельным нажатиям, не учитывает межударные интервалы.
• Программные шумодавы (RNNoise, Krisp). Тюнятся под сохранение речи и удаление широкополосного шума. Клавишные транзиенты выглядят как короткие речевые звуки и проходят насквозь — некоторые шумодавы даже «чистят» нажатия от окружающего фона.
• Белый шум на фоне. Современные модели учатся с шумовой аугментацией — постоянный фон сдвигает точность на копейки. Прерывистые звуки (музыка с резкими пиками) мешают сильнее, но и для оператора некомфортнее.

Чек-лист «что сделать сегодня»

1. Проверить, что у вас стоит password manager с auto-fill (1Password, Bitwarden, KeePassXC, Яндекс.Ключ — что вам ближе) и им активно пользуются для всех проводных логинов.
2. Купить или подключить аппаратный ключ для критичных аккаунтов (root в облаках, GitHub, банк-клиент). YubiKey 5 серии или Token2 — общедоступно в РФ.
3. Поставить хоткей на «mute mic» в Zoom/Teams/Discord, чтобы рефлекторно нажимать перед вводом любого секрета.
4. Если работаете из публичного пространства — внешняя клавиатура подальше от ноутбука, либо bluetooth-наушники с шумодавом + далеко отнесённый телефон вместо встроенного микрофона.
5. Команды разработки: добавить «mute при работе с секретами» в общий гайд по безопасности, а аппаратные ключи — в onboarding для новых сотрудников.

Выводы

Технический барьер атаки за два десятилетия упал до уровня «студент за выходные обучит модель на ноутбуке». Это значит, что угроза перестала быть теоретической — это рабочий инструмент в руках любого, у кого есть доступ к записи вашего созвона. Главная мысль: рассматривать включённый микрофон рядом с клавиатурой как реальный канал утечки секретов, а не как абстрактный риск из академических статей.

Хорошая новость в том, что защита дёшева и не требует новых технологий — менеджер паролей (про бесплатный open-source Bitwarden у нас уже выходил материал) плюс мьют микрофона закрывают практически весь сценарий. Аппаратные ключи (см. обзор YubiKey 5) закрывают остаток.

Источник: Acoustic Keystroke Recovery — Reconstructing Typed Text from a Laptop Microphone (pwn.guide).

• Скомпрометирована одна npm-версия @bitwarden/cli@2026.4.0. Окно атаки — 1 час 33 минуты 22 апреля 2026 года.
• Vault-данные пользователей Bitwarden не затронуты. Пострадал только npm-канал доставки CLI и те, кто успел поставить эту сборку.
• Вектор — скомпрометированный action checkmarx/ast-github-action, который Bitwarden подтягивал в свой CI. По словам исследователей, это первый зафиксированный взлом пакета через npm trusted publishing.
• Малварь таргетит ИИ-ассистенты Claude, Cursor, Codex CLI, Aider и AWS-based Kiro — отдельный модуль собирает их конфиги и API-ключи.
• Если ставили — ротируйте npm/GitHub-токены, SSH-ключи и облачные креденшлы AWS/Azure/GCP; проверьте CI/CD-пайплайны и публичные репозитории со строкой «Shai-Hulud» в имени.

Что случилось с пакетом

По данным The Hacker News, в ночь с 22 на 23 апреля 2026 года в npm-реестре появилась версия @bitwarden/cli@2026.4.0 с дополнительным файлом bw1.js внутри. Сборка была доступна 1 час 33 минуты — с 17:57 до 19:30 по времени Нью-Йорка, — после чего её сняли с публикации. Первыми на неё обратили внимание исследователи Socket, JFrog и OX Security. JFrog описал поведение как «кражу GitHub/npm-токенов, содержимого .ssh, .env, истории shell, секретов GitHub Actions и облачных провайдеров с выгрузкой на внешние домены и в виде коммитов в GitHub».

Bitwarden подтвердил инцидент и уточнил, что «расследование не обнаружило признаков доступа к данным пользовательских хранилищ и компрометации продакшн-систем». По словам компании, доступ нарушителя был отозван, вредоносный релиз помечен как deprecated, по версии 2026.4.0 заводится отдельный CVE. Пострадавшие — только те, кто успел скачать пакет в полуторачасовом окне и выполнил его установку.

Как устроен троян

Механика по отчёту Socket проста, но многоступенчата. В package.json зловредной версии добавлен preinstall-хук, который запускает скрипт bw_setup.js. Тот проверяет наличие Bun — альтернативного JS-рантайма — и, если его нет, скачивает. Затем Bun-ом запускается обфусцированный загрузчик bw1.js. Bun тащат с собой не случайно: на машине жертвы его, скорее всего, нет, а корпоративный EDR (антивирус нового поколения для рабочих станций и серверов) реагирует на неожиданный бинарник хуже, чем на стандартный npm-скрипт. Preinstall-хук при этом срабатывает ещё до того, как код пакета формально «установлен».

• npm- и GitHub-токены из локальных конфигов и переменных окружения;
• приватные SSH-ключи из ~/.ssh;
• содержимое .env-файлов и историю shell (.bash_history, .zsh_history);
• секреты GitHub Actions из переменных окружения CI;
• креденшлы облачных провайдеров — AWS, Azure, Google Cloud;
• конфиги и API-ключи ИИ-ассистентов Claude, Cursor, Codex CLI, Aider и AWS-based Kiro.

Собранные данные шифруются AES-256-GCM и выгружаются двумя каналами. Основной — POST на домен audit.checkmarx[.]cx (конкретно путь /v1/telemetry), который притворяется инфраструктурой Checkmarx. Резервный — малварь создаёт публичные GitHub-репозитории в аккаунте жертвы и кладёт туда зашифрованный payload. В названиях репозиториев встречается строка «Shai-Hulud: The Third Coming» — отсылка к прошлогодней одноимённой кампании в npm. OX Security подчёркивает, что такой тайник (по терминологии безопасников — dead-drop) через GitHub опасен отдельно: утёкшие секреты становятся доступны любому, кто ищет по публичным репозиториям, — а системы защиты почти не следят за исходящим трафиком в GitHub.

Поверх этого в бинарнике есть модуль-червь: с украденным npm-токеном малварь находит все пакеты, которые жертва имеет право публиковать, и вбрасывает в них тот же payload. Endor Labs называет его «CanisterSprawl» и считает один из самых полных npm supply chain-пейлоадов на сегодняшний день: шесть разных поверхностей для сбора секретов, OIDC- и cloud-кража, самораспространение через npm-публикации и отдельный модуль для ИИ-ассистентов.

Отдельный удар по ИИ-ассистентам

Отдельный модуль малвари специально ищет артефакты ИИ-кодеров — API-ключи OpenAI и Anthropic из конфигов Claude, Cursor и Codex CLI, токены Aider, настройки AWS-based Kiro. Endor Labs считает, что это один из первых публично задокументированных случаев, когда supply chain-атака отдельной веткой целится на «кошельки разработчиков у ИИ». Ключ к Anthropic или OpenAI — это не только деньги на балансе аккаунта жертвы, но и возможность с его помощью заставить ИИ-ассистента писать закладки в код при следующих авто-запросах.

Почему малварь пропускает русскую локаль

Малварь завершается без выполнения, если в системе выставлена русская локаль. Socket отмечает три возможных причины: отдельный оператор, использующий общую инфраструктуру, отколовшаяся группа с идеологическими мотивами или эволюция самой кампании. На практике для российских разработчиков это не даёт защиты: большинство dev-машин, серверов и CI-раннеров работают с англоязычной локалью по умолчанию (обычно en_US.UTF-8), поэтому пропуск по локали чаще всего не срабатывает.

Что делать, если могли установить 2026.4.0

• Сначала убедитесь, что пакет действительно попал в ваши машины и раннеры: прогрепайте package-lock.json, pnpm-lock.yaml и yarn.lock на @bitwarden/cli версии 2026.4.0, посмотрите логи npm-установок в ночь на 23 апреля МСК.
• Ротируйте все токены с этих машин: npm-токены, GitHub PAT (включая fine-grained), SSH-ключи, AWS access/secret keys и STS-сессии, Azure SP, GCP service accounts.
• Замените секреты в GitHub Actions и других CI-системах, где пакет мог запускаться, — включая secrets, variables и OIDC-конфигурации.
• Пройдитесь по API-ключам ИИ-ассистентов (Anthropic, OpenAI, Cursor, Aider) и отзовите их в кабинетах провайдеров; сверьте биллинг на предмет аномальных трат.
• Проверьте публичные репозитории в своём GitHub-аккаунте: ищите имена в формате <слово>-<слово>-<3 цифры> (например, fremen-muaddib-042) со строкой «Shai-Hulud» в README и удалите.
• Откатитесь на безопасную версию CLI — 2026.3.x или актуальную стабильную, которую Bitwarden опубликовал после инцидента. Ставьте её через npm i @bitwarden/cli@<версия>, а не через latest или диапазон.

Связь с Checkmarx и первый взлом через npm trusted publishing

Накануне, 21 апреля, Checkmarx раскрыла собственный инцидент — компрометацию KICS Docker-образов, GitHub-расширений и пакета checkmarx/ast-github-action, который используется во многих CI-пайплайнах. По данным Endor Labs, репозиторий Bitwarden подтягивал именно этот action, и через него злоумышленники получили доступ к npm-каналу. Socket приводит прямые пересечения: тот же домен audit.checkmarx[.]cx, тот же паттерн обфускации __decodeScrambled с seed-значением 0x3039 — технический отпечаток, указывающий на одних и тех же авторов, — плюс тот же приём «украсть → выгрузить в GitHub → распространиться дальше».

Исследователь Аднан Хан утверждает, что это первый зафиксированный случай компрометации пакета, использующего npm trusted publishing — механизм OIDC-публикации, при котором GitHub Actions обменивается на короткоживущий npm-токен без долгоживущих секретов в CI. Его как раз продвигали в ответ на регулярные утечки npm-токенов у мейнтейнеров. На деле trusted publishing оказался не панацеей: если нарушитель получает доступ к GitHub Actions-воркфлоу с правом публиковать пакет, OIDC-токен ему выдаёт сам npm. Атрибуция у исследователей — группа TeamPCP, уже засветившаяся на взломах LiteLLM и Trivy. Аккаунт TeamPCP в X на момент выхода материала заблокирован.

Выводы для npm-экосистемы и supply chain

Случай укладывается в серию ударов по цепочке доставки последних двух недель: Trivy и LiteLLM на PyPI, Axios и PyPI, теперь Checkmarx и Bitwarden. Характерная деталь — защитный слой не спасает: trusted publishing, OIDC и короткоживущие токены не помогают, если злоумышленник уже получил доступ к CI-воркфлоу. Практический вывод: pin-версии в лок-файлах, отдельный CI-аккаунт с минимальными правами, еженедельная ревизия CI-секретов и мониторинг собственного GitHub на появление незнакомых публичных репозиториев. Инвентаризация секретов, которые ходят через CI/CD, перестала быть теоретическим упражнением.

Инцидент формально небольшой — Vercel пишет про «ограниченный subset» клиентов, — но показательный. Злоумышленники всё чаще заходят в большие платформы не через уязвимости в коде, а через сторонние ИИ-интеграции, которым разработчики дают «Allow all» на Google Workspace (то есть соглашаются на все запрошенные OAuth-scopes — чтение почты, диска, календаря). Для российских разработчиков ситуация актуальна в двух сценариях: деплоите ли вы что-то на Vercel напрямую или работаете на зарубежного заказчика, у которого есть Vercel-проекты. Логика рекомендаций — «sensitive env vars + аккуратные OAuth-scopes + 2FA» — применима и к Netlify, Cloudflare Pages и любому другому хостингу с dashboard-ом.

Точка входа: OAuth-токен сотрудника Vercel в Context AI Office Suite. Сотрудник выдал приложению «Allow all» на Google Workspace.

Что утекло: переменные окружения на Vercel, которые не помечены как sensitive — API-ключи, токены, DB-credentials, ключи подписи.

Что защищено: env vars с флагом sensitive, npm-пакеты Vercel (проверено совместно с GitHub, Microsoft, npm и Socket), enterprise-клиенты Context.ai на Context Bedrock — это собственная on-premise enterprise-платформа Context.ai, не AWS Bedrock.

Сколько затронуто: по данным Vercel, «ограниченный subset» клиентов получил персональное уведомление. Если письма не было — вас, скорее всего, не коснулось.

Что делать: ротировать все не-sensitive env vars, включить 2FA, пометить секреты как sensitive, проверить activity log.

Что такое «sensitive» env vars на Vercel

В Vercel у каждой переменной окружения есть чекбокс «Sensitive». Если он включён, значение переменной хранится так, что его нельзя прочитать обратно — ни в UI, ни через API. Приложение получает значение в рантайме, но никакой интерфейс на стороне Vercel не может его показать даже самому владельцу проекта. Если чекбокс выключен — значение лежит в открытом виде в панели, и разработчик (а значит, и тот, кто получил его учётку) может его увидеть.

До инцидента новые переменные по умолчанию создавались без флага sensitive — значит, часть секретов в проектах была в открытом виде в панели, даже у аккуратных команд. Польза sensitive-флага простая: даже если атакующий украл учётку разработчика и вошёл в dashboard, прочитать значения этих переменных он уже не может — значения доступны только приложению в рантайме. После инцидента Vercel сделал sensitive-флаг включённым по умолчанию и улучшил team-wide управление переменными.

Как атакующий дошёл до env vars Vercel

Из двух официальных заявлений восстанавливается такая цепочка:

1. Июнь 2025. Context.ai запустил Context AI Office Suite — consumer-продукт для работы с ИИ-агентами (документы, слайды, таблицы). У Suite была функция «агенты действуют в вашем Google Workspace»: писать письма, создавать документы.
2. До апреля 2026. Сотрудник Vercel подключил свой служебный Google Workspace-аккаунт к Context AI Office Suite и выдал OAuth-приложению «Allow all» — разрешил читать и модифицировать всё, что доступно в Workspace: почту, диск, календарь.
3. Март 2026. Context.ai независимо обнаружил несанкционированный доступ к своему AWS-окружению. Привлекли CrowdStrike для расследования, закрыли AWS и свернули потребительский продукт.
4. Апрель 2026. По данным от Vercel и внутреннего расследования Context.ai выяснил: во время инцидента были скомпрометированы OAuth-токены пользователей AI Office Suite. Один из них использовался атакующим для входа в Google Workspace сотрудника Vercel — через почту и привязанные магические ссылки атакующий добрался до панели управления Vercel.
5. 19 апреля 2026. Vercel опубликовал первое уведомление об инциденте, затем раскрыл IOC и источник атаки. Context.ai выпустил параллельное заявление.

Vercel оценивает атакующего как «высокопрофессионального» — исходя из скорости работы и детального понимания внутренних систем платформы. К расследованию привлечены Mandiant и правоохранительные органы.

Индикатор компрометации (IOC)

Vercel опубликовал ID OAuth-приложения, через которое проходила атака. Администраторам Google Workspace стоит проверить, не авторизован ли этот app у кого-то из сотрудников:

Проверить можно в консоли Google Admin: Security → API controls → Third-party app access. Если app найден — отозвать все его токены, связаться с сотрудниками, у которых он был подключён, и ротировать их секреты по тому же чеклисту, что и клиентам Vercel.

Что делать клиентам Vercel

Прямой чеклист из рекомендаций Vercel. Начинать сверху, даже если уведомления от Vercel не получали — «ограниченный subset» определяется по подтверждённым фактам, а расследование ещё идёт.

1. Ротировать все не-sensitive env vars — API-ключи, токены, строки подключения к БД, ключи подписи. Все значения, которые видны в интерфейсе Vercel в открытом виде, считайте потенциально утёкшими.
2. Пометить секреты как sensitive. Зайдите в Settings → Environment Variables, откройте каждый секрет, включите чекбокс Sensitive. С этого момента значение нельзя будет прочитать обратно.
3. Включить 2FA на всех аккаунтах команды. Authenticator-app или passkey — ссылки есть в официальном бюллетене Vercel.
4. Проверить activity log проекта и команды на подозрительные действия: неожиданные деплои, смена настроек, приглашения новых членов команды. Лог доступен в dashboard и через CLI.
5. Поставить Deployment Protection как минимум в режим Standard. Если использовали Deployment Protection tokens — ротировать их.
6. Удалить подозрительные деплои. Если в логе есть деплой, которого вы не помните, — удалить его, даже если не уверены.

Удалить проект или аккаунт недостаточно — по словам Vercel, скомпрометированные секреты остаются валидными, пока вы их не ротируете. Сначала ротация, потом чистка.

Чему учит этот инцидент

Это не первая supply-chain атака, но она показательна двумя вещами.

Первое: сторонний ИИ-инструмент с «Allow all» на Google Workspace — это, по сути, полный доступ к почте, диску и календарю компании. Любая его компрометация превращается в компрометацию всего, что висит на SSO вокруг Google Workspace. У Vercel это привело к тому, что одна галочка сотрудника открыла доступ к production env vars целой платформы.

Второе: «encrypted at rest» — это не защита от кражи credentials из рабочей среды. Env vars всегда должны быть декодированы для запуска приложения; поэтому бекенд Vercel умеет их читать, и атакующий, получивший доступ к интерфейсу команды, тоже мог. Флаг sensitive решает именно эту задачу — делает значение нечитаемым для самого интерфейса, не для рантайма.

Выводы

Когда один OAuth-токен может скомпрометировать dev-tools, CI-pipeline, секреты и деплой одновременно — это сигнал, что где-то в архитектуре доверия пошло не так.

Полный тред — на Hacker News: в обсуждении 858 баллов и почти 500 комментариев разбирают, как архитектура «одна OAuth-связка = доступ ко всему» стала нормой в SaaS.

После инцидента Vercel выкатил четыре продуктовых изменения, полезных и за пределами этой истории: sensitive-флаг включён по умолчанию для новых переменных, улучшено team-wide управление env vars, activity log стал информативнее и получил deep-linking по фильтрам, обновлены письма-приглашения в команду. Старые проекты это не починит автоматически — идти в Settings и помечать секреты sensitive вручную всё равно придётся.

Полный текст уведомлений — бюллетень Vercel и statement Context.ai. Обе страницы обновляются по мере расследования, стоит подписаться на уведомления или заглянуть через неделю.

Рассказываем, что показала компания, о чём говорили спикеры и куда движется индустрия.

Сначала цифры: как вырос Cloud.ru

На конфренции Cloud.ru впервые публично раскрыла детальную финансовую отчётность. Выручка за 2025 год — 76,5 млрд рублей (+50% год к году). Чистая прибыль — 14,7 млрд(+86%).

Основной драйвер роста — инфраструктура для ИИ: обучение и инференс моделей дали 54% выручки. При этом классические облачные сервисы тоже выросли на 31%, что быстрее темпов роста рынка России.

По инфраструктуре Cloud.ru — один из крупнейших облачных провайдеров в стране. В парке находится 43 000+ единиц оборудования, 29 000+ серверов, 9 ЦОДов суммарной мощностью 56 МВт.

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

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

АФЛТ-Системс, например, уже в активной фазе перехода к регулярной эксплуатации AI. Павел Павленко, руководитель направления развития GenAI, говорит: «GoCloud для меня в этом году — про то, как индустрия перешла от разговоров про потенциал GenAI к разговору про реальные внедрения, метрики и архитектурные решения. Мы строим внутреннюю AI-платформу, выстраиваем процессы и запускаем первые продукты, в том числе AI-фикацию пайплайна разработки. На таком этапе ценность партнёра измеряется не презентациями, а скоростью реакции и готовностью идти в эксперимент».

Что происходит на рынке: от пилотов к промышленной эксплуатации

Последние 2–3 года компании делали пилоты по внедрению генеративного ИИ в основном благодаря визионерской силе лидеров, CEO, директоров. Пилоты часто были точечными и экспериментальными: автоматизировали поддержку и отвечали на частые простые вопросы, генерировали контент.

Сейчас модели стали лучше, а бизнес опытным путем выяснил, какие функции эффективнее передавать ИИ. Результаты пилотов всё чаще признаются успешными.

Например, Артём Бондарь, руководитель направления NLP в Центре искусственного интеллекта Т-Банка, выделяет три ключевых направления GenAI-инструментов. Первое — агенты и копайлоты в полном цикле разработки. Второе — инструменты для HQ-профессий: от генеративных моделей для общих задач до вертикальных решений вроде автоматической генерации креативов «почти без касания людей».

Но прямой финансовый эффект особенно заметен в автоматизации поддержки и операционки. Здесь задействован весь спектр GenAI-подходов:

• пошаговая автоматизация с помощью LLM там, где есть регламентированный процесс,
• агенты, которые ищут решение в сконструированной для них среде,
• и AI-сотрудник Афанасий Иванов (АИ), который работает в компании уже больше года и использует те же интерфейсы, что и люди.

Становится ясно, что перелом скоро наступит. И это точно не год.

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

DevOps-практики тоже перешли в практическую плоскость. В МТТЕХ выстроили модель GitOps, где Git — единый источник истины, а все изменения проходят через ревью и автоматизированный деплой. IaC-подход (Terraform, Ansible) и self-hosted GitLab в облаке позволяют управлять инфраструктурой как кодом.

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

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

Neocloud: GPU как отдельное направление

На этом фоне Cloud.ru выделил AI-инфраструктуру в отдельное бизнес-направление — Neocloud. Это единая управляемая среда для полного цикла работы с моделями: от разработки и обучения до инференса и эксплуатации.

Нагрузки под ИИ сильно отличаются от классических. Для них нужны высокоскоростные соединения между GPU, умный шедулинг (днём — инференс, ночью — дообучение), возможность получить кластер из сотен HGX, а потом отпустить. Но на рынке такого предложения нет. Neocloud как раз решает управление вычислительными ресурсами на масштабе.

В Neocloud есть:

• Доступ к тысячам современных GPU в публичном облаке.
• Поддержка гибридных сценариев (своя инфраструктура + облако).
• Собственная платформа Distributed Train для распределённого обучения с проактивным мониторингом, автоматической заменой отказавших узлов и гибким управлением очередями.

Чем Neocloud выгодно разработчикам

Решения такого уровня остаются доступными и для пользователей. Арендовать HGX теперь не проблема, они доступны буквально по цене обеда.

Выгодная стоимость для Cloud.ru остается приоритетом. Компания заявляет, что не планирует повышать цены в этом году.

Это не единственный аргумент в пользу облака. Как отмечает Артём Сычев, первый заместитель генерального директора РТ-Информационная безопасность, для госсектора и крупных компаний есть ещё одно важное преимущество: «С облаком удобнее проходить закупочные процедуры. Ты сделал рамочный договор, и в любой момент, когда у тебя появился новый госзаказчик, быстро развернул инфраструктуру».

Агенты: EvoClaw, Agent Space и новый способ общения с облаком

Другой инструмент, о котором рассказали на конференции, — EvoClaw. Это управляемый облачный сервис для работы с OpenClaw и другими open source агентными фреймворками. ИИ-агент обеспечивает observability, мониторинг, логирование и поддерживает политики безопасности. Cloud.ru одним из первых в России приступил к открытому тестированию OpenClaw ещё в феврале 2026 года.

Ключевые особенности EvoClaw:

• Агент запускается в пару кликов.
• Политики безопасности приведены к Zero Trust, привилегии — по минимальному принципу.
• Агенты изолированы своим рабочим пространством.
• Интеграция с AI Factory (Foundation Models, AI Agents, Managed RAG).

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

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

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

Ещё одно решение Cloud.ru для работы с агентами — Agent Space — мобильное и десктоп-приложение, которое позволяет чатиться с агентом. Оно работает на протоколе A2A (Agent-to-Agent). А в каталоге представлены уже более 20 бизнес-сценариев, среди которых и «Агент Python-разработчик».

AI Workflows: low-code оркестратор

Бизнес-процесс редко состоит из одного действия. Обычно это цепочка: проверить данные в 1С, прогнать их через LLM, создать задачу в Jira, отправить уведомление в Telegram.

Для таких сценариев Cloud.ru запустил AI Workflows — low-code конструктор, который сейчас находится в публичном тестировании.

Пользователь собирает цепочку шагов в визуальном интерфейсе (как в n8n, но с ИИ-блоками). На каждом шаге можно подключить готовый коннектор к 1С, Jira, Confluence, PostgreSQL, почтовым клиентам, мессенджерам или внутренним сервисам через API. А между ними — вызовы LLM из Evolution Foundation Models, инференс-моделей или даже готовых агентов.

На старте AI Workflows ориентирован на готовые коннекторы и предсобранные кубики. Вставлять кастомные скрипты прямо в цепочку пока нельзя. Но в компании понимают, что разработчикам это нужно и планируют дать такую возможность, подчеркивает Анастасия Тафеенко, директор блока разработки платформы Cloud.ru Evolution.

На пресс-конференции прозвучала интересная мысль: AI Workflows — это тоже промежуточный этап. Через пару лет, когда компании привыкнут делегировать задачи ИИ, и этот уровень оркестрации станет не нужен, всё будет ИИ-фицировано насквозь.

Безопасность: Guardrails и Container Security

Агенты получают доступ к вашей инфраструктуре. Да, это удобно, но возникает закономерный вопрос: как не допустить, чтобы агент случайно (или специально) не отправил чувствительные данные во внешнюю LLM? Или не поднял контейнер с критической уязвимостью?

На GoCloud 2026 анонсировали два инструмента, которые закрывают эти риски — на уровне данных и на уровне инфраструктуры.

Guardrails Filter: чтобы секреты не утекли

Guardrails Filter — это фильтр между агентами и большой языковой моделью. Он сканирует исходящий запрос, находит потенциально чувствительные данные (ПДн, реквизиты, API-ключи, секреты), маскирует их и только потом отправляет в LLM. Когда модель возвращает ответ, фильтр восстанавливает реальные значения на месте.

Guardrails как раз обеспечивает фильтрацию при обращении к внешним моделям. Наши же модели не дообучаются, данные не используются, не имеют доступа в интернет. Это проверено пен-тестами,

Evolution Container Security: чтобы контейнеры не стали дырой

На уровне государства вводятся понятия «суверенного искусственного интеллекта», проходят публичные слушания по закону. Граница безопасности активно формируется. Cloud.ru отвечает на этот запрос и даёт широкую линейку сервисов безопасности, чтобы клиент мог выбрать нужный уровень под свой класс информационной системы.

По оценкам экспертов, порядка 80% запущенных кластеров Kubernetes содержат роли с избыточными привилегиями. И Evolution Container Security обеспечивает безопасность контейнерных сред Kubernetes. Сервис уже доступен в публичном тестировании.

Возможности Evolution Container Security:

• Сканирование контейнеров на уязвимости (включая БДУ ФСТЭК).
• Встроенный ИИ-агент для генерации политик безопасности.
• Создание и управление политиками через конфигуратор.
• Проверка конфигураций во время развёртывания.

Это классическая контейнерная безопасность — он проходит по настройкам кластера через фреймворк. Есть агент, который помогает настройщику сделать это правильно,

Что еще волнует безопасников

На круглом столе «Облако уже сегодня. Как получить конкурентное преимущество без компромиссов по безопасности» участники честно рассказали о своих страхах. Главный — потеря контроля. «Облако — это чёрный ящик, который необходимо контролировать, обвязывать своими сервисами, чтобы перепроверять подрядчика», — поделился Артём Сычев, первый заместитель генерального директора РТ-Информационная безопасность.

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

Облачные провайдеры, включая Cloud.ru, уже отвечают на эти запросы — едиными политиками безопасности, мониторингом и логированием как в публичном облаке, так и в гибридных средах.

Но есть и другой уровень безопасности — физический. Антон Фомин, CDO Navio, рассказывает, как GenAI помогает спасать жизни: «Как собрать данные о лобовом столкновении, не отправляя водителя на встречную машину? Мы это делаем с помощью нашего фотореалистичного стимулятора. Вот настоящая польза генеративного ИИ: заглянуть за горизонт и научить машины ездить без риска».

Гибридные облака: почему это сложно и как Cloud.ru стали одними из первых в этом поле

Гибридное облако — одна из тех тем, о которой много говорят, но мало кто делает хорошо. На конференции Cloud.ru представил исследование, которое показывает: интерес к гибридной модели растёт, но её часто воспринимают как нечто сложное и размытое.

Что такое гибрид на самом деле? Если отбросить маркетинговые формулировки, гибрид — это частное облако (on-prem) + публичное облако + связь между ними под единой платформой. Из единого личного кабинета можно управлять ресурсами и там, и там, переезжать виртуальными машинами из публичного облака в свой ЦОД и обратно.

Гибрид для меня — это возможность использования on-prem инфраструктуры, но с биллингом, управлением ресурсами, логированием, личным кабинетом

Гибрид это всё ещё больно и дорого. Публичное облако можно обновлять постоянно — раз-два в день, а то и чаще. Если в сервисе появилась ошибка, её сразу исправляют. С гибридом так не получится. Релиз, который поедет к клиенту на on-prem инфраструктуру, нужно собирать, тестировать, сертифицировать. И каждый сервис внутри этого релиза должен работать без оглядки на внешние зависимости.

Плюс требования клиента: пройти ПСИ, подтвердить безопасность, соответствие регуляторным нормам. В публичном облаке за это отвечает провайдер. В гибриде — всё ложится на клиента и интегратора.

Почему индустрия всё равно придёт к гибриду

• Безопасникам проще контролировать конфигурации и видеть всю инфраструктуру.
• Финансистам — смотреть утилизацию оборудования.
• CTO — видеть все виртуальные машины.
• В on-prem сложно инвентаризировать legacy-системы. Гибрид даёт прозрачность.

Cloud.ru начал строить гибридную платформу ещё на ранней стадии публичного облака. В прошлом году анонсировали Evolution Stack — платформу для создания частных и гибридных облаков. Клиенты уже могут получить единые политики безопасности, мониторинг и логирование для on-prem и публичного облака. Единой консоли управления «из облака» (модель Outpost, как у западных гиперскейлеров) пока нет. Но пилоты с единым центром управления готовы запускать уже сейчас.

В России почти нет провайдеров, которые могут предложить гибридное облако как отчуждаемый продукт, который можно установить у себя в ЦОДе. Cloud.ru сделал это за счёт того, что публичное облако и гибридная платформа построены на единой кодовой базе. Сервисы идентичны, пользовательский опыт одинаковый. Разработка начинается в публичном облаке, а прод уезжает на on-prem — и это работает, потому что сервисы внутри одни и те же.

Что будет с разработкой: не паникуем, но не забываем готовиться

Агенты уже пишут код, тестируют, разворачивают инфраструктуру. DevOps-инженер отдаёт помощнику создание виртуальных машин и настройку баз данных. SRE-агент сам поднимает метрики и ищет первопричины инцидентов. Вопрос, который возникает у каждого разработчика: «Меня заменят?»

В ближайшем будущем роли не отомрут, но изменятся. «Разработчику нужно поднимать уровень, становиться тимлидом — а его тиммейтами будут агенты», считает Анастасия Тафеенко, директор блока разработки платформы Cloud.ru Evolution.

Чем больше у разработчика экспертизы, чем лучше он понимает, как на самом деле устроен продукт, что такое репозитории, из каких блоков он состоит, — тем эффективнее он будет с агентами работать,

Новый челлендж — экономика решений. Можно написать агенту одну строчку, а потом 10 тысяч раз переделывать, уточнять, перезапускать. Каждый шаг — это токены. А токены — это деньги. Борьба будет не за то, кто быстрее написал код, а за то, сколько стоило решить задачу.

Новая роль — оркестратор агентов. На круглом столе «DevOps инструменты в облаке» представители МТТЕХ, Familia, Ventra и «Технологии – и точка» сформулировали главный тренд: «Мы движемся к модели, где человек становится оркестратором агентов. Он их направляет, пишет принципы, управляет — как оргструктурой».

Количество агентов будет расти драматически — от десятков до тысяч. И тот, кто научится управлять этой «армией», останется востребованным.

Агенты не приходят на пустое место. Основной барьер для внедрения ИИ-агентов не технологический, а организационный. Если в компании данные разрознены, процессы не формализованы, а культура не готова делегировать решения машине — никакой агент не поможет. И наоборот: в компаниях, где данные структурированы и процессы прозрачны, агенты достигают 60–90% автоматизации.

CVE-2026-39987 (CVSS 9.3) — критическая pre-auth RCE (удалённое выполнение кода до авторизации) в популярном реактивном Python-ноутбуке. По данным Sysdig, первая эксплуатация в дикой природе зафиксирована через 9 часов 41 минуту после публикации advisory — без публичного PoC. Кража учётных данных из honeypot заняла меньше трёх минут.

• Marimo до версии 0.20.4 включительно уязвим к CVE-2026-39987 — pre-auth RCE с CVSS 9.3. Патч: обновиться до 0.23.0.
• Корень проблемы — WebSocket-эндпоинт /terminal/ws пропускал вызов validate_auth(), который у соседнего /ws есть. Одного WebSocket-хендшейка достаточно для полного PTY-шелла.
• Attackers поймали тайминг: 9 ч 41 мин от раскрытия до реальной атаки, эксплойт собран по описанию advisory, без готового PoC.
• В Docker-сборках Marimo по умолчанию работает от root, а в .env лежат ключи OpenAI, Anthropic, Google Gemini, cloud-credentials — типичная цель атаки.
• Это третий RCE подряд в AI-тулчейне за несколько месяцев: Langflow CVE-2026-33017 (эксплойт через 20 ч), Flowise CVE-2025-59528. Паттерн устойчив.

В чём уязвимость

WebSocket — протокол постоянного двустороннего соединения между браузером и сервером; одно соединение висит долго и гоняет по нему сообщения. Сервер Marimo держит несколько таких эндпоинтов: /ws — для обмена состоянием ячеек и UI, /terminal/ws — для встроенного терминала внутри интерфейса ноутбука. Первый корректно вызывает validate_auth() (проверка сессионного токена пользователя) перед принятием соединения. Второй — нет.

Вместо аутентификации /terminal/ws проверял только две вещи: включён ли терминальный режим и поддерживает ли платформа PTY (псевдотерминал — эмуляция tty-интерфейса, через который обычно общаются командные оболочки). В сетевом деплое обе проверки почти всегда истинны. Итог — любой сетевой соседний или интернет-доступный атакующий открывает WebSocket, получает PTY-шелл с правами процесса Marimo. В дефолтном Docker-образе это root.

Endor Labs охарактеризовали баг как «root в один запрос»: один WebSocket-хендшейк — и атакующий внутри. Уязвимость зарегистрирована как GHSA-2679-6MX9-H9XC, CWE-306 (Missing Authentication for Critical Function). Исправлена в PR #9098.

Как выглядела эксплуатация

Advisory для CVE-2026-39987 опубликовали 8 апреля 2026 года. Sysdig разворачивает honeypot-инфраструктуру с уязвимыми Marimo-инстансами в нескольких облаках — первое срабатывание пришло через 9 часов 41 минуту, без публичного PoC. Описание advisory было достаточно точным, чтобы собрать рабочий эксплойт прямо по нему.

Дальше атакующий действовал методично. Подключился к /terminal/ws, прошёлся по файловой системе, прочитал .env, поискал SSH-ключи и конфиги. Полный цикл от коннекта до эксфильтрации учётных данных — меньше трёх минут. Через час атакующий вернулся проверить, не пришли ли другие.

Ни майнеров, ни бэкдоров не поставили. Sysdig интерпретирует это как работу живого оператора, который идёт по списку целей и возвращается за результатом, — а не как массовый автоматизированный скан.

Marimo не один: RCE в AI-тулчейне становится паттерном

Marimo используют инженерные команды Stanford, Mozilla AI, OpenAI и BlackRock. У проекта около 20 000 звёзд на GitHub, типичные деплои — Docker, Hugging Face Spaces, SkyPilot, CoreWeave. В этих окружениях под рукой обычно всё, что атакующий и ищет: ключи OpenAI, Anthropic и Google Gemini, cloud-credentials, SSH-ключи к training-серверам и бакетам с датасетами.

Компрометация Marimo-инстанса — это не просто shell на сервере. Это доступ к LLM-аккаунту с биллингом, к batch-инференсу на fine-tuned моделях, к облачному хранилищу с моделями и данными обучения. И это уже третий похожий инцидент за несколько месяцев: Langflow CVE-2026-33017 (эксплойт за 20 часов), Flowise CVE-2025-59528 (CVSS 10.0, активная эксплуатация спустя полгода после патча). Паттерн устойчивый: AI-тулчейн попадает в «серую зону» безопасности — воспринимается как dev-инструмент, а не production, и получает меньше мониторинга и сегментации сети.

Что делать прямо сейчас

1. Обновите Marimo до 0.23.0 или выше. Проверка: marimo --version. Для Docker — обновите базовый образ и pinned-зависимости.
2. Проверьте, был ли ваш инстанс доступен из сети после 8 апреля 2026 года. Если да — считайте учётные данные скомпрометированными и ротируйте их: ключи LLM-провайдеров (OpenAI, Anthropic, Google), cloud-credentials, SSH-ключи, токены пакетных менеджеров.
3. Проверьте биллинг и активность в админках LLM-провайдеров и облаков — есть ли запросы или инстансы, которых вы не запускали.
4. Не выставляйте Marimo в интернет напрямую. Минимум — запуск на loopback: marimo edit --host 127.0.0.1. Публичный деплой — только за реверс-прокси с авторизацией (nginx basic-auth / auth_request, Caddy + OAuth2-Proxy), в VPN или в private subnet.
5. Разверните Marimo от непривилегированного пользователя, не от root. Стандартный Docker-образ работает как root — поправьте в своей сборке через USER в Dockerfile.
6. Подпишитесь на GitHub Security Advisories для репозиториев AI-тулчейна: на странице репо в GitHub — Watch → Custom → Security alerts. Или добавьте в rss-агрегатор фид github.com/owner/repo/security/advisories.atom. Для кросс-платформенного мониторинга — osv.dev и CISA KEV.

Индикаторы компрометации

Искать в логах веб-сервера или прокси перед Marimo:

Marimo сам логи WebSocket-соединений не пишет. Если Marimo стоит за reverse-proxy — смотрите access-логи прокси: nginx в /var/log/nginx/access.log, Caddy и Traefik — в stdout контейнера. Без прокси проверить ретроспективно по логам не выйдет — остаётся только ротация секретов по принципу «предположи компрометацию».

Проверить файлы, к которым типично обращается атакующий после получения шелла:

Выводы

CVE-2026-39987 — ещё один пример того, как удобная «фича для разработчика» превращается в точку входа для атакующего, если её не прогнали через ту же модель угроз, что и основной API. Встроенный терминал выглядел как локальный инструмент — на деле обслуживал тот же сетевой стек, что и весь остальной интерфейс.

Предположение, что атакующие охотятся только за массово развёрнутыми платформами, — неверно. Любое интернет-доступное приложение с критическим advisory — цель, независимо от популярности.

Практический вывод для команд, использующих AI-тулчейн: отнеситесь к Marimo, Langflow, Flowise и прочим notebook-платформам как к production-сервисам, а не как к dev-утилитам. Это значит patch management, сегментация сети, least privilege в контейнерах и мониторинг исходящего трафика. Десять часов от advisory до эксплойта — время реакции, на которое стоит рассчитывать.

Минимальная проверка за 30 секунд для любого notebook- или AI-сервиса в вашей инфраструктуре: запустите ss -tlnp | grep LISTEN на хосте и найдите порты, на которых сидит Jupyter, Marimo, Flowise, Langflow, Streamlit, Gradio. Если порт слушает на 0.0.0.0, а не на 127.0.0.1 — разберитесь, зачем и как он защищён. Если не знаете зачем — переведите на loopback или за прокси с авторизацией.

Источники: The Hacker News, Cloud Security Alliance, SecurityWeek.

Исследователи Aikido Security обнаружили в реестре Open VSX расширение code-wakatime-activity-tracker — почти полный клон легитимного WakaTime. Отличие одно: в функции activate() расширение подгружает нативный бинарник на Zig, который сканирует систему и устанавливает второй дроппер в каждый редактор на базе VS Code.

• Кампания GlassWorm добавила новую стадию — нативный бинарник на Zig (win.node и mac.node), который запускается вне JavaScript-песочницы Node.js.
• Заражаются все VS Code-совместимые редакторы на машине: VS Code, VS Code Insiders, Cursor, Windsurf, VSCodium, Positron.
• Второй этап — фейк популярного расширения steoates.autoimport (5+ миллионов установок) под именем floktokbok.autoimport.
• Вредонос пропускает машины с русской локалью и использует Solana-блокчейн как C2-инфраструктуру.
• Если у вас стояли расширения specstudio.code-wakatime-activity-tracker или floktokbok.autoimport — считайте машину скомпрометированной и ротируйте секреты.

Как устроена атака

Клон WakaTime с одной изменённой функцией

Расширение code-wakatime-activity-tracker на Open VSX визуально повторяет оригинальный WakaTime: те же команды, те же запросы API-ключа, та же иконка в статус-баре. Разница только в одной функции — activate(), которая запускается при первом открытии расширения:

До какой-либо логики WakaTime расширение подгружает нативный бинарник из вложенной папки ./bin/ и сразу вызывает install(). На Windows это win.node — PE32+ DLL, на macOS — mac.node, универсальный Mach-O для x86_64 и arm64.

Полный обход песочницы

Оба бинарника — Node.js native addons: скомпилированные shared-библиотеки, которые Node подгружает через require() как обычные пакеты. Они загружаются прямо в рантайм Node и выполняются за пределами JavaScript-песочницы, с правами уровня операционной системы. Оба написаны на Zig. В macOS-бинарнике остались debug-символы — из них исследователи вытащили путь к проекту автора:

Сканирование всех VS Code-совместимых редакторов

Дальше бинарник ищет на машине каждый редактор, который понимает формат расширений VS Code. Проверяются стандартные пути установки — как в %LOCALAPPDATA%, так и в %ProgramFiles%:

На macOS аналогично обходятся /Applications/*.app для VS Code, Cursor, Windsurf, VSCodium и Positron. Если разработчик использует Cursor как основной редактор, но рядом стоит VS Code — оба окажутся скомпрометированы.

Подмена autoimport — расширения с 5 млн установок

Собрав список редакторов, бинарник скачивает вредоносный .vsix с GitHub Releases-страницы, подконтрольной атакующим. Пакет называется floktokbok.autoimport и подделывается под steoates.autoimport — популярное расширение с более 5 миллионов установок. Скачанный файл сохраняется во временный путь, а затем «тихо» ставится в каждый найденный IDE через его CLI-установщик:

После установки функция cleanupVsix удаляет скачанный файл, чтобы скрыть следы.

Что делает вторая ступень

Установленный autoimport — это тот же дроппер GlassWorm, который Aikido уже анализировали раньше. Он проверяет локаль системы и пропускает машины с русскими настройками, затем обращается к C2-серверу через Solana-блокчейн. Адрес C2 не зашит в бинарник — дроппер каждый раз читает его из блокчейн-транзакций подконтрольного кошелька, поэтому для блокировки недостаточно добавить один домен в deny-list, а закрыть весь Solana нереально.

Дальше дроппер выкачивает секреты с машины, ставит persistent-RAT и доставляет вредоносное расширение для Google Chrome — infostealer, который перехватывает сессионные cookies и нажатия клавиш.

Контекст: год эволюции GlassWorm

Aikido отслеживают GlassWorm больше года: кампания засветилась в марте 2025 с npm-пакетами, прятавшими payload в невидимых Unicode-символах, а с тех пор успела скомпрометировать сотни проектов на GitHub, npm и в VS Code Marketplace. Ключевое отличие нового этапа — переход к нативному коду на Zig: раньше нагрузка выполнялась в JS-рантайме расширения и её было видно в Developer Tools, теперь она уходит на уровень ОС, где статический анализ JavaScript-кода её уже не поймает.

Что делать прямо сейчас

1. Проверьте в каждом VS Code-совместимом редакторе список установленных расширений. Искомые имена: specstudio.code-wakatime-activity-tracker и floktokbok.autoimport.
2. Если нашли — считайте машину скомпрометированной. Удалите расширения, но этого недостаточно.
3. Ротируйте все секреты, к которым у машины был доступ: SSH-ключи, npm/pypi-токены, cloud-CLI, GitHub PAT, облачные credentials в ~/.aws, ~/.config.
4. Проверьте Chrome и Chromium-браузеры на неизвестные расширения и удалите их.
5. Пересмотрите cookies и активные сессии во всех браузерах, разлогиньтесь везде.
6. Для профилактики — перед установкой проверяйте издателя и число установок (autoimport, WakaTime и другие популярные расширения имеют миллионы установок и проверенного автора). Если в команде используется корпоративный endpoint protection — добавьте в его охват папки расширений IDE: это ловит malware в нативных аддонах, которые расширения тянут с собой.

Индикаторы компрометации (IoC)

Вредоносные расширения:

Хеши бинарников SHA-256:

Хеши действительны на момент анализа Aikido. Атакующие могут пересобрать бинарник — в этом случае хеши изменятся, но имена расширений и пути установки остаются корректными индикаторами.

Сетевые индикаторы:

Строки в бинарнике:

Выводы

Главный сдвиг в этом релизе GlassWorm — не сама подделка WakaTime, а то, что группа научилась перекладывать payload на нативный слой. Для защитников это означает две вещи: во-первых, статического анализа JS теперь мало — нужен контроль за любыми нативными аддонами, которые расширения тянут с собой; во-вторых, атакующим доступна не одна экосистема, а весь зонтик VS Code-совместимых редакторов сразу.

Расширение [...] кладёт рядом с JavaScript-кодом скомпилированный на Zig нативный бинарник. Это не первый раз, когда GlassWorm прибегает к нативному коду в расширениях. Но теперь бинарник работает не как payload напрямую, а как скрытый слой, который незаметно заражает все остальные IDE на машине.

Если вы разработчик — самый быстрый прикладной вывод: пройдитесь по списку расширений во всех установленных редакторах прямо сейчас, особенно если недавно ставили что-то через Open VSX. И пересмотрите, чьим расширениям вы в принципе доверяете по умолчанию.

Источники: Aikido Security, The Hacker News.

Flatpak — система для установки и запуска десктопных Linux-приложений в изолированной песочнице (sandbox). Используется в Fedora, Ubuntu, Linux Mint и большинстве современных дистрибутивов как безопасная альтернатива прямой установке пакетов.

• CVE-2026-34078 (Critical) — любое Flatpak-приложение может полностью выйти из песочницы
• Механизм: portal принимает символические ссылки, контролируемые приложением, и монтирует произвольные пути хоста в sandbox
• Затронуты все версии до 1.16.4 — обновитесь немедленно
• Дополнительно исправлены ещё 3 уязвимости: удаление файлов хоста, чтение файлов и отмена операций других пользователей
• Обнаружено Codean Labs

Как работает уязвимость

Flatpak Portal (сервис, через который приложения запрашивают доступ к ресурсам хоста) принимает пути из опции sandbox-expose. Эти пути могут быть символическими ссылками, контролируемыми самим приложением.

Flatpak разрешает символическую ссылку на хосте и монтирует целевой путь внутрь песочницы. Приложение может создать symlink на / (корень файловой системы) — и получить полный доступ ко всем файлам хоста. Далее это можно использовать для выполнения произвольного кода.

Все уязвимости от 7 апреля

• CVE-2026-34078 (Critical) — полный побег из песочницы через символические ссылки в sandbox-expose
• CVE-2026-34079 (Moderate) — удаление произвольных файлов на хост-системе
• GHSA-2fxp-43j9-pwvc (Low) — чтение файлов в контексте system-helper
• GHSA-89xm-3m96-w3jg (Low) — отмена операции pull другого пользователя

Что делать

Обновить Flatpak до версии 1.16.4 или выше:

Если обновление невозможно — временное смягчение через отключение Flatpak Portal:

Внимание: отключение Portal может привести к некорректной работе некоторых Flatpak-приложений, но закроет вектор атаки.

Подробности и полный анализ: GitHub Advisory.

Это не рядовое обновление безопасности: OpenSSH 10.3 меняет поведение сертификатов, ужесточает валидацию и предупреждает о необходимости перехода на постквантовые алгоритмы обмена ключами.

• OpenSSH 10.3 (релиз 2 апреля 2026) — исправление shell injection в ssh через %-tokens в ssh_config
• Изменено поведение сертификатов: пустая секция principals больше не работает как wildcard
• scp в legacy-режиме больше не сохраняет setuid/setgid при скачивании файлов от root
• Исправлена ошибка в PubkeyAcceptedAlgorithms: ECDSA-алгоритмы больше не взаимозаменяемы
• Начало постквантовой миграции: предупреждения о не-PQC алгоритмах обмена ключами

Исправления безопасности

Shell injection через имена пользователей

Самый серьёзный фикс: валидация метасимволов оболочки в именах пользователей, переданных через командную строку, выполнялась слишком поздно. В определённых конфигурациях — например, при использовании %u в блоке Match exec — атакующий мог выполнить произвольные shell-команды.

Обнаружил: Florian Kohnhäuser. Разработчики OpenSSH напоминают: не стоит напрямую передавать пользовательский ввод в командную строку ssh.

Ошибка в principals сертификатов

До 10.3 сертификат с пустой секцией principals работал как wildcard — позволял аутентификацию от имени любого пользователя, доверяющего CA через authorized_keys. Если CA случайно выпускал такой сертификат — вместо бесполезности он давал максимальный доступ.

Теперь: пустая секция principals не совпадает ни с одним principal. Также исправлена обработка wildcard-символов в principals сертификатов.

setuid/setgid в scp

При скачивании файлов через scp -O (legacy mode) от root без флага -p — setuid/setgid биты не очищались. Баг существовал с оригинальной программы rcp из Berkeley.

ECDSA: алгоритмы больше не взаимозаменяемы

Если в PubkeyAcceptedAlgorithms указан один ECDSA-алгоритм (например, ecdsa-sha2-nistp384), другие ECDSA-алгоритмы тоже принимались. Теперь каждый алгоритм проверяется строго по списку.

Потенциально несовместимые изменения

• Rekeying обязателен. Убрана совместимость с реализациями SSH, которые не поддерживают rekeying. Такие соединения теперь будут разрываться при необходимости обновить ключи сессии
• ProxyJump валидирует имена. Параметры -J и ProxyJump из командной строки теперь проверяют имена пользователей и хостов на метасимволы. Это предотвращает shell injection при прямом пробросе пользовательского ввода

Постквантовая миграция

OpenSSH 10.3 начинает предупреждать о соединениях, использующих не-постквантовые алгоритмы обмена ключами. Это не блокировка — пока только предупреждение в логах — но сигнал индустрии: миграция на PQC-алгоритмы должна начаться уже сейчас.

Контекст: Cloudflare нацелился на полную постквантовую безопасность к 2029 году. Filippo Valsorda, ведущий криптограф Go, считает, что риск появления криптографически значимых квантовых компьютеров в ближайшие годы достаточно высок, чтобы действовать.

Проверить, какие алгоритмы используют ваши соединения:

Как обновиться

Выводы

OpenSSH 10.3 — важный релиз: не только закрывает реальные уязвимости (shell injection, ошибки сертификатов), но и начинает подготовку экосистемы к постквантовому будущему. Обновитесь и проверьте, какие алгоритмы используют ваши SSH-соединения.

Supply chain атаки на пакетные менеджеры стали системной угрозой. Axios с 100 млн загрузок в неделю оказался заражён RAT-трояном через захваченный аккаунт мейнтейнера. Google атрибутировал атаку северокорейской группировке UNC1069. Параллельно обнаружены атаки на PyPI-пакеты LiteLLM и Trivy.

• Axios (npm, 100M+ загрузок/неделю) — RAT-троян через захваченный аккаунт мейнтейнера. Атрибуция: Северная Корея (UNC1069)
• PyPI-пакеты LiteLLM и Trivy — поддельные версии с вредоносным кодом через тайпсквоттинг
• Все атаки — через скомпрометированные учётные записи, а не уязвимости в коде
• OIDC Trusted Publishers снижает риск захвата аккаунта мейнтейнера — классические npm-токены уязвимы

Axios: RAT-троян в самом популярном HTTP-клиенте

30 марта 2026 года компания StepSecurity обнаружила две вредоносные версии axios — 1.14.1 и 0.30.4. Атакующий захватил npm-аккаунт ведущего мейнтейнера jasonsaayman, сменив email на подконтрольный адрес на ProtonMail.

В самом коде axios не было ни одной вредоносной строки. Вместо этого обе версии добавляли зависимость plain-crypto-js@4.2.1 — пакет, замаскированный под легитимный crypto-js. Его единственная задача — выполнить postinstall-скрипт (дроппер SILKBELL), который разворачивает кроссплатформенный RAT-троян для macOS, Windows и Linux.

В течение двух секунд после npm install малварь уже связывалась с C2-сервером атакующего — ещё до того, как npm заканчивал резолвинг зависимостей. После выполнения дроппер удалял себя и подменял package.json чистой версией, чтобы скрыть следы.

Хронология атаки на axios: от заражения до удаления за 3 часа

1. 30 марта, 05:57 UTC — публикация «чистой» версии plain-crypto-js@4.2.0 для создания истории пакета
2. 30 марта, 23:59 UTC — публикация вредоносной plain-crypto-js@4.2.1 с postinstall-хуком
3. 31 марта, 00:21 UTC — публикация axios@1.14.1 через захваченный аккаунт
4. 31 марта, 01:00 UTC — публикация axios@0.30.4 (legacy-ветка) — 39 минут спустя
5. 31 марта, ~03:15 UTC — npm удаляет обе версии. axios@1.14.1 был доступен ~2 часа 53 минуты

Атрибуция: Северная Корея

Google Threat Intelligence Group (GTIG) атрибутировал атаку северокорейской группировке UNC1069. Бэкдор WAVESHAPER.V2 — эволюция ранее известного импланта, используемого для кражи криптовалюты.

Microsoft подтвердил атрибуцию и связал инцидент с группировкой Sapphire Sleet (ответвление BlueNoroff). CrowdStrike связал атаку со Stardust Chollima через переиспользование кода ZshBucket. Исследователь Giuseppe Massaro обнаружил, что macOS-вариант содержит пути сборки, связывающие его с кампаниями RustBucket и Hidden Risk (2023–2024).

PyPI: поддельные пакеты LiteLLM и Trivy

Параллельно с атакой на Axios в конце марта обнаружены поддельные PyPI-пакеты, маскирующиеся под популярные библиотеки LiteLLM (ИИ-прокси для работы с несколькими LLM) и Trivy (сканер уязвимостей от Aqua Security). Атаки используют тайпсквоттинг — похожие имена пакетов — и нацелены на разработчиков, которые ошибаются при вводе имени зависимости.

Как отметил Томислав Перичин из ReversingLabs, атаки уже распространяются на PyPI и NuGet. Цель — максимальный охват разработчиков через все основные пакетные менеджеры. Подробный разбор инцидентов с LiteLLM, Telnyx и Trivy — в нашем предыдущем материале.

Как защититься: чеклист для разработчика

1. Аудит зависимостей — проверьте дерево зависимостей на наличие скомпрометированных версий. Для axios: если установлена 1.14.1 или 0.30.4 — считайте систему скомпрометированной
2. Пиннинг версий — фиксируйте точные версии в package-lock.json / poetry.lock. Но помните: SHA pinning не защищает от захвата аккаунта мейнтейнера
3. Мониторинг postinstall-скриптов — используйте npm audit, а также инструменты вроде Socket.dev или StepSecurity Harden-Runner для контроля сетевой активности при установке
4. Блокировка C2-доменов — добавьте в блоклист: sfrclak[.]com, IP 142.11.206[.]73
5. Ротация секретов — если затронутые пакеты были установлены, ротируйте все ключи API, токены и пароли в проекте
6. OIDC для публикации — используйте Trusted Publishers (npm OIDC) вместо долгоживущих токенов. Атака на axios стала возможна потому, что мейнтейнер использовал классический npm-токен
7. Аудит PyPI-зависимостей — проверьте имена пакетов в requirements.txt / pyproject.toml на тайпсквоттинг. Используйте pip-audit для проверки известных уязвимостей

Что изменилось в supply chain атаках 2026 года

Три инцидента за одну неделю показывают сдвиг в тактике: атакующие больше не ищут уязвимости в коде — они захватывают аккаунты мейнтейнеров и публикуют вредоносные версии от их имени. Ждать исправлений от мейнтейнеров недостаточно — нужен контроль на уровне CI/CD: OIDC для публикации, мониторинг сетевой активности при установке, аудит postinstall-скриптов.

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

Общий сценарий таков: злоумышленники получают временный доступ к ноутбуку администратора кластера, который отошёл, чтобы ответить на звонок, и не заблокировал устройство. Их задача — выяснить, как получить и сохранить доступ к кластеру до возвращения администратора.

Первоначальный доступ

Первое, что, скорее всего, захочет сделать хакер, — получить root-шелл на одном из узлов кластера. Это отличная отправная точка, чтобы поискать другие учётки или подложить свои бинарники. В Kubernetes это делается элементарно, потому что есть встроенная функция kubectl debug.

Типичная команда выглядит следующим образом (только подставьте имя из вашего кластера):

Важный момент здесь — флаг --profile, поскольку он определяет уровень доступа к узлу. Профиль sysadmin обеспечивает наивысший уровень доступа, поэтому он наиболее полезен для злоумышленников.

Запуск исполняемых файлов

Получив доступ к оболочке узла, злоумышленник, скорее всего, попытается загрузить и запустить свои инструменты. Это может оказаться не так просто, поскольку многие дистрибутивы Kubernetes защищают ОС узла, монтируя файловые системы в режиме «только для чтения» или с флагом noexec. Но есть одна вещь, которую умеют выполнять узлы любого Kubernets-кластера, — запуск контейнеров! Так что если атакующий сможет загрузить на узел контейнер и запустить его на нём, то у него будет возможность выполнить любую программу.

Чтобы понять, как это сделать, давайте рассмотрим некоторые малоизвестные фичи Kubernetes. В кластере все контейнеры запускаются средой исполнения контейнеров (container runtime), обычно это containerd или CRI-O. Находясь на узле, можно взаимодействовать с этими программами напрямую, в обход API Kubernetes.

В примере ниже я создаю новый неймспейс containerd с помощью утилиты ctr. Это полезно, потому что (по моему опыту):

• ctr всегда идёт в комплекте с containerd, не нужно качать никаких сторонних клиентов;
• контейнер в отдельном неймспейсе сложнее заметить тому, кто мониторит хост.

Важно: неймспейсы containerd — это не то же самое, что неймспейсы Kubernetes или Linux.

Назовём его sys_net_mon — это не так бросается в глаза, как что-нибудь вроде «здесь-были-хакеры». Когда неймспейс готов, нужно скачать образ контейнера:

Самое интересное, что внутри этого образа нет ничего, связанного с systemd или мониторингом сети. С точки зрения безопасности важно помнить: Docker Hub не следит за содержимым неофициальных и непроверенных (unverified) образов. Кроме того, назвать свой образ можно как угодно.

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

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

Статические манифесты

Ещё один способ, которым можно запустить контейнер на узле, — это статические манифесты. На большинстве хостов у kubelet'а есть специальная директория, из которой он автоматически подгружает статические манифесты. Поды, которые описываются такими манифестами, запускаются вообще без участия API-сервера. И тут у атакующих есть классный трюк: прописать свой статический под в несуществующем неймспейсе. Тогда он не зарегистрируется на API-сервере и не будет показываться в kubectl get pods -A или других подобных командах. Подробнее о статических подах и их особенностях в плане безопасности можно почитать в блоге Иэна Смарта.

Удалённый доступ

Следующая проблема для наших атакующих — сохранить удалённый доступ к системе после возвращения администратора. Существует множество программ для удалённого доступа, но большинство хакерских утилит легко обнаруживаются EDR/XDR-агентами, поэтому в качестве альтернативы можно использовать что-то вроде Tailscale.

У Tailscale есть несколько фич, очень полезных для атакующих (вдобавок к их обычному применению!). Первая — его можно запустить с помощью всего двух статически скомпилированных Go-бинарников, которые легко переименовать. Другими словами, можно выбрать, что будет отображаться в списке процессов на узле. В том же духе, что и с образом контейнера, воспользуемся бинарниками с именами systemd_net_mon_server и systemd_net_mon_client.

Запуск сервера:

Запуск клиента:

Что касается сети, если используется DERP-сеть Tailscale, трафик пойдёт через порт 443/TCP, а такой доступ обычно разрешен в большинстве окружений. К тому же можно использовать Tailscale'овский ACL (Access Control List, список контроля доступа), чтобы запретить «подсадному» контейнеру связываться с другими машинами в сети Tailnet злоумышленника.

Как только эти сервисы поднимутся, можно будет спокойно заходить обратно в контейнер по SSH. У Tailscale свой SSH-сервер в комплекте, так что никакой «левый» sshd не будет светиться в процессах :).

Учётные данные — API kubelet'а

После получения удалённого доступа злоумышленникам всё ещё необходимы «долгоиграющие» учётные данные. Кроме того, было бы неплохо иметь возможность «прощупывать» кластер в обход API Kubernetes, поскольку такие действия могут засветиться в журналах аудита. Для этого им нужен доступ к учётным данным пользователя, который может напрямую обращаться к API kubelet'а. Этот API работает на каждом узле на порту 10250/TCP и лишён встроенных опций аудита.

В своём докладе для этой цели я использую инструмент teisteanas, который через API запросов на подпись сертификатов (Certificiate Signing Request, CSR API) создает учётные данные в kubeconfig-формате. Так можно завести учётку для любого пользователя. Для скрытности злоумышленник, скорее всего, выберет существующего пользователя, которому уже назначены права в системе RBAC, чтобы избежать необходимости создавать новые роли кластера или привязывать роли. Конкретный выбор пользователя зависит от окружения. В своих демках я использую kube-apiserver — пользователя, существующего в кластерах GKE.

С kubeconfig-файлом и доступом к порту kubelet'а на хосте можно получать списки подов на узле или выполнять команды внутри этих подов. Проще всего это сделать с помощью утилиты kubeletctl. Таким образом, из нашего контейнера, работающего в сетевом неймспейсе узла, можно выполнить следующую команду:

CSR API

Стоит также пару слов сказать о CSR API — для атакующих это очень удобная лазейка. Этот API встроен практически во все дистрибутивы Kubernetes. Через него можно создавать учётные данные для доступа к кластеру (кроме EKS, там это не работает). Самое важное: этими учётными данными может воспользоваться любой, у кого есть доступ к API-серверу. А поскольку большинство облачных Kubernetes-решений по умолчанию «выставляет» API-сервер в интернет, атакующий с такими учётными данными сможет подключиться к кластеру откуда угодно.

CSR API также привлекателен для злоумышленников по ряду других причин:

• Если ведение журналов аудита не включено и не настроено должным образом, не остаётся никаких записей ни об использовании этого API, ни о создании учётных данных.
• Учётные данные, созданные через этот API, не могут быть отозваны без ротации корневого сертификата всего кластера, что чревато. Соответствующее Issue на GitHub, касающееся отзыва сертификатов, открыто всего лишь с 2015 года, так что в ближайшей перспективе вряд ли что изменится.
• Можно создавать учётные данные для системных аккаунтов. Поэтому даже при включённом аудите бывает сложно отличить вредоносную активность от легитимной.
• Учётные данные, как правило, долгоживущие. Конечно, срок их действия зависит от конкретного дистрибутива, но обычно он варьируется в диапазоне 1–5 лет.

В примерах для доклада я использую кластер GKE и с помощью CSR API создаю учётку для пользователя system:gke-common-webhooks, у которого довольно много прав.

Token Request API

Даже если CSR API недоступен, в Kubernetes есть и другой встроенный способ заводить новые учётки — Token Request API. Обычно он используется для создания токенов для сервисных аккаунтов, но администратор с нужными правами может адаптировать его для своих задач. Как и в случае с CSR API, никаких следов не остаётся (кроме логов аудита), и новые учётки сложно отозвать, особенно если использовался сервисный аккаунт системного уровня, ведь единственный способ — удалить сам аккаунт, к которому привязан токен.

Со сроком жизни токена тоже не всё так плохо для хакера. В зависимости от дистрибутива он может варьироваться от 24 часов до целого года (по крайней мере в тех managed-дистрибутивах, что я видел).

В докладе я использую утилиту tocan, чтобы упростить создание kubeconfig-файла из токена сервисного аккаунта.

Выбранный сервисный аккаунт очень интересен тем, что у него есть право escalate. Это означает, что он всегда может стать cluster-admin'ом, даже если у него изначально нет таких прав. (Я уже писал об escalate ранее.)

Обнаружение подобных атак

Пора поговорить о том, как обнаруживать и предотвращать такие атаки. Чтобы их выявить, стоит обратить внимание на несколько ключевых моментов:

• Журналы аудита Kubernetes — крайне важный аспект. Необходимо, чтобы журналирование было включено, логи были централизованы и хранились достаточно долго. Это позволит выявить некоторые из описанных техник, особенно злоупотребление CSR API и Token Request API.
• Агенты на узлах — агенты безопасности на узлах кластера помогут обнаружить активность вроде трафика Tailscale (в зависимости от их настроек).
• Журналы узлов — важно обеспечить надлежащую централизацию и хранение журналов с узлов, поскольку злоумышленники могут оставлять в них следы.
• Знай свою систему — звучит просто, но это не так. Если вы знаете, какие процессы в норме работают на ваших узлах, то сможете заметить аномалии вроде systemd_net_mon. Проблема в том, что у каждого дистрибутива свой набор системных сервисов, которые запускает облачный провайдер, так что разобраться в том, что есть норма, — задача непростая.

Как защититься

Пара советов администраторам, как снизить риски такого сценария:

• Изолируйте свои кластеры от интернета! Публичный доступ к API-серверу означает, что вы находитесь в шаге от серьёзных проблем в случае утери учётных данных. Как правило, managed-дистрибутивы Kubernetes позволяют ограничить доступ, но по умолчанию такое ограничение не настроено.
• Принцип наименьших привилегий — в рассмотренном сценарии скомпрометированный ноутбук имел права уровня cluster-admin, что позволило злоумышленникам легко перемещаться по кластеру. Если бы администратор использовал учётную запись с меньшими привилегиями, атака, скорее всего, провалилась бы. Хотя некоторые из использованных прав, такие как отладка узлов, довольно распространены, другие (вроде доступа к CSR API и Token Request API) вряд ли необходимы для повседневного администрирования и могут быть отключены.

Заключение

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

curl — одна из самых распространённых программных библиотек в мире. В форме libcurl она работает на десятках миллиардов устройств. При таком масштабе любая компрометация может иметь катастрофические последствия.

— Каждый коммит и каждый релиз open-source проекта — потенциальная точка атаки: от внедрённого контрибьютора до взломанного CI

— curl применяет более 20 мер верификации: от запрета бинарных блобов и Unicode в коде до обязательного фаззинга и torture-тестов

— Внешние пользователи могут и должны верифицировать релизы: проверять подписи, сравнивать содержимое архивов с git-репозиторием

— Это не паранойя — это инженерная дисциплина, которая позволяет проекту оставаться надёжным уже 30 лет

— Стенберг призывает требовать такого же уровня верификации от всех зависимостей в вашем стеке

Атаки на supply chain: 9 сценариев угроз

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

• Внедрённый контрибьютор — как в случае с Jia Tan и xz-utils: внешне добросовестный участник команды, который намеренно маскирует вредоносный код под обычные коммиты
• Скомпрометированный мейнтейнер — авторизованный разработчик, чья учётная запись или машина взломаны. Его коммиты и релизы теперь содержат заражённый код
• «Полезный» баг-фикс от незнакомца — маленький шаг в длинной цепочке крошечных изменений, которые постепенно формируют уязвимость или бэкдор
• Шантаж или давление — существующего участника проекта принуждают вносить изменения, которые иначе были бы отклонены
• Непреднамеренная ошибка — добросовестный разработчик при добавлении фичи или исправлении бага случайно создаёт уязвимость
• Подмена на уровне дистрибуции — сайт, с которого раздаются тарболлы (архивы с исходным кодом для релиза), взломан; вместо оригинальных архивов раздаётся малварь
• Компрометация учётных данных — от имени известного участника проекта распространяется дезинформация через email, соцсети, блоги или даже дипфейк-видео
• Атака через CI-инфраструктуру — инструмент, используемый в CI и размещённый в облаке, взломан и исполняет вредоносный код
• Поддельное зеркало — пока основной git-репозиторий недоступен, кто-то предлагает «временное зеркало» с заражённым кодом

Любой из этих сценариев может произойти в комбинации с другими и в быстрой последовательности.

Верификация релизов: как пользователи могут проверить curl

Люди спрашивают Стенберга, как он спит по ночам, учитывая масштаб curl и количество возможных атак.

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

Если хотя бы несколько независимых пользователей проверят, что релиз curl подписан мейнтейнером, а содержимое совпадает с тем, что есть в git-репозитории, — проект в хорошем состоянии. Достаточно нескольких независимых наблюдателей, чтобы любая аномалия была замечена.

Стенберг подчёркивает: он не знает, кто эти пользователи и существуют ли они вообще. Они должны быть полностью независимы от него и от проекта curl. Но проект предоставляет все инструменты и делает верификацию максимально простой.

Безопасность curl изнутри: более 20 мер верификации

Внешние наблюдатели могут подтвердить, что релизы соответствуют тому, что есть в git. Но обеспечить, чтобы в git попадал только безопасный и корректный код, — это внутренняя работа команды. Вот полный список мер:

Стандарты кода и ограничения

• Единый стиль кода — нарушение стиля вызывает ошибку сборки. Это снижает риск случайных ошибок и упрощает ревью
• Запрет «опасных» C-функций — функции, которые легко использовать неправильно, запрещены. Их использование вызывает ошибку
• Лимит на сложность функций — если функция слишком сложна, это ошибка сборки. Код должен быть читаемым и понятным
• Запрет бинарных блобов в git — никаких способов спрятать зашифрованный вредоносный код. Попытка добавить блоб вызывает ошибку
• Избегание base64-кодированных фрагментов — ещё один способ обфускации, который curl активно исключает
• Ограничение Unicode в коде и документации — большинство использований Unicode запрещено, чтобы предотвратить homoglyph-атаки (подмену символов визуально похожими из другой кодировки, например кириллической «а» вместо латинской «a»)
• Документирование всего — код, API, поведение — всё задокументировано, чтобы не было сюрпризов. Документация тестируется, проверяется спеллчекером и проходит ревью наравне с кодом

Тестирование и непрерывная интеграция

• Обязательное ревью каждого PR — и людьми, и ботами. Коммиты ссылаются на исходный PR
• Тысячи тестов — для каждой функции. Поиск «белых пятен» в покрытии — приоритетная задача
• Более 200 CI-джобов — запускаются для каждого коммита и каждого PR. Без объяснённых провалов тестов мёрж невозможен
• Максимально строгие опции компилятора — все предупреждения трактуются как ошибки через -Werror. Ни одно предупреждение не остаётся без внимания
• Valgrind и санитайзеры — все тесты прогоняются через valgrind и несколько комбинаций санитайзеров для обнаружения проблем с памятью и неопределённого поведения (undefined behavior)
• Torture-тесты — каждый тест перезапускается так, чтобы каждый вызов функции, способной завершиться ошибкой, упал ровно один раз. Это гарантирует: curl не утекает памятью и не падает при любых сбоях
• Непрерывный фаззинг — автоматическое тестирование случайными входными данными для поиска крашей и уязвимостей. Работает без остановки в рамках Google OSS-Fuzz и кратко в CI для каждого коммита

Защита CI-инфраструктуры от компрометации

• CI-джобы не пишут обратно в репозиторий — доступ только на чтение. Даже при компрометации CI код не может быть заражён
• Анализ конфигов CI — инструменты вроде zizmor проверяют скрипты CI на уязвимости
• Обязательная двухфакторная аутентификация — для всех коммиттеров на GitHub

Политика безопасности и стабильность API

• Уязвимости исправляются в следующем релизе — без исключений. Проблемы безопасности не висят после того, как о них сообщили
• Полная документация всех уязвимостей — каждая когда-либо найденная уязвимость curl задокументирована со всеми деталями
• Стабильность ABI и API — curl никогда не ломает обратную совместимость (ABI — бинарный интерфейс приложения, API — программный интерфейс). Это позволяет пользователям легко обновляться до версий с исправленными уязвимостями вместо того, чтобы сидеть на устаревших
• Независимые аудиты — код curl неоднократно проверяли внешние эксперты по безопасности. Все найденные проблемы были немедленно устранены

Всё это делается в открытую, с полной прозрачностью и отчётностью. Любой может наблюдать за процессом и проверять, что команда следует своим правилам.

Не паранойя, а инженерная дисциплина

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

Это не паранойя. Эта система позволяет нам спокойно спать по ночам. Именно поэтому пользователи до сих пор полагаются на curl спустя тридцать лет разработки.

Недавно Стенберг добавил на сайт curl отдельную страницу верификации, где подробно описано, как проверить целостность релизов.

Безопасность зависимостей: что проверить в вашем проекте

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

Проверка подписей и целостности пакетов

Большинство пакетных менеджеров умеют проверять подписи. Убедитесь, что эта проверка включена:

Аудит зависимостей в CI

Встройте проверку уязвимостей в ваш CI-пайплайн:

Базы уязвимостей OSV и NVD — основные источники данных для этих инструментов.

Оценка практик ваших зависимостей

Прежде чем добавить зависимость, проверьте:

• Есть ли у проекта обязательное ревью PR? Посмотрите историю мёржей
• Есть ли CI с тестами? Проверьте бейджи в README и конфиги в .github/workflows/
• Как быстро закрываются уязвимости? Проверьте security advisories на GitHub
• Сколько активных мейнтейнеров? Один человек — точка отказа
• Используется ли OpenSSF Scorecard — автоматическая оценка безопасности open-source проекта

Выводы: доверяйте коду, а не репутации

Опыт curl показывает: безопасность open source — это не вопрос доверия, а вопрос верификации. За 30 лет разработки проект выстроил систему из более чем 20 конкретных мер — от запрета бинарных блобов до непрерывного фаззинга — которые вместе создают многоуровневую защиту.

Если проект с десятками миллиардов установок может работать полностью открыто и предоставлять инструменты верификации для каждого, то и другие проекты обязаны стремиться к тому же стандарту. Начните с малого: npm audit signatures, pip-audit, проверка security advisories ваших зависимостей.

Не доверяйте — проверяйте.

Источник: Don't trust, verify — блог Даниэля Стенберга

Source map (карта исходников) — это отладочный артефакт, который включает оригинальный исходный код до компиляции. Бандлер Bun, который использует Claude Code, генерирует source map по умолчанию — и кто-то забыл исключить его из npm-пакета. Утечка произошла не из-за атаки, а из-за ошибки в конфигурации сборки.

— В npm-пакете Claude Code v2.1.88 оказался source map с полным исходным кодом

— ~1900 файлов, 512 000+ строк TypeScript — вся архитектура CLI-клиента

— Обнаружены нерелизованные фичи: виртуальный питомец BUDDY, фоновый агент KAIROS, облачное планирование ULTRAPLAN

— Раскрыт «режим инкогнито» для сотрудников Anthropic, коммитящих в open-source

— Утечка произошла из-за конфигурационной ошибки, не атаки. Anthropic удалил файл

Claude Code — CLI-инструмент Anthropic, позволяющий использовать Claude для написания кода, работы с файлами и выполнения команд в терминале. Инструмент распространяется через npm и имеет доступ к файловой системе и терминалу разработчика.

Как произошла утечка

Исследователь Chaofan Shou (сооснователь и CTO Fuzzland) обнаружил в npm-пакете файл cli.js.map. Source map содержал массив sourcesContent с полным исходным кодом каждого из ~1900 файлов проекта. Кроме того, в map-файле была ссылка на публичный Cloudflare R2-бакет с ZIP-архивом всех исходников (57 МБ).

Причина банальная: бандлер Bun генерирует source map по умолчанию. Чтобы исключить его из пакета, достаточно было добавить *.map в .npmignore или отключить генерацию в конфигурации. Этого не сделали.

Ирония: в кодовой базе есть система «Undercover Mode», которая скрывает следы использования Claude Code сотрудниками Anthropic в публичных репозиториях. При этом весь исходный код инструмента был опубликован в открытом виде в npm.

Что обнаружили в коде

Архитектура

• 1906 файлов TypeScript, рантайм на Bun
• Терминальный UI на React + Ink
• ~40 инструментов (tools), ~85 слеш-команд
• Мультиагентная оркестрация (координатор + параллельные воркеры)
• OAuth 2.0 аутентификация, JWT-мост к VS Code и JetBrains
• Динамическая сборка системного промпта из 40+ фрагментов

Нерелизованные фичи

В коде обнаружены фичи за compile-time флагами, не доступные пользователям:

• BUDDY — виртуальный питомец в стиле тамагочи, живущий в терминале. 18 видов существ с системой редкости (от Common 60% до Legendary 1%), 5 характеристик (Debugging, Patience, Chaos, Wisdom, Snark), шляпы и «блестящие» варианты. Claude генерирует имя и характер при первом «вылуплении»
• KAIROS — постоянно работающий фоновый агент. Ведёт ежедневный лог, получает регулярные «тики», может проактивно действовать. Имеет эксклюзивные инструменты: отправка файлов, push-уведомления, подписка на pull-реквесты
• ULTRAPLAN — режим облачного планирования. Выгружает сложные задачи в облачный контейнер с Opus 4.6 на срок до 30 минут. Результат возвращается в локальный терминал
• autoDream — фоновая консолидация памяти. Запускается как отдельный подагент с тремя условиями: 24 часа с последнего «сна», 5 сессий, блокировка. Четыре фазы: Orient → Gather → Consolidate → Prune

«Режим инкогнито» для сотрудников

Файл utils/undercover.ts содержит систему, которая активируется автоматически, когда сотрудник Anthropic использует Claude Code в публичном репозитории. Системный промпт в этом режиме прямо запрещает Claude упоминать внутренние кодовые имена моделей, названия проектов, Slack-каналы и сам факт того, что код пишет ИИ.

Из кода также следует, что внутренние кодовые имена моделей Anthropic — названия животных. «Tengu» (тэнгу) встречается сотни раз как префикс для фич и аналитических событий — по всей видимости, это внутреннее кодовое имя Claude Code.

Телеметрия

Код раскрывает систему телеметрии, которая, помимо стандартных метрик сессии, отслеживает:

• Частоту использования нецензурной лексики в обращениях к Claude (метрика «frustration»)
• Частоту набора слова «continue» (когда Claude обрывает ответ на середине)
• Данные маршрутизируются через Datadog. Код пользователя и пути к файлам не передаются — есть явные фильтры. Телеметрию можно отключить через переменные окружения

Контекст: вторая утечка за пять дней

Это вторая крупная случайная утечка Anthropic за неделю. 26 марта 2026 года ошибка конфигурации CMS раскрыла около 3000 неопубликованных файлов, включая черновик блогпоста о нерелизованной модели «Claude Mythos» (внутреннее кодовое имя «Capybara»). Обе утечки — результат конфигурационных ошибок, не взломов.

Реакция Anthropic

На момент публикации Anthropic не выпустил официального заявления. Компания молча обновила npm-пакет, удалив source map, и убрала из реестра ранние версии. Однако исходный код уже зеркалирован на GitHub — несколько репозиториев набрали более 1000 звёзд и сотни форков за первые часы.

Что это значит для пользователей

Чего НЕ утекло: веса моделей, обучающие данные, серверная инфраструктура, пользовательские репозитории или промпты. Утечка затрагивает исключительно CLI-клиент — код, который работает на стороне разработчика.

Что утекло: полная система разрешений (какие действия Claude Code может выполнять и при каких условиях), логика сборки системных промптов, OAuth-потоки и механизмы авторизации. Это упрощает поиск уязвимостей в инструменте, который имеет доступ к файловой системе и терминалу.

Выводы

Утечка исходного кода Claude Code — редкий случай, когда можно заглянуть внутрь коммерческого ИИ-инструмента. Технически это не уязвимость и не взлом, а конфигурационная ошибка — но масштаб раскрытой информации впечатляет: полная архитектура мультиагентной оркестрации, нерелизованные фичи и внутренние процессы компании.

Для Anthropic это урок о том, что инструменты, которым разработчики доверяют доступ к своему коду, должны проходить особенно тщательный аудит — включая процесс публикации npm-пакетов. Две утечки за пять дней — это системная проблема процессов, а не случайность.

Скомпрометированы версии axios@1.14.1 и axios@0.30.4 — обе ветки, актуальная и легаси. Вредоносный код устанавливает кроссплатформенный RAT, который работает на macOS, Windows и Linux. Пакеты были доступны в npm-реестре около 3 часов, прежде чем npm их удалил.

— Скомпрометированы axios@1.14.1 и axios@0.30.4 через взлом npm-аккаунта мейнтейнера

— Вредоносная зависимость plain-crypto-js устанавливает RAT-троянец на все ОС

— axios — самый популярный HTTP-клиент в JS-экосистеме: более 100 млн загрузок в неделю

— Безопасные версии: 1.14.0 (для 1.x) и 0.30.3 (для 0.x)

— Все секреты на затронутых системах нужно ротировать немедленно

Axios — HTTP-клиент для Node.js и браузеров с более чем 100 миллионами загрузок в неделю. Атаки на цепочки поставок (supply chain attacks) — это компрометация инфраструктуры распространения ПО: вместо атаки на конечную цель злоумышленник внедряет вредоносный код в доверенный пакет, который жертва сама устанавливает.

Как произошла атака

Злоумышленники получили доступ к npm-аккаунту jasonsaayman — основного мейнтейнера axios. Email аккаунта был изменён с легитимного адреса на ifstap@proton.me. Предположительно, был украден долгоживущий классический npm access token.

Легитимные релизы axios публикуются через GitHub Actions с криптографической привязкой npm OIDC Trusted Publisher и содержат SLSA-провенанс (Supply chain Levels for Software Artifacts — стандарт подтверждения целостности сборки). Вредоносные версии были опубликованы вручную через npm CLI — без привязки к GitHub, без SLSA-провенанса, без соответствующего тега в репозитории.

Атака была подготовлена заранее: за 18 часов до компрометации axios в npm был опубликован пакет-приманка plain-crypto-js — клон легитимного crypto-js с тем же описанием и именем автора. Сначала чистая версия 4.2.0, затем вредоносная 4.2.1 с постустановочным скриптом.

Хронология атаки

Все события — по UTC, 30–31 марта 2026 года:

• 30 марта, 05:57 — атакующий публикует чистый plain-crypto-js@4.2.0 для формирования истории публикаций
• 30 марта, 23:59 — выходит вредоносный plain-crypto-js@4.2.1 с постустановочным скриптом
• 31 марта, 00:05 — Socket детектирует вредоносный пакет — через 6 минут после публикации
• 31 марта, 00:21 — публикуется axios@1.14.1 со скомпрометированного аккаунта
• 31 марта, 01:00 — публикуется axios@0.30.4 — обе ветки поражены за 39 минут
• 31 марта, ~03:15 — npm удаляет обе вредоносные версии, dist-tag latest откатывается к 1.14.0
• 31 марта, 04:26 — npm публикует заглушку безопасности для plain-crypto-js — пакет заблокирован

Итого: axios@1.14.1 был доступен около 2 часов 53 минут, axios@0.30.4 — около 2 часов 15 минут.

Что делает вредоносный код

В исходном коде axios изменений нет — добавлена только зависимость plain-crypto-js@^4.2.1. Сам пакет никогда не импортируется в коде; он существует исключительно для запуска postinstall-хука при npm install.

Дроппер setup.js

Файл setup.js весит 4209 байт и использует двухслойную обфускацию: сначала reversed Base64-декодирование (с подстановкой символов), затем XOR-шифр с ключом OrDeR_7077. Дроппер определяет ОС и загружает платформенный payload с C2-сервера.

Payload по платформам

macOS: AppleScript-дроппер скачивает бинарный RAT с C2-сервера и сохраняет его как /Library/Caches/com.apple.act.mond — замаскирован под системный демон Apple. Запускается через /bin/zsh.

Windows: PowerShell копируется в %PROGRAMDATA%\wt.exe (маскировка под Windows Terminal). VBScript-дроппер запускает скрытый PowerShell-скрипт с обходом Execution Policy.

Linux: Python-скрипт RAT скачивается в /tmp/ld.py и запускается через nohup в фоновом режиме.

Возможности RAT

При первом запуске RAT отправляет на C2-сервер «отпечаток» системы: hostname, имя пользователя, версию ОС, архитектуру CPU, часовой пояс, время установки ОС и загрузки, список процессов, а также содержимое директорий /Applications, ~/Library и ~/Application Support. Затем RAT опрашивает C2 каждые 60 секунд. Поддерживаемые команды:

• runscript — выполнение произвольных shell-команд и Python-кода
• peinject — загрузка и запуск дополнительных бинарных payload
• rundir — перечисление содержимого директорий
• kill — самоуничтожение процесса

Антифорензика

После выполнения дроппер удаляет себя (setup.js) и подменяет package.json чистой версией без postinstall-секции. При инспекции node_modules после заражения следов вредоносного скрипта не остаётся.

Это означает, что проверка node_modules постфактум бесполезна. Единственный надёжный способ определить компрометацию — проверить package-lock.json на наличие вредоносных версий и IoC-пути на файловой системе (см. ниже).

Кто обнаружил

Атаку независимо обнаружили несколько компаний: Socket задетектировал вредоносный plain-crypto-js через 6 минут после публикации. StepSecurity подтвердил компрометацию через AI Package Analyst и инструментирование GitHub Actions-раннера. Детальный технический разбор также опубликовала SafeDep.

Индикаторы компрометации (IoC)

Файловая система:

Сеть:

SHA256 хеши:

Что делать прямо сейчас

Быстрая проверка — есть ли вредоносные версии в вашем lockfile:

Если команда ничего не вернула — ваш проект не затронут. Если нашлись совпадения:

1. Откатить axios: npm install axios@1.14.0 (для 1.x) или npm install axios@0.30.3 (для 0.x) — это автоматически удалит plain-crypto-js
2. Проверить IoC-пути на файловой системе для вашей ОС (см. выше)
3. Заблокировать C2 на сетевом уровне: sfrclak[.]com / 142.11.206.73
4. Ротировать все секреты на затронутых системах: npm-токены, SSH-ключи, API-ключи, переменные из .env
5. Проверить CI/CD-логи за 30–31 марта — ротировать все secrets из затронутых пайплайнов
6. Перейти на npm ci --ignore-scripts в CI/CD как постоянную политику

Если обнаружены артефакты RAT — считайте систему полностью скомпрометированной и пересоберите из заведомо чистого состояния.

Защита от транзитивных зависимостей

Если axios используется как транзитивная зависимость (его тянет другой пакет), прямой npm install axios@1.14.0 не поможет — нужно зафиксировать версию через overrides в package.json:

Поле overrides работает в npm 8+, resolutions — в Yarn.

Выводы

Инцидент с axios — один из самых масштабных supply chain атак в npm по потенциальному охвату: при 100 миллионах загрузок в неделю даже 3-часовое окно доступности вредоносных версий критично. Для сравнения: компрометация event-stream в 2018 году затронула пакет с 2 миллионами загрузок в неделю.

Скорость реакции экосистемы впечатляет: Socket обнаружил вредоносный plain-crypto-js через 6 минут, npm отозвал пакеты менее чем за 3 часа. Но сам факт, что атакующему хватило одного украденного токена для публикации от имени доверенного мейнтейнера, ставит вопрос о необходимости обязательного использования OIDC Trusted Publishing для критической инфраструктуры npm.

Проверьте свои зависимости, ротируйте секреты и убедитесь, что ваш CI/CD-пайплайн защищён от автоматической установки непроверенных версий.

Исследователь под ником Sveba опубликовал разбор двух способов детектировать headless-браузеры через Chrome DevTools Protocol (CDP). Оба метода работают в одну строку JavaScript, не требуют никаких разрешений и срабатывают синхронно — без замеров тайминга. Второй способ по состоянию на март 2026 года не закрыт и, по заявлению автора, не может быть закрыт без изменения поведения ECMAScript.

Ключевые выводы:
— Оба сигнала срабатывают, когда активен CDP Runtime domain — то есть одновременно при открытых DevTools и при работе Puppeteer/Playwright
— Сигнал 1 (май 2025): кастомный getter на stack у объекта Error — частично закрыт патчем V8, но обходится через прототипы
— Сигнал 2 (март 2026): Proxy в прототипе объекта + console.groupEnd() — не закрыт, корень проблемы в спецификации ECMAScript
— Детектирование синхронное, без тайминга, без permissions — один вызов console.*
— Runtime.enable одинаково активируется и DevTools UI, и автоматизацией

Что такое CDP и почему он нас выдаёт

Chrome DevTools Protocol (CDP) — это API, через который DevTools общается с браузером. Когда вы открываете инструменты разработчика, браузер активирует домен Runtime внутри V8. То же самое происходит, когда Puppeteer или Playwright вызывают Runtime.enable — с точки зрения V8 это неотличимо.

В режиме Runtime.enable инспектор подписывается на все вызовы console.* и начинает сериализовывать аргументы для отображения в панели DevTools. Именно эта сериализация и создаёт side effects, которые становятся детектируемыми.

Сигнал 1: кастомный getter на stack (май 2025, частично закрыт)

Первый вектор, который широко использовался среди вендоров bot-detection, выглядит так:

В нормальном браузере console.debug(e) просто логирует объект. Никто не читает .stack, getter не вызывается, detected остаётся false.

При активном Runtime.enable инспектор перехватывает вызов и прогоняет аргумент через функцию descriptionForError() в v8/src/inspector/value-mirror.cc. Эта функция обращается к свойствам name, stack и message через object->Get() — а C++ API V8 при обращении к свойству честно вызывает getter, если тот определён. Getter срабатывает. detected становится true.

Патч V8 и его неполнота

В мае 2025 года в V8 приземлились два коммита (7 и 9 мая), которые ввели обёртку getErrorProperty(). Перед чтением свойства она проверяет ScriptId getter'а: если у него есть реальный ScriptId (то есть getter написан на JavaScript, а не является нативным C++-аксессором) — читать отказывается.

Проблема в том, что патч срабатывает только если GetOwnPropertyDescriptor на объекте возвращает дескриптор. Если нет — функция идёт по альтернативной ветке и вызывает object->Get() напрямую, до всякой проверки ScriptId. Getter, определённый не как собственное свойство экземпляра, а через прототип — обходит патч полностью.

Сигнал 2: Proxy в прототипе + console.groupEnd (март 2026, не закрыт)

Второй вектор аккуратнее и глубже:

obj — это не Proxy. Это обычный объект, у которого прототипом является Proxy. typeof obj === "object". Именно эта деталь позволяет обойти защиту.

Четыре слоя C++, которые приводят к срабатыванию trap

Автор прошёлся по всей цепочке выполнения в debug-сборке V8 и задокументировал каждый переход:

• Слой A — инспектор генерирует preview безусловно. Функция V8ConsoleMessage::wrapArguments вызывается для каждого аргумента любого console.*-метода с флагом generatePreview = true. console.groupEnd по спецификации не принимает аргументов — но JavaScript позволяет передавать аргументы любой функции, и V8 их исправно обрабатывает.
• Слой B — проверка Proxy работает только на поверхности. В buildObjectPreviewInternal есть цикл, который снимает обёртку Proxy через while(value->IsProxy()). Поскольку obj сам не является Proxy, цикл не выполняется ни разу. Инспектор считает объект «пассивными данными» и передаёт его дальше.
• Слой C — DebugPropertyIterator обходит цепочку прототипов заранее. При создании итератора через DebugPropertyIterator::Create() он сразу накапливает ключи — не лениво по запросу, а при конструировании. Итератор проходит по всей цепочке прототипов: объект без свойств → переход к прототипу (нашему Proxy) → запрос ключей.
• Слой D — спецификация ECMAScript требует вызова trap. Когда KeyAccumulator::GetKeys наконец добирается до Proxy, выбора нет: спецификация (§10.5.11 [[OwnPropertyKeys]]) прямо требует вызвать ownKeys trap, если он определён. V8 вызывает его через Execution::Call — граница C++/JavaScript пересекается. detected = true.

Корень проблемы: три разумных решения создают дыру

Автор подчёркивает: ни одна отдельная строка кода не является ошибкой. Уязвимость — это пересечение трёх архитектурных решений:

1. Безусловная генерация preview. Инспектор сериализует аргументы всех console.*-методов, даже тех, которые по спецификации аргументов не принимают.
2. Неполное раскрытие Proxy. Проверка IsProxy() в двух местах смотрит только на сам объект, но не на его прототипы. Полная защита потребовала бы обхода всей цепочки прототипов при каждом вызове — дорогая операция для того, что сейчас является однострочной проверкой.
3. Жадный сбор ключей при создании итератора. DebugPropertyIterator собирает все ключи заранее, включая из прототипов. Ленивый подход позволил бы вообще не трогать прототипы, если их ключи в итоге не нужны.

Паттерн — достичь управляемого пользователем trap через код инспектора, который защищает только непосредственный аргумент — вряд ли уникален для этих двух поверхностей.

Что это значит для автоматизации браузеров

Оба сигнала срабатывают в любой среде, где активен Runtime.enable: при открытых DevTools, при использовании Puppeteer, Playwright или любого другого инструмента, работающего через CDP. Среды без Runtime.enable — не детектируются.

Детектирование синхронное — никаких таймингов, никаких разрешений, никаких browser extensions. Один вызов console.groupEnd() с правильно подготовленным объектом даёт однозначный ответ.

Закрыть второй сигнал на стороне V8 сложно: любое решение либо потребует дорогого обхода цепочки прототипов, либо изменит поведение инспектора при работе с Proxy. Спецификация ECMAScript не оставляет пространства для манёвра — trap должен вызываться.

Частые вопросы

Что такое CDP Runtime domain и зачем его активируют?

Chrome DevTools Protocol (CDP) — это API для взаимодействия с внутренностями браузера. Домен Runtime отвечает за исполнение JavaScript и отображение объектов. DevTools активирует его, чтобы показывать переменные в консоли. Puppeteer и Playwright активируют его автоматически для управления страницей и выполнения скриптов.

Можно ли заблокировать детектирование на стороне Puppeteer/Playwright?

Для первого сигнала есть частичные обходы (не определять getter как собственное свойство Error, использовать прототипы). Для второго сигнала — нет. Вызов ownKeys trap при обращении к ключам Proxy является требованием спецификации ECMAScript и не может быть пропущен движком без нарушения совместимости.

Это касается только headless Chrome?

Нет. Сигналы срабатывают всякий раз, когда активен Runtime.enable — то есть в том числе при открытых DevTools в обычном браузере. Разница в том, что bot-detection интересует именно автоматизация, а не пользователи с открытой консолью.

Был ли сигнал 2 раскрыт вендорам bot-detection?

Статья опубликована в личном блоге исследователя. Отдельного responsible disclosure в Chromium не упоминается. Автор ссылается на пост castle.io, который задокументировал первый сигнал и майский патч 2025 года — именно он послужил вдохновением для этого исследования.

Выводы

Исследование наглядно показывает, как три независимых, разумно выглядящих инженерных решения образуют детектируемый side effect. V8 закрыл первый вектор патчем в мае 2025 года — но неполно. Второй вектор остаётся открытым и, по мнению автора, не может быть устранён без изменений либо в архитектуре инспектора, либо в поведении ECMAScript.

Если вы занимаетесь разработкой инструментов автоматизации или browser fingerprinting — полный разбор с исходниками V8 стоит прочитать целиком. Обсуждение развернулось в r/ReverseEngineering.

Атака затрагивает пользователей множества репозиториев на GitHub — уведомления о «критических уязвимостях» приходят прямо на почту всем подписчикам и участникам проектов.

- Тысячи фейковых security-алертов публикуются в GitHub Discussions по множеству репозиториев - Злоумышленники выдают себя за мейнтейнеров и используют поддельные CVE ID - Ссылки ведут на вредоносные расширения VS Code, размещённые на Google Drive - За фасадом — Traffic Distribution System с JS-разведкой и фильтрацией исследователей - GitHub Discussions автоматически рассылает email-уведомления всем подписчикам репозиториев

Как работает атака

Кампания построена на злоупотреблении функцией GitHub Discussions — раздела для обсуждений внутри репозиториев. Атакующие создают новые аккаунты или используют малоактивные учётные записи и за считаные минуты публикуют тысячи постов с одинаковым шаблоном.

Каждый пост оформлен как срочное предупреждение о безопасности с заголовком вида Severe Vulnerability — Immediate Update Required. В тексте указаны поддельные CVE-идентификаторы (CVE — Common Vulnerabilities and Exposures, стандартная система нумерации известных уязвимостей) и ссылка на «пропатченную» версию расширения. Злоумышленники тщательно имитируют стиль настоящих security advisories и подписываются именами реальных мейнтейнеров или исследователей безопасности.

Ключевой рычаг атаки — механизм уведомлений GitHub. Все пользователи, которые подписаны на репозиторий (watchers) или участвовали в обсуждениях (participants), автоматически получают email с содержимым фейкового алерта. Таким образом, одна публикация в Discussions может охватить сотни и тысячи разработчиков.

Цепочка заражения

Ссылка из фейкового алерта ведёт на Google Drive, где размещён файл, замаскированный под обновлённое расширение VS Code. Далее запускается многоступенчатая цепочка:

1. Жертва переходит по ссылке на Google Drive и скачивает файл
2. Файл инициирует цепочку cookie-driven редиректов, которая приводит на домен drnatashachinn[.]com
3. На этом домене выполняется JavaScript-скрипт разведки — он собирает данные о системе: часовой пояс, локаль, user agent, операционную систему и индикаторы автоматизации
4. Собранные данные отправляются на C2-сервер (Command and Control — управляющий сервер атакующих) через POST-запрос
5. Сервер работает как Traffic Distribution System (TDS) — фильтрует ботов и ИБ-исследователей, пропуская к следующему этапу только реальных пользователей

Исследователям из Socket не удалось перехватить финальную полезную нагрузку (payload — вредоносный код второго этапа) — TDS-система определяла их как аналитиков и блокировала доставку. Важно: сам JS-скрипт разведки не крадёт пароли и не перехватывает учётные данные — он только собирает информацию о системе для фильтрации. Что именно получают прошедшие фильтрацию жертвы — пока неизвестно.

Как распознать фейковый алерт

Разработчикам стоит проявлять бдительность при получении уведомлений о безопасности из GitHub Discussions. Вот чеклист для проверки:

1. Проверьте автора поста — кликните на профиль. Новый аккаунт без активности или с минимальной историей — красный флаг
2. Настоящие security advisories публикуются во вкладке Security репозитория, а не в Discussions
3. Проверьте CVE ID через официальную базу cve.mitre.org или nvd.nist.gov — фейковые идентификаторы там не найдутся
4. Не скачивайте расширения VS Code из Google Drive или любых внешних источников — используйте только официальный VS Code Marketplace
5. Обращайте внимание на язык поста: паникёрские формулировки вроде «Immediate Update Required» нехарактерны для реальных мейнтейнеров
6. Если получили email-уведомление — перейдите в репозиторий и проверьте обсуждение в контексте, а не переходите по ссылкам из письма

Прецеденты: атаки через GitHub в 2024–2025

Это не первый случай использования инфраструктуры GitHub для распространения вредоносного ПО:

• Март 2025 — масштабная кампания затронула более 12 000 репозиториев. Злоумышленники публиковали фейковые security alerts и через них направляли разработчиков на авторизацию вредоносного OAuth-приложения, получая доступ к их аккаунтам
• Июнь 2024 — атакующие использовали спам-комментарии и pull requests для запуска email-уведомлений GitHub, перенаправляя разработчиков на фишинговые страницы

Общий тренд очевиден: злоумышленники всё активнее эксплуатируют доверие разработчиков к платформе GitHub и её встроенные механизмы уведомлений для доставки вредоносного контента.

Как защититься прямо сейчас

Вот конкретные шаги, которые стоит предпринять уже сегодня:

1. Отключите email-уведомления для Discussions: Settings → Notifications → Watching → Custom → снимите галочку с Discussions
2. Включите двухфакторную аутентификацию на GitHub: Settings → Password and authentication → Enable two-factor authentication
3. Проверьте список установленных расширений VS Code: откройте Extensions (Ctrl+Shift+X) → убедитесь, что все расширения установлены из официального VS Code Marketplace
4. Не переходите по ссылкам из email-уведомлений GitHub — открывайте репозиторий напрямую в браузере
5. Сообщайте о подозрительных постах через кнопку Report в GitHub Discussions — это помогает платформе быстрее блокировать вредоносный контент

Выводы

Атака через GitHub Discussions показывает, что даже доверенные платформы могут стать каналом доставки вредоносного ПО. Злоумышленники комбинируют социальную инженерию (срочность, имитация авторитетных фигур), легитимную инфраструктуру (Google Drive, email-уведомления GitHub) и техническую изощрённость (TDS-фильтрация, JS-разведка). Подробности — в отчёте BleepingComputer.

Главное правило остаётся прежним: не устанавливайте ПО из непроверенных источников, даже если предупреждение выглядит правдоподобно. Настоящие обновления безопасности для расширений VS Code всегда доступны через официальный VS Code Marketplace.

Приложение White House (gov.whitehouse.app, версия 47.0.1) — официальный Android-клиент Белого дома, доступный в Google Play. Под капотом — React Native на Expo SDK 54 с движком Hermes. Бэкенд — WordPress, который отдаёт контент через REST API на whitehouse.gov.

— Приложение содержит JavaScript-инжектор, который скрывает cookie-баннеры, GDPR-диалоги, пейволлы и логин-стены на любых сайтах, открытых через встроенный браузер

— В коде заложена инфраструктура GPS-трекинга через OneSignal: опрос координат каждые 4,5 минуты при активном использовании и каждые 9,5 минут в фоне

— YouTube-плеер загружает HTML-страницу с GitHub Pages мейнтейнера сторонней библиотеки — компрометация аккаунта позволит выполнить произвольный код

— В продакшен-сборке остались артефакты разработки: URL localhost, IP разработчика и экспортированная Activity

Что из себя представляет приложение

Приложение Белого дома — по сути, обёртка над WordPress. Весь контент загружается через REST API с эндпоинтами вида /wp-json/whitehouse/v1/*. Вот основные разделы:

• /home — главный экран
• /news/articles — новости
• /wire — лента «The Wire»
• /live — прямые трансляции
• /galleries — фотогалереи
• /issues и /priorities — политические приоритеты
• /achievements — «достижения»
• /media-bias — раздел «предвзятость СМИ»
• /social/x — прокси ленты X/Twitter

Среди контента — разделы «THE TRUMP EFFECT», «Greatest President Ever!», «Text President Trump» (с номером 45470) и ссылки на TrumpRx.gov, TrumpAccounts.gov, а также форма доноса ICE. Конфиг Expo указывает владельца forty-five-press — судя по всему, это медиа-команда, а не государственное агентство.

Инжектор обхода cookie-баннеров и пейволлов

Самая неожиданная находка — JavaScript-код, который инжектируется в каждый сайт, открытый через встроенный WebView приложения. Пейволл (paywall) — это платная стена, блокирующая доступ к контенту для неподписчиков. Скрипт использует механизм injectedJavaScript в React Native WebView.

Что именно скрывает инжектор:

• Cookie-баннеры (по CSS-селекторам *cookie*, *Cookie*)
• GDPR-диалоги согласия (*consent*, *gdpr*, *GDPR*)
• Баннеры OneTrust (*onetrust*)
• Баннеры приватности (*privacy-banner*)
• Логин-стены (*login-wall*, *loginWall*)
• Стены регистрации (*signup-wall*, *signupWall*)
• Апсейл-блоки (*upsell*, *Upsell*)
• CMP-боксы (.cmpboxBtnYes, .cmpbox)
• Любые элементы с aria-label, содержащим «cookie» или «consent»

Скрипт работает в два этапа. Сначала создаёт CSS-правило display: none !important для всех элементов, соответствующих селекторам. Затем устанавливает MutationObserver, который отслеживает любые изменения DOM и скрывает новые элементы с соответствующими классами. Дополнительно принудительно снимает блокировку прокрутки: body { overflow: auto !important }.

По сути, приложение Белого дома обходит GDPR-требования и пейволлы на сторонних сайтах. Для государственного приложения это, мягко говоря, неожиданно.

Инфраструктура GPS-трекинга

В конфиге Expo есть плагин withNoLocation, который, казалось бы, отключает геолокацию. Однако в скомпилированном коде присутствует полноценная инфраструктура трекинга через OneSignal SDK.

Константы опроса координат

В классе LocationConstants жёстко заданы интервалы опроса:

• FOREGROUND_UPDATE_TIME_MS = 270000 — 4,5 минуты при активном использовании
• BACKGROUND_UPDATE_TIME_MS = 570000 — 9,5 минут в фоне
• TIME_FOREGROUND_SEC = 300 — 5-минутный порог для переднего плана
• TIME_BACKGROUND_SEC = 600 — 10-минутный порог для фона

Как работает трекинг

Класс GmsLocationController использует Google Fused Location API. При каждом опросе запрашивает координаты с приоритетом PRIORITY_BALANCED_POWER_ACCURACY (код 102) и устанавливает maxWaitTime в полтора раза больше интервала.

Перехваченные координаты обрабатывает LocationCapturer: широта, долгота, точность, временная метка, флаг фоновой работы и тип (грубый/точный). Всё сохраняется в PropertiesModel и отправляется на серверы OneSignal (api.onesignal.com).

Есть и фоновый сервис LocationBackgroundService, который продолжает собирать координаты даже когда приложение свёрнуто.

Защита — есть, но условная

Формально GPS-трекинг защищён гейтом: флаг _isShared по умолчанию false. Трекинг активируется только после вызова setLocationShared(true). Плагин withNoLocation по идее не должен его включать. Но вся инфраструктура скомпилирована в приложение. Поскольку трекинг реализован в нативном коде (Java), простое OTA-обновление JavaScript-бандла его не активирует. Однако если в приложении есть bridge-вызов к setLocationShared из JS — достаточно серверного конфига для включения без обновления через Google Play.

Риски цепочки поставок

JavaScript с чужого GitHub Pages

Для YouTube-плеера используется библиотека react-native-youtube-iframe, которая загружает HTML-страницу с GitHub Pages пользователя lonelycpp — мейнтейнера этой библиотеки:

Если аккаунт lonelycpp на GitHub будет скомпрометирован, злоумышленник сможет подменить эту страницу и выполнить произвольный JavaScript в WebView приложения Белого дома. Это классическая supply-chain атака (атака через цепочку поставок — компрометация стороннего компонента для проникновения в целевую систему). Хостинг ресурсов на GitHub Pages вместо CDN с Subresource Integrity — плохая практика для любого приложения, тем более государственного.

Виджеты Elfsight

Приложение загружает JavaScript-платформу Elfsight с CDN:

Elfsight — это виджет-платформа для социальных сетей. Никакой песочницы — скрипт исполняется в том же контексте, что и основное приложение.

Сторонние сервисы вместо госинфраструктуры

Ни один из сторонних сервисов не является государственной инфраструктурой:

• Mailchimp (whitehouse.us10.list-manage.com) — обработка email-подписок. Адреса пользователей уходят на серверы Mailchimp
• Uploadcare (ucarecdn.com) — хостинг контентных изображений через 6 захардкоженных UUID
• Truth Social — захардкоженный embed с профилем Трампа, аватаркой со static-assets-1.truthsocial.com и кнопкой «Follow»
• Facebook — плагин страницы через iframe facebook.com/plugins/page.php

Профилирование пользователей через OneSignal

OneSignal SDK в приложении — это не просто пуш-уведомления. Платформа предоставляет широкие возможности для профилирования пользователей:

• addTag — тегирование пользователей для сегментации
• addSms — привязка номеров телефонов к профилям
• addAliases — кросс-девайсная идентификация пользователей
• addOutcomeWithValue / addUniqueOutcome — отслеживание действий и конверсий
• Полный цикл in-app сообщений: WillDisplay, DidDisplay, WillDismiss, DidDismiss, inAppMessageClicked
• Отслеживание изменений состояния: подписки, разрешения, пользовательский профиль

Локальная SQLite-база хранит таблицы notification (с полями notification_id, opened, dismissed, title, message, full_data) и in_app_message (с отслеживанием показов и кликов).

Артефакты разработки в продакшен-сборке

В релизной версии приложения остались следы, которых там быть не должно:

• URL http://localhost:8081/wp-json/whitehouse/v1/galleries?page= — захардкоженный адрес локального дев-сервера
• IP-адрес разработчика 10.4.4.109 — прописан в strings.xml как react_native_dev_server_ip
• Пакеты expo-dev-client, expo-devlauncher, expo-devmenu — средства разработки Expo
• Иконка дев-меню dev_menu_fab_icon.png
• Экспортированная PreviewActivity из Compose UI Tooling — доступна другим приложениям через android:exported="true"

Экспортированная Activity — это потенциальный вектор атаки. Любое приложение на устройстве может запустить PreviewActivity через Intent.

Отсутствие certificate pinning

Certificate pinning (закрепление сертификата) — это метод защиты от атак «человек посередине» (MITM), при котором приложение принимает только заранее известные сертификаты сервера. Приложение Белого дома использует стандартный Android Trust Manager без закрепления сертификатов. Это означает, что при использовании скомпрометированного Wi-Fi или корпоративного прокси трафик между приложением и серверами whitehouse.gov может быть перехвачен и прочитан.

Разрешения и файловый доступ

Манифест запрашивает следующие разрешения:

• INTERNET — доступ к сети
• VIBRATE — вибрация
• ACCESS_NETWORK_STATE — состояние сети
• POST_NOTIFICATIONS — отправка уведомлений
• WAKE_LOCK — предотвращение засыпания
• RECEIVE_BOOT_COMPLETED — автозапуск при загрузке
• C2DM.RECEIVE — облачные пуш-уведомления
• CHECK_LICENSE — проверка лицензии Google Play

Конфигурация FileProvider описывает путь external-path name="shared" path="." — приложение может предоставлять любые файлы из внешнего хранилища другим приложениям через FileProvider. Это не означает чтение чужих данных, но расширяет поверхность атаки при взаимодействии между приложениями.

Полный стек зависимостей

Список SDK внутри приложения впечатляет:

• Фреймворк: React Native, Expo SDK 54, Hermes JS engine
• Пуш/вовлечение: OneSignal, Firebase Cloud Messaging, Firebase Installations
• Аналитика: Firebase Analytics, Google Data Transport, OpenTelemetry
• Сеть: OkHttp 3, Apollo GraphQL, Okio
• Изображения: Fresco, Glide, Coil 3, Uploadcare CDN
• Видео: ExoPlayer (Media3), Expo Video
• ML: Google ML Kit Vision (сканирование штрих-кодов), модель Barhopper
• Криптография: Bouncy Castle
• Хранилище: Expo Secure Store, React Native Async Storage
• WebView: React Native WebView (с инжектором)
• DI: Koin
• Сериализация: GSON, Wire (Protocol Buffers)
• Лицензия: PairIP license check (Google Play Verification)

Что делать пользователям

1. Не открывать ссылки через встроенный браузер приложения — копировать URL и открывать в Chrome/Firefox, где cookie-баннеры отображаются корректно
2. Проверить разрешения приложения в настройках Android: Настройки → Приложения → White House → Разрешения — убедиться, что геолокация отключена
3. Учитывать, что RECEIVE_BOOT_COMPLETED запускает сервисы приложения при каждой загрузке устройства — даже если вы не открывали приложение
4. Для параноиков: использовать отдельный рабочий профиль Android (Настройки → Система → Несколько пользователей) для изоляции

Чеклист для разработчиков: что не должно попадать в прод

Этот случай — хороший повод проверить собственные приложения. Вот что стоит убрать перед релизом:

1. URL localhost и IP-адреса разработчиков — искать в strings.xml, конфигах и коде
2. Дев-пакеты (expo-dev-client, devmenu) — исключать из релизных сборок через build flavors
3. Экспортированные Activity для отладки — убирать android:exported="true" у дев-компонентов
4. Внешние JS-зависимости без SRI — хостить критичные ресурсы на собственном CDN
5. Избыточные SDK-модули — если не используете геолокацию, исключить модуль из сборки, а не просто «отключить» флагом
6. Широкие пути в FileProvider — ограничивать до конкретных директорий вместо path="."
7. Certificate pinning — добавить для всех критичных эндпоинтов через network_security_config.xml

Выводы

Приложение Белого дома — это React Native обёртка над WordPress с инжектором обхода cookie и пейволлов, инфраструктурой GPS-трекинга через OneSignal и JavaScript-зависимостями с GitHub Pages стороннего разработчика. Без certificate pinning.

Этот разбор показывает, что даже государственные приложения могут содержать сомнительные практики: от обхода GDPR-баннеров до supply-chain зависимостей от случайных разработчиков. Полная инфраструктура GPS-трекинга, встроенная в код, но формально «отключённая» — это бомба замедленного действия, которая может быть активирована без обновления приложения.

Оригинальный анализ доступен в блоге thereallo.dev.

А вы проверяли, какие разрешения у государственных приложений на вашем телефоне?

Telnyx — платформа для программируемой телефонии, SMS и сетевых сервисов. Её Python SDK (telnyx на PyPI) скачивают более 1 миллиона раз в месяц (~30 000 загрузок в день). 27 марта 2026 года исследователи из SafeDep обнаружили, что версии 4.87.1 и 4.87.2 содержат вредоносный код, которого нет в исходном репозитории на GitHub. Инциденту присвоен CVE-2026-33634 (CVSS 9.4). Обе заражённые версии уже карантинированы PyPI.

Главное: Версии telnyx 4.87.1 и 4.87.2 на PyPI содержат вредоносный код — 74 строки, внедрённые в файл _client.py. Пакет скачивают более 1 млн раз в месяц. Вредонос использует стеганографию в WAV-файлах для доставки полезной нагрузки. На Windows устанавливается бэкдор, на Linux/macOS — крадутся учётные данные. Безопасная версия — 4.87.0. Атака связана с группировкой TeamPCP — это уже третье звено в цепочке после компрометации Trivy, Checkmarx и litellm.

Supply chain attack (атака на цепочку поставок) — тип атаки, при которой злоумышленник компрометирует не конечную цель, а один из компонентов, от которого она зависит: библиотеку, SDK или инструмент сборки. Разберём, как именно сработала атака и что делать, если вы используете telnyx.

Как произошла компрометация

Последняя чистая версия пакета — 4.87.0 — была опубликована 26 марта через штатный CI/CD-пайплайн (GitHub Actions + Rye). У неё есть соответствующий тег v4.87.0 в репозитории.

Версии 4.87.1 и 4.87.2 не имеют ни тегов, ни релизов на GitHub. Workflow публикации не запускался после v4.87.0. Метаданные PyPI показывают, что заражённые версии были загружены через twine/6.2.0, тогда как легитимный пайплайн использует rye publish.

Вывод: атакующий получил украденный PyPI API-токен и загрузил троянизированные версии напрямую, минуя CI/CD. У проекта не был настроен PyPI Trusted Publisher (OIDC), который привязывает загрузку к конкретному репозиторию и воркфлоу, делая украденные токены бесполезными.

Как работает вредоносный код

В файл telnyx/_client.py было внедрено ровно 74 строки кода в трёх местах: импорты в начале файла, base64-закодированная переменная с полезной нагрузкой и функции атаки после легитимных классов. Код выполняется автоматически при import telnyx — никакого взаимодействия с пользователем не требуется.

WAV-стеганография

Ключевая особенность атаки — использование стеганографии. Вредонос скачивает с C2-сервера файлы, замаскированные под WAV-аудио (ringtone.wav для Linux/macOS, hangup.wav для Windows). Исполняемый код спрятан в аудиофреймах и извлекается через XOR-деобфускацию. Импорт модуля wave в SDK для телефонии — единственный «красный флаг», который мог выдать атаку при code review.

Windows: бэкдор через автозагрузку

Функция setup() проверяет os.name == 'nt', затем скачивает бинарник из WAV-файла и сохраняет его как msbuild.exe в папку автозагрузки Windows. Имя файла имитирует легитимный инструмент Microsoft Build Engine. Бэкдор запускается при каждом входе в систему с кулдауном повторной установки 12 часов.

Linux/macOS: кража учётных данных

Функция FetchAudio() запускает второй этап из base64-закодированной переменной (4 436 символов). Скрипт собирает учётные данные, API-ключи, SSH-ключи и секреты, шифрует их связкой AES-256-CBC + RSA-4096 с хардкодированным публичным ключом и отправляет на C2-сервер через HTTP POST.

Баг атакующего

Любопытная деталь: в версии 4.87.1 атака на Windows не работала. Атакующий вызвал Setup() с заглавной буквы, тогда как функция определена как setup() со строчной. Это вызывало NameError, прерывавший выполнение модуля до запуска FetchAudio(). Версия 4.87.2 — по сути патч-релиз атакующего, исправляющий эту опечатку.

Связь с TeamPCP: цепочка атак

RSA-4096 публичный ключ, зашитый в вредоносный код, побайтово совпадает с ключом из компрометации пакета litellm. Это позволяет с высокой уверенностью атрибутировать атаку группировке TeamPCP. Группировка использует инфраструктуру CanisterWorm, размещённую на блокчейне Internet Computer Protocol (ICP) — без единой точки отказа.

Компрометация telnyx — третье крупное звено в каскадной атаке TeamPCP:

• 27 февраля — атака на репозиторий Trivy (сканер уязвимостей от Aqua Security) через вредоносный PR
• 19–20 марта — заражённый Trivy v0.69.4 опубликован, CanisterWorm распространился на 46+ npm-пакетов
• 23 марта — скомпрометированы Checkmarx GitHub Actions
• 24 марта — заражены версии litellm 1.82.7 и 1.82.8 на PyPI (~97 млн загрузок/мес)
• 27 марта — заражены версии telnyx 4.87.1 и 4.87.2 на PyPI

Что делать

1. Проверьте версию telnyx в ваших проектах
2. Если установлена 4.87.1 или 4.87.2 — немедленно откатитесь на 4.87.0
3. Проверьте наличие файла msbuild.exe в папке автозагрузки Windows
4. Проверьте сетевые соединения с IP 83.142.209.203
5. Если обнаружены IoC — считайте все учётные данные, API-ключи и SSH-ключи скомпрометированными
6. Проверьте CI/CD на использование других скомпрометированных пакетов TeamPCP: Trivy, Checkmarx Actions, litellm
7. Включите Trusted Publishers для всех ваших PyPI-пакетов

Индикаторы компрометации (IoC)

CVE-2026-33634 (CVSS 9.4) — GitHub issue #235

FAQ

Какие версии telnyx заражены?

Вредоносный код содержится в версиях 4.87.1 и 4.87.2. Обе уже карантинированы PyPI. Последняя безопасная версия — 4.87.0. При этом в 4.87.1 из-за опечатки атакующего ни один из векторов атаки фактически не срабатывал.

Как атакующие получили доступ к PyPI?

Через украденный PyPI API-токен. GitHub-репозиторий telnyx не был скомпрометирован — атакующие загрузили пакеты напрямую на PyPI через twine, минуя CI/CD. У проекта не был настроен Trusted Publisher (OIDC), который предотвратил бы такую атаку.

Кто стоит за атакой?

Атака атрибутирована группировке TeamPCP. Это та же группа, которая ранее скомпрометировала сканер уязвимостей Trivy, GitHub Actions Checkmarx и PyPI-пакет litellm. RSA-ключ в вредоносном коде побайтово совпадает с ключом из предыдущих атак. Инфраструктура CanisterWorm размещена на блокчейне ICP, что делает её устойчивой к блокировке.

Что делать, если я уже установил заражённую версию?

Немедленно откатитесь на версию 4.87.0. Проверьте систему на наличие IoC. Если обнаружены признаки компрометации — считайте все учётные данные, API-ключи и SSH-ключи на этой машине скомпрометированными и выполните их ротацию. Также проверьте CI/CD на использование Trivy, Checkmarx Actions и litellm.

Выводы

Атака на telnyx — не изолированный инцидент. Это часть каскадной кампании TeamPCP, которая за месяц скомпрометировала Trivy, Checkmarx, litellm и теперь telnyx. Единственная надёжная защита — PyPI Trusted Publishers (OIDC), привязывающий загрузку к конкретному GitHub-репозиторию.

Этот инцидент в очередной раз показывает: доверять пакетам из PyPI «на слово» нельзя, даже если это официальный SDK крупной платформы. Настройте Trusted Publishers, пиньте версии зависимостей, проверяйте хеши при установке. Проверьте свои проекты прямо сейчас.

Источники: SafeDep, Aikido, The Hacker News, JFrog Security Research

LiteLLM — это open-source прокси для работы с API различных LLM-провайдеров: OpenAI, Anthropic, Azure, Bedrock и ещё сотней других. Библиотека позволяет переключаться между моделями через единый интерфейс с автоматическими фоллбэками, ретраями и трекингом расходов. При 97 миллионах загрузок в месяц (около 3,4 млн в день) это один из самых популярных инструментов в AI-инфраструктуре.

В скомпрометированных версиях 1.82.7 и 1.82.8, опубликованных на PyPI, обнаружили встроенный стилер учётных данных. Он крал SSH-ключи, токены облачных сервисов, API-ключи и пароли, а затем расползался по Kubernetes-кластерам.

Ключевое: Версии LiteLLM 1.82.7 и 1.82.8 на PyPI содержали стилер, крадущий SSH-ключи, облачные токены и API-ключи. Версия 1.82.8 запускала вредоносный код при каждом старте Python — даже без импорта библиотеки. Если вы устанавливали LiteLLM 24 марта 2026 года — проверьте свои системы. Последняя чистая версия — 1.82.6.

Но эта атака — не изолированный инцидент. Это финал пятидневной supply chain атаки (атаки через цепочку поставок — внедрение вредоносного кода в легитимный пакет через компрометацию его инфраструктуры). За ней стоит группировка TeamPCP — ранее неизвестная группа, которая за последнюю неделю марта целенаправленно атаковала инструменты безопасности и разработки. Кампания началась с компрометации сканера уязвимостей Trivy и через цепочку украденных CI/CD-креденшалов дотянулась до LiteLLM.

Разбираем всю цепочку атаки от начала до конца — подробнее, чем где-либо ещё.

Хронология: пять дней, три вендора, пять экосистем

Чтобы понять, как LiteLLM оказался скомпрометирован, нужно отмотать на пять дней назад. Атакующие не ломали LiteLLM напрямую — они добрались до него через цепочку компрометаций, каждая из которых давала доступ к следующей цели.

19 марта: Trivy — точка входа

Всё началось с Trivy — open-source сканера уязвимостей от Aqua Security, которым пользуются тысячи компаний для проверки контейнеров и кода.

Атакующие использовали скомпрометированные учётные данные мейнтейнера, чтобы:

• Опубликовать вредоносный релиз Trivy v0.69.4, который прошёл через стандартную release-машинерию и попал в GHCR, ECR Public, Docker Hub, deb/rpm-пакеты
• Подменить 76 из 77 тегов aquasecurity/trivy-action на вредоносные коммиты
• Заменить все 7 тегов aquasecurity/setup-trivy

Вредоносный код в GitHub Actions сканировал память процесса Runner.Worker, собирал креденшалы, шифровал данные AES+RSA и отправлял на подставной домен scan.aquasecurtiy[.]org — обратите внимание на опечатку в слове «security». Если прямая эксфильтрация не удавалась, малварь создавала публичный репозиторий tpcp-docs через GitHub-токен жертвы и сливала данные туда.

20–22 марта: npm-червь и дефейс

Уже на следующий день украденные токены пошли в дело. Атакующие запустили самораспространяющегося npm-червя: 28 пакетов в @EmilGroup, 16 в @opengov, плюс отдельные пакеты в других скоупах. Червь крал npm-токены из скомпрометированных окружений, проверял, к каким пакетам они дают доступ, поднимал patch-версию, подставлял оригинальный README для маскировки и переиздавал пакет с вредоносной начинкой.

К 22 марта та же инфраструктура начала обслуживать Kubernetes-скрипт с разделением жертв по геолокации. На иранских системах деплоился DaemonSet с контейнером kamikaze, который удалял файловую систему хоста и перезагружал ноду. На остальных — устанавливал персистентный бэкдор.

В тот же день атакующие дефейснули 44 репозитория внутренней GitHub-организации Aqua Security (aquasec-com), переименовав их с префиксом tpcp-docs- и описанием «TeamPCP Owns Aqua Security».

23 марта: Checkmarx

Кампания добралась до Checkmarx — ещё одного крупного вендора в сфере безопасности приложений. Были скомпрометированы:

• Checkmarx/kics-github-action — сканер инфраструктурного кода
• Checkmarx/ast-github-action — GitHub Action для платформы Checkmarx
• Расширения VS Code в реестре Open VSX: ast-results v2.53.0 (около 36 000 загрузок) и cx-dev-assist v1.7.0 (около 500 загрузок)

Паттерн тот же: стилер креденшалов, привязанный к домену checkmarx[.]zone, с фоллбэком на публичный репозиторий docs-tpcp для эксфильтрации.

24 марта: LiteLLM

В 10:52 UTC на PyPI появилась версия LiteLLM 1.82.8. Соответствующий тег или релиз на GitHub отсутствовал — пакет был загружен напрямую, в обход стандартного процесса. По данным ReversingLabs, был скомпрометирован GitHub-аккаунт сооснователя и CEO LiteLLM Криша Дхолакии — предположительно, через CI/CD-пайплайн, где Trivy использовался без пиннинга версии.

Через три часа команда безопасности PyPI поставила проект на карантин. Скомпрометированные версии были удалены. Последняя чистая версия — 1.82.6. Но при 3,4 миллионах загрузок в день даже три часа — это огромное окно.

Мейнтейнеры LiteLLM опубликовали security-апдейт, подтвердив компрометацию и рекомендовав всем пользователям обновиться до версии 1.82.6 или выше (после снятия карантина). Issue #24512 на GitHub, описывающий уязвимость, был закрыт — предположительно, самим атакующим через скомпрометированный аккаунт.

Как работает вредоносный код

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

Версия 1.82.7: инъекция в proxy_server.py

В версии 1.82.7 вредоносный код был внедрён в файл litellm/proxy/proxy_server.py. Малварь запускалась только при реальном использовании LiteLLM Proxy в приложении. Если пакет был установлен, но прокси-сервер не запускался, код мог не сработать.

Версия 1.82.8: .pth-файл — запуск без импорта

Версия 1.82.8 принципиально опаснее. В wheel-пакет был добавлен файл litellm_init.pth размером 34 628 байт, содержащий дважды закодированный в base64 вредоносный код.

.pth-файлы — малоизвестная особенность Python. Согласно документации модуля site, исполняемые строки в .pth-файлах выполняются автоматически при каждом запуске интерпретатора. Не при импорте библиотеки, а при запуске любого Python-процесса в окружении, где установлен пакет.

Это означает: достаточно было выполнить pip install litellm==1.82.8, и каждый последующий запуск Python на этой машине активировал стилер. Не нужно писать import litellm — даже python -c "print('hello')" запускал вредоносный код.

Три стадии: сбор, шифрование, эксфильтрация

Стадия 1 — сбор. Скрипт прочёсывает машину и собирает:

• SSH-ключи и конфигурации (~/.ssh/)
• .env-файлы с секретами
• Креденшалы AWS (Access Key, Secret Key), GCP (ADC), Azure
• Конфигурации Kubernetes (~/.kube/config)
• Docker-конфиги (~/.docker/config.json)
• Пароли баз данных
• Историю шелла (bash_history, zsh_history)
• Файлы криптокошельков
• Все переменные окружения
• Данные с облачных metadata-эндпоинтов (IMDS)

Стадия 2 — шифрование. Собранные данные упаковываются в tar-архив и шифруются гибридной схемой: случайный сессионный ключ AES-256-CBC для данных, зашифрованный захардкоженным 4096-битным RSA-публичным ключом.

Стадия 3 — эксфильтрация. Зашифрованный архив отправляется POST-запросом на models.litellm[.]cloud (домен не имеет отношения к настоящему litellm.ai) с заголовком X-Filename: tpcp.tar.gz.

Горизонтальное распространение в Kubernetes

Если на машине обнаружен токен сервисного аккаунта Kubernetes, малварь переходит в режим горизонтального распространения (lateral movement):

1. Читает все секреты кластера во всех неймспейсах
2. Создаёт привилегированный pod на каждой ноде в kube-system на основе образа alpine:latest
3. Каждый pod монтирует корневую файловую систему хоста
4. Устанавливает персистентный бэкдор в /root/.config/sysmon/sysmon.py
5. Регистрирует systemd user service для автозапуска

Таким образом, компрометация одного pip-пакета превращается в полную компрометацию всего Kubernetes-кластера.

Персистентность и бэкдор

На локальной машине малварь создаёт:

• ~/.config/sysmon/sysmon.py — скрипт-бэкдор
• ~/.config/systemd/user/sysmon.service — systemd unit для автозапуска

После установки бэкдор периодически обращается к https://checkmarx[.]zone/raw, скачивает файл в /tmp/pglog и выполняет его содержимое. Это даёт атакующим возможность удалённо выполнять произвольный код на скомпрометированных машинах в любой момент.

Как обнаружили: баг в малвари устроил fork-бомбу

Ирония истории в том, что атаку обнаружили благодаря ошибке самих хакеров.

Команда FutureSearch столкнулась с проблемой случайно: MCP-плагин в IDE Cursor подтянул LiteLLM как транзитивную зависимость. Вредоносный .pth-файл запускал дочерний Python-процесс через subprocess.Popen. Но поскольку .pth-файлы срабатывают при каждом запуске интерпретатора, дочерний процесс тоже запускал малварь, та порождала ещё один процесс — и так далее.

Результат — экспоненциальная fork-бомба, которая мгновенно съедала всю оперативную память и вешала систему. Без этого бага стилер мог бы работать незамеченным значительно дольше.

Мы были взломаны… тысячи людей, вероятно, прямо сейчас под атакой

Что делать, если вы затронуты

Если в ваших проектах, CI/CD-пайплайнах или на рабочих машинах устанавливался LiteLLM 24 марта или позже — проверьте версию:

Если обнаружена версия 1.82.7 или 1.82.8:

1. Удалите пакет и очистите кэши: pip cache purge, rm -rf ~/.cache/uv
2. Проверьте наличие бэкдора: файлы ~/.config/sysmon/sysmon.py и ~/.config/systemd/user/sysmon.service
3. В Kubernetes: аудит kube-system на наличие подов node-setup-*, проверка секретов на несанкционированный доступ
4. Ротация всех креденшалов: SSH-ключи, облачные токены (AWS, GCP, Azure), API-ключи, пароли БД, .env-файлы
5. Сетевые логи: проверьте обращения к models.litellm[.]cloud, checkmarx[.]zone, scan.aquasecurtiy[.]org
6. Восстановление: не ограничивайтесь удалением пакета — пересобирайте системы из известных чистых образов с закреплёнными (pinned) зависимостями

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

Индикаторы компрометации (IoC)

Вредоносные домены:

• models.litellm[.]cloud — C2 для LiteLLM
• checkmarx[.]zone — C2, используемый для персистентности и Checkmarx-атаки
• scan.aquasecurtiy[.]org — C2 для Trivy-атаки

Файлы на диске:

• litellm_init.pth в site-packages/
• ~/.config/sysmon/sysmon.py
• ~/.config/systemd/user/sysmon.service
• /tmp/pglog
• /tmp/.pg_state

Kubernetes-артефакты:

• Поды с именами node-setup-* в kube-system
• Контейнеры с именами kamikaze или provisioner

Инциденту присвоен идентификатор CVE-2026-33634. Полный список IoC в формате CSV доступен в репозитории Datadog Security Labs.

Частые вопросы

Что такое LiteLLM и зачем его используют?

LiteLLM — это open-source Python-библиотека и прокси-сервер, который предоставляет единый интерфейс для работы с более чем 100 LLM-провайдерами (OpenAI, Anthropic, Azure, AWS Bedrock и другие). Библиотека позволяет переключаться между моделями без изменения кода, автоматически обрабатывает фоллбэки и ретраи, отслеживает расходы. По данным PyPI, пакет загружается около 3,4 миллионов раз в день.

Какие версии LiteLLM скомпрометированы?

Скомпрометированы версии 1.82.7 и 1.82.8, опубликованные на PyPI 24 марта 2026 года. Обе версии удалены. Последняя безопасная версия — 1.82.6. Версия 1.82.8 опаснее: она запускает вредоносный код при каждом старте Python через механизм .pth-файлов, тогда как 1.82.7 активируется только при использовании прокси-сервера.

Как проверить, затронут ли я?

Выполните pip show litellm для проверки версии и find ~/.cache/uv -name "litellm_init.pth" для поиска вредоносного файла в кэше. Также проверьте наличие бэкдора: файлы ~/.config/sysmon/sysmon.py и ~/.config/systemd/user/sysmon.service. В Kubernetes ищите поды node-setup-* в namespace kube-system.

Кто стоит за атакой?

Атака приписывается группировке TeamPCP, которая за последнюю неделю марта 2026 года провела серию supply chain атак на инструменты разработки и безопасности: сканер уязвимостей Trivy (Aqua Security), GitHub Actions и расширения VS Code от Checkmarx, npm-пакеты, и в финале — LiteLLM. Инциденту присвоен идентификатор CVE-2026-33634.

Что такое .pth-файл и почему он опасен?

Файлы с расширением .pth, размещённые в директории site-packages, автоматически обрабатываются модулем site Python при каждом запуске интерпретатора. Исполняемые строки в таких файлах выполняются без явного импорта библиотеки. В случае LiteLLM 1.82.8 файл litellm_init.pth содержал дважды закодированный в base64 вредоносный скрипт, который запускался при каждом вызове python в скомпрометированном окружении.

Выводы

Ирония инцидента — в том, что LiteLLM по определению хранит API-ключи ко всем LLM-провайдерам организации. Атакующие выбрали пакет, который гарантированно имеет доступ к самым ценным секретам.

Одна зависимость. Одна цепная реакция. Пять экосистем supply chain скомпрометированы менее чем за месяц

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

Устанавливать пакеты из публичного реестра без проверки хешей и без lock-файлов — значит фактически отдать root-доступ любому, кто сможет скомпрометировать аккаунт мейнтейнера. Как ёмко выразилась Ноэлль Мурата, старший инженер по безопасности в Xcape: «Это цифровой эквивалент того, чтобы съесть бутерброд, найденный в метро, и удивиться пищевому отравлению».

Подробный технический анализ от Datadog Security Labs доступен здесь. Оригинальный отчёт FutureSearch — здесь. Официальный security-апдейт LiteLLM — здесь.

Проверьте свои зависимости сегодня. Команды для аудита — в разделе выше.

Корпоративное ядро: как оно устроено

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

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

В корпоративном сегменте энергетики ядро состоит из набора базовых сервисов: каталог, почта, коммуникации, документооборот, файловый слой, рабочие места и защита. Его фундамент – доменная структура, часто на Alt Domain или RedADM (службы на базе Samba DC): эти решения без сюрпризов проходят проверки совместимости и корректно работают с Kerberos и LDAP.

В реальных проектах переход к новому домену почти всегда начинается с гибридного режима. Старый Active Directory продолжает хранить SID и привязки приложений – без trust-связей массовую миграцию просто не запустить. Так домен становится точкой опоры для всех остальных компонентов. Почта – один из первых сервисов в корпоративном сегменте, который начинает жить по доменной модели: учетные записи, группы, права. И чаще всего именно она на прикладном уровне первой замечает любые отклонения в каталоге.

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

Документооборот и файловый сервис – отдельный слой. Для пользователя это привычные папки с доступом к документам, но под капотом здесь ролевая модель, оргструктура и строгие ACL. Когда включается централизованная модель прав, самодельные сетевые диски исчезают из контура, а файловый слой превращается в управляемую систему доступа.

На уровне ниже находится невидимый пласт сервисов, на которых держится все ядро: DNS/DHCP домена, репликация, политики и настройки безопасности. Ошибки в любом из них могут спровоцировать каскад проблем – от задержек авторизации до потери доступа у части пользователей. На такие сценарии и заточены внутренние ППИ/ПМИ каждого компонента. Сценарии отрабатывают вручную, фиксируют протоколы, закрывают замечания – и только после этого переходят к пилоту.

Все это – «серверная» часть ядра. Но самый сложный участок начинается там, где архитектура сталкивается с пользователями – на АРМ (рабочих станциях). Здесь требуется подключение к каталогу, перенос профилей, миграция данных, проверка приложений, контроль целостности и унификация конфигураций.

В корпоративном сегменте на практике применяются переходные схемы – гибридный режим домена и поэтапная миграция пользовательских сервисов. В КИИ-контуре такие компромиссы возможны далеко не всегда

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

В рамках такой стандартизации на пользовательском уровне и появляется частичный dual-OS: критичные приложения остаются в Windows, а пользовательская среда переезжает в Linux. Это самый безопасный способ пройти миграцию без остановки процессов.

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

Как выглядит внедрение на практике

На проектах внедрение почти всегда проходит в три этапа.

1. Прототипирование – создание в миниатюре будущей инфраструктуры и выявление несовместимостей.
2. Настройка паттернов – сборка образов, настройка групп, OU, профилей, fallback-логики.
3. Переходный период – введение dual-OS, выравнивание политик и подготовка к ОПЭ.

Прототипирование занимает от трех до шести месяцев. На этом этапе всплывает все, что невозможно увидеть на этапе проектирования. Где-то рабочие станции не загружаются на новых образах без обновления BIOS. Где-то плоттеры, сканеры и терминалы требуют ручной настройки. Профили Windows при переносе в Linux теряют ярлыки, MIME-ассоциации и политики. Если корпоративный домен в гибридном режиме, любое расхождение по времени, сбой Kerberos или конфликт GPO могут вывести из строя авторизацию на половине контура.

После пилота начинается настройка паттернов – определяем, какие драйверы исключать из образа, как собирать профили, какие группы синхронизировать, какие параметры ядра уменьшают количество сбоев, как организовать корректный fallback.

Но часть задач паттернами не решить – слишком много рабочих мест держится на Windows-приложениях. Поэтому dual-OS закрепляется как рабочая норма в корпоративном контуре: пользовательский профиль — в Linux, технологические приложения — в Windows, а архитектура постепенно приводится к единому набору политик, профилей и прав.

Откат в этом контуре обязателен. Пользователь должен иметь возможность вернуться в привычную среду в любой момент. На практике команда стремится уложиться в 10–15 минут – иначе миграционный участок становится неуправляемым

Даже после перехода в ОПЭ двухслойная конфигурация сохраняется. Часть сервисов – на новой платформе, часть – на старой. Пока среды существуют параллельно, они должны быть синхронны. Расхождение в правах, политиках или репликации моментально ломает согласованность контуров – и превращается в локальный инцидент.

Информационная безопасность как каркас архитектуры

Эта архитектура не может существовать без четкой рамки ИБ. Причем ИБ здесь – не надстройка, а несущая конструкция. Она определяет, что допустимо в контуре, а что нет, и где проходят реальные границы риска.

Виртуализацию разрешают только там, где можно контролировать изоляцию гостевых систем. Каналы управления – только внутри защищенных сегментов. Требования к виртуализации опираются на ГОСТ 56938: разделение зон исполнения, защита потоков управления, никаких «черных ящиков» в обновлениях.

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

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

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

И все это не имело бы смысла без гарантированного восстановления: система должна уметь возвращать себя в рабочее состояние через резервные копии, откат и проверенные сценарии. Например, компания в финсекторе после отказа всей инфраструктуры, потери ЦОД должна заработать через 2 часа.

Стандартизация через эксплуатацию

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

Конечно же, у компаний в разных регионах – своя история, парк оборудования или глубина легаси. Но архитектурные требования одинаковые везде. Они и формируют единый «слепок» корпоративного ядра при сохранении изоляции КИИ-контуров: правила для каталога, почты, коммуникаций и подготовки рабочих мест.

Если система стабильно прошла ОПЭ на одной площадке, она, как правило, так же ведет себя и на других

В этот момент внедрение перестает быть разовым проектом и превращается в последовательный сценарий. Архитектуру не приходится пересобирать – запускается отлаженная цепочка шагов с заранее понятными точками риска и стабильности. А полевые практики – унифицированные образы, dual-OS, fallback-механизмы – закрепляются как формальные требования.

Импортонезависимое ядро – основа цифровой устойчивости

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

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

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

В марте 2026 Trivy — один из наиболее популярных open-source сканеров уязвимостей — был скомпрометирован дважды за три недели. Пострадали тысячи CI/CD-пайплайнов по всему миру. Если ваш проект использует Trivy или связанные с ним GitHub Actions, эта информация критически важна для защиты вашей инфраструктуры.

Хронология инцидентов: две атаки за три недели

Первая атака: CVE-2026-28353 и hackerbot-claw

Даты: 21–28 февраля 2026

Злоумышленники эксплуатировали критическую уязвимость в GitHub Actions-воркфлоу через механизм pull_request_target. Автономный бот hackerbot-claw автоматически создал Pull Request #10252, что позволило выполнить произвольный код в контексте с доступом к секретам репозитория. Через эту атаку было скомпрометировано VSCode-расширение Trivy, а вредоносная версия v1.8.12 попала в Open VSIX Registry.

Инцидент получил идентификатор CVE-2026-28353 с максимальной оценкой критичности CVSS 10.0. Это означает полную компрометацию конфиденциальности, целостности и доступности системы. Причём исходный disclosure discussion (#10265) был удалён во время второго инцидента, что вызвало критику сообщества за недостаточную прозрачность в обработке уязвимостей.

Вторая атака: TeamPCP и ретроактивное отравление тегов

Дата: 19 марта 2026

Группа TeamPCP использовала учётные данные, украденные в первом инциденте, и опубликовала вредоносный релиз v0.69.4. Однако главная особенность этой атаки — ретроактивное отравление тегов: атакующие переместили (force-push) 76 из 77 существующих тегов релизов так, чтобы они указывали на вредоносный код.

Это означает, что даже если вы использовали «старую стабильную версию», вы также могли получить малварь. Команды, которые зафиксировали версии через теги, оказались под ударом, поскольку теги были изменены задним числом. Полезная нагрузка обеих атак была направлена на кражу секретов CI/CD: GitHub-токенов, npm-токенов, API-ключей и других данных из GitHub Secrets.

Каскадный эффект: CanisterWorm

Ситуация усугубилась каскадным эффектом: украденные npm-токены запустили CanisterWorm — самораспространяющегося червя, который заразил от 28 до 47 пакетов в npm-реестре.

Как проверить свой проект на компрометацию: инструкция

Если вы использовали Trivy или связанные GitHub Actions в период с февраля по март 2026 года, по умолчанию считайте, что ваш пайплайн скомпрометирован. Выполните следующие проверки в указанном порядке.

1. Проверьте версии Trivy и GitHub Actions

Откройте ваши workflow-файлы (.github/workflows/*.yml) и найдите использования trivy-action и setup-trivy. Обратите особое внимание на версии.

Статус версий на момент публикации (22.03.2026, 14:30 GMT+3):

2. Проанализируйте логи CI/CD на подозрительную активность

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

• Необъяснимые HTTP-запросы к неизвестным доменам или IP-адресам.
• Запросы к canister-контейнерам на блокчейне Internet Computer (ICP), это характерный признак CanisterWorm.
• Странное поведение переменных окружения, особенно GITHUB_TOKEN и NPM_TOKEN.
• Подозрительные base64-кодированные строки в выводе, которые могут маскировать полезную нагрузку.

3. Проверьте npm-пакеты на заражение CanisterWorm

Если ваши npm-токены были скомпрометированы, злоумышленники могли опубликовать через них вредоносные версии ваших пакетов. CanisterWorm самораспространяется: каждый заражённый пакет пытается заразить другие пакеты, к которым имеет доступ.

Используйте инструменты для сканирования ваших npm-пакетов на наличие вредоносного кода, зарубежные кибербез-издания рекомендуют Socket.dev или Snyk.

Особое внимание стоит уделить пакетам, опубликованным или обновлённым в период с 19 по 22 марта 2026 года — именно в это время происходила первичная волна распространения CanisterWorm.

4. Проведите аудит учётных данных и токенов

Надо определить, какие секреты были доступны скомпрометированным workflow. Проверьте следующие категории токенов:

GITHUB_TOKEN — автоматически предоставляется workflow → доступ к репозиторию и коду
NPM_TOKEN — публикация npm-пакетов → публикация вредоносных версий
DOCKER_USERNAME/PASSWORD — публикация контейнеров → компрометация образов
AWS_ACCESS_KEY_ID/SECRET — доступ к облаку → несанкционированный доступ к инфраструктуре

Как защитить CI/CD пайплайн: практическое руководство

1. Немедленно ротируйте все секреты

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

Последовательность действий:

1. Сгенерируйте новые токены для всех сервисов (GitHub, npm, Docker Hub, AWS и других).
2. Обновите секреты в настройках репозитория
3. Проверьте, что новые токены работают корректно (запустите тестовый workflow).
4. Отзовите старые токены.

2. Закрепляйте версии GitHub Actions через SHA-хеши

Вместо тегов используйте неизменяемые ссылки по SHA-хешу. Это один из наиболее эффективных методов защиты от атак на зависимости.

Для получения SHA-хеша конкретной версии перейдите на страницу релиза или используйте команду git ls-remote для получения хеша конкретного тега.

3. Реализуйте принцип минимальных привилегий для GITHUB_TOKEN

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

• Отключите запись, если workflow только читает данные
• Используйте блок permissions в каждом workflow для явного указания требуемых прав
• Не передавайте токен в шаги, которым он не нужен

4. Защитите pull_request_target

Этот тип триггера особенно опасен: workflow выполняется в контексте базовой ветки с доступом к секретам. Если вам необходим pull_request_target, применяйте следующие меры защиты:

Никогда не выполняйте код из PR в контексте с секретами — сначала проверяйте источник.

Используйте явные проверки на доверенные источники перед выполнением кода.

Рассмотрите альтернативные паттерны запуска workflow, например pull_request вместо pull_request_target.

Изолируйте привилегированные операции в отдельные workflow с ограниченным доступом.

5. Настройте мониторинг и оповещения

Настройте мониторинг на все критичные точки входа в ваш CI/CD процесс:

• Уведомления о необычных workflow-запусках — особенно в нерабочее время или из незнакомых источников.
• Алерты на подозрительные исходящие запросы из CI/CD (особенно на неизвестные домены и IP).
• Контроль публикаций пакетов — отслеживайте, кто, когда и откуда публикует пакеты в ваши реестры.

А ещё чистите зубы, мойте руки с мылом и надевайте шапку.

Технические детали для юных детективов: как сработали атаки на Trivy

Бот hackerbot-claw

Инцидент начался 27 февраля 2026 года, когда автономный бот hackerbot-claw создал Pull Request #10252 в репозитории Trivy. Бот эксплуатировал workflow с использованием pull_request_target, который позволял выполнить произвольный код в контексте с доступом к секретам репозитория.

Результат атаки — скомпрометированное VSCode-расширение Trivy. Версия 1.8.12, попавшая в Open VSIX Registry, содержала вредоносный код, который выполнял следующие действия:

1. Собирал конфиденциальные данные из среды разработки пользователя.
2. Эксфильтрировал украденные данные на командный сервер злоумышленников.
3. Создавал персистентный бэкдор для повторного доступа.

NVD зарегистрировала инцидент как CVE-2026-28353 с оценкой CVSS 10.0 — максимально возможной оценкой, указывающей на полную компрометацию информационной безопасности.

Ретроактивное отравление тегов

Группа TeamPCP получила write-доступ к репозиторию Trivy через скомпрометированные учётные данные, украденные в первом инциденте.

Ключевая инновация атаки — ретроактивное отравление тегов. Атакующие не просто опубликовали новую вредоносную версию — они переместили 76 из 77 существующих тегов так, чтобы те указывали на вредоносный код. Это означает, что под удар попадает любой пользователь, который:

• Использовал trivy-action@latest
• Использовал конкретную версию через тег
• Фиксировал зависимости через теги

CanisterWorm: блокчейн как командный сервер

Отдельного внимания заслуживает CanisterWorm — малварь, распространившаяся через скомпрометированные npm-токены.

Ключевые особенности CanisterWorm:

1. Использование блокчейна Internet Computer (ICP) как C2-сервера — децентрализованная инфраструктура, устойчивая к традиционным методам блокировки доменов и IP-адресов.
2. Автоматическое распространение — каждый заражённый пакет пытается заразить другие пакеты в экосистеме.
3. Кража токенов из среды разработчиков и CI/CD окружения для расширения сферы влияния.
4. Персистентный бэкдор для повторного несанкционированного доступа.

FAQ / TLDR

Как проверить, использовал ли я скомпрометированную версию Trivy?

Проверьте ваши workflow-файлы в .github/workflows/*.yml на наличие версий v0.69.4 для Trivy или любых версий для trivy-action от 19 марта 2026 года. Также проверьте логи CI/CD на подозрительную активность: исходящие запросы к неизвестным доменам, особенно к canister-контейнерам на ICP.

Что делать, если я обнаружил компрометацию?

Немедленно ротируйте все секреты, которые передавались в workflow, отдельное внимание уделите GITHUB_TOKEN и NPM_TOKEN. Проверьте npm-пакеты на заражение CanisterWorm с помощью Socket.dev или Snyk. Проведите аудит всех публикаций в реестры за период с февраля по март 2026 года.

Почему атака на сканер уязвимостей особенно опасна?

Инструменты безопасности работают с максимальными привилегиями в инфраструктуре. Они имеют доступ к коду, секретам и конфиденциальным данным. Компрометация инструмента безопасности даёт злоумышленнику всё то, что этот инструмент защищает — секреты CI/CD, код и доступ к инфраструктуре.

Как защититься от атак на зависимости в будущем?

Используйте SHA-хеши вместо тегов для закрепления версий зависимостей.

Применяйте принцип минимальных привилегий для всех токенов в CI/CD.

Настройте регулярную ротацию секретов.

Мониторьте исходящий трафик из CI/CD на предмет аномалий.

Проводите регулярный аудит зависимостей и их источников.

Материал подготовлен по открытым данным.

Основные источники: CrowdStrike, StepSecurity, Socket.dev, Ars Technica, Apache Foundation, Aikido Security, The Hacker News, NVD (CVE-2026-28353), GitHub Discussion #10265, Chainguard.

Solar appScreener разработан для повышения уровня кибербезопасности программного обеспечения путём комплексного анализа на каждом этапе жизненного цикла разработки. Согласно данным отчёта Solar 4RAYS за 2024 год, около 54% инцидентов связаны с уязвимостями веб-приложений.

Межсайтовый скриптинг, SQL-инъекция, неограниченная загрузка файла опасного типа, внедрение команды ОС, обход авторизации — всё это можно найти и исправить заранее. Solar appScreener объединяет статический анализ SAST, динамическое тестирование DAST и проверку сторонних библиотек OSA.

Главная инновация — AI-модули или Цифровые сотрудники, которые работают даже без доступа в Интернет, обучаемые на протяжении семи лет. Они не просто помогают обрабатывать найденные уязвимости, но и сами генерируют исправленный код. Большинство предложенных исправлений разработчики принимают без доработок.

Параметры проекта

История: продукт начал свою историю 10 лет назад внутри российского стартапа. Сегодня поддерживает 36 языков программирования — ABAP, Apex, ASP.NET, COBOL, С#, C/C++, Objective-C, Dart, Delphi, Go, Groovy, HTML5, Java, Java for Android, JavaScript, JSP, Kotlin, LotusScript, Pascal, Perl, PHP, PL/SQL, T/SQL, Python, Ruby, Rust, Scala, Solidity, Swift, TypeScript, VBA, VB.NET, VBScript, Visual Basic 6.0, Vyper, 1C

Анализ бинарных файлов 10 форматов — JAR, WAR, EAR, AAR, DLL, EXE, APK, AAB, IPA, APP

Обучение ИИ: семь лет на тренировку модулей DerTriage AI и DerCodeFix AI

Задача: найти уязвимости в ПО до того, как их найдут хакеры

Какие проблемы можно решить с помощью анализа кода?

1. Избежать финансовые потери: Большинство инцидентов, связанных с кибератаками связано с недостаточной защитой веб-приложений и программного обеспечения, что ведет к значительным финансовым убыткам у компаний. Даже одна уязвимость – может стать причиной, по которой хакеры проникнут в контур компании, где вы работаете.
2. Потеря доверия клиентов: Атаки хакеров негативно влияют на репутацию бренда и доверие потребителей.
3. Несоблюдение нормативных требований: Компании сталкиваются с необходимостью соответствовать строгим требованиям регуляторов, игнорирование которых влечет серьезные последствия.
4. Повышенная нагрузка на команду: Недостаточная автоматизация процессов выявления уязвимостей увеличивает нагрузку на разработчиков, DevSecOps-инженеров и сотрудников информационной безопасности.

Российский рынок характеризуется особыми рисками, такими как целенаправленные атаки на отечественные информационные системы. Использование open-source-библиотек несет дополнительные опасности. Например, деструктивные действия со стороны отдельных представителей open source сообщества. Отсутствие регулярных проверок повышает вероятность появления закладок или слабых мест, что подчеркивает необходимость внедрения специализированных инструментов вроде Solar appScreener.

Архитектура решения

В архитектуре три главных инструмента:

1. OSA (Open Source Analysis): анализ стороннего кода выявляет известные зависимости, проверяет лицензии open-source-библиотек и выявляет риски использования компонент на основании поведения авторов, обеспечивая безопасность поставок и юридическую чистоту проекта.
2. SAST (Static Application Security Testing): Статический анализ обнаруживает уязвимости в исходном коде с первых этапов разработки. Цифровые сотрудники — компоненты, помогающие обрабатывать результаты сканирования основанные на технологии машинного обучения.
3. DAST (Dynamic Application Security Testing): Динамическое тестирование анализирует веб-приложения и ПО, отправляя заведомо неверные данные и проверяя реакцию приложения на них.

Каждый метод дополняет друг друга, создавая комплексную систему анализа. Дополнительно платформа интегрируется с CI/CD-конвейерами, что позволяет минимизировать ручную работу и повысить скорость развертывания обновленных версий.

Ключевые инновации и технические решения номинированного продукт

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

Почему AppScreener выигрывает:

• Избавление от ложных срабатываний

Проблема ложных срабатываний в инструментах SAST стала камнем преткновения для многих команд. Однако интеллектуальные Цифровые сотрудники решают её окончательно. За счёт семилетнего обучения эти модули мгновенно фильтруют лишние предупреждения, оставляя лишь критически важные уязвимости, нуждающиеся в исправлении. А также предлагают исправленные участки кода для найденной уязвимости. При этом большинство предложенных исправлений принимается без доработок от разработчиков и AppSec-команд.

• Увеличение скорости разработки

Производительность вашей команды растет экспоненциально. Вместо недель ожидания отчётов и кучи задач - теперь отчёт доступен буквально за считанные минуты. Исправления уязвимостей занимают секунды, а не дни. Все это способствует значительному снижению сроков вывода продуктов на рынок (time-to-market) и одновременно сохранению высокого уровня безопасности.

• Интеграция с современной средой разработки

AppScreener идеально встраивается в существующие CI/CD конвейеры и рабочие среды, обеспечивая максимальную совместимость и комфорт для разработчиков. Инструмент легко адаптируется к любым условиям, будь то небольшой стартап или крупная корпорация.

• Уникальная инфраструктура и надежность

Наш продукт разработан в России и прошел самую жесткую сертификацию. Мы предлагаем поддержку широкого спектра популярных языков программирования, в том числе написанных на “устаревших” языках. Это делает AppScreener незаменимым инструментом для компаний любого масштаба.

Основные преимущества AppScreener заключаются в интеграции передовых методов анализа и автоматизации процесса устранения уязвимостей.

Путь от стартапа до стандарта рынка

Продукт начал свою историю внутри российского стартапа, занимающейся консультированием по вопросам безопасности. Команда начала развивать идею продукта в сегменте application security. Процесс включал исследования и разработки, которые в итоге завершились созданием эффективного инструмента для анализа программного обеспечения и приложений. Ряд сотрудников Солар, благодаря своей работе получили научные степени.

Результаты: скорость и экономия

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

1. Экономия ресурсов: Раннее выявление и быстрое исправление уязвимостей экономит средства, необходимые для ликвидации последствий серьезных инцидентов.
2. Оптимизация бюджета: Сокращение количества ложных срабатываний за счет новых разработок снижает расходы на обработку данных и привлечение квалифицированных специалистов.
3. Увеличение скорости вывода продукта на рынок: благодаря автоматизированному исправлению ошибок, новые версии продуктов выходят быстрее, сохраняя высокое качество.

Эти показатели подтверждают эффективность инструмента и способствуют повышению конкурентоспособности бизнеса.

Отзывы клиентов

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

Планы развития

Команда продолжает развивать Solar appScreener, проводя совместные исследования, интересные рынку. Запущена первая в России премия по безопасной разработке совместно с Ассоциацией ФинТех и сообществом FinDevSecOps. В планах — дальнейшее обучение ИИ-моделей.

Реклама. АО «Солар Секьюрити», ИНН 9714069290, erid: 2W5zFJQwYmo

Я, Иван Глинкин, руководитель группы аппаратных исследований в Бастионе, автор канала HydrAttack, продолжаю обучающий цикл для начинающих «белых» хакеров. Мы уже выбрали дистрибутив Линукса для хакинга и успешно установили его — пора начать с ним работать. Сегодня мы научимся пользоваться командной строкой, ведь именно так раскрывается вся сила Линя (Linux). Командная строка в Linux позволяет управлять всей операционной системой: выполнять скрипты, запускать команды, управлять папками и файлами, настраивать систему и пр. Если вы не знаете базовые команды — вы не знаете Linux.

man

Вы наверняка слышали выражение из компьютерной и геймерской культуры «курить маны». Оно используется в шутливом контексте среди сисадминов и программистов в тех случаях, когда кто-то пытается разобраться с трудными техническими аспектами с помощью мануалов. Это своего рода «хакерский» сленг, который обозначает процесс самообучения через официальные документы и инструкции. В Unix-подобных ОС такая документация называется man-страницами.

Программа man (от англ. "manual ", руководство) — это утилита, которая предоставляет доступ к справочной документации по различным командам, программам, системным вызовам и конфигурациям системы. Она предназначена для того, чтобы пользователи могли быстро получить информацию о функциональности и параметрах программ прямо из командной строки.

При вызове программы man пользователь указывает имя команды, по которой он хочет получить справочную информацию, например, man ls:

Если вы не уверены в точном названии команды, можно использовать ключ -k или утилиту apropos, чтобы найти все команды, связанные с определенным ключевым словом: man -k network:

Программа man — мощный инструмент для быстрого поиска справочной информации, он помогает пользователям и администраторам эффективно задействовать системы на базе Linux или других Unix-подобных ОС.

cat

Программа cat (от "concatenate", конкатенация, т.е. сцепление) — это одна из наиболее часто используемых утилит в Linux. Ее основная задача — считывать содержимое одного или нескольких файлов и выводить его в терминал. Имеет также несколько дополнительных функций, которые делают ее полезной в разных сценариях.

cat может соединять несколько файлов в один, что отражает ее название "concatenate":

cat может отображать содержимое файла с нумерацией строк при помощи флага:

Дополнительные опции:

● -n — выводит нумерацию строк;

● -s — подавляет вывод пустых строк;

● -b — нумерует только непустые строки;

● -T — отображает табуляции в виде символов ^I;

● -v — отображает непечатаемые символы.

ls

Команда ls (от "listing", список) — одна из самых часто используемых команд в Linux. Она предназначена для вывода списка содержимого директории, то есть файлов и подкаталогов. Команда ls очень гибкая, она поддерживает множество опций для изменения формата вывода и сортировки данных.

Если не указывать каталог, то по умолчанию ls покажет содержимое текущего рабочего каталога:

Опция -l (long format) выводит информацию о каждом файле или каталоге в более подробном виде, включая права доступа, владельца, группу, размер и время последней модификации:

Файлы и директории, имена которых начинаются с точки (.), считаются скрытыми. Опция -a покажет также и скрытые файлы:

При использовании флага -h с -l размер файлов будет отображаться в более привычном формате (кБ, МБ и т.д.):

Флаг -R позволяет рекурсивно просматривать содержимое подкаталогов:

pwd

Команда pwd (от "print working directory", вывести рабочий каталог) — это утилита, которая выводит полный путь к текущему рабочему каталогу. Она особенно полезна для определения местоположения в файловой системе, когда выполняется работа в командной строке.

Когда вы используете команду pwd, она возвращает полный абсолютный путь к директории, в которой вы находитесь в данный момент.

Команда всегда выводит полный путь, начиная с корневого каталога. Это помогает точно определить текущее местоположение в файловой системе.

cd

Команда cd (от "change directory", смена каталога) — одна из базовых команд, которая используется для перемещения между директориями в файловой системе.

Чтобы перейти в определенный каталог, необходимо указать его путь:

Домашний каталог пользователя — это каталог, в котором пользователь находится при первом входе в систему. Чтобы вернуться в него, достаточно просто ввести команду cd без аргументов или cd ~

Чтобы вернуться на один уровень выше в иерархии каталогов, применяется команда cd ..

mkdir

Команда mkdir (от "make directory", создание каталога) — это утилита для создания новых директорий в файловой системе.

Основная задача команды — создать новый каталог по указанному пути. Например:

Можно создать сразу несколько каталогов, передав их имена через пробел:

Если нужно создать вложенную структуру директорий, а родительские каталоги еще не существуют, флаг -p создаст их автоматически:

rm

Команда rm (от "remove", удалить) — это утилита, которая используется для удаления файлов и директорий. Команда представляет собой мощный инструмент, при неосторожном использовании которого можно случайно уничтожить важные файлы без возможности восстановления.

Для удаления файла просто укажите его имя:

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

Для удаления директории с ее содержимым (файлы и подкаталоги) необходимо использовать флаг -r (рекурсивное удаление).

Флаг -f (force) позволяет удалять файлы и директории без запроса на подтверждение, даже если у них установлены ограничения доступа:

rm -rf directory_name

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

Если вы хотите, чтобы система запрашивала подтверждение перед удалением каждого файла, используйте флаг -i:

which

Команда which (от англ. который, чей) используется для поиска местоположения исполняемых файлов команд. Она выводит путь к файлу, который будет выполнен. Это полезно для выяснения того, где находятся программы или скрипты и какой из нескольких возможных вариантов будет запущен.

Команда which ищет исполняемый файл команды в каталогах, перечисленных в переменной окружения PATH (о ней — позже). Например:

Если одна и та же команда существует в нескольких местах, можно использовать опцию -a, чтобы отобразить все ее возможные местоположения:

Команда which показывает только те команды, которые находятся в каталогах, указанных в переменной окружения PATH. Если команда существует в другом каталоге, который не указан в PATH, which ее не найдет.

whoami, id

Команда whoami (от англ. "who am i" — кто я) выводит имя пользователя, под которым в данный момент выполняется сессия. Это полезно, чтобы узнать, под каким пользователем запущена текущая сессия, особенно, если были выполнены команды для смены пользователя.

Команда id используется для отображения информации о пользователе, включая идентификатор пользователя (UID), идентификатор группы (GID), а также список всех групп, к которым принадлежит пользователь.

При выполнении команды id без опций выводится информация о текущем пользователе.

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

locate

Команда locate (локация) используется для быстрого поиска файлов и каталогов в файловой системе. Она работает на основе предварительно созданной базы данных, которая содержит информацию о расположении файлов на диске.

Команда имеет простой синтаксис:

Поиск не зависит от регистра, т.е. команда locate myfile найдет файлы как с именем myfile, так и с именами MyFile, MYFILE и т.д.

Можно использовать опции для фильтрации результатов. Например, -i для игнорирования регистра или -r для регулярных выражений.

Для обновления базы данных используется команда updatedb, которая обычно выполняется по расписанию с помощью cron, однако вы можете запустить ее вручную, если хотите получить свежие данные.

find

Команда find (найти) используется для поиска файлов и каталогов в файловой системе с учетом различных критериев. Она более мощная и гибкая, чем locate, но может работать медленнее, так как выполняет поиск в реальном времени.

find позволяет использовать различные критерии для поиска, такие как имя файла, тип, размер, дата модификации и права доступа.

Также можно искать файлы, каталоги, символьные ссылки и т.д. с помощью опции -type:

Примеры использования:

● поиск файла по имени: find /path/to/search -name "filename";

● поиск всех текстовых файлов: find . -type f -name "*.txt";

● поиск файлов, измененных за последние семь дней: find /path/to/search -mtime -7.

grep

Команда grep (от "Global regular expression print" — вывод глобальных регулярных выражений) в Linux используется для поиска текстовых строк, соответствующих заданному шаблону, в файлах или входных данных. Это один из самых мощных инструментов для обработки текста и анализа данных.

С помощью опции -i можно игнорировать регистр при поиске:

Опция -n выводит номера строк, в которых найден шаблон:

Опция -r позволяет искать в подкаталогах.

grep поддерживает регулярные выражения, что позволяет создавать сложные шаблоны. Например, grep "^abc" ищет строки, начинающиеся с "abc".

sudo

Команда sudo (от англ. "substitute user and do" — подменить пользователя и выполнить) в Linux используется для выполнения команд с привилегиями суперпользователя (root) или других пользователей, заданных в конфигурационном файле /etc/sudoers. Это позволяет пользователям выполнять административные задачи, не входя в систему как root.

При первом использовании sudo в сессии пользователю будет предложено ввести свой пароль для подтверждения прав.

Конфигурация доступа для пользователей и групп определяется в файле /etc/sudoers. Можно задать, какие команды может выполнять конкретный пользователь или группа. sudo записывает все выполненные команды и их результаты в системные журналы, что помогает отслеживать действия пользователей с повышенными правами.

Опции:

● -u — позволяет указать, от имени какого пользователя выполнять команду;

● -i — запускает командную оболочку с правами root, аналогично входу в качестве root;

● -s — запускает командную оболочку с сохранением текущих переменных окружения.

su

Команда su (от англ. "substitute user" — подменить пользователя) предназначена для смены пользователя в командной строке. Обычно она используется для входа в систему в качестве суперпользователя (root) или для перехода на другого пользователя без выхода из текущей сессии. При использовании su для переключения на другого пользователя (особенно на root) потребуется ввести пароль этого пользователя.

Можно использовать su для выполнения одной команды от имени другого пользователя, добавив параметр -c.

sed

Команда sed (от "stream editor", редактор потоков) в Linux используется для обработки и трансформации текстовых данных в потоковом режиме. Она особенно полезна для выполнения автоматических замен, редактирования и фильтрации текстовых файлов.

Можно использовать несколько команд, разделяя их точкой с запятой:

Можно выполнять действия только на определенных строках, используя адресацию. Например, чтобы заменить текст только на строке 2:

Примеры использования

● замена текста в файле: sed 's/apple/orange/g' fruits.txt;

● замена текста только в первых 10 строках: sed '1,10s/old/new/g' filename.txt;

● удаление пустых строк: sed '/^$/d' filename.txt.

cut

Команда cut (вырезать) используется для извлечения определенных частей текста из строк файла или стандартного ввода. Она полезна для работы с табличными данными, где информация структурирована в виде строк и столбцов.

Опции

● -d — задает разделитель (по умолчанию — символ табуляции). Например, для запятой: -d “ ,”;

● -f — указывает, какие поля извлекать. Можно указать одно поле, несколько полей или диапазон, например: -f 2;

В данном случае наш разделитель «пробел», и мы извлекаем данные 2 между первым и вторым пробелами.

● -c — извлечение символов по позициям. Например, для извлечения первых пяти символов: -c 1-5.

awk

awk (первые буквы фамилий разработчиков языка: Aho, Weinberger, Kerninghan) — это утилита в Linux, используемая для обработки текстовых данных и автоматизации задач, связанных с анализом и формированием текстов. awk часто применяется для работы с табличными данными, где информация представлена в виде строк и столбцов.

awk поддерживает регулярные выражения, что позволяет отфильтровать строки по шаблону. Имеет несколько встроенных переменных, таких как NR (номер текущей строки) и NF (количество полей в текущей строке).

С помощью функции printf можно форматировать вывод так же, как в языке C.

Вывод первого и третьего полей каждой строки: awk '{print $1, $3}' filename.txt

awk '{printf "Field1: %s, Field2: %s\n", $1, $2}' filename.txt

awk — мощный инструмент для текстовой обработки в Linux, позволяющий выполнять сложные операции с данными, анализировать текстовые файлы и генерировать отчеты.

comm

Команда comm (от англ. "comparison" — сравнение) в Linux используется для сравнения двух отсортированных файлов построчно. Она показывает строки, которые уникальны для каждого из файлов, а также строки, которые присутствуют в обоих файлах. Это полезно для анализа различий и сходств между двумя текстовыми файлами.

comm принимает два отсортированных файла и выводит три колонки:

1. строки, уникальные для первого файла;
2. строки, уникальные для второго файла;
3. строки, общие для обоих файлов.

Опции:

● -1 — не выводить первую колонку (уникальные строки первого файла);

● -2 — не выводить вторую колонку (уникальные строки второго файла);

● -3 — не выводить третью колонку (общие строки);

● -i — игнорировать регистр при сравнении строк.

Вывод только уникальных строк первого и второго файлов:

diff

Команда diff (от англ. "difference" — разница) используется для сравнения файлов и отображения различий между ними. Она может сравнивать как текстовые файлы, так и каталоги. Предоставляет информацию о том, какие строки были добавлены, удалены или изменены.

Для сравнения с контекстом используется ключ -c:

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

Мы из Красноярска (да, из Сибири). Пару месяцев назад по просьбе спасателей сделали GPSki — приложение, чтобы обмениваться геокоординатами через SMS там, где нет интернета. P2P, никаких серверов для слежки, всё честно. Запустились в RuStore, получили первые позитивные отзывы и… тут началось.

Блок 1: Атака ложноположительных

В один день пользователи завалили нас скриншотами. Встроенный сканер «СберБанк Онлайн» с дикой серьёзностью писал, что наше безобидное приложение — это…

… и его срочно нужно удалить.

Наступила классическая пятиминутка паники:

• Репутация проекта, который мы выстраивали, пошла крахом.
• Пользователи в ужасе удаляли приложение.
• Поддержка захлебнулась.

Первым делом связались со Сбером. Их поддержка вежливо сообщила, что используют базы «Лаборатории Касперского». Стало ясно: ругаться с банком бессмысленно, надо идти к источнику сигнала.

Блок 2: Тактика: не скандалить, а забросать фактами

Да, можно было громко трясти статьёй 152 ГК РФ о защите репутации. Но мы решили, что быстрее и эффективнее будет поговорить с инженерами на их языке.

Мы собрали не письмо с эмоциями, а полное техническое досье:

1. APK-файлы текущей и новой версий.
2. Видеозапись экрана, где чётко видно ложное срабатывание — железобетонный proof.
3. Подробное описание логики работы: зачем нужны разрешения на SMS, как мы обеспечиваем приватность (читаем только сообщения с особой меткой).
4. Ссылка на RuStore как главный аргумент легитимности.

Отправили этот пакет через форму поддержки Касперского с запросом на проверку False Positive.

Блок 3: Развязка и чек-лист для таких же как мы

Через несколько дней пришёл ответ. Короткий и ясный:

Это было ошибочное срабатывание. Оно будет исправлено.

Вот и всё. С этим ответом мы вернулись к диалогу со Сбером.

Итоговый чек-лист, который сэкономит вам нервы:

Итог

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

P.S. Респект аналитикам «Лаборатории Касперского» за оперативный и честный разбор. И огромное спасибо нашим пользователям, которые не стали молча удалять приложение, а написали нам.

Но вместе с ростом популярности подхода, возник и главный вопрос: насколько безопасен код, который генерирует ИИ-агент?

Исследование показало: функционально — да, безопасно — нет

Ученые из Carnegie Mellon, Columbia и Johns Hopkins выпустили первое крупное исследование безопасности вайб-кодинга.

Они создали собственный бенчмарк SUSVIBES, состоящий из 200 настоящих задач с GitHub-проектов, где ранее были реальные уязвимости (77 видов CWE).

Каждая задача требует внедрения фичи в живой репозиторий размером в сотни тысяч строк. Это максимально приближено к реальной работе.

Далее они протестировали популярных агентов: SWE-Agent, OpenHands и Claude Code. Все они использовали самые свежие ИИ-модели вроде Claude 4 Sonnet, Gemini 2.5 Pro и Kimi K2.

Результаты оказались тревожными:

• 61% решений от лучшей связки (SWE-Agent + Claude 4 Sonnet) — функционально корректны.
• Но только 10,5% — безопасны.
• Иными словами: около 90% рабочего кода, который агент считает «готовым», содержит уязвимости.

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

Какие уязвимости генерируют ИИ-агенты

Исследователи обнаружили весь спектр проблем:

• утечки данных и неправильная обработка паролей;
• XSS и небезопасные URL-редиректы;
• ошибки верификации сессий;
• тайминг-атаки;
• отсутствие проверки входных данных.

Что характерно, в реальных задачах агенты часто пишут код, который выглядит вполне логично. Но они все же упускают один-два критичных условия, создавая легко эксплуатируемые уязвимости.

На визуальных примерах в исследовании видно, что даже маленькие фрагменты вроде verify_password или URL-редиректа превращаются в брешь безопасности, если агент пропускает один шаг — например, нормализацию данных или сравнение времени выполнения.

Вывод

Исследователи подчеркивают: вайб-кодинг полезен для увеличения продуктивности, но категорически непригоден без ручного ревью безопасности.

Особенно это касается тех проектов, которые работают с данными пользователей, авторизацией, сессиями, API или любыми критичными процессами.

ИИ-агент может написать фичу, пройти тесты и выглядеть уверенно. Но с вероятностью около 80–90% там останется дыра, которая в реальной среде превратится в эксплойт.

США до сих пор живут без единого федерального закона о защите персональных данных. Но в 2024–2025 годах появились первые реальные шаги: регуляторы начали штрафовать брокеров, торгующих локацией пользователей, а штаты принимают собственные законы.

Разбираем, что происходит с приватностью, кто на самом деле зарабатывает на наших данных — и почему новая волна ИИ делает вопрос личной информации критическим.

Начнем с того, что есть сейчас

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

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

Всё это превращается в детальные досье — персонализированные профили, которые можно покупать и продавать. И чаще всего — без нашего участия и согласия.

Почему это важно

В США растёт консенсус: людям нужны реальные механизмы защиты персональных данных. И единственный способ это обеспечить — принять единый федеральный закон о приватности.

На бумаге такой закон уже существует — American Privacy Rights Act of 2024. Он должен был стать первым крупным прорывом в этой сфере, но… по мере согласований документ настолько упростили, что в итоге он потерял поддержку и республиканцев, и демократов — так и не дойдя до голосования в Конгрессе.

Если бы Россия шла тем же путём, это было бы примерно как принять аналог GDPR, но потом прописать столько исключений, что его можно не соблюдать вовсе. Так и случилось с американским законом: пока обсуждают, кто должен отвечать за защиту данных — компании, пользователи или государство — данные продолжают утекать и продаваться.

Кто торгует нашими данными — и почему это всё ещё законно

За последние месяцы в США появились первые подвижки — пусть и локальные. Государственные регуляторы начали ограничивать возможности дата-брокеров — третьих компаний, которые собирают и перепродают личные данные: от истории покупок до геолокации.

Например, в декабре Федеральная торговая комиссия (FTC) заключила соглашения с двумя такими брокерами — Mobilewalla и Gravy Analytics (включая дочернюю Venntel). Проверка показала, что эти компании продавали информацию о местоположении пользователей, включая координаты больниц, церквей и даже военных баз, — без какого-либо согласия. Теперь им запретили перепродавать подобные данные, за редким исключением.

Это стало продолжением целой серии дел: в 2024 году FTC уже несколько раз штрафовала брокеров за торговлю геоданными, а Минюст предложил запретить продажу «оптом» таких данных иностранным компаниям.

В тот же день, когда FTC объявила о сделках, другое ведомство — Бюро финансовой защиты потребителей (CFPB) — предложило приравнять дата-брокеров к статусу кредитных бюро. Если эта норма вступит в силу, брокеры будут обязаны раскрывать источники и цели сбора данных, а также соблюдать те же стандарты отчётности и защиты, что и банки.

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

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

Сколько вообще таких компаний?

Никто не знает точно. Эксперты оценивают, что в мире работает от 4 до 5 тысяч дата брокеров — причём названия и структуры этих компаний постоянно меняются.

В одной только Калифорнии официальный реестр 2024 года насчитывает 527 зарегистрированных брокеров, из которых около 90 признались, что собирают геолокационные данные.

И все эти данные можно купить.

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

Даже иностранные структуры спокойно покупают сведения о военных или госслужащих США.

А на сайтах по поиску людей можно заплатить и получить контакты и подробности практически о любом.

Анонимизация, которой никто не верит

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

Вспомните продажу баз автономеров или данных из Delivery Club. Формально все обезличены, но на практике всегда можно восстановить личность по нескольким косвенным признакам. Американская проблема — та же, только в масштабе континента.

Как государство пытается изменить индустрию данных

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

Например, конгрессвумен-республиканка Кэти Макморрис Роджерс, глава комитета по энергетике и торговле, возмущалась тем, что Центры по контролю заболеваний (CDC) покупали данные о передвижениях граждан, чтобы анализировать эффективность локдаунов во время пандемии.

Суд, который перевернул разговор о приватности

Но настоящая встряска для Вашингтона произошла после решения Верховного суда по делу Dobbs v. Jackson Women's Health Organization (2022), которое отменило конституционное право на аборт.

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

Реакция последовала быстро. Президент Джо Байден подписал исполнительный указ о защите доступа к репродуктивной медицине.

Документ поручил Федеральной торговой комиссии (FTC) разработать меры, которые не позволили бы компаниям передавать данные о посещениях медицинских учреждений и аборт-клиник в руки правоохранительных органов или прокуроров.

Новая администрация и угроза отката регулирования

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

Это значит, что судьба всех инициатив по защите данных — под вопросом. В частности, CFPB (Бюро финансовой защиты потребителей), которое предложило приравнять дата брокеров к кредитным бюро, может просто перестать существовать.

Республиканцы давно недолюбливают CFPB

Среди тех, кто призывает удалить бюро, — люди из проекта Project 2025, а также Илон Маск, назначенный Трампом главой нового консультативного органа с ироничным названием — Department of Government Efficiency (Департамент эффективности правительства).

Формально для ликвидации CFPB потребуется закон Конгресса, что вряд ли произойдёт быстро. Но есть и другой путь — Трамп, скорее всего, уволит нынешнего директора и поставит лояльного республиканца, который сможет отменять существующие правила и блокировать новые инициативы.

FTC — беззубый регулятор?

То же самое может коснуться и Федеральной торговой комиссии (FTC). Как объясняет Бен Уинтерс, бывший сотрудник Минюста и директор направления ИИ и приватности в Consumer Federation of America, решения FTC сами по себе не создают прецедента, как судебные.

Чтобы индустрия реально испугалась, нужны постоянные и последовательные проверки — иначе компании быстро поймут, что можно проскочить.

Кроме того, нынешние дела FTC касаются в основном геолокационных данных — а ведь это только малая часть всего, что собирают и перепродают брокеры.

Что будет после ухода Лины Хан

Ключевая фигура последних лет — Лина Хан, нынешняя глава FTC, — уже подтвердила, что покидает пост. Она стала символом нового курса в защите приватности: именно при ней комиссия начала впервые бить по брокерам, а не по мелким сайтам.

Её сменит Эндрю Фергюсон, выбранный Трампом новый председатель FTC.

Фергюсон известен тем, что критиковал дата-брокеров, называя торговлю геолокацией «вторжением в личную жизнь в самой прямой форме». Но у него есть оговорка: Фергюсон против того, чтобы FTC заменяла собой Конгресс. То есть он не хочет, чтобы ведомство издавало квази-законы вместо законодателей.

А значит — если Конгресс не примет федеральный закон о приватности (а пока всё к этому идёт) — реальных изменений может не быть.

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

Когда федеральный закон не работает — штаты берут всё в свои руки

Пока Конгресс буксует с федеральным законом о приватности, отдельные штаты начали выстраивать собственные правила игры.

И этот процесс уже стал массовым. В 2025 году в силу вступают восемь новых законов о защите данных — и общее их количество по стране достигнет 25.

Ещё несколько штатов, включая Вермонт и Массачусетс, готовят свои варианты на следующий год.

Пока все законы примерно похожи — их можно соблюдать без катастрофических затрат. Но если хотя бы один штат примет достаточно отличающуюся норму, бизнес просто не выдержит — и тогда федеральный закон станет неизбежным способом упростить жизнь компаниям

Регистрация дата-брокеров и первые реальные проверки

Некоторые штаты уже пошли дальше общих принципов и приняли специальные законы о брокерах данных.

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

Это позволяет хотя бы понять масштаб индустрии и формально ограничить продажу самых чувствительных категорий данных.

Сбор данных под предлогом безопасности

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

Когда государство покупает данные у бизнеса

Многие брокеры, включая Venntel (дочку Gravy Analytics, которую недавно наказала FTC), уже продавали геолокационные данные иммиграционным и пограничным службам — ICE и CBP.

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

Фактически, власти просто покупают данные, которые им нельзя было бы получить по ордеру, — и таким образом обходят конституционные гарантии.

Закон, который может всё изменить

ACLU и другие правозащитные организации уже несколько лет продвигают законопроект под названием The Fourth Amendment Is Not For Sale Act — в переводе "Четвёртая поправка не продаётся".

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

Если закон примут, государство больше не сможет обходить требования Конституции, просто оплачивая доступ к базам.

В апреле 2024 года этот законопроект прошёл Палату представителей — его поддержали 123 республиканца и 93 демократа — но он застрял в Сенате. ACLU надеятся, что новый Конгресс всё же доведёт дело до конца, но многие эксперты настроены пессимистично.

Продавать свои данные ИИ?

Пока юристы спорят о законах и полномочиях, технологии не ждут.

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

В идеальном мире пользователи начнут зарабатывать на своих данных — ведь если модели ИИ обучаются на нашем контенте, тексте, поведении, почему бы не получить долю?

Но на практике компании уже начали искать способы обойти законы.

Пример — сделка Reddit и Google: $60 миллионов в год за право использовать пользовательский контент Reddit для обучения моделей ИИ. То есть теперь ваши посты, комментарии и даже мемы — это сырьё для машинного обучения.

Регуляторы пытаются реагировать

В 2024 году FTC выпустила предупреждение для компаний: любые скрытые изменения в политике конфиденциальности, которые позволяют использовать пользовательские данные для обучения ИИ, могут быть признаны «нечестной и обманной практикой».

Но, как отмечают эксперты, всё снова упирается в людей, которые стоят у руля. Если в новом составе FTC не будет кого-то вроде Лины Хан, то даже самые жёсткие заявления останутся просто словами на сайте регулятора.

Что ждёт приватность в 2025 году

Ноябрь 2025-го. У них — новая администрация, новые технологии, но старая проблема: персональные данные американцев (а значит, и всех нас, чьи данные проходят через американские сервисы) по-прежнему легко купить.

Недавние решения FTC против брокеров вроде Mobilewalla и проект постановления CFPB — важные шаги вперёд. Но пока они касаются лишь узкого сегмента — геолокационных данных.

Остальная часть индустрии, от маркетинговых трекеров до ИИ-платформ, продолжает работать по принципу «собирай всё, что можно».

Что могут делать обычные пользователи

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

Как минимум —

• проверять настройки приватности в аккаунтах и приложениях,
• выключать историю геолокации,
• использовать шифрованные мессенджеры (Signal, Threema, Session — альтернатива WhatsApp и Telegram для тех, кому важна анонимность),
• и не соглашаться по умолчанию на сбор телеметрии или улучшение качества сервиса.

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

За последние годы атаки типа DDoS (Distributed Denial of Service) стали не просто вопросом «когда», а практически неизбежностью для многих компаний. Специалисты отмечают: «для организаций с высокой видимостью уже не вопрос если, а когда вас атакуют».

Главные изменения:

• Доступность инструментария «DDoS-as-a-Service» делает возможными атаки даже с небольшими знаниями.
• Атаки становятся быстрее, изощреннее, и все чаще выполняются автоматически. Например, могут запустить миллионы запросов за несколько минут – и даже прежде чем мониторинг сработает.
• Атакующие все чаще обходят простые фильтры: меняют URL, заголовки, куки, используют бот-сети с огромным географическим разбросом.
• Рост объемов: по данным Cloudflare, крупные атаки выросли экспоненциально за последние десять лет. Например, битрейт (Gbps) вырос с сотен Gbps до 5.6 Tbps к 2025 году.

Эти изменения обуславливают, почему устаревшие методы защиты уже не работают или работают слабо.

Почему традиционные решения уступают

Если раньше меры ограничивались фаерволами, CDN и простыми лимитами, то сегодня этого недостаточно. CDN или фаервол часто настроены по-умолчанию и дают лишь частичную защиту.

Атаки перешли с сетевого уровня на уровень приложений (Layer 7) – где они влияют на веб-сервисы и API, которые генерируют ключевой доход

Ключевые уязвимости:

• Блокировка по IP/ГЕО становится бессильной, когда источники атак меняются динамически.
• Статические правила (лимиты, капчи) не успевают реагировать на автоматизированные, быстрые атаки.
• Отслеживание только трафика без анализа поведения – позволяет атакам «проскальзывать» через кэши и защитные механизмы.

Современные подходы к защите в 2025 году

Как должна выглядеть эффективная защита от DDoS сегодня? Вот основные принципы:

1. Многоуровневая стратегия: защита должна быть на уровне edge (CDN), приложения и поведения. Например, скрытие исходного сервера, лимиты не только на динамические запросы, но и на кэш-контент; специальные правила против «cache-busting».
2. Анализ поведения и автоматизация: атаки идут очень быстро (в 2023 году 50 % атак длились менее 52 секунд). Поэтому вручную реагировать уже нельзя – требуется автоматизированная система, которая распознает паттерны: заголовки, время запросов, структура.
3. Инфраструктурные меры и глобальное распределение. Важно подчеркнуть значение глобальных anycast-сетей, автоматизированной фильтрации и подхода без лимитов на трафик («unmetered DDoS mitigation»).
4. Проактивный партнер и мониторинг: все домены через CDN, лимиты на кэш/некэш-трафик, мониторинг скрытых сигналов (например, странные запросы), наличие плана инцидентов.

Что это значит на практике. Рекомендации:

• Убедитесь, что ваша инфраструктура направляется через надежный CDN и исходные сервера не видны напрямую.
• Настройте лимиты и кэширование не только для типичного контента, но и для потенциально «обратных» точек: поиск, ошибки 404, динамика.
• Выбирайте решения с автоматическим анализом поведения, а не только статическими правилами.
• Проверяйте партнеров: способны ли они эффективно действовать без вашего ручного вмешательства и с минимальным влиянием на законный трафик.
• Рассмотрите услуги по защите от DDoS через специализированных провайдеров – на сайте https://stormwall.pro вы найдете соответствующие предложения, например защита для сайта https://stormwall.pro/products/website-ddos-protection.
• Не забывайте: защита – это не покупка и установка, а постоянная адаптация. Атаки эволюционируют и защита должна меняться вместе с ними.

Заключение

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

Если вы до сих пор полагаетесь лишь на базовый фаервол или CDN по-умолчанию, сейчас отличный момент пересмотреть подход и усилить защиту своих онлайн-сервисов.

Автор: Тео Леггетт, международный бизнес-корреспондент, The true cost of cyber attacks - and the business weak spots that allow them to happen

Первый день сентября должен был открыть один из самых активных периодов года для Jaguar Land Rover.

Это был понедельник, и запуск новых номерных знаков серии 75 (в Великобритании номерные серии выходят дважды в год и являются важным фактором спроса, поскольку покупатели хотят машину со свежим номером) предполагал всплеск покупательской активности.

На заводах в Солихалле и Хейлвуде, а также на моторном предприятии в Вулверхэмптоне персонал ожидал работы «в полный оборот».

Однако, когда утренняя смена прибыла на место, её отправили домой. Производственные линии с тех пор остаются остановленными.

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

Компания сотрудничает с разными экспертами по кибербезопасности и полицией для проведения расследования, но финансовый ущерб уже нанесён. Потери мировой выработки за более чем месяц стали фактом.

Аналитики оценивают убытки в 50 млн фунтов стерлингов в неделю.

Для компании, которая получила прибыль в размере 2,5 млрд фунтов стерлингов в прошлом финансовом году и принадлежит индийскому гиганту Tata Group, эти потери, вероятно, будут болезненными, но не смертельными.

Однако JLR — не единственный случай.

С начала этого года произошла целая волна кибератак, нацеленных на крупный бизнес, включая таких розничных ритейлеров, как Marks & Spencer и Co-op, а также поставщика ключевых систем для аэропортов.

Среди других громких жертв оказалась сеть детских садов Kido, а в прошлом году инциденты, связанные с Southern Water и компанией, предоставлявшей услуги по анализу крови для NHS (государственная система здравоохранения Великобритании), вызвали серьёзные опасения по поводу уязвимости критически важной инфраструктуры и услуг (в Великобритании NHS считается «сердцем» госуслуг, поэтому атака на поставщика лабораторных данных воспринимается как угроза национальному масштабу).

В целом, по оценкам государственного опроса о кибернарушениях, 612 000 предприятий и 61 000 благотворительных организаций по всей Великобритании стали целями атак.

Так сколько же стоят такие атаки для бизнеса и экономики?

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

Пирамида затронутых поставщиков

Особенность атаки такого масштаба, как та, что поразила JLR, заключается в том, насколько широко могут распространиться её последствия.

Компания находится на вершине пирамиды поставщиков, в которой — тысячи организаций. Они варьируются от крупных международных корпораций, таких как Bosch, до маленьких фирм с несколькими сотрудниками (в британской автомобильной индустрии множество узкопрофильных производителей деталей работают почти исключительно на одного заказчика), включая компании, полностью зависящие от JLR.

Для многих из этих фирм остановка производств представляла очень реальную угрозу их существованию.

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

Отраслевые аналитики выразили обеспокоенность тем, что если компании начнут банкротиться, небольшие сбои могут быстро перерасти в массовую волну — потенциально нанеся постоянный ущерб высокотехнологичной инженерной индустрии страны (имеется в виду риск цепной реакции, когда падение одного поставщика срывает производство других, и всё рушится каскадно).

Возобновление производства само по себе не означает, что кризис завершён.

Слишком поздно. Все наши компании прожили шесть недель с нулевыми продажами, но при этом с сохранением всех расходов. Сектор по-прежнему отчаянно нуждается в денежных средствах.

Российские киберпреступники или западные подростки

Недавний отчёт IBM, изучивший утечки данных примерно у 600 организаций по всему миру, показал, что средняя стоимость инцидента составляла 4,4 млн долларов (или 3,3 млн фунтов стерлингов).

Однако JLR далеко не единственный случай крупномасштабных кибератак. Атаки на Marks & Spencer и сеть супермаркетов Co-op в этом году оцениваются в 300 млн и 120 млн фунтов соответственно.

В апреле 2025 года злоумышленникам удалось получить доступ к IT-системам Marks & Spencer через стороннего подрядчика, вынудив компанию отключить некоторые сети (в Великобритании использование subcontractors широко распространено, и цепочка доверия часто становится уязвимостью).

Хакеры заразили сети компании программой-вымогателем (ransomware), которая зашифровала или перемешала (scrambled) данные.

Поначалу казалось, что нарушения будут незначительными — перестали работать системы бесконтактной оплаты, а также клиенты не могли воспользоваться услугой «click and collect» (это популярный формат покупки в британском ритейле: заказ онлайн — получение в офлайн-точке).

Однако спустя несколько дней пришлось остановить всю онлайн-торговлю — а она в обычное время составляет около трети бизнеса компании.

Эта ситуация была описана как «почти как отрубить себе конечность», по выражению Найны МакИнтош, бывшего члена исполнительного комитета Marks & Spencer и основательницы сети Hope Fashion.

Перед компанией встала распространённая на сегодняшний день дилемма: восстановить все компьютерные системы с нуля или заплатить хакерам миллионы фунтов стерлингов выкупа за антидот.

Marks & Spencer отказалась сообщать, выплатила ли она преступникам деньги.

Ущерб был не только финансовый. Позднее ритейлер признал, что в результате атаки были украдены данные клиентов.

Возможно, это включало телефонные номера, домашние адреса и даты рождения, хотя, по словам компании, платёжные реквизиты или данные карт похищены не были (обычно в отчётах такого рода отдельно подчёркивают, что PCI-данные не утекли — чтобы успокоить клиентов и регуляторов).

К дополнительному позору в СМИ Marks & Spencer, хакеры заявили, что отправили требование выкупа напрямую генеральному директору, используя учётную запись одного из сотрудников.

Когда была атакована сеть супермаркетов Co-op, ответственность взяла на себя та же группа хакеров.

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

Однако IT-сети были отключены достаточно быстро, чтобы избежать значительных повреждений.

По словам преступников, которые с раздражением описали это в разговоре с BBC, «они сами выдернули свой шнур — обрушив продажи, они сожгли логистику и подорвали стоимость акций» (здесь видно злорадство — хакеры подчеркивают, что даже без их действий компания бы пострадала, пытаясь защититься).

По словам Джейми МакКолла, эксперта по кибербезопасности из исследовательской группы Королевского института объединённых служб (RUSI), нет ничего удивительного в том, что крупные бизнесы становятся мишенью.

Он объясняет, что хакерам стало очень легко получить доступ к программам-вымогателям (ransomware), которые могут блокировать или шифровать сети жертвы до тех пор, пока не будет выплачен выкуп.

Слабые места крупного бизнеса

Уязвимость таких компаний, как Jaguar Land Rover и Marks & Spencer, во многом объясняется тем, как работают их цепочки поставок.

Автопроизводители давно используют так называемую систему «just-in-time delivery» (поставки точно в срок), при которой запчасти не хранятся на складе, а поступают от поставщиков ровно в тот момент, когда они нужны на производственной линии.

Это снижает затраты на хранение и минимизирует потери, но требует точной координации всех аспектов цепочки поставок. Если компьютерные системы выходят из строя, последствия оказываются крайне разрушительными (поскольку весь поток связан, каждый простой мгновенно «замикается» в производственную остановку).

Аналогично, такой ритейлер, как Marks & Spencer, опирается на тщательно скоординированную цепочку поставок, чтобы гарантировать наличие нужного количества свежих продуктов в нужных магазинах — что делает систему столь же уязвимой (к примеру, если прогнозируемые объёмы поставок «замораживаются» из-за недоступности IT-систем, логистика теряет способность перераспределять товар вовремя).

(Прим. перевода: в британской торговле отказ IT-систем часто приводит не только к отсутствию товара на полках, но и мгновенным финансовым потерям из-за штрафов логистическим партнёрам.)

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

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

Накопительный эффект бездействия

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

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

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

Но эта ситуация указывает на более серьёзный вопрос: что произойдёт, если кибератака на критическую инфраструктуру парализует финансовые системы, транспорт или энергетические сети, потенциально приведя к огромным экономическим убыткам — или даже к более тяжёлым последствиям?

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

Какой будет результат атаки на энергетическую отрасль, не совсем ясно.

Исследование, проведённое Lloyds Bank в 2015 году под названием «Business Blackout», моделировало последствия гипотетической атаки на энергосистему США и пришло к выводу, что экономические потери могут превысить 1 трлн долларов (742 млрд фунтов стерлингов).

Тем не менее МакКолл считает, что в Великобритании, вероятно, есть достаточный запас мощности в энергосистеме для того, чтобы справиться с киберинцидентом (речь идёт о наличии резервных ресурсов, которые можно включить при частичной потере управления системой).

Реакция правительства, угрозы ИИ и скрытые точки отказа

Джейми Макколл считает, что за последние 15 лет в Великобритании наблюдался «довольно попустительский подход (laissez-faire) к кибербезопасности», и сменявшие друг друга правительства уделяли этому вопросу мало внимания. Он полагает, что крупные атаки этого года могут быть «накопительным эффектом бездействия в сфере кибербезопасности как со стороны правительства, так и со стороны бизнеса, и теперь это начинает по-настоящему сказываться».

В мае Национальный центр кибербезопасности (NCSC), входящий в состав GCHQ (Центра правительственной связи Великобритании), опубликовал отчет, в котором предупредил о растущем влиянии киберугроз со стороны хакеров, использующих инструменты на основе искусственного интеллекта.

Однако больше всего Джейми Макколла беспокоят те виды атак, от которых мы еще не придумали, как защититься.

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

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

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

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

Что такое бэкапы

Итак, бэкап сайта (с англ. backup — запасной) — это резервное копирование файлов, папок, данных проекта на отдельный сервер. Таким образом можно избежать потери информации в случае атаки, сбоев в работе сервера или базы данных, плановых работ или даже неудачных изменений на сайте.

Главная идея резервного копирования — возможность в любой момент откатить версию проекта до более старой.

Бэкапы делятся на несколько видов. Разберём их в зависимости от механизма копирования:

• Полный

Такая резервная копия сохраняет все данные. Она требует больше всего памяти и времени для создания.

• Инкрементальный

Сохраняет только те данные, которые изменились с момента последнего бэкапа.

• Дифференциальный

Включает только те файлы, которые изменились относительно последнего полного бэкапа.

• Обратное инкрементальное копирование

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

• Синтетическое копирование

За основу берётся последний полный бэкап, на который «наслаиваются» инкрементные копии — пока система не соберёт актуальную версию. Когда эта версия устаревает, цикл повторяется: создаётся новый синтетический бэкап поверх предыдущего полного.

Бэкапы также могут храниться на разных носителях, вот основные из них:

Сетевое хранилище (NAS)

Локальный сервер, где можно централизованно хранить бэкапы разных устройств и/или пользователей, объединяя их в одну сеть. Работает через LAN (локальное соединение) или интернет.

Другой компьютер

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

Внешний (жёсткий) диск

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

Облачное хранилище

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

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

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

Почему люди не делают бэкапы

В России лишь 13% работающих россиян выполняют бэкапы регулярно, тогда как, например, в Европе 37% пользователей делают резервные копии еженедельно.

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

• Халатность или недостаток технической грамотности. Многие думают, что резервное копирование не требует особых настроек и работает фоново. 43% IT-руководителей и вовсе уверены, что бэкап данных на сервере — полностью ответственность провайдера.

Теперь рассмотрим, как предупредить ошибки при организации резервного копирования и поставить этот процесс на поток.

Ошибки при организации резервного копирования

Еще в 2021 году разработчик программного обеспечения Veeam выяснил, что 58% бэкапов проваливаются, не выполнив своей основной функции. Разберём несколько возможных причин, почему так происходит.

• Нерегулярность

62% пользователей в РФ копируют и сохраняют рабочие данные, но большинство делают это нерегулярно.

• Хранение всех копий в одном месте

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

• Хранение только одной копии

Иметь одну резервную копию рискованно – если она повредится или вы случайно сохраните неверную версию, данные пропадут безвозвратно. Поэтому существует правило «3-2-1»: лучше иметь не менее трех копий данных, хранить их на двух и более физических носителях и не менее одной копии – удалённо.

• Отсутствие тестирования восстановления

По статистике, лишь 30% компаний проводят комплексное тестирование резервного копирования.

• Незащищенность бэкапов

Хотя бэкапы не требуются ежедневно, защищать их очень важно: 96% всех атак программ-вымогателей направлены на заражение резервных копий.

Когда бэкапы пригодились: кейсы компаний

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

Google Cloud

В 2024 году пенсионный фонд UniSuper обнаружил, что его учетная запись в Google Cloud удалена. Из-за сбоя пострадали около 620 000 пенсионеров — доступ к их счетам оказался заблокирован на неделю.

Решить проблему помог другой партнер UniSuper — хостинг-провайдер, которому фонд отдал свои резервные копии на хранение. Они помогли компании восстановить данные и доступ к аккаунтам.

Hycu

Одна медицинская компания и клиент Hycu уделяла кибербезопасности огромное внимание, но в её инфраструктуре всё равно нашлось слабое место. Через электронное письмо систему поразила программа-вымогатель, а когда проблему заметили, заражены уже были все файлы.

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

Samsung

Когда в 2014 году в дата-центре Samsung произошёл крупный пожар, большая часть данных пропала безвозвратно из-за отсутствия удалённых бэкапов.

Как показывают эти и другие подобные кейсы, создание резервных копий сервера — один из главных инструментов защиты данных.

Кто обычно отвечает за бэкапы

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

Мы в Beget тоже придерживаемся такой практики и внедрили для пользователей как автоматическое резервное копирование, так и бэкапы по требованию. Автоматический бэкап сайта на хостинге создается в среднем раз в 3 дня, на VPS – раз в 2–5 дней. Полный бэкап сервера VPS хранится в среднем 10 суток, после чего заменяется более свежей версией. Точного срока хранения бэкапов на виртуальном хостинге нет: на каждом аккаунте может храниться единовременно только 10 бэкапов, а когда место заканчивается, более старые копии удаляются.

Заключение

Утечка данных — проблема, которая почти всегда приходит без предупреждения. Пожалуй, именно поэтому, несмотря на все затраченные на системы безопасности средства, данные теряются постоянно: например, в 2023 году более 90% компаний оказались в ситуации, когда им пришлось обратиться к бэкапам, и при этом только 27% компаний смогли восстановить все данные, так как резервное копирование было организовано неправильно.

По данным, поданным в Комиссию по ценным бумагам и биржам США (SEC), злоумышленникам удалось похитить исходный код флагманской платформы BIG-IP и документы с описанием нераскрытых уязвимостей.

Атака была обнаружена 9 августа 2025 года, однако властям США позволили компании временно не разглашать детали, чтобы не помешать расследованию.

Что известно о взломе

По данным F5, киберпреступники, предположительно связанные с «государственными структурами», длительное время сохраняли доступ к сегменту сети, связанному с разработкой и распространением обновлений BIG-IP.

Эти устройства используются 48 из 50 крупнейших корпораций мира для управления интернет-трафиком и защиты приложений.

Известно, что хакеры похитили часть файлов, включая:

• исходные коды отдельных модулей BIG-IP;
• данные о частных, еще не исправленных уязвимостях;
• конфигурации и сведения о внедрении решений у «небольшого процента клиентов».

F5 утверждает, что нет доказательств вмешательства в цепочку поставок ПО — исходники и сборочные конвейеры остались нетронутыми, а продукты NGINX, Silverline и F5 Distributed Cloud не пострадали.

Реакция компании

После инцидента F5 выпустила пакет патчей для 44 уязвимостей, часть которых фигурировала среди украденных данных, и настоятельно рекомендовала клиентам обновить все системы.

Обновления уже доступны для BIG-IP, F5OS, BIG-IP Next для Kubernetes, BIG-IQ и APM-клиентов.

Компания также опубликовала руководство по защите инфраструктуры, включая рекомендации:

• включить потоковую передачу событий BIG-IP в SIEM;
• настроить удаленные syslog-сервера;
• отслеживать неудачные входы и изменения привилегий.

Что говорят эксперты

Инцидент стал ударом по репутации F5, поставщика решений для защиты корпоративных сетей.

Однако эксперты отмечают: компания действует прозрачно и уже устранила последствия, не обнаружив признаков активной эксплуатации утечек.

🔐 Что изменилось в Apple Security Bounty

Программа действует с 2020 года и за это время выплатила исследователям уже $35 миллионов, в среднем — по $43 750 каждому из более чем 800 специалистов. Теперь Apple значительно увеличила размеры выплат и расширила список категорий уязвимостей:

Apple отмечает, что программа теперь охватывает более широкий спектр угроз, включая уязвимости в WebKit, механизмы защиты macOS и бета-версии iOS и iPadOS.

🧠 Почему это важно

Обновлённая программа помогает Apple защищать пользователей от атак высшего уровня — таких, что используются в дорогостоящем наёмном шпионском ПО.

За последние годы компания:

• внедрила Lockdown Mode, блокирующий большинство векторов атак;
• переработала систему защиты Safari;
• добавила Memory Integrity Enforcement в чипах серии A19, которая предотвращает уязвимости, связанные с повреждением памяти.

По словам Apple, сегодня лишь единичные iOS-атаки происходят на уровне системы, и они стоят миллионы долларов в разработке.

С ростом числа киберугроз и шпионских атак Apple активно позиционирует себя как лидера в области приватности и защиты данных. Повышенные награды отражают стратегию компании — поощрять белых хакеров и опережать киберпреступников на шаг.

Что произошло

По данным, опубликованным BleepingComputer, злоумышленники утверждают, что взломали Zendesk-инстанс, который Discord использует для поддержки клиентов.

Они заявляют, что получили 1,6 ТБ данных — это около 8,4 миллиона тикетов поддержки, затрагивающих 5,5 миллиона уникальных пользователей.

Discord в ответ пояснил, что речь идёт не о взломе платформы, а о компрометации стороннего сервиса, связанного с техподдержкой:

«Это не взлом Discord, а инцидент с участием стороннего поставщика, который помогает нам обрабатывать запросы пользователей», — говорится в официальном заявлении компании.

Что могли украсть

Хакеры утверждают, что получили доступ к внутреннему инструменту Zenbar, позволявшему:

• просматривать e-mail и номера телефонов пользователей;
• отключать двухфакторную аутентификацию (MFA);
• просматривать внутренние тикеты и обращения.

По их словам, среди украденных данных есть:

• адреса электронной почты и Discord ID;
• номера телефонов;
• частичная платёжная информация;
• даты рождения;
• данные MFA и статусы активности;
• переписки с техподдержкой.

Особенно тревожная часть — это фотографии удостоверений личности, которые пользователи отправляли для проверки возраста. Discord признаёт, что утечка затронула около 70 000 пользователей, а не 2,1 миллиона, как утверждают хакеры.

Что говорит Discord

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

«Мы не собираемся вознаграждать тех, кто нарушает закон.

Количество затронутых пользователей сильно завышено», — подчеркнули представители Discord.

Как произошёл взлом

Хакеры утверждают, что получили доступ через аккаунт сотрудника аутсорсинговой компании (BPO), которая занимается поддержкой пользователей Discord.

Доступ сохранялся в течение 58 часов — с 20 по 22 сентября 2025 года.

Такие компании нередко становятся уязвимым звеном: атакующие получают доступ не напрямую к IT-инфраструктуре бренда, а через подрядчиков.

Попытка вымогательства

По данным BleepingComputer, злоумышленники потребовали $5 миллионов, позднее снизив сумму до $3,5 млн. Переговоры шли до 2 октября, но после официального отказа Discord платить, группа заявила о намерении слить данные в открытый доступ.

Пока достоверность образцов данных, предоставленных хакерами, не подтверждена.

Что делать пользователям

Эксперты советуют:

• обновить пароль Discord и включить двухфакторную аутентификацию;
• не переходить по подозрительным ссылкам, даже если они приходят от знакомых аккаунтов;
• при совпадении e-mail с утекшими адресами — проверить их через Have I Been Pwned;
• следить за сообщениями от поддержки Discord о возможных уведомлениях безопасности.

Что произошло

Redis — это высокопроизводительное хранилище данных с открытым исходным кодом, применяемое как кэш, брокер сообщений и база данных. Оно используется примерно в 75% облачных инфраструктур по всему миру.

Новая уязвимость, прозванная исследователями RediShell, связана с 13-летней ошибкой типа use-after-free в интерпретаторе Lua. При успешной эксплуатации она позволяет аутентифицированному злоумышленнику выйти за пределы «песочницы» Lua, установить обратное соединение и добиться удалённого выполнения кода (RCE) на хосте Redis.

Потенциальные последствия

После компрометации сервера атакующий может:

• похищать учётные данные и конфиденциальные данные из памяти Redis;
• внедрять вредоносное ПО и криптомайнеры;
• перемещаться по внутренней сети жертвы;
• использовать полученные токены доступа для атак на другие облачные сервисы.

Исследователи из Wiz, впервые представившие уязвимость на конференции Pwn2Own Berlin 2025, отметили, что она «предоставляет злоумышленнику полный доступ к хостовой системе, включая возможность стирания, шифрования и перехвата данных».

Масштаб угрозы

По данным Wiz, в сети обнаружено около 330 000 экземпляров Redis, из которых не менее 60 000 не требуют аутентификации, что делает их уязвимыми к немедленной атаке.

Уязвимость затрагивает все версии Redis, включая OSS/CE и Stack-редакции. Исправления уже доступны в версиях:

• 7.22.2-12 и выше,
• 7.8.6-207 и выше,
• 7.4.6-272 и выше,
• 7.2.4-138 и выше,
• 6.4.2-131 и выше,
  а также в OSS/CE релизах 8.2.2+, 8.0.4+, 7.4.6+, 7.2.11+ и Stack-релизах 7.4.0-v7+ и 7.2.0-v19+.

Рекомендации для администраторов

Redis и Wiz настоятельно советуют:

• немедленно обновить все экземпляры Redis;
• включить аутентификацию и ограничить доступ доверенным сетям;
• отключить выполнение Lua-скриптов, если оно не требуется;
• запускать Redis без прав root;
• включить журналирование и мониторинг активности;
• использовать сетевые фильтры, VPN и брандмауэры для защиты.

Исследователи представили видео об уязвимости, где можно посмотреть подробности о возможных угрозах и мерах безопасности.

Исторический контекст

Redis уже не раз становился целью атак. В 2024 году ботнет P2PInfect использовал уязвимые экземпляры для майнинга Monero, а ранее вредоносные программы Redigo, HeadCrab и Migo внедряли криптомайнеры и отключали защиту на серверах Redis.

По словам Wiz, сочетание широкого распространения Redis, небезопасных конфигураций по умолчанию и критичности уязвимости создаёт «острую необходимость в немедленном обновлении».