Bagaimana Rahasia yang Bersembunyi di Kode Sumber Menyebabkan Pelanggaran Besar

  • Whatsapp
Major Data Breaches
Bagaimana Rahasia yang Bersembunyi di Kode Sumber Menyebabkan Pelanggaran Besar

News.nextcloud.asia –

Pelanggaran Data Utama

Jika satu kata dapat meringkas tahun infosecurity 2021 (well, sebenarnya tiga), itu akan menjadi ini: “serangan rantai pasokan”.

Serangan rantai pasokan perangkat lunak terjadi ketika peretas memanipulasi kode dalam komponen perangkat lunak pihak ketiga untuk mengkompromikan aplikasi ‘hilir’ yang menggunakannya. Pada tahun 2021, kami telah melihat peningkatan dramatis dalam serangan semacam itu: insiden keamanan tingkat tinggi seperti SolarWinds, Kaseya, dan Codecov pelanggaran data telah mengguncang kepercayaan perusahaan dalam praktik keamanan penyedia layanan pihak ketiga.

Apa hubungannya ini dengan rahasia, Anda mungkin bertanya? Singkatnya, banyak. Ambil kasus Codecov (kita akan kembali ke sana dengan cepat): ini adalah contoh buku teks untuk menggambarkan bagaimana peretas memanfaatkan kredensial hardcode untuk mendapatkan akses awal ke sistem korban mereka dan mengumpulkan lebih banyak rahasia di rantai.

Rahasia-dalam-kode tetap menjadi salah satu kerentanan yang paling diabaikan di ruang keamanan aplikasi, meskipun menjadi target prioritas dalam buku pedoman peretas. Pada artikel ini, kita akan berbicara tentang rahasia dan bagaimana menjaganya dari kode sumber adalah prioritas nomor satu saat ini untuk mengamankan siklus pengembangan perangkat lunak.

Apa itu rahasia?

Rahasia adalah kredensial otentikasi digital (kunci API, sertifikat, token, dll.) yang digunakan dalam aplikasi, layanan, atau infrastruktur. Sama seperti kata sandi (ditambah perangkat dalam kasus 2FA) digunakan untuk mengotentikasi seseorang, rahasia mengotentikasi sistem untuk mengaktifkan interoperabilitas. Tapi ada masalah: tidak seperti kata sandi, rahasia dimaksudkan untuk didistribusikan.

Untuk terus menghadirkan fitur baru, tim rekayasa perangkat lunak perlu menghubungkan lebih banyak blok bangunan. Organisasi mengamati jumlah kredensial yang digunakan di beberapa tim (skuat pengembangan, SRE, DevOps, keamanan, dll.) meledak. Terkadang pengembang akan menyimpan kunci di lokasi yang tidak aman untuk memudahkan pengubahan kode, tetapi hal itu sering kali mengakibatkan informasi yang salah dilupakan dan dipublikasikan secara tidak sengaja.

Dalam lanskap keamanan aplikasi, rahasia yang di-hardcode benar-benar merupakan jenis kerentanan yang berbeda. Pertama, karena kode sumber adalah aset yang sangat bocor, dimaksudkan untuk dikloning, diperiksa, dan di-fork pada banyak mesin dengan sangat sering, rahasia juga bocor. Tapi, yang lebih mengkhawatirkan, jangan lupa bahwa kode itu juga memiliki memori.

Basis kode apa pun dikelola dengan semacam sistem kontrol versi (VCS), menjaga garis waktu historis dari semua modifikasi yang pernah dilakukan, terkadang selama beberapa dekade. Masalahnya adalah bahwa rahasia yang masih berlaku dapat bersembunyi di mana saja di garis waktu ini, membuka dimensi baru ke permukaan serangan. Sayangnya, sebagian besar analisis keamanan hanya dilakukan pada kondisi basis kode saat ini yang siap digunakan. Dengan kata lain, ketika menyangkut kredensial yang tinggal di komit lama atau bahkan cabang yang tidak pernah digunakan, alat ini benar-benar buta.

Enam juta rahasia didorong ke GitHub

Tahun lalu, memantau komitmen yang didorong ke GitHub secara real-time, GitGuardian mendeteksi lebih dari 6 juta rahasia yang bocormenggandakan jumlah dari tahun 2020. Rata-rata, 3 komitmen dari 1.000 berisi kredensial, yang lima puluh persen lebih tinggi dari tahun lalu.

Sebagian besar rahasia itu memberikan akses ke sumber daya perusahaan. Tidak heran jika penyerang yang ingin mendapatkan pijakan ke dalam sistem perusahaan pertama-tama akan melihat repositori publiknya di GitHub, dan kemudian pada yang dimiliki oleh karyawannya. Banyak pengembang menggunakan GitHub untuk proyek pribadi dan dapat terjadi kebocoran kredensial perusahaan secara tidak sengaja (ya, itu terjadi secara teratur!).

