CodeRabbit güvenlik açığı istismarı: Basit bir PR’den 1 milyon depoda RCE ve yazma yetkisi elde etmeye kadar

• Güvenlik araştırma ekibi, CodeRabbit’in prodüksiyon sunucusunda uzaktan kod çalıştırma (RCE) ve API token’ları ile gizli bilgilerin sızdırılmasını başardı
• Rubocop kullanan bir PR ile ortam değişkenleri ele geçirildi; PostgreSQL erişimi ve 1 milyondan fazla depoda okuma/yazma imkanı elde edildi
• GitHub App’in private key’inin sızdırılmasıyla, public/private depolar dahil geniş çaplı depolara zararlı kod enjekte etme, kaynak kodunu değiştirme gibi gerçek zararlar mümkün hale geldi
• CodeRabbit tarafı, açık bildirildikten sonraki saatler içinde hızla müdahale etti ve güvenlik önlemlerini güçlendirdi
• Harici araçlar çalıştırılırken sandbox izolasyonu, en az yetki ve ağ erişiminin engellenmesi gibi önlemlerle güvenlik olaylarının önlenmesi gereği vurgulandı

---

Giriş

• Ocak 2025’te Kudelski Security araştırma ekibi, CodeRabbit’teki ciddi bir güvenlik açığını kamuoyuna açıkladı
• PR inceleme otomasyonu için yaygın biçimde kullanılan CodeRabbit’te uzaktan kod çalıştırma (RCE), ortam değişkenleri ile hassas bilgilerin sızması ve 1 milyondan fazla depoda okuma/yazma yetkisi elde edilmesi gibi kritik sorunlar doğrulandı
• Bu yazı, Black Hat USA’de sunulan açığın ayrıntılı analizini içeriyor ve kod tabanlı inceleme araçları ile entegre sistemlerdeki zafiyetlere dair gerçek bir örnek olarak yüksek referans değeri taşıyor
• Bildirilen açıklar, raporlamanın hemen ardından hızlıca yamandı

CodeRabbit’e genel bakış

• CodeRabbit, GitHub/GitLab Marketplace’te en çok kurulan yapay zeka tabanlı kod inceleme uygulaması
• İki platformda da 1 milyon depo ve 5 milyon pull request inceliyor
• Kullanıcı bir PR oluşturduğunda veya güncellediğinde, yapay zeka motoru kodu analiz ederek yorum ve önerileri otomatik üretiyor
• Kod özeti, güvenlik açığı tespiti, iyileştirme önerileri, diyagram üretimi gibi alanlarda geliştirici verimliliğini ciddi biçimde artırıyor

CodeRabbit kullanımı ve yetki yapısı

• Pro plan, linter ve SAST (statik analiz) araçlarıyla entegrasyon sunuyor
• GitHub hesabıyla kimlik doğrulama ve uygulama kurulumu sırasında, seçilen depolara okuma/yazma yetkisi veriliyor
• Bu yetki yönetimi kötüye kullanılırsa, kurulu olduğu tüm depolardaki koda doğrudan etki edebilir

Harici araç çalıştırma ve istismarın keşfi

• CodeRabbit, PR içindeki kod değişikliklerini algıladığında birden fazla harici statik analiz aracını (ör. Rubocop) otomatik olarak çalıştırıyor
• Rubocop, .rubocop.yml yapılandırma dosyası üzerinden harici Ruby eklenti dosyalarını (ext.rb vb.) yükleyebilecek şekilde tasarlanmış
  • Saldırgan, .rubocop.yml ve ext.rb içine kötü amaçlı kod yerleştirip PR göndererek CodeRabbit’in bu kodu uzak sunucuda çalıştırmasını sağlayabiliyor
• Bu teknikle çalışan kod, sunucudaki tüm ortam değişkenlerini saldırganın sunucusuna gönderdi

Ortam değişkeni sızıntısının analizi

• Sızan ortam değişkenleri arasında çeşitli servislerin API key’leri, token’ları ve parolaları bulunuyordu
  • Anthropic/OpenAI API anahtarları, encryption salt/password, GitHub App private key’i, PostgreSQL bağlantı bilgileri vb.
• RCE üzerinden veritabanına erişim, kod değiştirme ve servis içi bilgilerin sızdırılması gibi ikincil etkiler büyük ve yayılım potansiyeli yüksek
• Gerçek sunucuda daha ileri kötü amaçlı keşif yapılabilirdi; ancak servis operasyonu gözetilerek yalnızca minimum doğrulama yapılıp duruldu

