Eksploit kerentanan CodeRabbit: dari PR sederhana hingga RCE dan perolehan izin tulis pada 1 juta repositori

• Tim riset keamanan berhasil melakukan remote code execution (RCE) di server produksi CodeRabbit serta membocorkan token API dan rahasia
• Melalui PR yang memanfaatkan Rubocop, mereka dapat mencuri variabel lingkungan, serta mengakses PostgreSQL dan membaca/menulis ke 1 juta repositori
• Dengan kebocoran private key GitHub App, dimungkinkan penyuntikan malware ke repositori publik maupun privat dalam skala besar, modifikasi source code, dan dampak nyata lainnya
• Pihak CodeRabbit merespons segera dalam hitungan jam setelah laporan kerentanan dan memperkuat langkah-langkah keamanan
• Saat menjalankan tool eksternal, ditekankan perlunya isolasi sandbox, prinsip hak akses minimum, dan pemblokiran jaringan untuk mencegah insiden keamanan

---

Pendahuluan

• Pada Januari 2025, tim riset Kudelski Security mengungkap kerentanan keamanan serius di CodeRabbit
• Pada CodeRabbit, yang luas digunakan sebagai tool otomatisasi review PR, ditemukan masalah besar berupa remote code execution (RCE), kebocoran variabel lingkungan dan informasi sensitif, serta perolehan hak Read/Write ke lebih dari 1 juta repositori
• Tulisan ini memuat analisis rinci atas kerentanan yang dipublikasikan dalam presentasi Black Hat USA, dan sangat bernilai sebagai contoh nyata kerentanan pada tool review berbasis kode dan sistem integrasinya
• Kerentanan yang dilaporkan ditambal dengan cepat segera setelah pelaporan

Gambaran umum CodeRabbit

• CodeRabbit adalah aplikasi code review berbasis AI yang paling banyak dipasang di GitHub/GitLab Marketplace
• Di dua platform tersebut, layanan ini telah mereview 1 juta repositori dan 5 juta pull request
• Setiap kali pengguna membuat atau memperbarui PR, mesin AI menganalisis kode dan otomatis membuat komentar serta saran
• Fitur seperti ringkasan kode, deteksi kerentanan keamanan, usulan perbaikan, dan pembuatan diagram memberi dampak besar pada produktivitas developer

Penggunaan CodeRabbit dan struktur perizinan

• Paket Pro menyediakan fitur integrasi dengan tool linter dan SAST (analisis statis)
• Saat mengautentikasi akun GitHub dan memasang aplikasi, pengguna memberikan izin baca/tulis ke repositori yang dipilih
• Jika pengelolaan izin ini disalahgunakan, maka dapat memberikan dampak langsung pada kode di seluruh repositori tempat aplikasi dipasang

Eksekusi tool eksternal dan penemuan eksploit

• Saat CodeRabbit mendeteksi perubahan kode dalam PR, ia otomatis menjalankan banyak tool analisis statis eksternal (misalnya Rubocop)
• Rubocop dirancang agar dapat memuat file ekstensi Ruby eksternal (ext.rb dan sejenisnya) melalui file konfigurasi .rubocop.yml
  • Penyerang dapat menyisipkan kode berbahaya ke .rubocop.yml dan ext.rb, lalu mengirim PR untuk mendorong CodeRabbit mengeksekusi kode tersebut di server jarak jauh
• Dengan teknik ini, kode yang dijalankan mengirim seluruh variabel lingkungan server ke server milik penyerang

Analisis isi kebocoran variabel lingkungan

• Variabel lingkungan yang bocor mencakup API key, token, dan kata sandi dari berbagai layanan, seperti:
  • API key Anthropic/OpenAI, encryption salt/password, private key GitHub App, informasi koneksi PostgreSQL, dan lain-lain
• Melalui RCE, dimungkinkan akses ke database, perubahan kode, dan kebocoran informasi internal layanan, sehingga dampak lanjutan sangat besar dan berdaya sebar tinggi
• Penelusuran berbahaya lebih lanjut di server produksi sebenarnya mungkin dilakukan, namun demi mempertimbangkan operasional layanan, verifikasi dibatasi seminimal mungkin lalu dihentikan

Perolehan hak Read/Write ke 1 juta repositori

