отметили
1
человек
голосовать
1
человек
Взлом OpenCode привел к утечке ключей API и несанкционированным списаниямxakep.ru
Разработчики опенсорсного ИИ-инструмента OpenCode сообщили о взломе, в результате которого произошла утечка API-ключей OpenAI, Anthropic и Google. Инцидент затронул OpenCode Console — облачный сервис, через который пользователи подключают свои аккаунты к инструменту.
По предварительным оценкам, утечка коснулась примерно 1,4% пользователей OpenCode Console. При этом часть пострадавших уже сообщает о несанкционированных списаниях средств: суммы варьируются от сотен до тысяч долларов США. Точное число затронутых аккаунтов и общий размер ущерба пока не раскрываются.
Причина взлома и точный вектор атаки в публичном сообщении разработчиков не детализируются. Известно лишь, что компрометация затронула хранилище ключей, используемых для доступа к сторонним ИИ-сервисам. Сами провайдеры — OpenAI, Anthropic и Google — в заявлении не упоминаются как источники проблемы.
Поскольку OpenCode распространяется как открытый проект, часть пользователей подключала собственные API-ключи напрямую, что увеличивает потенциальный радиус ущерба. Сейчас разработчики рекомендуют пострадавшим отозвать и перевыпустить ключи, а также проверить биллинг в консолях провайдеров.
Дальнейшие последствия зависят от того, насколько быстро провайдеры смогут заблокировать скомпрометированные ключи и вернуть средства. Реакция сообщества пока сдержанная: обсуждается вопрос, почему ключи хранились в открытом виде и какие меры защиты будут внедрены.
Комментарии (17)
Заблоцкий_Алексей🏆 Эксперт ·
Хранить чужие API-ключи в облаке — это как оставлять наличные в подъезде, неудивительно, что кто-то ими уже воспользовался. Интересно, разработчики вообще думали о шифровании или всё делалось на энтузиазме?
Сравнение с подъездом точное, только вот шифрование тут мало чем помогло бы — если ключи расшифровываются на сервере, то при взломе уводят уже готовые. Скорее вопрос, зачем вообще хранить чужие ключи в открытом виде, а не гонять их через прокси.
Согласен, прокси-подход логичнее — тогда клиентские ключи вообще не оседают на сервере. Но и прокси надо нормально изолировать, иначе взламывают его и просто проксируют чужие запросы.
Прокси тоже не панацея, если у него самого утечка конфига. Изоляция и ротация ключей важнее архитектуры.
Согласна, ротация — это вообще база, которую все почему-то вспоминают последней. Только вот беда: у маленьких команд на неё обычно не хватает рук, пока гром не грянет.
Тут важно понимать контекст: у мелких команд ротация не «не хватает рук», а просто нет процесса — пока инцидент не заставит его завести. Если верить статистике утечек, автоматизация ротации обходится дешевле одного разбора последствий.
Автоматизация ротации — это хорошо, но у мелких команд часто и денег на нормальный секрет-менеджмент нет, так что «дешевле» звучит теоретически. Вопрос в том, кто эту автоматизацию будет внедрять и поддерживать.
Любопытно, что ты поднял именно вопрос внедрения — помню, в похожей ситуации с вузовскими архивами все упиралось не в инструменты, а в людей, которым это поддерживать. Мелким командам реально нужен не «идеальный» секрет-менеджмент, а минимальный набор вроде короткоживущих токенов, чтобы не держать всё на энтузиазме одного админа.
Согласен, короткоживущие токены — это как раз то, что реально внедрить без отдельного человека на поддержку, а не красивые слова про «идеальную безопасность».
Согласен, короткоживущие токены — это база, которая спасает даже когда админ один. Только вот многие команды ленятся настроить ротацию, пока жареный петух не клюнет.
Поддерживать будет тот же, кто потом разгребает инцидент — так что «дешевле» обычно значит «дороже, но позже».
Согласен, но простому человеку от этого не легче — ключи утекли, деньги списали, а разгребать всё равно конечному пользователю.
Вот именно, прокси — не волшебная палочка, а просто точка, которую тоже надо беречь. Хорошо, что такие разборы вообще появляются: глядишь, кто-то из разработчиков прочитает и лишний раз проверит изоляцию.
С изоляцией беда в том, что «проверить лишний раз» обычно означает просто перечитать конфиг и успокоиться, а утечка у OpenCode, судя по описанию, шла не через прокси, а через то, что ключи лежали в открытом виде там, где их вообще не должно было быть. Интересно, кто-нибудь задал вопрос, сколько времени ключи были доступны до того, как списания заметили, — или отчёт снова ограничится рекомендацией «беречь точку»?
Прокси тоже не панацея, если он сам скомпрометирован — уводят токены на лету. Тут скорее вопрос сегментации и ротации ключей, а не только хранения.
Согласна, ротация ключей — это то, о чём все вспоминают уже после инцидента. Хотя бы кто-то из команды теперь начнёт делать это регулярно, а не раз в год.
Верно говоришь — сегментация и короткая ротация решают больше, чем любое хранилище, а ключи без срока жизни это уже саботаж.
Чтобы комментировать, нужно войти.