Bug reset kata sandi GitLab membuat lebih dari 5.300 server berisiko

 (scmagazine.com)
1 poin oleh GN⁺ 2024-01-29 | 1 komentar | Bagikan ke WhatsApp
  • Kerentanan CVE-2023-7028 di GitLab masih ada pada 5.379 server di seluruh dunia sekitar dua minggu setelah patch dirilis, dan dapat berujung pada pengambilalihan akun developer dari jarak jauh
  • Masalahnya terdapat pada alur reset kata sandi di sistem login, yang memungkinkan penyerang membuat tautan reset dikirim ke alamat email miliknya yang belum terverifikasi tanpa interaksi korban
  • GitLab mengungkap kerentanan dengan skor CVSS 10 pada 11 Januari 2024 dan menyediakan pembaruan keamanan untuk versi 16.5.6, 16.6.4, 16.7.2 serta versi backport 16.1.6 hingga 16.4.5
  • Shadowserver Foundation mendeteksi 5.379 instance rentan pada 23 Januari; jumlah terbanyak berada di AS dengan 964 dan Jerman dengan 730, lalu turun menjadi 4.652 pada 24 Januari
  • Operator GitLab Community Edition dan Enterprise Edition self-managed perlu memeriksa permintaan reset berbentuk array multi-email di log dan mengaktifkan 2FA untuk menurunkan risiko pengambilalihan akun

Risiko CVE-2023-7028

  • CVE-2023-7028 adalah kerentanan pada sistem login GitLab yang dapat berujung pada pengambilalihan akun jarak jauh di server GitLab yang belum dipatch
  • GitLab pertama kali mengungkap dan menambal kerentanan ini pada 11 Januari 2024
  • Skor CVSS kerentanan ini adalah 10, tingkat keparahan tertinggi
  • Dengan permintaan HTTP yang disusun secara khusus, penyerang dapat mengirim email reset kata sandi ke alamat email miliknya yang belum terverifikasi tanpa interaksi korban
  • Seorang peneliti yang mengujinya pada GitLab Community Edition 16.6.1 menilai CVE-2023-7028 di AttackerKB sebagai “sangat efektif dan mudah dieksploitasi”

Versi terdampak dan patch

  • GitLab menyediakan pembaruan keamanan untuk versi berikut
    • 16.5.6
    • 16.6.4
    • 16.7.2
  • Patch juga di-backport ke versi berikut
    • 16.1.6
    • 16.2.9
    • 16.3.7
    • 16.4.5

Hasil deteksi Shadowserver

  • Pada 23 Januari, sekitar dua minggu setelah patch dirilis, Shadowserver Foundation mendeteksi 5.379 instance GitLab yang rentan di seluruh dunia
  • Berdasarkan negara, instance rentan paling banyak berada di Amerika Serikat dan Jerman
    • Amerika Serikat: 964
    • Jerman: 730
  • Pada 24 Januari, jumlah instance rentan di dasbor Shadowserver turun menjadi 4.652
  • Pihak Shadowserver mengonfirmasi bahwa penurunan itu sendiri positif, tetapi masih perlu waktu lebih banyak untuk menentukan apakah ini tren nyata atau fluktuasi sementara dalam pemindaian

Cara memeriksa indikator kompromi

  • Pelanggan GitLab Community Edition dan GitLab Enterprise Edition self-managed perlu memeriksa log untuk jejak eksploitasi CVE-2023-7028
  • Log dan kondisi yang perlu diperiksa adalah sebagai berikut
    • gitlab-rails/production_json.log: permintaan HTTP yang masuk ke path /users/password dengan params.value.email berupa array JSON yang berisi beberapa alamat email
    • gitlabs-rails/audit_json.log: ketika meta.caller.id adalah PasswordsController#create dan target_Details berupa array JSON yang berisi beberapa alamat email

Dampak pada GitLab.com, GitLab Dedicated, dan 2FA

  • GitLab menyatakan tidak mendeteksi kasus eksploitasi bug ini pada instance GitLab.com atau GitLab Dedicated
  • Pelanggan disarankan untuk mengaktifkan 2FA
  • 2FA mencegah pengambilalihan akun melalui CVE-2023-7028, tetapi pada instance yang belum dipatch, penyerang masih dapat mereset kata sandi dan membuat pengguna terkunci dari akunnya

Bacaan terkait