1 milyon depoda okuma/yazma yetkisi elde edilmesi

• Ortam değişkenlerinde yer alan GITHUB_APP_PEM_FILE (private key) kullanılarak GitHub API’ye kimlik doğrulama yapılabiliyordu
• CodeRabbit’in erişebildiği tüm depolarda (public/private dahil)
  • kaynak kodunu okuma/yazma, release dosyalarını değiştirme (tedarik zinciri saldırısı), git geçmişini değiştirme gibi son derece güçlü yetkiler kullanılabiliyordu
• Yeniden üretim kodu (PoC) yayımlandı ve açığın pratikte istismar edilebilir olduğu kanıtlandı

PoC özeti

• PyGitHub gibi kütüphaneler kullanılarak sızdırılan private key, App ID vb. ile istenen herhangi bir depo için erişim token’ı üretilebildi
• Bu token ile private repository klonlama, dosya değiştirme, yeni commit atma ve release dosyalarını manipüle etme işlemleri otomatikleştirilebiliyordu

CodeRabbit’in şirket içi/gizli depolarının ihlal edilebilmesi

• CodeRabbit organizasyonu da bu uygulamayı kendi servisinde kurup kullandığı için, CodeRabbit’in iç kaynak kodu depolarına erişmek ve bunları klonlamak da mümkündü
• Yalnızca organizasyon adı biliniyorsa, kurulum ID’si sorgulanıp ilgili depo listesine doğrudan erişmek mümkün oluyordu

Etki özeti

• Private repository’lere yetkisiz erişim ve kişisel veri sızıntısı
• Kaynak kod manipülasyonu, zararlı yazılım/arka kapı ekleme gibi tedarik zinciri saldırısı tehditleri
• GitHub Actions gibi ek zafiyetlerle zincirleme kullanım ihtimali
• Doğrudan RCE nedeniyle veri yıkımı, servis kesintisi ve diğer hizmetlere sıçrayan zararlar

Bağlam ve yapay zekanın karar sınırları

• Saldırı sırasında bile PR’nin kendisi CodeRabbit tarafından normal şekilde incelendi; açıkla ilgili uyarı yorumu bıraksa da tehdit oluşturan ifadeyi fiilen tespit edemedi
• Bu durum, “yapay zeka kod inceleme aracı”nın gerçek risk bağlamını her zaman anlayamadığını gösteriyor

Müdahale ve öneriler

• CodeRabbit, açık bildirildikten sonraki saatler içinde Rubocop’u devre dışı bıraktı, gizli bilgileri yeniledi ve sistem denetimi yaptı
• Sorun, sandbox uygulanmayan bir araçta (Rubocop) ortaya çıktı; müdahale sonrası tüm harici araçların izole ortamlarda çalıştırılması yönünde iyileştirme yapıldı
• Güvenliği güçlendirmek için, harici araç çalışma ortamında ortam değişkenlerinin en aza indirilmesi, ağa erişebilen IP’lerin sınırlandırılması ve internet erişiminin kapatılması gibi savunmacı tasarım gereksinimleri vurgulandı

Sorumlu açıklama ve sonuç

• Ocak 2025’te, bildirim sonrasında hızlı müdahale ve düzeltme adımları atıldı
• Çalışma PoC ile sınırlı kaldı; ancak kötü niyetli bir saldırganın yüksek değerli depoları seçerek büyük ölçekli fidye yazılımı veya yıkıcı tedarik zinciri saldırıları için bunu kolayca kötüye kullanabileceği görüldü
• Harici analiz araçları ve yapay zeka tabanlı otomasyon servisleriyle entegrasyonda, sandbox ve en az yetki ilkesinin ne kadar kritik olduğu bir kez daha doğrulandı

[GN⁺]

Hacker News yorumu

