ghrc.io Diduga sebagai Situs Berbahaya

• Kebingungan sederhana akibat salah ketik antara ghcr.io dan ghrc.io menimbulkan ancaman keamanan serius
• ghrc.io sekilas terlihat seperti server nginx bawaan, tetapi secara internal terdeteksi meniru OCI API
• Situs ini, melalui header www-authenticate, mendorong klien kontainer untuk mengirim informasi autentikasi sensitif
• Jika tanpa sengaja memasukkan kredensial seperti lewat docker login atau memakai registry yang salah, dapat terjadi kebocoran kredensial
• Jika pernah login ke server yang salah, perlu mengganti kata sandi, mencabut PAT, dan memeriksa aktivitas mencurigakan pada akun GitHub

---

Gambaran umum

Kebingungan yang mudah terjadi karena salah ketik antara ghcr.io dan ghrc.io dapat memicu masalah keamanan yang sangat berbahaya. Pada ghrc.io, versi typo dari GitHub Container Registry (ghcr.io) yang digunakan banyak developer dan tim, terdeteksi upaya pencurian kredensial.

Apa itu ghcr.io

• ghcr.io adalah registry yang kompatibel dengan OCI untuk image kontainer dan artefak OCI
• Sebagai bagian dari GitHub, layanan ini dipakai luas sebagai registry populer oleh banyak proyek open source

ghrc.io: tampilan di permukaan

• Saat mengakses ghrc.io, yang terlihat hanyalah halaman default nginx
• Perilaku dasar seperti error 404 yang umum juga sama seperti server nginx biasa

Hakikat perilaku berbahaya tersebut

• Masalah utamanya muncul saat ada pemanggilan OCI API di bawah prefix /v2/
• Saat jalur ini diakses, ia menampilkan perilaku yang sangat mirip dengan registry kontainer resmi melalui header www-authenticate dan respons 401
• Terdapat header www-authenticate: Bearer realm="https://ghrc.io/token";
• Karena header ini, klien seperti Docker, containerd, podman, Kubernetes, dan lainnya akan secara otomatis mencoba mengirim informasi autentikasi pengguna ke https://ghrc.io/token
• Konfigurasi default nginx tidak memiliki header tersebut, sehingga ini jelas dikonfigurasi dengan sengaja

Tingkat bahaya: skenario pencurian kredensial

• Pola ini dinilai sebagai serangan pencurian kredensial berbasis typo-squatting
• Risikonya hanya muncul jika klien pengguna pernah memasukkan atau menyimpan kredensial untuk ghrc.io
• Contoh situasi ketika kredensial nyata dapat terekspos
  • Menjalankan docker login ghrc.io
  • Saat menggunakan docker/login-action di GitHub Action dan registry disetel ke ghrc.io
  • Menyimpan kredensial registry untuk ghrc.io di secret Kubernetes lalu mencoba melakukan image pull
• Jika hanya mencoba push/pull image ke ghrc.io, informasi autentikasi tidak akan terekspos (setelah percobaan token anonim, server mengembalikan error)

Langkah penanganan

• Jika pernah tanpa sengaja login ke ghrc.io, segera ganti kata sandi dan cabut PAT (personal access token) yang digunakan
• Wajib memeriksa login tidak wajar atau aktivitas berbahaya di akun GitHub
• Penyerang dapat memanfaatkan ini untuk menambahkan image berbahaya ke repository di ghcr.io atau memperoleh akses ke akun

Kesimpulan

• Perlu waspada terhadap situs phishing yang memakai alamat mirip dengan ghcr.io
• Diperlukan kebijakan yang lebih ketat dalam pengelolaan informasi keamanan seperti kredensial, token, dan kata sandi

[ndrgrd]

Bukankah akan lebih baik jika langsung diubah menjadi subdomain github.com saja.

[GN⁺]

Komentar Hacker News