Dengan kredensial perusahaan yang valid, penyerang beroperasi sebagai pengguna yang berwenang, dan mendeteksi penyalahgunaan menjadi sulit. Waktu untuk kredensial dikompromikan setelah didorong ke GitHub hanya 4 detik, yang berarti kredensial harus segera dicabut dan diputar untuk menetralisir risiko pelanggaran. Karena rasa bersalah, atau kurang pengetahuan teknis, kita dapat melihat mengapa orang sering mengambil jalan yang salah untuk keluar dari situasi ini.

Kesalahan buruk lainnya bagi perusahaan adalah menoleransi keberadaan rahasia di dalam repositori non-publik. Laporan State of Secrets Sprawl GitGuardian menyoroti fakta bahwa repositori pribadi menyembunyikan lebih banyak rahasia daripada yang setara dengan publik. Hipotesisnya di sini adalah bahwa repositori pribadi memberi pemiliknya rasa aman yang salah, membuat mereka sedikit kurang peduli tentang rahasia potensial yang bersembunyi di basis kode.

Itu mengabaikan fakta bahwa rahasia yang terlupakan ini suatu hari nanti bisa berdampak buruk jika diambil oleh peretas.

Agar adil, tim keamanan aplikasi sangat menyadari masalah ini. Tetapi jumlah pekerjaan yang harus dilakukan untuk menyelidiki, mencabut, dan memutar rahasia yang dilakukan setiap minggu, atau menggali wilayah yang belum dipetakan selama bertahun-tahun, sungguh luar biasa.

Pelanggaran judul… dan sisanya

Namun, ada urgensi. Peretas secara aktif mencari “dorks” di GitHub, yang merupakan pola yang mudah dikenali untuk mengidentifikasi rahasia yang bocor. Dan GitHub bukan satu-satunya tempat di mana mereka dapat aktif, registri apa pun (seperti Docker Hub) atau kebocoran kode sumber apa pun berpotensi menjadi tambang emas untuk menemukan vektor eksploitasi.

Sebagai bukti, Anda hanya perlu melihat pelanggaran yang baru-baru ini diungkapkan: favorit dari banyak proyek sumber terbuka, Codecov adalah alat cakupan kode. Tahun lalu, itu dikompromikan oleh penyerang yang memperoleh akses dengan mengekstrak kredensial akun cloud statis dari gambar Docker resminya. Setelah berhasil mengakses repositori kode sumber resmi, mereka dapat mengutak-atik skrip CI dan mengumpulkan ratusan rahasia dari basis pengguna Codecov.

Baru-baru ini, seluruh basis kode Twitch bocor, memperlihatkan lebih dari 6.000 repositori Git dan 3 juta dokumen. Meskipun banyak bukti yang menunjukkan tingkat tertentu dari kematangan AppSec, hampir 7.000 rahasia bisa muncul! Kita berbicara tentang ratusan kunci AWS, Google, Stripe, dan GitHub. Hanya beberapa dari mereka akan cukup untuk menyebarkan serangan skala penuh pada sistem perusahaan yang paling kritis. Kali ini tidak ada data pelanggan yang bocor, tapi itu sebagian besar keberuntungan.

Beberapa tahun yang lalu, Uber tidak seberuntung itu. Seorang karyawan secara tidak sengaja memublikasikan beberapa kode perusahaan di repositori GitHub publik, yang merupakan miliknya sendiri. Peretas menemukan dan mendeteksi kunci penyedia layanan cloud yang memberikan akses ke infrastruktur Uber. Terjadi pelanggaran besar-besaran.

Intinya adalah bahwa Anda tidak dapat benar-benar yakin kapan sebuah rahasia akan dieksploitasi, tetapi yang harus Anda waspadai adalah bahwa aktor jahat sedang memantau pengembang Anda, dan mereka mencari kode Anda. Juga perlu diingat bahwa insiden ini hanyalah puncak gunung es, dan mungkin lebih banyak pelanggaran yang melibatkan rahasia tidak diungkapkan kepada publik.

Kesimpulan

Rahasia adalah komponen inti dari tumpukan perangkat lunak apa pun, dan mereka sangat kuat, oleh karena itu mereka membutuhkan perlindungan yang sangat kuat. Sifat terdistribusi mereka dan praktik pengembangan perangkat lunak modern membuatnya sangat sulit untuk mengontrol di mana mereka berakhir, baik itu kode sumber, log produksi, gambar Docker, atau aplikasi perpesanan instan. Deteksi rahasia dan kemampuan remediasi adalah suatu keharusan karena bahkan rahasia dapat dieksploitasi dalam serangan yang mengarah ke pelanggaran besar. Skenario seperti itu terjadi setiap minggu dan karena semakin banyak layanan dan infrastruktur yang digunakan di dunia perusahaan, jumlah kebocoran meningkat dengan sangat cepat. Tindakan sebelumnya diambil, semakin mudah untuk melindungi kode sumber dari ancaman di masa depan.

Catatan – Artikel ini ditulis oleh Thomas Segura, penulis konten teknis di GitGuardian. Thomas telah bekerja sebagai analis dan konsultan insinyur perangkat lunak untuk berbagai perusahaan besar Prancis.

Pos terkait

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan.