Витік ключів Google API обходиться у $128K на рахунках Gemini

Рахунок на $82 314 за 48 годин — зростання у 455 разів відносно базового рівня витрат — є найпоказовішою цифрою в цій історії. Це не неправильно налаштований cron job і не вийшовший із-під контролю тестовий стенд. Це невелика команда в Мексиці, яка спостерігає, як їхній хмарний рахунок множиться приблизно на три порядки, тому що ключ, який їм казали безпечно вбудовувати, став живим обліковим даним для Gemini inference. Ця закономірність повторюється в трьох задокументованих інцидентах і 22 застосунках, а архітектурна першопричина знаходиться на стороні Google, а не розробників.

Цифри

Головна цифра — $128 000 несанкціонованого використання Gemini API в одній японській компанії, як повідомляє TechRadar, і ця компанія мала IP-обмеження на рівні брандмауера. Список дозволених IP-адрес не зупинив зловживання. Ця деталь важливіша за суму в доларах, оскільки вона говорить нам, що вектор атаки не є проблемою мережевого рівня.

Інші два інциденти дозволяють оцінити діапазон збитків. Одиночний розробник у першому випадку відкликав скомпрометований ключ через кілька хвилин після першого сповіщення про виставлення рахунку, але лічильник все одно зупинився на позначці $15 400 через затримку звітності про виставлення рахунків у Google Cloud. Мексиканська команда отримала $82 314 за 48 годин — зростання у 455 разів відносно їхнього звичайного темпу витрат. Три точки даних, три різні реакції на інцидент — і всі три призвели до збитків від чотиризначних до шестизначних сум.

Поверхня розкриття є ширшою, ніж свідчать окремі випадки. Дослідження CloudSEK виявило 32 відкритих ключі Google API у 22 Android-застосунках, а ці 22 застосунки мають сукупну базу встановлень понад 500 мільйонів користувачів. Серед уражених застосунків — OYO Hotel Booking, Google Pay for Business, Taobao та ELSA Speak. Щодо ELSA Speak конкретно: дослідники підтвердили, що могли отримати доступ до завантажених користувачами аудіофайлів через Gemini Files API — отже, наслідки не обмежуються лише рахунками, а стосуються і даних користувачів.

Для розуміння масштабу бази встановлень: 500 мільйонів встановлень — це приблизно населення Європейського Союзу та Великої Британії разом узятих. Навіть якщо лише частина цих встановлень перебуває в регіонах, де ключі можна успішно вилучити та перехопити, доступний пул можливостей для безкоштовних AI-обчислень для зловмисників є величезним. Джерело не розкриває, скільки з 32 ключів активно використовується зловмисниками, а скільки просто можна виявити, і ця межа має значення: якщо рівень зловживань становить 5%, це локальний інцидент; якщо 50% — слід очікувати хвилі несподіваних рахунків у III кварталі, які ще не з'явилися у звітах про розкриття інформації.

Якщо ця модель розкриття збережеться, я б передбачив щонайменше два нових публічних розкриття несанкціонованих рахунків Gemini на п'ятизначні суми або більше від названих компаній до кінця III кварталу 2026 року.

Що справді нового

Новий елемент тут — це тихе підвищення привілеїв. Тухін Бос, дослідник CloudSEK, який очолював роботу, висловився прямо: «Ця проблема не виникла через недбалість розробників; реалізації відповідали встановленим рекомендаціям Google». Бос описав архітектуру як таку, що фактично перетворила нечутливі ідентифікатори на токени автентифікації, створивши системну вразливість у численних застосунках. Це формулювання варто прочитати двічі.

Вбудовування ключів API для Maps або Firebase у клієнтський Android-код є стандартною практикою протягом десяти років. Власна документація Google традиційно розглядала ці ключі як ідентифікатори з низьким рівнем чутливості, оскільки вони були прив'язані до конкретних, здебільшого доступних лише для читання або з обмеженням частоти запитів сервісів. Тайли карт завантажуються, конфіги Firebase зчитуються, життя триває. Неявна угода полягала в тому, що це публічні ідентифікатори з обмеженнями, а не токени доступу.

Ця угода була порушена, коли ті самі ключі на рівні проекту почали надавати живий доступ до Gemini. Розробники, які випустили застосунки у 2022 або 2023 роках, не погоджувалися на ризик виставлення рахунків за AI, і в джерелі немає жодних свідчень того, що Google надіслала сповіщення або запити на підтвердження під час цього підвищення привілеїв. Облікові дані у 22 виробничих застосунках тихо стали чимось потужнішим, ніж те, на що підписувалися їхні автори, а застосунки продовжують передавати ці ключі через цикли оновлень. Вразливість може зберігатися після оновлень застосунку, а це означає, що розробник, який виправив ключ у версії 4.2, все ще має встановлення версії 4.1, які генерують виклики Gemini.