• Menekankan bahwa ini serius karena GitHub Container registry hanya mendukung token klasik lama, bukan token granular
  Juga melampirkan tautan ke dokumentasi terkait dan issue
  Dokumentasi resmi
  Diskusi komunitas
  Issue roadmap

  • Karena masalah ini, classic PAT tidak bisa dimatikan sepenuhnya
    Sebagai langkah tambahan, masa berlaku sesi bisa dibuat pendek dan autentikasi ulang bisa dipaksa lewat enterprise SSO, tetapi itu menjadi pilihan yang merepotkan untuk satu classic PAT yang memang dibutuhkan

  • Akan bagus jika seseorang membeli semua domain typo dengan niat baik lalu menyerahkannya ke Microsoft
    Menurutnya Microsoft perlu mengganti nama registry tersebut
    Namanya terlalu membingungkan, dan dia sendiri juga sering salah ketik

• Baru bisa memahami masalahnya setelah membaca isu domain itu beberapa kali; ini adalah vektor serangan yang cukup meyakinkan

  • Bukan hanya dia, banyak orang lain juga mengalami hal serupa
    Sudah mencoba berkali-kali, gagal, bahkan setelah me-restart komputer pun masalah yang sama tetap terjadi
    Sebagai referensi, ada juga jawaban Stack Overflow dan diskusi forum Docker

• Menyertakan tautan ke hasil pencarian kode terkait ghrc.io

• Tidak menyadari masalahnya sampai artikel itu secara langsung menunjukkan bahwa huruf c dan r tertukar

  • Ini jenis typo yang saya buat hampir lebih dari 10 kali sehari

  • Masalahnya di sini adalah nama domain GitHub memang berantakan
    Nama container registry-nya benar-benar buruk

• Membagikan tautan diskusi Hacker News sebelumnya

• Whois menunjukkan bahwa domain ini terdaftar di dynadot
  Karena itu, tampaknya layak untuk melaporkannya ke [e-mail]

• Menyebutkan bahwa banyak proyek open source menggunakan domain ini, sambil sekali lagi membagikan hasil pencarian kode

  • GitHub secara internal membutuhkan alat yang bisa mengusulkan dan menerapkan perbaikan otomatis secara massal

  • Juga disebutkan bahwa hasil pencarian kode GitHub memang cukup besar skalanya

• Menyatakan kekhawatiran bahwa typo dalam pekerjaan CI bisa menimbulkan masalah besar

• Menyarankan agar sebisa mungkin menghindari penggunaan TLD yang nilai keamanannya rendah
  Keamanan harus lebih diutamakan daripada upaya agar terlihat lucu
  Karena penonaktifan domain jahat mungkin tidak secepat .com, dia merasa .com yang dikelola Verisign di AS lebih bisa dipercaya
  Mengandalkan British Indian Ocean Territory, Kolombia, atau Anguilla dianggap tidak tepat

  • Menambahkan bahwa TLD .io dikelola oleh perusahaan AS, Afilias

• Bertanya apakah risiko sebenarnya di sini adalah masalah penggunaan ulang token
  Bearer token tidak memberikan password secara langsung, dan sambil mengutip RFC serta dokumentasi Mozilla, dia mempertanyakan apakah masalah sebenarnya bukan pada token autentikasi itu sendiri, melainkan pada proses mendapatkan token lagi untuk autentikasi
  Jika OAuth lintas domain tidak menggunakan ulang token, bukankah pada akhirnya domain palsu itu tidak akan bisa mendapatkan token?

  • Dijawab oleh penulis blog sekaligus maintainer OCI
    Dalam permintaan untuk mendapatkan Bearer token, password atau PAT dikirim dalam header Basic Auth yang di-encode dengan base64, tetapi pada dasarnya dikirim sebagai plaintext
    Saat permintaan diterima, header www-authenticate muncul dan token autentikasi diambil untuk memverifikasi akses ke registry, lalu token tersebut memang kedaluwarsa
    Namun struktur masalahnya adalah penyerang bukan mencuri token yang sebenarnya, melainkan memancing agar kredensial untuk mendapatkan Bearer token itulah yang dikirim