Bug reset kata sandi GitLab membuat lebih dari 5,3 ribu server terpapar risiko

Server yang belum ditambal untuk kerentanan GitLab CVE-2023-7028

• Kerentanan kritis GitLab CVE-2023-7028 per Selasa masih belum ditambal pada lebih dari 5.300 server, sehingga memungkinkan pengambilalihan akun pengembang perangkat lunak dari jarak jauh.
• Bug ini menerima skor CVSS maksimum 10, dan pertama kali diungkap serta ditambal oleh GitLab pada 11 Januari.
• Kerentanan pada sistem login GitLab memungkinkan penyerang mengirim tautan reset kata sandi ke alamat email yang tidak diautentikasi tanpa interaksi dari korban.

Informasi patch dan hasil pengujian kerentanan

• Pembaruan keamanan telah dirilis untuk GitLab versi 16.5.6, 16.6.4, 16.7.2, dan juga di-backport ke versi 16.1.6, 16.2.9, 16.3.7, 16.4.5.
• Seorang peneliti menguji bug ini pada GitLab Community Edition versi 16.6.1 dan membagikan hasilnya ke AttackerKB dengan menyatakan bahwa bug ini "sangat efektif dan mudah dimanfaatkan".

Deteksi instance rentan dan tren penurunan

• Hampir dua minggu setelah patch tersedia, Shadowserver Foundation mendeteksi 5.379 instance GitLab yang rentan di seluruh dunia.
• Amerika Serikat dan Jerman memiliki jumlah instance rentan terbanyak, masing-masing 964 dan 730.
• Alat dasbor Shadowserver menunjukkan bahwa pada 24 Januari jumlah instance rentan turun menjadi 4.652.
• Dalam konfirmasi kepada SC Media, juru bicara Shadowserver menyebut penurunan jumlah instance rentan sebagai perkembangan positif, tetapi menambahkan bahwa masih diperlukan lebih banyak waktu untuk menentukan apakah ini merupakan tren atau sekadar fluktuasi sementara.

Indikator kompromi GitLab CVE-2023-7028

• Pelanggan GitLab yang memiliki instance self-managed GitLab Community Edition dan GitLab Enterprise Edition harus meninjau log untuk memeriksa apakah CVE-2023-7028 telah dieksploitasi.
• Perlu memeriksa permintaan HTTP ke jalur /users/password di gitlab-rails/production_json.log, dan memastikan apakah params.value.email berbentuk array JSON yang berisi beberapa alamat email.
• Perlu memeriksa entri di gitlabs-rails/audit_json.log tempat meta.caller.id adalah PasswordsController#create dan target_Details berbentuk array JSON yang berisi beberapa alamat email.
• Pada GitLab.com atau instance khusus GitLab, eksploitasi bug ini tidak terdeteksi.
• GitLab juga merekomendasikan untuk mengaktifkan autentikasi dua faktor (2FA), yang dapat mencegah pengambilalihan akun melalui CVE-2023-7028, tetapi pengguna instance yang belum ditambal tetap berisiko terkunci dari akun mereka jika penyerang mengeksploitasi kerentanan ini dengan mereset kata sandi.

Opini GN⁺

• Artikel ini memberikan informasi penting terkait kerentanan keamanan serius di GitLab. CVE-2023-7028 dapat menjadi ancaman langsung terhadap keamanan akun pengembang perangkat lunak dan memerlukan tindakan yang tepat.
• Meskipun patch telah tersedia, masih banyak server di seluruh dunia yang tetap berada dalam kondisi rentan, menekankan pentingnya kesadaran keamanan dan pembaruan tepat waktu.
• Artikel ini menyoroti pentingnya autentikasi dua faktor (2FA) dan mendorong pengguna memanfaatkan lapisan keamanan tambahan, sehingga membantu meningkatkan kesadaran terhadap keamanan.

[GN⁺]

Komentar Hacker News

• "Saya ingin membahas risiko dari fitur 'mengaitkan alamat email dengan akun' di aplikasi web berbasis akun. Ini adalah salah satu hal yang langsung dicoba dimanipulasi oleh para pentester, dan kerentanannya sudah ditemukan sejak awal 2000-an. Masalah seperti ini juga terulang di GitLab. GitLab memiliki tim keamanan yang hebat, tetapi tampaknya bug seperti ini sulit dihindari. Jika pembaca Hacker News biasa tertarik pada cerita ini, saya harap mereka memeriksa fitur reset kata sandi mereka sendiri, terutama logika pengaitan email."

• "Saya membagikan tautan commit tempat kerentanan ini ditemukan di codebase Rails: tautan commit GitLab"

• "Saya terdampak oleh bug ini. Serangan memerlukan pengetahuan tentang email pengguna, tetapi ada alamat email tersembunyi yang terhubung ke ID pengguna GitLab (angka yang bertambah mulai dari 1). ID 1 atau 2 kemungkinan besar adalah admin, jadi menjadi target yang bagus. Format emailnya seperti '[e-mail].<gitlabhost>'. Ini tampak seperti serangan otomatis, dan 2FA menyelamatkan kami."

• "Reset kata sandi lewat email adalah mimpi buruk keamanan bahkan ketika diimplementasikan dengan benar. Di sebagian besar layanan, fitur ini tidak bisa dinonaktifkan, dan alternatifnya sering kali hanya SSO enterprise. Beberapa layanan memungkinkan Anda menetapkan nomor telepon untuk token SMS, tetapi saya belum pernah melihat opsi yang mewajibkan email dan token SMS sekaligus."

• "Saya pernah menemukan bug yang memungkinkan brute force akun dengan memasukkan array kata sandi ke formulir login. Ini adalah antarmuka web yang buruk untuk sebuah spam appliance, dan saya tidak yakin apakah itu disengaja atau hasil kode dari pemula PHP. Seorang pengguna yang saat itu memakai kata sandi dengan karakter khusus menemukan hal ini."

• "Ini mengingatkan bahwa layanan internal seperti GitLab sebaiknya dijalankan di balik VPN yang hanya bisa diakses oleh pengguna tepercaya."

• "Otomatisasi pembaruan GitLab sangat mudah. Gunakan GitLab di Docker+Compose dan perbarui setiap hari melalui Watchtower atau semacamnya. Saya sudah menjalankan server GitLab dengan cara ini selama lebih dari 7 tahun tanpa masalah. Kalau melihat sekeliling, banyak GitLab yang masih memakai versi lama; sebenarnya para admin itu sedang apa?"

• "Saya punya prinsip untuk tidak mengekspos server internal jenis apa pun ke internet publik. Saya membuatnya hanya bisa diakses lewat VPN untuk menambahkan lapisan pertahanan kedua."

• "Ini pengingat lain bahwa kita harus selalu memakai SSO dan jangan lupa menggunakan 2FA."

• "Mari berhenti menganggap Ruby/Rails sebagai pilihan yang cocok untuk perangkat lunak yang harus aman. Saya paham GitLab harus menangani ini, tetapi ke depan kita perlu mengakui bahwa sesuatu yang lebih sederhana lebih baik daripada bahasa dan framework yang memprioritaskan alur kontrol yang cerdas dan tersembunyi. Saya bekerja pada codebase Ruby produksi, dan saya bisa dengan jelas melihat kemungkinan masalah serupa muncul karena seseorang menganggap beberapa lapisan abstraksi membuat kode menjadi sangat mudah diperluas."