Порівняйте це зі стандартним сценарієм витоку облікових даних: розробник комітить ключ доступу AWS на GitHub, GitGuardian позначає його протягом кількох хвилин, AWS автоматично відкликає, загальна шкода обмежена. Цей процес передбачає, що витіклий обліковий даний завжди був чутливим. Тут же обліковий даний не був чутливим на момент виникнення проблеми. Він став чутливим ретроактивно, і жодна система виявлення не відстежувала цей перехід. Джерело не розкриває, чи є у Google внутрішня телеметрія, яка позначає аномальні патерни викликів Gemini, що походять від ключів, які раніше зверталися лише до кінцевих точок Maps або Firebase, — а це очевидний засіб контролю, про який варто запитати.

Перевіряємо прогноз: якщо Google випустить виправлення протягом наступних 90 днів, очікуйте, що воно матиме форму обов'язкового розділення на рівні проекту між застарілими ключами сервісів і доступом до Gemini з явним процесом підключення. Якщо ні — очікуйте колективних позовів від постраждалих розробників у IV кварталі.

Що вже враховано в performance marketing

Для команд, що займаються платним залученням, актуальне питання полягає в тому, як це впливає на економіку трафіку мобільних застосунків. Кампанії з встановлення застосунків через Google Ads API залежать від даних конверсій, що надходять від SDK, які часто використовують той самий простір проекту з тією самою поверхнею API-ключів, яку досліджувала CloudSEK. Ринок вже врахував ризик облікових даних на рівні SDK для вимірювання реклами — саме тому серверні API конверсій та агрегована звітність є напрямком розвитку з 2022 року. Що ще не враховано — це ідея про те, що самі ключі SDK можуть бути використані для атак на витрати проти видавця, а не лише для витоку даних.

Наслідки для performance marketing є конкретними. Якщо ви керуєте мобільним застосунком, що монетизується через рекламу, і вбудовуєте ключі Firebase або Maps відповідно до рекомендацій Google, ваша юніт-економіка тепер несе хвостовий ризик, що не корелює з вашим трафіком. Один зловмисник, що вичерпує вашу квоту Gemini, може перевищити ваші місячні витрати на рекламу, як демонструє японський випадок: $128 000 — це значна частина річного бюджету на залучення користувачів для застосунку середнього розміру. Фінансові директори, що моделюють LTV відносно CAC, не враховували цього, тому що до минулого тижня цей вектор загрози не існував у своїй нинішній формі.

Що вже враховано: загальна крихкість клієнтських облікових даних, необхідність серверного проксювання дорогих API-викликів і припущення, що будь-який ключ, включений до APK, є перелічуваним. Зрілі команди роками виносили чутливі операції за власні бекенди. Справді несподіваним є те, що саме дотримання задокументованих найкращих практик Google і створило вразливість, а це означає, що стандартна відповідь команди безпеки «читайте документацію уважніше» тут не застосовується.

Контраріанська точка зору

Консенсусна інтерпретація полягатиме в тому, що Google має це виправити, а розробники не винні. Я б заперечив половині з цього. Так, архітектурне рішення про підвищення привілеїв застарілих ключів без підтвердження — це на Google, і Бос правий, що реалізації були відповідними. Але глибший урок, який індустрія продовжує відмовлятися засвоювати, полягає в тому, що будь-який обліковий даний, включений до клієнтського бінарного файлу, — це обліковий даний, який ви надали публіці. Класифікація постачальника «чутливий» чи «нечутливий» — це ввічливість, а не гарантія, тому що постачальник може переглянути класифікацію в будь-який момент без вашої участі.

Ставлення до клієнтських вбудованих ключів як до токенів доступу, незалежно від того, як їх називає документація, — єдина захищена позиція. Команди, що винесли дорогі операції за власні аутентифіковані бекенди, не постраждали від цього, і вони не постраждають від наступного варіанту теж. Контраріанське прочитання полягає в тому, що цей інцидент менш стосується Gemini і більше — повторюваної невдачі в проектуванні архітектури з урахуванням змін політики на стороні постачальника. Очікуйте, що принаймні ще один хмарний провайдер повторить цю модель протягом 18 місяців, мабуть, з іншим AI-сервісом поверх раніше низькоризикового класу ключів.

Ключові висновки

• Три задокументованих інциденти призвели до збитків у $15 400, $82 314 та $128 000, причому мексиканський випадок представляє зростання у 455 разів відносно базового рівня за 48 годин. IP-обмеження на рівні брандмауера не запобігли японським збиткам.
• 32 відкритих ключі у 22 Android-застосунках із сукупною кількістю встановлень понад 500М, включаючи OYO, Google Pay for Business, Taobao та ELSA Speak, де аудіофайли користувачів були доступні через Gemini Files API.
• Першопричина є архітектурною: ключі, видані для Maps або Firebase, тихо отримали доступ до Gemini без сповіщення або підтвердження, перетворивши публічні ідентифікатори на токени автентифікації.
• Затримка звітності про виставлення рахунків у Google Cloud означає, що навіть негайне відкликання не обмежує збитки. Одиночний розробник відкликав ключ через кілька хвилин і все одно заборгував $15 400.
• Питання без відповіді з перевіряємою межею: джерело не розкриває, скільки з 32 ключів активно використовується зловмисниками. Якщо рівень перевищує 25%, очікуйте хвилі публічних розкриттів рахунків на п'ятизначні суми і більше від названих компаній до кінця III кварталу 2026 року.