Все еще покупаете AI-центр на Таобао? Информатор утечки исходного кода Claude Code: как минимум десятки были отравлены

Последние исследования разоблачителя утечки исходного кода Claude Code раскрывают скрытые риски безопасности в коммерческих AI-центрах пересылки. Практическое тестирование выявило, что некоторые такие центры крадут сертификаты, приватные ключи кошельков или внедряют вредоносный код, становясь узлами цепочки поставок атак.

Последние исследования разоблачителя утечки исходного кода Claude Code раскрывают риски безопасности AI-центров пересылки

Недавно опубликована исследовательская статья «Ваш агент — мой» (Your Agent Is Mine), одним из авторов которой является Chaofan Shou, один из первых разоблачителей утечки исходного кода Claude Code.

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

Что такое AI-центр пересылки?

Поскольку вызов LLM потребляет большое количество токенов и ведет к высоким затратам на вычисления, AI-центры пересылки позволяют кэшировать повторяющиеся вопросы и контекст, значительно сокращая расходы клиентов.

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

Центры пересылки особенно популярны в Китае, поскольку в стране невозможно напрямую использовать некоторые зарубежные AI-продукты, а также из-за потребности компаний в локализации расчетов. Поэтому такие центры становятся важным мостом между upstream моделями и downstream разработчиками. В их число входят платформы, такие как OpenRouter и SiliconFlow.

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

Источник: исследовательская статья, раскрывающая риски цепочки поставок атак на AI-центры пересылки

AI-центры пересылки имеют полный доступ, становясь уязвимыми для цепочек атак

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

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

Исследовательская команда указывает, что еще в марте 2026 года известный open-source маршрутизатор LiteLLM подвергся атаке с использованием зависимости, что позволило злоумышленнику внедрить вредоносный код в обработку запросов, подчеркнув уязвимость этого компонента.

• **Связанные новости:**Обзор инжекции вредоносного кода в LiteLLM: как проверить криптокошельки и облачные ключи на взлом?

Практическое тестирование десятков AI-центров пересылки выявило вредоносное поведение

Команда исследователей приобрела 28 платных центров пересылки на платформах Taobao, Xianyu и Shopify, а также собрала 400 бесплатных центров из открытых сообществ для глубокого тестирования, и обнаружила, что один платный и восемь бесплатных центров активно внедряют вредоносный код.

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

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

В ходе тестов на заражение было обнаружено, что эти узлы обработали более 2,1 миллиарда токенов, в 440 сессиях было раскрыто 99 реальных сертификатов, а 401 сессия находилась в полностью автономном режиме, что позволяет злоумышленникам легко внедрять вредоносные нагрузки без сложных условий активации.

Источник: исследовательская статья, тестирование более 400 центров пересылки, выявлены десятки с вредоносным поведением

Четыре основные метода атак раскрыты

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

• Инъекция нагрузки: После получения результата от upstream-модели центр пересылки тайно изменяет параметры вызова инструмента, например, заменяет легитимный URL на сервер злоумышленника, что приводит к выполнению вредоносного кода на клиенте.
• Утечка конфиденциальных данных: Центр пересылки пассивно сканирует передаваемый трафик, перехватывает и крадет API-ключи, сертификаты AWS и приватные ключи Ethereum.

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

Еще один метод — условная доставка, при которой вредоносное поведение активируется только при выполнении определенных условий, например, при превышении 50 запросов или обнаружении режима полной автономной работы (YOLO), что помогает обойти ограничения по безопасности.

Три возможных меры защиты

В ответ на цепочные атаки с подменой в AI-центрах пересылки исследование предлагает три меры защиты:

• Политика контроля для инструментов высокого риска: проверка и блокировка несанкционированных доменов или команд установки пакетов, что с ошибкой менее 1% предотвращает большинство инъекций нагрузки.
• Механизм обнаружения аномалий на стороне ответа: позволяет с ошибкой около 6,7% отмечать 89% вредоносных образцов нагрузки, помогая разработчикам проводить ручную проверку.
• Дополнительные журналы прозрачности: хотя не предотвращают атаки, сохраняют хэш-запросов и ответов для последующего анализа и оценки ущерба при инцидентах.

Призыв к upstream-поставщикам внедрять криптографическую проверку

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

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

Дополнительные материалы:
OpenAI использует Mixpanel — произошел инцидент! Некоторые пользовательские данные утекли, будьте осторожны с фишинговыми письмами

Ошибочный копипаст — 50 миллионов долларов исчезли! Вновь активирована мошенническая атака с подменой адресов, как защититься?