10 poin oleh GN⁺ 2024-07-25 | 1 komentar | Bagikan ke WhatsApp
  • Di GitHub, data dari fork yang dihapus, repositori yang dihapus, bahkan repositori privat dapat diakses
  • GitHub mengetahui hal ini dan ini adalah cara kerja yang memang dirancang dengan sengaja
    • Karena ini menjadi vektor serangan yang sangat besar bagi semua organisasi yang menggunakan GitHub, diperkenalkan istilah baru "Cross Fork Object References (CFOR)"
  • Kerentanan CFOR terjadi ketika satu fork repositori dapat mengakses data penting dari fork lain, termasuk data dari fork privat dan fork yang telah dihapus

Mengakses data fork yang dihapus

  • Jika melihat alur kerja umum di GitHub, ada kasus ketika seseorang mem-fork repositori publik, melakukan commit kode ke fork tersebut, lalu menghapus fork-nya
  • Kode yang di-commit ke fork itu tetap dapat diakses dan akan dapat diakses selamanya
  • Mungkin terlihat aman jika harus mengetahui hash commit, tetapi hash tersebut bisa ditemukan
  • Menemukan data dari fork yang dihapus ternyata cukup sering terjadi

Mengakses data repositori yang dihapus

  • Bayangkan skenario ketika ada repositori publik di GitHub, seorang pengguna mem-fork repositori itu, melakukan commit data setelah fork, lalu menghapus seluruh repositori,
  • Kode yang di-commit setelah fork tetap dapat diakses
  • GitHub menyimpan repositori dan fork dalam sebuah jaringan repositori, dengan repositori "upstream" asli berperan sebagai node akar
  • Jika repositori publik "upstream" yang telah di-fork "dihapus", GitHub akan menetapkan ulang peran node akar ke salah satu fork downstream
  • Namun, semua commit dari repositori "upstream" tetap ada dan dapat diakses melalui semua fork

Mengakses data repositori privat

  • Jika melihat alur kerja umum saat membuka source code alat baru di GitHub,
  • ada kasus ketika dibuat repositori privat yang nantinya akan dipublikasikan, lalu dibuat versi internal privat dari repositori tersebut (melalui fork), commit kode tambahan untuk fitur yang tidak akan dipublikasikan, kemudian repositori "upstream" dipublikasikan sementara fork tetap privat
  • Fitur privat dan kode terkait (pada langkah 2) dapat diakses dari repositori publik, selama sudah dapat diakses dari repositori publik
  • Apa pun yang di-commit ke fork privat setelah repositori "upstream" dipublikasikan tidak dapat dilihat

Bagaimana sebenarnya data diakses?

  • Dengan mengakses commit secara langsung
  • Dalam jaringan repositori GitHub, tindakan destruktif (seperti 3 skenario yang disebutkan di atas) menghapus referensi ke data commit dari UI GitHub standar dan operasi git biasa
  • Namun data ini masih tetap ada dan dapat diakses jika mengetahui hash commit-nya
  • Hash commit adalah nilai SHA-1, dan jika pengguna mengetahui hash commit SHA-1 dari commit tertentu yang ingin dilihat, mereka dapat langsung membuka commit tersebut melalui endpoint https://github.com/<user/org>/…;
  • Hash commit dapat diburu secara brute force melalui UI GitHub
  • Hash commit juga bisa di-query melalui endpoint public events API GitHub

Kebijakan GitHub

  • Temuan ini baru-baru ini telah dilaporkan melalui program VDP GitHub, dan GitHub menegaskan bahwa repositori memang dirancang untuk bekerja seperti ini
  • Setelah meninjau dokumentasi, terlihat bahwa GitHub memang telah mendokumentasikan dengan jelas apa yang harus diharapkan pengguna pada kasus-kasus yang dijelaskan di atas

Dampak

  • Selama masih ada setidaknya satu fork, semua commit dalam jaringan repositori tersebut (baik commit di repositori "upstream" maupun fork "downstream") akan tetap ada selamanya
  • Arsitektur repositori GitHub memang membutuhkan cacat desain ini, dan sebagian besar pengguna GitHub kemungkinan tidak memahami bagaimana jaringan repositori sebenarnya bekerja sehingga menjadi kurang aman
  • Seiring secret scanning berkembang hingga dapat memindai semua commit dalam jaringan repositori, pengguna bisa menerima peringatan tentang secret yang bahkan bukan miliknya
  • Tiga skenario ini memang mengejutkan, tetapi belum mencakup semua cara GitHub dapat menyimpan data yang telah dihapus dari repositori