• Dengan menggunakan GITHUB_APP_PEM_FILE (private key) yang terdapat di variabel lingkungan, autentikasi ke GitHub API menjadi memungkinkan
• Terhadap seluruh repositori yang dapat diakses CodeRabbit (termasuk publik dan privat), pelaku dapat:
  • membaca/menulis source code, mengganti file rilis (serangan supply chain), mengubah riwayat git, dan menjalankan hak akses yang sangat kuat lainnya
• Kode reproduksi (PoC) dipublikasikan dan membuktikan bahwa eksploitasi nyata memang memungkinkan

Ringkasan PoC

• Dengan library seperti PyGitHub, private key yang bocor, App ID, dan data lain digunakan untuk menerbitkan access token repositori arbitrer
• Melalui token ini, otomatisasi atas kloning repositori privat, perubahan file, commit baru, dan manipulasi file rilis menjadi mungkin

Potensi kompromi repositori internal/nonpublik CodeRabbit

• Organisasi CodeRabbit sendiri juga memasang dan menggunakan layanannya, sehingga akses dan kloning repositori source code internal CodeRabbit juga dimungkinkan
• Jika nama organisasinya diketahui, maka dengan melihat installation ID, akses ke daftar repositori terkait dapat segera dilakukan

Ringkasan dampak

• Akses tidak sah ke repositori privat dan kebocoran data pribadi
• Ancaman serangan supply chain seperti manipulasi source code, penyisipan malware/backdoor, dan sejenisnya
• Potensi dirangkai dengan kerentanan tambahan seperti GitHub Actions
• RCE langsung dapat menyebabkan penghancuran data, gangguan layanan, dan dampak berantai ke layanan lain

Konteks dan keterbatasan penilaian AI

• Bahkan selama serangan berlangsung, PR itu sendiri tetap direview secara normal oleh CodeRabbit, dan meski meninggalkan komentar peringatan kerentanan, ia tetap gagal mengidentifikasi sintaks berbahaya sebagai ancaman nyata
• Ini menunjukkan bahwa tool review kode AI belum tentu mampu memahami konteks situasi risiko yang sebenarnya

Tanggapan dan rekomendasi

• CodeRabbit menonaktifkan Rubocop, mengganti rahasia, dan melakukan audit sistem dalam hitungan jam setelah laporan kerentanan
• Masalah terjadi pada tool (Rubocop) yang tidak memakai sandbox, dan setelah penanganan, sistem diperbaiki agar seluruh tool eksternal dijalankan dalam lingkungan terisolasi
• Untuk memperkuat keamanan, ditekankan perlunya desain defensif seperti meminimalkan variabel lingkungan pada lingkungan eksekusi tool eksternal, membatasi IP untuk akses jaringan, dan memblokir akses internet

Pengungkapan yang bertanggung jawab dan kesimpulan

• Pada Januari 2025, setelah pelaporan, respons dan tindakan penanganan dilakukan dengan cepat
• Meski hanya berhenti pada PoC, dipastikan bahwa penyerang jahat dapat dengan mudah menyalahgunakannya untuk memilih repositori bernilai tinggi, menjalankan ransomware skala besar, atau melancarkan serangan supply chain yang destruktif
• Pentingnya penerapan sandbox dan prinsip hak akses minimum kembali ditegaskan saat mengintegrasikan tool analisis eksternal dan layanan otomatisasi berbasis AI

[GN⁺]

Komentar Hacker News

• Wah, ini benar-benar kerentanan yang serius. Syukurlah sudah diperbaiki kali ini, tapi fakta bahwa masalah seperti ini bisa ada sejak awal tetap bermasalah. Aturan paling dasar saat membangun sistem yang menganalisis kode pengguna di platform cloud adalah analyzer harus selalu dijalankan di lingkungan yang terisolasi. Injeksi kode langsung bisa terjadi melalui plugin, dan linter/analyzer/compiler adalah perangkat lunak kompleks dengan permukaan kerentanan yang luas. Menurut saya, kita sama sekali tidak boleh berasumsi bahwa menjalankan alat-alat seperti ini pada repositori arbitrer di lingkungan bersama itu aman. Saya juga pernah menjalankan platform analisis kode, dan bahkan saat kami menjalankan analyzer buatan kami sendiri pada repositori pelanggan, kami merancangnya agar berjalan di lingkungan sandbox. Tidak ada variabel lingkungan atau izin permintaan jaringan juga, tetapi analisis tetap hanya berjalan di sandbox. Itu satu-satunya cara untuk membuat analisis kode aman
  https://github.com/getgrit/gritql