• Vay canına, bu gerçekten çok ciddi bir zafiyet. Bu kez düzeltilmiş olmasına sevindim ama en başta böyle bir sorunun var olması bile başlı başına problem. Bulut platformunda kullanıcı kodunu analiz eden bir sistem kurarken en temel kural, analizörün mutlaka izole bir ortamda çalıştırılması gerektiğidir. Eklentiler üzerinden doğrudan kod enjeksiyonu olabilir ve linter/analizör/derleyiciler karmaşık yazılımlar olduğundan saldırı yüzeyi geniştir. Rastgele depolarda bu araçları paylaşımlı bir ortamda çalıştırmanın güvenli olduğunu asla varsaymamak gerekir. Ben de bir kod analiz platformu işlettim; müşteri depolarında bizim geliştirdiğimiz analizörleri çalıştırırken bile sandbox ortamında çalışacak şekilde tasarladık. Ortam değişkeni ya da ağ isteği yetkileri de vermedik ama analiz zaten yalnızca sandbox içinde çalışıyordu. Kod analizini güvenli yapmanın tek yolu bu
  https://github.com/getgrit/gritql

• Coderabbit ücretli aboneliğimi iptal ettim. Bir şirketin sorunu kabul etmesi için HN'de viral olacak kadar yayılması gerekip gerekmediği beni hep endişelendiriyor. Resmi blogda bu zafiyetle ilgili hiçbir şey yoktu ve bugün de yeni bir yazı görünmüyordu. Hata herkes yapabilir ama böyle bir şey olduğunda şeffaf davranmamak şirket imajına zarar veriyor bence

  • https://www.coderabbit.ai/blog/our-response-to-the-january-2025-kudelski-security-vulnerability-disclosure-action-and-continuous-improvement
  • İki yazı da bugün yayımlandı. Görünüşe göre araştırma ekibiyle coderabbit eşzamanlı açıklama konusunda anlaşmış. Böyle eşzamanlı açıklamalar, müşteri verisi sızıntısı ya da buna dair somut emareler yoksa zorunlu değildir; satıcının özellikle açıklamayı tercih ettiği durumlarda görülen bir uygulamadır. Güvenlik araştırmacılarının müdahaleyi övmesi iyi bir işaret gibi görünüyor
  • Güvenlik hatalarının çoğu herhangi bir duyuru olmadan sessizce çözülür. Müşteri verisi sızmadıysa — ki bu genelde doğrulanabilir — yasal olarak açıklama zorunlu değildir. Bunu yapmanın şirkete bir faydası da yokken neden mutlaka yapılması gerektiğini düşündüğünü anlamıyorum

• "Exploit çalışırken CodeRabbit'in PR'a tehlike uyarısı yorumu bırakması ama aslında o PR'ı çalıştırırken hackleniyor olması" gerçekten tuhaf. Yapay zekanın kendisinin hacklendiğini anlattığı bir dünyada yaşıyor olmamız gerçeküstü hissettiriyor. Ayrıca CodeRabbit ekibi hızlı tepki vermiş olsa da, "diğer satıcıların inceleme iletişimlerine hiç yanıt vermediği ve hâlâ savunmasız olduğu" kısmı daha da kaygı verici. CodeRabbit ekibini alkışlıyorum ama herkesin çok dikkatli hareket etmesi gerekiyor

  • CodeRabbit'in kendi sisteminde çalıştırılan exploit'i kendisinin incelemiş olması komik
  • Aslında exploit'i söyleyen anthropic modeli olmuş, coderabbit sistemi ise bunu görmezden gelmiş sayılır
  • Sonuçta bu, yapay zekanın zeki olmasından çok iyi tahmin yapan bir çıkarım sistemi olduğunu bir kez daha gösteriyor

• CEO'nun resmi açıklamasının bir kısmında "Sorun, Rubocop'un sandbox dışında çalışmasından kaynaklandı" deniyor ama açıkçası buna biraz şüpheyle yaklaşıyorum. Neden yalnızca bir şey tamamen farklı çalışıyordu ve ihlal edilen görev de neden tam olarak oydu?

  • Bunun neden yalan gibi göründüğünü anlamıyorum. Böyle hatalar sık olur
  • Zaten Kudelski Security araştırmacılarının birden fazla statik analiz aracını denemiş olma ihtimali yüksek. Sadece Rubocop farklı davranmış. Yazıda da çeşitli yaklaşım denemelerine dair izler var
  • "Neden yalnızca bazı görevler farklı yapılandırılmıştı?" → Biri hata yapmıştır. Bu olabilir. "Neden ihlal edilen servis özellikle o oldu?" sorusuna gelince, savunmasız bir servisin saldırıya uğraması zaten en doğal senaryo gibi geliyor

