Kebocoran Kunci API Stripe Membahayakan Data 688.363 Pelanggan

Peneliti melaporkan menemukan 650 kunci rahasia sk_live dan sembilan kunci terbatas. Dari akun yang terdampak, 573 dapat menerima pembayaran, 531 dapat melakukan pencairan dana, dan 519 memiliki kedua kemampuan tersebut.

Mengapa satu kunci live saja bisa berbahaya?

Kunci rahasia Stripe adalah kredensial untuk mengakses API, bukan sekadar pengenal akun. Dampaknya bergantung pada izin kunci dan konfigurasi akun merchant, tetapi kredensial yang jatuh ke tangan pihak lain dapat membuka akses ke sumber daya merchant serta memungkinkan aktivitas pembayaran tanpa izin.

Pengujian yang dijelaskan dalam laporan menunjukkan bahwa satu kunci aktif dapat digunakan untuk mengakses daftar pelanggan, membuat tautan pembayaran palsu, dan melakukan charge pengujian. Risiko lanjutannya mencakup pengumpulan data pelanggan, penyalahgunaan pembayaran, refund tanpa izin, phishing tertarget, serta rekayasa sosial yang berkaitan dengan pembayaran. Akun yang memiliki kemampuan payout juga perlu memeriksa pengaturan dan tujuan pencairan dananya.

Risiko praktisnya terletak pada kecepatan. Kredensial server-side yang bocor dapat mengubah kelalaian dalam pengelolaan rahasia menjadi penyelidikan penipuan aktif sebelum merchant menyadari adanya aktivitas janggal.

Mengapa ini tidak dikategorikan sebagai peretasan infrastruktur Stripe?

Bukti yang tersedia menunjukkan bahwa penyerang kemungkinan menggunakan kredensial merchant yang valid untuk mengambil data melalui akses API Stripe yang sah. Peneliti yang memeriksa berkas tersebut secara offline menyatakan bahwa objek bergaya Stripe dan struktur direktorinya konsisten dengan hasil ekspor dari endpoint API. Dalam peninjauan itu, mereka tidak melakukan autentikasi menggunakan kunci yang terekspos atau mengakses lingkungan live milik merchant.

Perbedaan ini penting karena kemungkinan titik kegagalannya berada pada tempat merchant menyimpan atau mengekspos rahasia, bukan pada sistem inti Stripe. Beberapa jalur paparan yang masuk akal meliputi:

• Infostealer pada perangkat pengembang atau administrator
• Repositori publik dan riwayat Git
• Berkas .env atau konfigurasi server yang terbuka
• Penyimpanan cloud, cadangan, dan lapisan container
• Sistem CI/CD serta log GitHub Actions
• Server yang salah konfigurasi atau pemindaian otomatis terhadap variabel yang terekspos

Namun, jalur pencurian awal terhadap 659 kredensial merchant tersebut belum ditetapkan. Daftar di atas adalah kemungkinan jalur paparan, bukan asal tunggal yang telah dikonfirmasi untuk seluruh dataset.

Rilis terkait dan mengapa angkanya tidak boleh dijumlahkan

Laporan Hudson Rock mengaitkan rilis lain di forum dengan aktor yang sama. Rilis tersebut disebut mencakup 669 folder vendor dan 1.033 kunci API yang telah disusupi, dengan ukuran yang diiklankan 33 GB; tautan unduh yang terkait dilaporkan berukuran lebih kecil. Aktor itu juga mengklaim memiliki sekitar 20.000 kunci API Stripe tambahan yang telah disusupi dan mengisyaratkan kemungkinan rilis berikutnya.

Angka-angka tersebut tidak boleh digabungkan sebagai satu total yang telah terverifikasi. Perbedaan antara 659 akun merchant, 669 folder vendor, dan 1.033 kunci dapat mencerminkan dataset yang berbeda, adanya beberapa kunci untuk satu akun, duplikasi, atau metode penghitungan yang tidak sama. Klaim tentang 20.000 kunci masih berasal dari aktor ancaman dan belum terverifikasi.

Negara dengan merchant terdampak terbanyak

Distribusi lokasi merchant yang paling banyak disebut dalam laporan adalah:

• Amerika Serikat: 212 merchant
• Inggris Raya: 81 merchant
• Prancis: 57 merchant
• Kanada: 38 merchant
• Brasil: 30 merchant
• Australia: 27 merchant

Angka tersebut menggambarkan distribusi merchant dalam laporan yang tersedia dan tetap perlu dibaca bersama catatan bahwa cakupan dataset masih dalam proses penilaian.

Langkah yang perlu dilakukan bisnis pengguna Stripe

1. Segera ganti kunci rahasia live

Cabut dan ganti setiap kunci live yang mungkin pernah muncul di kode sumber, log, cadangan, telemetri endpoint, image container, atau infrastruktur publik. Jangan menunggu bukti penipuan sebelum mengganti kredensial yang berpotensi terekspos.

2. Audit aktivitas API dan operasi pembayaran

Periksa log API serta keamanan untuk menemukan pemanggilan yang tidak dikenal, tautan pembayaran baru, charge pengujian atau tanpa izin, refund yang tidak biasa, perubahan hak akses, dan alamat IP yang mencurigakan. Simpan log terkait agar kronologi insiden dapat disusun.

3. Verifikasi konfigurasi payout

Periksa pengaturan pencairan dana, detail rekening bank yang terhubung, dan tujuan payout. Segera eskalasikan perubahan mencurigakan kepada Stripe serta lembaga keuangan terkait, sesuai prosedur respons insiden dan pelaporan yang berlaku.

4. Ganti kredensial luas dengan kunci terbatas

Gunakan restricted key yang hanya memiliki izin API minimum sesuai kebutuhan tiap layanan. Pisahkan sistem produksi, lingkungan pengembangan, dan peran operasional. Hindari membagikan satu rahasia dengan hak akses luas ke banyak aplikasi.

5. Cari rahasia di seluruh tempat penyimpanan

Telusuri repositori saat ini dan lama, riwayat Git, keluaran CI/CD, log GitHub Actions, berkas .env, lapisan container, penyimpanan cloud, dokumentasi, serta cadangan untuk menemukan nilai sk_live. Setiap kredensial yang ditemukan harus dicabut dan diganti, meskipun sudah tidak muncul dalam versi kode terbaru.

6. Jangan mengandalkan pemindaian GitHub sebagai satu-satunya perlindungan

GitHub menyatakan bahwa secret scanning berjalan otomatis untuk repositori publik, sedangkan repositori privat dan internal milik organisasi memerlukan GitHub Secret Protection pada paket yang memenuhi syarat. Pemindaian juga tidak dapat menjangkau rahasia yang sudah tersalin ke log, cadangan, telemetri endpoint, atau arsip yang telah diunduh.

Karena itu, secret scanning sebaiknya menjadi salah satu lapisan pertahanan—bukan pengganti pengelolaan rahasia terpusat, masa berlaku kredensial yang singkat, pembatasan akses, dan pemantauan berkelanjutan.

Pelajaran utama bagi merchant

Kesimpulan paling jelas dari insiden ini adalah bahwa keamanan platform pembayaran juga bergantung pada kebersihan pengelolaan kredensial di sisi merchant. Laporan yang tersedia tidak membuktikan adanya pembobolan infrastruktur Stripe, tetapi menunjukkan bagaimana kunci API live yang terekspos dapat menjadi jalan menuju akses data pelanggan dan penyalahgunaan pembayaran.

Perlakukan rahasia produksi sebagai kredensial berdampak tinggi: jangan menyimpannya di kode atau log, batasi izinnya, rotasi secara cepat, dan selidiki setiap aktivitas API atau payout yang tidak biasa.