• Saya membatalkan langganan berbayar Coderabbit. Saya selalu khawatir melihat situasi di mana perusahaan baru mengakui masalah setelah isu itu viral di HN. Tidak ada penyebutan tentang kerentanan ini di blog resmi mereka, dan hari ini juga tidak ada tulisan baru. Saya paham semua orang bisa membuat kesalahan, tetapi menurut saya citra perusahaan rusak ketika mereka tidak mengungkapkannya secara transparan saat hal seperti ini terjadi

  • https://www.coderabbit.ai/blog/our-response-to-the-january-2025-kudelski-security-vulnerability-disclosure-action-and-continuous-improvement
  • Kedua artikel itu sama-sama dipublikasikan hari ini. Sepertinya tim peneliti dan coderabbit sepakat untuk melakukan pengungkapan secara bersamaan. Pengungkapan serempak seperti ini bukan sesuatu yang wajib dilakukan kecuali ada kebocoran data pelanggan atau bukti keadaan yang kuat, tetapi memang kadang menjadi praktik ketika vendor memang ingin mengungkapkannya. Fakta bahwa para peneliti keamanan memuji respons mereka terlihat sebagai sinyal yang baik
  • Mayoritas bug keamanan diselesaikan diam-diam tanpa pengumuman khusus. Jika tidak ada kebocoran informasi pelanggan (dan itu biasanya bisa diverifikasi), secara hukum tidak ada kewajiban untuk mengungkapkannya. Tidak ada keuntungan khusus dari mengungkapkannya, jadi saya tidak paham kenapa harus selalu begitu

• Sangat aneh bahwa "selama exploit berjalan, CodeRabbit sendiri meninggalkan komentar peringatan bahaya di PR, padahal pada kenyataannya peretasan terjadi saat menjalankan PR itu." Terasa ganjil hidup di dunia di mana AI memberi tahu bahwa dirinya sedang diretas. Selain itu, meskipun tim CodeRabbit merespons dengan cepat, yang lebih mengkhawatirkan adalah "vendor lain sama sekali tidak menanggapi kontak investigasi dan masih rentan." Tepuk tangan untuk tim CodeRabbit, tapi semua orang tetap harus bergerak dengan hati-hati

  • Lucu bahwa CodeRabbit meninjau sendiri exploit yang dijalankan di sistemnya sendiri
  • Sebenarnya yang memberi tahu soal exploit itu adalah model anthropic, dan sistem coderabbit justru mengabaikannya
  • Ini sekali lagi menunjukkan bahwa AI bukan benar-benar pintar, melainkan hanya sistem inferensi yang pandai menebak

• Di sebagian pernyataan resmi CEO disebutkan bahwa "masalah terjadi karena Rubocop berjalan di luar lingkungan sandbox", tetapi jujur saya agak ragu. Kenapa hanya satu hal tertentu yang berjalan dengan cara yang sepenuhnya berbeda, dan kebetulan itulah pekerjaan yang berhasil ditembus?

  • Saya tidak mengerti kenapa itu terlihat seperti kebohongan. Kesalahan seperti ini sering terjadi
  • Sejak awal, kemungkinan besar para peneliti dari Kudelski Security memang mencoba beberapa alat analisis statis. Hanya Rubocop yang kebetulan berperilaku unik. Artikel itu juga menunjukkan jejak berbagai percobaan pendekatan
  • "Kenapa hanya pekerjaan tertentu yang dikonfigurasi berbeda" → karena seseorang membuat kesalahan. Hal seperti ini bisa terjadi. Untuk pertanyaan "kenapa layanan yang rentan justru yang ditembus", menurut saya justru wajar kalau layanan yang rentan itulah yang diserang