• Gerçekten ilgi çekici bir yazıydı ama aslında şaşırtıcı da değil. Kullanıcılar hiç düşünmeden geniş yetkili bir sürü uygulama ekliyor ve github'un izin sistemi de sorunlu olduğu için bunun olması kaçınılmazdı. Birçok kişi github uygulamalarına depo yazma yetkisini, hatta bulut yetkilerini bile gereğinden fazla veriyor. Branch protection olsa bile pull request üzerinden github actions içinde ayrıcalıklı erişim mümkün. Bunu düzgün yapılandırmak için github oidc audience değerini değiştirmeniz gerekiyor ama bunun dokümantasyonu da iyi değil. Uygulama geliştiricisinden yetkileri azaltılmış ve bazı özellikleri kapatılmış ayrı bir sürüm istemenize rağmen çoğu şirket ilgilenmiyor ve güvenlik sorununu anlamıyor. github'un uygulama erişim izinlerini daha ayrıntılı hale getirmesi gerekiyor; genel olarak izinlerin kendisi de çok daha granular olmalı

• Gerçekten sarsıcı. Yazının tamamını henüz okumadım bile ama o kadar çok şey var ki insanın başı dönüyor. Bir saldırganın 100 bin ila 1 milyon arası açık kaynak araç/kütüphane/yazılım dağıtım dosyasına zararlı yazılım yerleştirebilmiş olabileceği kısmı, dünyanın sonu gelebilirdi diye düşündürüyor. Buna benzer daha kaç sorun kaldığını hayal etmek bile zor

  • Artık 'Github Apps' yapısının kendisinin tehlikeli olduğunu düşünüyorum. CodeRabbit hiç ihlal edilmemiş olsaydı bile, böyle bir şirketin her zaman düzgün davranacağını kim garanti edebilir? İçeriden bir çalışanın kötü niyetli davranmayacağını kim garanti edebilir? Sıradan SaaS'ta kişisel veri yönetimi bir boyut, ama burada hedefli tedarik zinciri saldırılarının anahtarını ellerinde tutuyorlar ve bu tam bir kaosa yol açabilir
  • Yazılım sektörüne de en azından asgari güvenlik önlemleri ya da düzenlemeler gelmeli. Şu anki gibi herkesin her türlü hatayı yapabildiği ve hiçbir sorumluluğun olmadığı durum gerçekten anormal

• Böyle ağır güvenlik başarısızlıklarının bir "ihlâl olayı" ya da "vaka" olarak sınıflandırılıp medyada zorunlu olarak açıklanması gerektiğini düşünüyorum. 7.000'den fazla müşteriye ve 1 milyon depoya erişebilen bir aracın, en fazla 11 yaşındaki bir çocuğun bile yapabileceği kadar basit bir exploit ile delinmiş olmasından bahsediyoruz. Bu kadar kolay hacklenebiliyorsa botların, black hat aktörlerin ya da APT'lerin çoktan sızıp sessizce yerleşmiş olması gayet olası. White hat açıklamadan önce zaten içeri girdilerse, zafiyetin kapatılması yalnızca yeni saldırganları durdurur; hâlihazırda içeride olanları temizlemeyebilir. Güvenliğin zor olduğunu biliyorum ama insanların gerçekten kendine çeki düzen vermesi gerekiyor

  • "Zorunlu açıklama olmalı" diyorsanız Cyber Resilience Act'e bakabilirsiniz
  • Code Rabbit bir 'vibe coder' şirketi; ne bekleniyor ki? Güvenlik olayını saklıyor, Google Cloud bloguna da sadece pazarlama yazısı koyup hacklendiğinden bahsetmiyor ve hâlâ backdoor olmadığını kanıtlayamıyor
  • Benim gibi sıradan bir kullanıcı için, bu kadar karmaşık ve güçlü bir hizmetin bir hata sonucu tüm değerli verileri dışarı sızdırabilmesi, bundan sonra böyle araçları kullanmaya devam edip etmemem gerektiğini sorgulatıyor. Kurumlarda, devletlerde, banka taşeronlarında ve daha sayısız yerde bu tür uygulamalar kullanılıyor; siz de sadece T&C'yi kabul ederek üçüncü taraf erişim hakkı veriyorsunuz. >>“Bu her şirketin başına gelebilir” türü güven verme cümleleri<< hizmet sağlayıcıyı rahatlatabilir ama kullanıcı için daha büyük bir endişe kaynağı oluyor

