Витік ключів Stripe: під загрозою дані сотень тисяч клієнтів

Дослідники повідомили про 650 активних секретних ключів sk_live і дев’ять ключів із обмеженими правами. Серед уражених акаунтів 573 могли приймати платежі, 531 — здійснювати виплати, а 519 мали обидві можливості.

Чому одного активного ключа могло бути достатньо для атаки

Секретний ключ Stripe — це повноцінний обліковий засіб для доступу до API, а не просто ідентифікатор. Його фактичні можливості залежать від дозволів ключа та конфігурації акаунта продавця. Однак скомпрометований ключ може відкрити доступ до ресурсів продавця й уможливити несанкціоновані платіжні операції.

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

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

Чому це не назвали зломом інфраструктури Stripe

Доступні докази вказують, що зловмисники могли використати чинні ключі продавців і отримати дані через легітимний API Stripe. Дослідники, які аналізували опубліковані файли офлайн, зазначили, що структура об’єктів і каталогів відповідала експорту через API-ендпоїнти. Водночас під час перевірки вони не автентифікувалися за допомогою відкритих ключів і не отримували доступу до робочих середовищ продавців.

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

• зараження пристроїв розробників або адміністраторів інфостілерами;
• публічні репозиторії та історію Git;
• відкриті файли .env і конфігурації серверів;
• хмарні сховища, резервні копії та шари контейнерів;
• системи CI/CD і журнали GitHub Actions;
• неправильно налаштовані сервери або автоматичне сканування відкритих змінних.

Початковий шлях викрадення 659 облікових даних не встановлено. Перелічені варіанти є можливими каналами витоку, а не підтвердженим єдиним джерелом усього набору даних.

Пов’язаний реліз і застереження щодо цифр

За даними Hudson Rock, пов’язаний реліз на форумі приписували тому самому зловмиснику. У ньому йшлося про 669 папок постачальників і 1 033 скомпрометовані ключі API; заявлений обсяг становив 33 ГБ, хоча доступний для завантаження файл, за повідомленнями, був меншим. Зловмисник також заявив, що має близько 20 000 додаткових скомпрометованих ключів Stripe і може опублікувати нові частини.

Ці числа не слід складати в один підтверджений підсумок. Різниця між 659 акаунтами продавців, 669 папками постачальників і 1 033 ключами може пояснюватися різними наборами даних, кількома ключами на один акаунт, дублюваннями або різними методами підрахунку. Оцінка у 20 000 ключів залишається неперевіреною заявою зловмисника.

У яких країнах було найбільше постраждалих продавців

У доступних звітах найчастіше згадувалися такі країни:

• США — 212 продавців;
• Велика Британія — 81;
• Франція — 57;
• Канада — 38;
• Бразилія — 30;
• Австралія — 27.

Ці показники описують розподіл продавців у заявленому наборі даних і мають оцінюватися з урахуванням того, що масштаб витоку ще встановлюють.

Що компаніям, які використовують Stripe, зробити зараз

1. Замінити активні секретні ключі

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

2. Перевірити активність API та платіжні операції

Проаналізуйте журнали API й безпеки на предмет незнайомих викликів, нових платіжних посилань, тестових або несанкціонованих списань, несподіваних повернень коштів, змін дозволів і нетипових IP-адрес. Важливі журнали потрібно зберегти, щоб відновити послідовність подій.

3. Перевірити налаштування виплат

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

4. Замінити широкі дозволи на обмежені ключі

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

5. Перевірити всі місця, де можуть залишатися секрети

Проскануйте актуальні й історичні репозиторії, історію Git, вивід CI/CD, журнали GitHub Actions, файли .env, шари контейнерів, хмарні сховища, документацію та резервні копії на наявність значень sk_live. Будь-який виявлений ключ потрібно відкликати й замінити, навіть якщо його вже немає в поточній версії коду.

6. Не покладатися лише на сканування GitHub

GitHub автоматично запускає пошук секретів у публічних репозиторіях, тоді як для приватних і внутрішніх репозиторіїв організацій потрібна функція GitHub Secret Protection на відповідних планах. Таке сканування не може виявити секрети, які вже потрапили до журналів, резервних копій, телеметрії пристроїв або завантажених архівів. Воно має доповнювати централізоване керування секретами, короткий термін дії ключів, контроль доступу та безперервний моніторинг.

Головний висновок для продавців

Доступні звіти не підтверджують злом інфраструктури Stripe. Водночас вони демонструють, наскільки небезпечними можуть бути відкриті активні ключі API: вони здатні забезпечити доступ до клієнтських даних і створити умови для платіжного шахрайства. Виробничі секрети потрібно захищати як критично важливі облікові дані — не зберігати в коді та журналах, обмежувати їхні права, швидко замінювати й розслідувати кожну нетипову подію в API або системі виплат.