• Tulisan yang sangat menarik, tetapi sebenarnya juga tidak mengejutkan. Pengguna menambahkan banyak aplikasi dengan izin yang sangat luas tanpa berpikir panjang, dan sistem perizinan github juga bermasalah, jadi kejadian seperti ini pada dasarnya tak terelakkan. Banyak orang memberikan izin menulis repositori pada github app, bahkan sampai izin cloud, secara berlebihan. Bahkan jika ada branch protection, akses istimewa tetap bisa didapat melalui github actions dari pull request. Untuk mengaturnya dengan benar, kita harus memodifikasi github oidc audience, dan dokumentasinya juga tidak bagus. Bahkan jika kita meminta vendor aplikasi membuat versi terpisah dengan izin yang diperkecil dan sebagian fitur dimatikan, kebanyakan tidak tertarik dan tidak memahami masalah keamanan. github perlu memungkinkan kontrol izin aplikasi yang lebih terperinci, dan secara umum izin itu sendiri harus jauh lebih granular

• Ini benar-benar mengejutkan. Saya bahkan belum selesai membaca artikelnya, tapi isinya sudah terlalu banyak sampai bikin kepala pening. Pada bagian yang menyebutkan bahwa peretas bisa menyisipkan malware ke file distribusi open source tool/library/software dalam skala 100 ribu sampai 1 juta, saya sampai berpikir dunia benar-benar bisa berakhir. Sulit bahkan membayangkan berapa banyak masalah serupa yang masih tersisa di masa depan

  • Sekarang saya mulai merasa bahwa 'Github Apps' itu sendiri berbahaya. Bahkan jika CodeRabbit tidak ditembus, di mana jaminannya bahwa perusahaan seperti ini akan selalu bertindak dengan itikad baik? Siapa yang bisa menjamin tidak ada pegawai internal yang bertindak jahat? Pengelolaan data pribadi di SaaS biasa itu satu hal, tetapi di sini mereka memegang kunci untuk serangan supply chain yang tertarget dan bisa menyebabkan kekacauan besar
  • Industri perangkat lunak juga perlu memiliki setidaknya pengaman minimum atau regulasi. Kondisi sekarang, di mana siapa saja bisa membuat kesalahan apa pun tanpa tanggung jawab apa pun, benar-benar tidak normal

• Saya rasa kegagalan keamanan separah ini harus diklasifikasikan sebagai "pelanggaran" atau "insiden", dan wajib diungkap ke publik melalui media. Ini adalah alat yang dapat mengakses sekitar 7.000 pelanggan dan 1 juta repositori, tetapi berhasil ditembus oleh exploit sederhana yang bahkan anak 11 tahun pun mungkin bisa buat. Jika diretas semudah ini, besar kemungkinan bot, black hat, atau APT sudah lebih dulu masuk dan berdiam secara tersembunyi. Jika mereka sudah masuk sebelum white hat mengungkapkannya, patch kerentanan hanya akan menghentikan penyerang baru, tetapi mungkin tidak mengusir pihak yang sudah telanjur menyusup. Saya tahu keamanan itu sulit, tapi rasanya orang-orang benar-benar perlu sadar

  • Jika "wajib diungkap", mungkin bisa melihat Cyber Resilience Act
  • Code Rabbit adalah perusahaan 'vibe coder', jadi saya tidak tahu ekspektasi apa yang seharusnya ada. Mereka menyembunyikan insiden keamanan, bahkan hanya memuat tulisan pemasaran di blog Google Cloud tanpa menyebut fakta peretasan, dan sampai sekarang pun masih tidak bisa memberi bukti bahwa tidak ada backdoor
  • Sebagai pengguna biasa, fakta bahwa layanan yang serumit dan sekuat ini bisa secara tidak sengaja membocorkan semua data berharga ke luar membuat saya bertanya-tanya apakah saya masih harus terus memakai hal seperti ini. Aplikasi seperti ini dipakai di organisasi, pemerintah, outsourcing bank, dan banyak tempat lain, dan strukturnya adalah menyerahkan hak akses pihak ketiga hanya dengan menyetujui T&C. >>“Kalimat penenang bahwa hal seperti ini bisa terjadi pada semua perusahaan”<< mungkin menenangkan penyedia, tetapi justru membuat pengguna makin khawatir