• Sorunlardan biri de çeşitli kod analizörlerinin, bundler'ların ve derleyicilerin (ör. Rust derleyicisi gibi) hiçbir uyarı vermeden rastgele kod çalıştırabilmesi. Örneğin bir saldırgan işe alım ödevi bahanesiyle size bir depo gönderir ve siz de npm install ya da Rust derleme komutunu çalıştırırsanız, bilgisayarınız anında saldırganın eline geçebilir. Ya da şirkette tek bir çalışanın PC'si ele geçirilip depoya zararlı kod eklenirse, sonuçta küresel bir dev şirketin tamamı yabancı saldırganların kontrolüne girebilir. Bu yapıyı oluşturanlar npm ve Rust derleyicisi. Bu araçlar, harici komut çalıştırıldığında açık bir onay istemeli bence; komut izin listesi önbelleğe alınarak tekrar tekrar sormayabilirler. Linux da geliştiricilerin kolayca kullanabileceği güvenli bir sandbox sunmalı; şu anda bunu herkesin kendisinin kurması gerekiyor. Üstelik JS paketi kurulumu gibi bazı durumlarda harici kod çalıştırmak aslında gerekli bile değil. Ayrıca sırları ve ayarları ortam değişkenleriyle vermek gerçekten kötü bir yöntem. "12-factor app" fikrini ortaya atanlar sanki komut satırı bayrakları ya da yapılandırma dosyalarının varlığını bilmiyormuş gibi

  • Kod analizörü/derleyici/linter'ı bir depoda çalıştırmanın, kaynak kodun kendisini doğrudan çalıştırmaktan asla daha güvenli olmadığını her zaman akılda tutmak gerekir
  • Rust derleyicisinin (ve LLVM tabanlı derleyicilerin) rastgele kod çalıştırma zafiyetleri barındırdığını varsaymak daha güvenlidir. Ama resmî olarak bu özellik derleyicinin kendisinde (rustc) değil, build system olan cargo'dadır
  • Ortam değişkenleri yerine komut satırı / yapılandırma dosyası kullanırsanız değerler süreç tablosunda görünür. Sadece ps komutu bile her şeyi gösterir
  • "Asla çalıştırılmayacak değerli kod diye bir şey olabileceği" iması komik
  • "Her harici komut çalıştırmada açık onay" yaklaşımı işe yaramaz. Sorun harici komutlar değil, rastgele kodun kendisinin yürütülmesidir. Böyle bir kod tüm sistem API'lerine ve syscall'lara erişebilir, dolayısıyla bunu onay ekranlarıyla engelleyemezsiniz. Python/pip de aynı soruna sahip, yani iş işten çoktan geçti denebilir

• "İstenildiği gibi bir github uygulaması olmaya yarayan" izin anahtarının (private key) ortam değişkeninde tutulmuş olması gerçekten korkunç bir uygulama. Evet, herkes hacklenebilir ama bu, sır yönetiminin en temel kuralı. github'un resmi belgelerinde bile private key'in ortam değişkenine konmaması gerektiği açıkça yazıyor. Gerçekten işin ABC'si bu
  https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps#storing-private-keys

  • Eğer sır imzalama için kullanılmıyorsa, sonuçta vault'tan uygulamaya getirilmesi gerekir; yani production sisteme erişebilen biri o sırra da erişebilir demektir. Elbette güvenilmeyen kod çalıştırma senaryosunda ortamı izole etmek ve bu tür anahtarları hiç iletmemek gerekirdi ama bu genelde çok sık görülen bir durum değil
  • Ben CodeRabbit'ten Howon. Uygulama sırları için bulut sağlayıcısının key vault'unu kullanıyoruz, buna GH private key de dahil

• Rubocop yapılandırma dosyasında harici Ruby dosyalarının yolunun belirtilebildiğini okuduğum anda "Yoksa kullanıcı uzantı aracını doğrudan production ortamında mı çalıştırdılar..." diye düşündüm; nitekim öyleymiş. Elbette tek bir deliği kapatmak sistemi gerçekten güvenli yapmaz. Çoğu linter'ın kötü niyetli girdilere karşı denetlenmiş ya da fuzzing'den geçirilmiş olması da muhtemelen nadirdir; bu, resmen kapıyı açık bırakıp üstüne "Lütfen hackleyin!" diye neon tabela asmak gibi bir şey

  • CEO'nun resmi yanıtındaki “Rubocop sandbox dışında çalışıyordu” kısmına bakınca, asıl kök nedenin bu olduğu da pek inandırıcı gelmiyor