Утечка ключей Stripe раскрыла данные более 688 000 клиентов в 42 странах

Опубликованный архив с API-ключами продавцов, использующих Stripe, раскрыл данные, связанные с примерно 688 363 клиентами из 42 стран. Инцидент стал публичным 18 августа, когда пользователь под псевдонимом "Satanic" выложил информацию в свободный доступ на форуме по торговле данными.

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

Каков масштаб утечки данных

Опубликованный архив имеет объем около 35 ГБ и содержит 17 654 файла. В нем находятся записи о клиентах, платежах, намерениях совершить платеж, платежных сессиях, счетах-фактурах, подписках, возвратах средств, спорах, переводах и транзакциях по балансу.

Данные охватывают период с января 2022 года по июнь 2026 года. Согласно анализу, в комплекте присутствуют ключи для 659 торговых аккаунтов. Из них 650 являются активными секретными ключами с префиксом "sk_live", а девять — ключами с ограниченными правами.

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

Наибольшее число пострадавших торговых аккаунтов зафиксировано в США — 212. Далее следуют Великобритания с 81 аккаунтом и Франция с 57.

Как, вероятно, были получены ключи

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

Среди возможных источников компрометации ключей — публичные репозитории исходного кода, незащищенные файлы ".env", логи систем непрерывной интеграции и доставки (CI/CD), неправильно настроенные резервные копии, диагностические журналы и вредоносное ПО для кражи данных с устройств разработчиков.

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

Насколько серьезен риск

Аналитики показали, что один активный ключ может предоставить широкий доступ к торговому профилю. При проверке рабочего ключа им удалось получить список клиентов, создать мошенническую платежную ссылку и провести тестовый платеж в течение 17 часов.

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

Компания Hudson Rock сообщила о связанной публикации того же злоумышленника, который утверждает, что располагает примерно 20 000 скомпрометированных API-ключей Stripe и планирует опубликовать дополнительные части. Это утверждение не было подтверждено независимо.

Что должны предпринять продавцы

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

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

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