• Salah satu masalahnya adalah berbagai code analyzer, bundler, dan compiler (misalnya compiler Rust) bisa mengeksekusi kode arbitrer tanpa peringatan apa pun. Misalnya, seorang peretas mengirim repositori dengan alasan itu tugas rekrutmen, lalu saya menjalankan “npm install” atau perintah kompilasi Rust, dan komputer saya bisa langsung jatuh ke tangan peretas. Atau jika satu PC rekan kerja di perusahaan diretas lalu malware masuk ke repositori, pada akhirnya seluruh perusahaan global besar pun bisa dikuasai peretas asing. Struktur seperti ini diciptakan oleh npm dan compiler Rust. Alat-alat semacam ini perlu meminta konfirmasi eksplisit setiap kali mengeksekusi perintah eksternal (meski daftar izin perintah bisa di-cache agar tidak terus ditanyakan). Linux juga harus menyediakan sandbox aman yang mudah dipakai pengembang, tetapi sekarang orang harus membuatnya sendiri satu per satu. Selain itu, dalam beberapa kasus seperti instalasi paket JS, eksekusi kode eksternal sebenarnya tidak diperlukan. Dan memasukkan secret serta konfigurasi lewat variabel lingkungan adalah cara yang sangat buruk. Orang yang membuat "12-factor app" tampaknya tidak tahu bahwa command-line switch dan file konfigurasi itu ada

  • Kita harus selalu sadar bahwa menjalankan code analyzer/builder/linter pada repositori tidak pernah lebih aman daripada sekadar mengeksekusi source code itu sendiri
  • Untuk compiler Rust (dan compiler berbasis LLVM), lebih aman berasumsi ada kerentanan eksekusi kode arbitrer. Tetapi secara resmi, itu fitur yang hanya berlaku pada build system cargo, bukan rustc (compiler itu sendiri)
  • Jika memakai command line/file konfigurasi alih-alih variabel lingkungan, nilainya terekspos di process table. Cukup dengan perintah "ps", semua informasinya bisa terlihat
  • Menarik ada implikasi bahwa "mungkin ada kode bernilai yang sama sekali tidak akan pernah dieksekusi"
  • Pendekatan "konfirmasi eksplisit setiap kali menjalankan semua perintah eksternal" tidak berguna. Masalahnya bukan perintah eksternal, melainkan eksekusi kode arbitrer itu sendiri. Kode semacam ini bisa mengakses semua system API dan syscall, jadi tidak ada cara untuk meminta konfirmasi. Python/pip juga punya masalah yang sama, jadi menurut saya semuanya sudah terlambat

• Fakta bahwa kunci izin (private key) yang memungkinkan "menjadi github app sesuai keinginan" disimpan di variabel lingkungan adalah praktik yang benar-benar paling buruk. Siapa pun memang bisa diretas, tetapi ini adalah dasar paling dasar dari pengelolaan secret. Dokumentasi resmi github pun dengan jelas mengatakan agar tidak menyimpan private key di variabel lingkungan. Ini benar-benar tingkat paling dasar
  https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps#storing-private-keys

  • Jika secret itu bukan untuk penandatanganan, pada akhirnya secret itu tetap harus dibawa dari vault ke aplikasi, jadi bisa mengakses sistem produksi pada dasarnya berarti juga bisa mengakses secret itu. Tentu saja, dalam situasi menjalankan kode yang tidak tepercaya, lingkungan seharusnya diisolasi dan kunci seperti ini tidak boleh diberikan, tetapi biasanya ini bukan kasus yang umum
  • Saya Howon dari CodeRabbit. Kami menggunakan key vault dari penyedia cloud untuk secret aplikasi, termasuk GH private key

• Saat membaca kalimat bahwa file konfigurasi Rubocop bisa menentukan path file Ruby ekstensi, saya langsung berpikir, "masa iya mereka menjalankan alat ekstensi buatan pengguna langsung di lingkungan produksi..." dan ternyata memang begitu. Tentu saja, hanya menutup satu lubang seperti ini tidak otomatis membuat semuanya aman. Kebanyakan linter pun mungkin jarang diaudit atau di-fuzz terhadap input yang agresif, jadi ini pada dasarnya seperti membiarkan pintu terbuka sambil menyalakan papan neon bertuliskan “silakan retas saya!”

  • Jika melihat bagian dalam tanggapan resmi CEO yang menyebut “Rubocop berjalan di luar sandbox”, sepertinya itu bukan inti masalah yang sebenarnya