Opini GN⁺

  • Artikel ini mengangkat isu keamanan penting bagi organisasi yang menggunakan GitHub. Fakta bahwa data dari repositori yang dihapus atau dijadikan privat masih dapat diakses sangat mengejutkan. Ini tampak sebagai cacat desain mendasar yang berasal dari arsitektur jaringan repositori GitHub
  • Para developer perlu menyadari masalah ini dan berhati-hati saat melakukan commit data penting atau secret ke GitHub. Sekali didorong ke repositori publik, data itu mungkin dapat diakses selamanya. Jika secret penting bocor, satu-satunya cara benar-benar menanganinya adalah melalui rotasi kunci
  • GitHub memang mengungkapkan dan mendokumentasikan masalah ini secara transparan, tetapi sebagian besar pengguna kemungkinan tidak sepenuhnya memahami cara kerja jaringan repositori. GitHub perlu berupaya lebih keras untuk meningkatkan kesadaran dan mengedukasi pengguna tentang masalah ini
  • Masalah serupa mungkin juga ada di sistem version control lain. Developer dan organisasi harus benar-benar memahami arsitektur serta batasan alat yang mereka gunakan saat mengelola data penting
  • Untuk mencegah kebocoran data penting, diperlukan langkah-langkah keamanan berlapis seperti kontrol akses yang ketat, penerapan prinsip hak akses minimum, secret scanning dan pemantauan rutin. Yang terpenting, kesadaran keamanan yang tinggi dari developer sangatlah penting

1 komentar

 
GN⁺ 2024-07-25
Komentar Hacker News
  • Sudah dilaporkan ke HackerOne pada 2018, tetapi GitHub tidak memperbaikinya karena menganggap ini sebagai perilaku yang memang disengaja. Kesimpulan: alih-alih memakai fork privat, salin repositori untuk digunakan
  • GitHub terobsesi membuat semuanya menjadi publik dan tidak dapat diubah. Misalnya, untuk menghapus komentar, Anda harus mengirim email berisi identitas resmi kepada pemilik repositori
  • Pengguna seharusnya tidak perlu mengetahui masalah seperti ini pada fitur "privat", dan fakta bahwa GitHub menganggapnya sebagai fitur, bukan bug, menunjukkan sikap tidak peduli terhadap keamanan. Akan lebih tepat jika repositori privat disebut repositori "tidak tercantum"
  • Jika Anda memakai repositori privat dan fork privat lalu mengubah repositori menjadi publik, fork tersebut juga akan menjadi publik. GitHub mungkin mengklaim ini perilaku yang disengaja, tetapi seharusnya memaksa pengguna untuk mengubah repositori dan fork menjadi publik secara bersamaan
  • Perilaku ini terlihat seperti dark pattern, dan meskipun mata pencaharian orang dipertaruhkan, GitHub tampaknya tidak peduli. Ini karena adanya plausible deniability yang disengaja dan syarat layanan yang samar dianggap lebih berharga daripada kerusakan reputasi
  • Saya terkejut melihat komentar yang mengecilkan masalah ini. Saya sudah lama menggunakan GitHub, tetapi tidak pernah memperkirakan akibat seperti ini dan merasa cemas. Saya sarankan membaca artikelnya langsung
  • Masalah ini bukan hal baru. Banyak orang sudah menemukannya sebelumnya
  • OSPO GitHub sedang mengembangkan GitHub App open source untuk mempertahankan mirror privat dari fork publik. Rilis beta dijadwalkan minggu ini
  • Kerentanan yang sebenarnya adalah cara arsip GitHub Events mengekspos hash SHA1 dari repositori yang rentan. Seluruh jaringan dapat ditelusuri untuk mengakses repositori privat yang sudah dihapus
  • Masalahnya adalah cara data privat dapat bergantung pada data publik. Misalnya, jika commit privat bergantung pada commit publik C, lalu C dihapus dari repositori publik, GitHub harus tetap menyimpannya. Jika tidak, commit privat akan rusak
  • Semua commit tetap ada selamanya setelah dikirim ke GitHub, dan commit yang pernah dipublikasikan sekali akan selalu bisa diakses melalui hash commit