Metodologi untuk mengumpulkan rahasia mencakup berbagai fase, yang pada akhirnya memungkinkan identifikasi informasi sensitif dengan tingkat kepercayaan yang tinggi. Ilustrasi dari karya ilmiahGitHub dan platform serupa untuk penerbitan open source saat ini telah menjadi alat standar untuk pengembang. Namun, masalah muncul jika kode sumber terbuka ini berfungsi dengan token otentikasi, kunci API pribadi, dan kunci kriptografi pribadi. Untuk memastikan keamanan, data ini harus dirahasiakan. Sayangnya, banyak pengembang menambahkan informasi sensitif ke kode, yang sering menyebabkan kebocoran informasi yang tidak disengaja.
Sebuah tim peneliti dari University of North Carolina melakukan
studi skala besar kebocoran data rahasia di GitHub.
Mereka memindai milyaran file, yang dikumpulkan dengan dua metode komplementer:
- Hampir enam bulan publik, GitHub melakukan scan secara real time
- potret repositori publik yang mencakup 13% dari semua repositori di GitHub, totalnya sekitar 4 juta repositori.
Kesimpulannya mengecewakan. Para ilmuwan tidak hanya menemukan bahwa kebocoran tersebar luas dan memengaruhi lebih dari 100.000 repositori. Lebih buruk lagi, ribuan "rahasia" baru dan unik mengunjungi GitHub setiap hari.
Tabel ini mencantumkan API layanan populer dan risiko yang terkait dengan kebocoran informasi ini.
Statistik umum tentang objek rahasia yang ditemukan menunjukkan bahwa kunci Google API yang paling sering masuk ke domain publik. Kunci pribadi RSA dan pengidentifikasi Google OAuth juga umum. Biasanya, sebagian besar kebocoran terjadi melalui repositori pemilik tunggal.
| Rahasia | Total | Unik | %, satu pemilik |
|---|
| Kunci API Google | 212 892 | 85 311 | 95,10% |
| Kunci Rahasia RSA | 158 011 | 37.781 | 90,42% |
| ID Google OAuth | 106 909 | 47.814 | 96,67% |
| Kunci pribadi biasa | 30.286 | 12.576 | 88,99% |
| ID Kunci Akses Amazon AWS | 26 395 | 4648 | 91,57% |
| Token akses Twitter | 20.760 | 7953 | 94,83% |
| EC kunci pribadi | 7838 | 1584 | 74,67% |
| Token akses Facebook | 6367 | 1715 | 97,35% |
| Kunci Pribadi PGP | 2091 | 684 | 82,58% |
| Kunci API MailGun | 1868 | 742 | 94,25% |
| Kunci API MailChimp | 871 | 484 | 92,51% |
| Stripe Standard API Key | 542 | 213 | 91,87% |
| Kunci API Twilio | 320 | 50 | 90,00% |
| Token Akses Persegi | 121 | 61 | 96,67% |
| Alun-Alun Rahasia | 28 | 19 | 94,74% |
| Amazon MWS Auth Token | 28 | 13 | 100,00% |
| Token Akses Braintree | 24 | 8 | 87,50% |
| Kunci API Picatic | 5 | 4 | 100,00% |
| Total | 575.456 | 201 642 | 93,58% |
Pemantauan real-time dari commit memungkinkan untuk menentukan seberapa banyak informasi sensitif dihapus dari repositori segera setelah sampai di sana. Ternyata pada hari pertama sedikit lebih dari 10% rahasia dihapus, dan pada hari-hari berikutnya beberapa persen, namun, lebih dari 80% informasi pribadi tetap berada di repositori dua minggu setelah penambahan, dan proporsi ini praktis tidak berkurang pada hari berikutnya.
Di antara kebocoran yang paling menonjol adalah akun AWS dari agen pemerintah di salah satu negara Eropa Timur, serta 7.280 kunci RSA pribadi untuk mengakses ribuan VPN pribadi.
Studi ini menunjukkan bahwa seorang penyerang, bahkan dengan sumber daya minimal, dapat membahayakan banyak pengguna GitHub dan menemukan satu ton kunci pribadi. Para penulis mencatat bahwa banyak metode perlindungan yang ada tidak efektif terhadap pengumpulan informasi rahasia. Misalnya, alat seperti TruffleHog hanya menunjukkan efisiensi 25%. Batas GitHub bawaan pada jumlah permintaan API juga mudah dilewati.
Namun, banyak rahasia yang ditemukan memiliki pola yang jelas yang membuatnya mudah
pencarian mereka. Adalah logis untuk mengasumsikan bahwa pola yang sama ini dapat digunakan untuk memantau kebocoran informasi rahasia dan memperingatkan pengembang. Mungkin, mekanisme seperti itu harus diimplementasikan di sisi server, yaitu di GitHub. Suatu layanan dapat mengeluarkan hak peringatan selama komit.
GitHub baru-baru ini mengimplementasikan pemindaian token versi beta (fungsi
Pemindaian Token ), yang memindai repositori, mencari token, dan memberi tahu penyedia layanan tentang kebocoran informasi. Pada gilirannya, vendor dapat membatalkan kunci ini. Para penulis percaya bahwa berkat penelitian mereka, GitHub dapat meningkatkan fitur ini dan memperluas jumlah vendor.