1 komentar

 
GN⁺ 2024-01-29
Opini Hacker News

  • Menurut saya, fitur menghubungkan alamat email ke akun di webapp berbasis akun itu benar-benar menakutkan
    Saya tidak tahu riwayat bug ini, tetapi ini area yang langsung dicoba oleh penetration tester, dan ini tipe lama yang bisa ditelusuri kembali hingga kerentanan di implementasi MTA Unix standar awal 2000-an, yang dapat ditipu agar mengirim email reset kata sandi ke beberapa alamat
    Di GitLab, sepertinya framework web yang kaya fitur justru menghidupkan kembali permukaan serangan ini; pembaca HN umum yang tertarik sebaiknya benar-benar memeriksa fitur reset kata sandi, terutama logika penghubungan email
    Meski setahu saya tim keamanan GitLab cukup bagus, munculnya bug seperti ini menunjukkan betapa sulitnya menghindari bug jenis ini

    • Melihat perilaku yang dijelaskan di komentar lain, bug ini tampaknya sangat mudah dihindari
      Kalau memakai bahasa bertipe statis, bug seperti ini sulit muncul kecuali sengaja dibuat begitu, dan dalam code review pun akan terlalu mencolok sampai-sampai rekan kerja mungkin curiga ada yang mencoba menanam backdoor
    • Sulit mengatakan bahwa tim keamanan GitLab itu hebat
      Fitur menghubungkan alamat email tambahan baru saja ditambahkan dan bukan fitur yang sudah ada sejak awal, jadi sepertinya mereka mengambil jalan pintas tanpa benar-benar menguji penyalahgunaan fitur baru yang terkait keamanan akun
      Selain itu, tampaknya juga pernah ada CVE dengan CVSS 9.6 yang membuat fitur integrasi dapat menjalankan perintah dengan hak pengguna lain
      Dari luar, laju peluncuran fitur tampak melampaui laju pengujian yang aman, mungkin karena monetisasi sulit
      Dari sudut pandang bisnis ini bisa dimengerti, tetapi jika inti dari solusi Git self-hosted pada dasarnya adalah manajemen akun, isu keamanan seperti ini bisa meruntuhkan bisnis itu sendiri
    • Sudut pandang yang aneh
      Kalau bukan ke email, harus dihubungkan ke apa? Saya mengelola situs dengan basis pengguna besar selama lebih dari 20 tahun; awalnya kami memakai nama pengguna dan itu bencana
      Semua orang tahu nama pengguna satu sama lain, sehingga brute force kata sandi atau percobaan reset menjadi mudah
      Masalahnya bukan penggunaan email itu sendiri, melainkan membuat logika login dan pemulihan kata sandi terlalu kompleks, menyalahgunakan abstraksi, melakukan overengineering, dan memasukkan kode di area sensitif keamanan tanpa verifikasi yang memadai
      Riwayat keamanan GitLab juga perlu dilihat. Beberapa kali dalam setahun ada exploit kritis yang memaksa distribusi GitLab di-upgrade darurat, dan dari sisi keamanan, GitLab adalah produk terburuk yang pernah saya pakai
    • Setiap kali menerima email reset kata sandi yang salah alamat, saya khawatir apakah seseorang diam-diam menambahkan alamat email pemulihan di luar kendali saya untuk mengambil alih akun saya
      Itu belum pernah terjadi pada saya, tetapi seperti kasus ini, sayangnya hal itu sangat mungkin terjadi
    • Bagaimana exploit ini bekerja? Saya penasaran kalau ada tautan tulisan yang merangkumnya

  • Jika ingin melihat bagian di codebase Rails yang menyebabkan exploit ini, commit perbaikannya ada di sini
    https://gitlab.com/gitlab-org/gitlab/-/commit/c571840ba2f0e9...

    • Ini lebih terlihat seperti refactoring lanjutan daripada perbaikan sebenarnya
      Sepertinya perbaikannya ada di sini: https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...
      Berubah dari recoverable.send_reset_password_instructions(to: email) if recoverable&.persisted? menjadi recoverable.send_reset_password_instructions if recoverable&.persisted?
    • # Concern that overrides the Devise methods / # to send reset password instructions to any verified user email / module RecoverableByAnyEmail, jadi ini memang fitur?
      Namun di versi yang sudah diperbaiki pun namanya masih RecoverableByAnyEmail. Apakah orang-orang tidak membaca kode di sekitar bagian yang mereka ubah?
    • Sebagai orang yang tidak terlalu paham Ruby, bisa jelaskan di mana letak kesalahannya?

  • Kami juga terkena serangan ini, dan melihatnya digunakan bersama “fitur” kedua yang memperbesar paparan
    Pada dasarnya, untuk serangan ini Anda perlu mengetahui email pengguna yang ingin direset, tetapi ada alamat email tersembunyi yang terikat ke ID pengguna GitLab. ID ini berupa angka yang meningkat dari 1
    ID 1 atau 2 kemungkinan besar adalah admin, sehingga menjadi target bagus, dan emailnya berbentuk seperti 1-user@mail.noreply..
    Itu benar-benar buruk dan tampak terotomatisasi. Di sini 2FA yang menyelamatkan kami

  • Reset kata sandi lewat email adalah mimpi buruk keamanan meski diimplementasikan dengan benar
    Yang lebih buruk, di sebagian besar layanan fitur ini tidak bisa dimatikan, dan cara mengakalinya biasanya hanya Enterprise SSO
    Sebagian layanan memungkinkan pengaturan nomor telepon untuk token SMS, tetapi saya belum pernah melihat metode yang mewajibkan token email dan SMS sekaligus

    • Saya penasaran, dalam hal apa Anda menganggapnya mimpi buruk keamanan?

  • Ini mengingatkan saya pada bug yang memungkinkan brute force akun jika memasukkan array kata sandi ke form login
    Kebetulan itu antarmuka web murahan milik perangkat spam, dan saya tidak tahu apakah itu disengaja atau kode buatan pemula PHP
    Saat itu, seorang pengguna yang memasukkan karakter khusus yang masih jarang dipakai di kata sandinya menemukan hal tersebut

    • Ruby on Rails memperlakukan array yang diterima sebagai parameter .where(...) ORM sebagai kondisi OR di antara nilai-nilai array tersebut
      Jadi jika kodenya seperti User.where(name: name, password: password), rasanya hal seperti ini sangat mungkin terjadi

  • Ini pengingat bagus bahwa layanan internal seperti GitLab sebaiknya ditempatkan di belakang VPN yang hanya dapat diakses pengguna tepercaya

    • Saya benar-benar tidak paham mengapa manajemen versi internal dan CI/CD ditaruh di internet publik
      VPN memang ada untuk penggunaan seperti ini
    • Betul, kami juga terselamatkan berkat itu, dan ada beberapa pengaman lain juga
      Saya bekerja di perusahaan telekomunikasi milik negara yang besar, dan tim jaringan kami benar-benar hebat. Mereka menjaga agar tim server tidak melewati batas
      Kami memang mengekspos GitLab sampai tingkat tertentu untuk proyek eksternal dan konsultan tertentu, tetapi tetap tidak bisa diakses bebas dari internet
      Pengguna juga dikelola di AD, jadi tidak ada koneksi SMTP sama sekali untuk reset kata sandi
      Namun, kewajiban 2FA perlu lebih diperketat. Saat ini tiap proyek masih dibiarkan menentukan aturan 2FA-nya sendiri

  • Sejujurnya, saya tidak akan menaruh server internal apa pun di internet publik
    Lebih baik aksesnya hanya lewat VPN agar ada lapisan pertahanan kedua

    • Khususnya untuk hal seperti GitLab, ada banyak manfaat dari integrasi eksternal yang perlu memanggil GitLab API
      Memang bisa saja hanya request tersebut yang dimasukkan ke allowlist, tetapi itu bisa cukup merepotkan
    • GitLab adalah pilihan favorit saya untuk menjalankan forge kode: git.drk.sc
      Kalau lingkungannya berkeamanan tinggi, saya setuju menggunakan taktik yang lebih defensif, tetapi menurut saya perangkat lunak harus dirancang agar tetap tahan di web publik
    • Benar, terutama jika perusahaan memakai GitLab yang di-host sendiri, itu harus selalu ditempatkan di belakang VPN perusahaan

  • Mengotomatiskan pembaruan GitLab itu benar-benar mudah
    Sebagai salah satu cara saja, jika memakai GitLab dengan Docker+Compose, itu sangat stabil, dan alat seperti Watchtower bisa memperbaruinya setiap hari
    Saya punya dua server GitLab yang berjalan seperti ini selama lebih dari 7 tahun tanpa masalah apa pun
    Kalau melihat sekitar, ada terlalu banyak GitLab versi lama, dan saya tidak tahu sebenarnya para adminnya sedang melakukan apa

  • Semoga kita berhenti berpura-pura bahwa Ruby/Rails adalah pilihan bagus untuk perangkat lunak yang harus aman
    Saya paham GitLab sudah terlanjur seperti itu dan harus ditangani, tetapi ke depannya kita harus berhenti berpura-pura bahwa bahasa dan framework yang mengutamakan kecerdikan dan alur kontrol tersembunyi lebih baik daripada alternatif yang lebih membosankan
    Kalau saya terdengar terlalu kesal, itu karena saya harus menangani codebase Ruby yang berjalan di produksi
    Karena seseorang mengira 17 lapis abstraksi akan membuat kode menjadi sangat mudah diskalakan, saya bisa melihat cukup banyak skenario dengan isu serupa yang tinggal menunggu untuk dieksploitasi

    • Menurut saya sebaiknya hindari bahasa atau framework yang memungkinkan pemanggil menentukan suatu parameter sebagai string atau array string
      Biaya satu kesalahan ini kemungkinan besar lebih besar daripada seluruh nilai yang diperoleh dari penggunaan fitur tersebut

  • Ini satu lagi pengingat untuk selalu menggunakan SSO dan 2FA