HashiCorp Vault'daki ikinci kritik RCE yamalanmadı, OpenBao ise düzeltmeleri yayınladı

Ne rapor edildi

dev.to'da yayımlanan bir rapor, HashiCorp Vault kod tabanında, OpenBao fork'unu da etkileyen ve belirli koşullar altında sunucunun tamamen ele geçirilmesine imkân veren ikinci bir uzaktan kod yürütme (RCE) açığını ele alıyor. Makaleye göre ControlPlane güvenlik firmasındaki mühendisler, kimlik doğrulaması gerektirmeyen bir giriş yolunu hatalı yapılandırılmış bir Raft anlık görüntü politikasıyla birleştirerek dört ayrı hatayı zincirlemek suretiyle sömürüyü (exploit) gösterdiler; böylece root yetkileriyle keyfi kod çalıştırılabiliyor.

Raporun ortaya koyduğu durum asimetrik. OpenBao düzeltmeleri 2.6.3 ve 2.7.0 sürümlerinde çoktan yayınladı; HashiCorp Vault ise makalenin anlatımına göre hâlâ yamalanmamış durumda. Belirtilen neden teknik değil prosedürel: İki proje arasında koordine edilmiş bir açıklama (coordinated disclosure) gerçekleşmemiş olması, Vault operatörlerini üretici onaylı bir düzeltme olmadan bırakıyor.

Saldırı zincirinin nasıl çalıştığı iddiası

dev.to yazısına göre sömürü dört aşamada ilerliyor. Önce saldırgan, kimlik doğrulaması gerektirmeyen bir API uç noktasına ulaşıyor; zayıf girdi temizleme ve doğrulama sayesinde kötü niyetli bir payload enjekte edilip uygulama bağlamında yürütülebiliyor. İkinci aşamada saldırgan, bu kaldıraç noktasından dağıtık veriyi tutarlı tutmak için var olan Raft anlık görüntü mekanizmasını kötüye kullanarak anlık görüntü sürecine komutlar yerleştiriyor; rapora göre burada komut doğrulaması eksik olduğundan enjekte edilen kod root yetkileriyle çalışıyor.

Üçüncü aşamada, root erişimiyle saldırgan sistem yapılandırmasını yeniden yazabilir, güvenlik kontrollerini kapatabilir veya arka kapılar yerleştirebilir; makaleye göre bu, firewall ve sızma tespiti gibi geleneksel savunmaları etkisiz hale getiriyor. Dördüncü aşamada sunucu tamamen ele geçirilmiş oluyor: sırlar (secret) dışarı sızdırılabilir, sistem davranışı değiştirilebilir veya makine, daha geniş ağa sıçrama noktası olarak kullanılabilir.

Makale ayrıca zincirin teorik değil pratik olduğunu savunuyor: birçok dağıtımın operasyonel kolaylık için kimlik doğrulamasız uç noktaları erişilebilir bıraktığını ve Raft anlık görüntü politikalarının sıklıkla varsayılan olarak açık ya da hatalı yapılandırılmış olduğunu, bu durumun saldırganlara öngörülebilir bir yol sunduğunu belirtiyor.

OpenBao yamaladı, Vault yamalamadı

Rapora göre OpenBao düzeltmeleri iki şey yapıyor: Daha önce kimlik doğrulaması gerektirmeyen giriş noktasında girdileri denetlemek ve Raft anlık görüntü mekanizmasını sıkılaştırarak anlık görüntülerin komut çalıştırma yoluna dönüşmesini engellemek. Her iki değişiklik de OpenBao 2.6.3 ve 2.7.0 sürümlerinde mevcut.

HashiCorp Vault ise ayrı bir konu. Makaleye göre ürün, HashiCorp ile raporun OpenBao'nun bakımıcısı olarak adlandırdığı IBM arasında koordine edilmiş bir açıklama yaşanmadığı için bir yama almadı ve rapor herhangi bir HashiCorp güvenlik bültenine işaret etmiyor. Bunun sonucunda Vault dağıtımlarının aynı sömürü zincirine, resmî bir önlem olmadan açık olduğu belirtiliyor. Bu iddiaların tek bir yayımlanmış rapordan geldiğini ve mevcut malzemede ikinci bir kaynakça doğrulanmadığını belirtmek gerek.

Vault operatörleri için ara dönem adımları

Bir yama çıkana dek makale üç savunmacı önlem öneriyor: İlk giriş noktasını ortadan kaldırmak için kimlik doğrulaması gerektirmeyen uç noktaları kapatın veya kilitleyin; Raft anlık görüntü ayarlarını gözden geçirin ve kilitleyin ki mekanizma komut çalıştırmak için kullanılamasın; ve beklenmedik şekilde çalışan komutlar ya da değişen kritik binary'ler ve yapılandırma dosyaları gibi olağandışı etkinlikleri yakından izleyin. Yazar, bu adımların riski azalttığını ama altta yatan hatayı düzeltmediğini açıkça belirtiyor ve kullanıcıları iki üreticiyi de koordine edilmiş açıklama yapmaya ve resmî bir çözüm yayınlamaya zorlamaya çağırıyor.

Neden önemli

Vault sunucuları, bir altyapının geri kalanının bağlı olduğu kimlik bilgilerini, sertifikaları ve şifreleme anahtarlarını barındırır; bu yüzden bunlardan birinde root düzeyinde kod yürütme, neredeyse en kötü senaryodur — o noktaya ulaşan bir saldırgan, aşağı akıştaki her şeyi koruyan sırları alıp gidebilir. Bu olay ayrıca fork'ların kod tabanını paylaşması durumunda ortaya çıkan yapısal bir riski gösteriyor: Bir fork yama yayınladığında, diff'in kendisi diğer üründeki düzeltilmemiş hataya bir harita gibi hizmet edebilir; bu da OpenBao sürümleri ile Vault yaması arasındaki boşluğu basit bir gecikmeden daha tehlikeli kılıyor. Her şeyden önce, bu durum üreticiler arası koordine edilmiş açıklama için somut bir argüman — ortak bir süreç olmadığında, bir kullanıcı tabanını koruyan yama bir diğerini korumasız bırakabilir ve ortada kalan operatörlere yol gösterecek resmî hiçbir şey olmayabilir.