GitLab parola sıfırlama hatası 5,3 binden fazla sunucuyu riske atıyor

 (scmagazine.com)
1 puan yazan GN⁺ 2024-01-29 | 1 yorum | WhatsApp'ta paylaş

GitLab CVE-2023-7028 açığı için yamalanmamış sunucular

  • GitLab’ın kritik açığı CVE-2023-7028, salı günü itibarıyla 5.300’den fazla sunucuda yamalanmamış durumda ve yazılım geliştiricilerinin hesaplarının uzaktan ele geçirilmesine yol açabilir.
  • Bu hata, en yüksek CVSS puanı olan 10 puanı aldı ve GitLab tarafından ilk kez 11 Ocak’ta açıklanıp yamalandı.
  • GitLab giriş sistemindeki bu açık nedeniyle saldırganlar, mağdurun herhangi bir etkileşimi olmadan parola sıfırlama bağlantısını doğrulanmamış bir e-posta adresine gönderebilir.

Yama bilgileri ve açık test sonuçları

  • GitLab 16.5.6, 16.6.4 ve 16.7.2 sürümleri için güvenlik güncellemeleri yayımlandı; ayrıca 16.1.6, 16.2.9, 16.3.7 ve 16.4.5 sürümlerine de backport edildi.
  • Bir araştırmacı, GitLab Community Edition 16.6.1 sürümünde hatayı test etti ve sonucu AttackerKB’de paylaşarak bunun "çok etkili ve kolayca istismar edilebilir" olduğunu söyledi.

Savunmasız instance tespiti ve azalma eğilimi

  • Yamanın kullanılabilir hale gelmesinden yaklaşık iki hafta sonra, Shadowserver Foundation tarafından dünya genelinde 5.379 savunmasız GitLab instance’ı tespit edildi.
  • ABD ve Almanya, sırasıyla 964 ve 730 ile en fazla savunmasız instance’a sahip ülkeler oldu.
  • Shadowserver’ın dashboard aracı, 24 Ocak’ta savunmasız instance sayısının 4.652’ye düştüğünü gösterdi.
  • Shadowserver sözcüsü, SC Media’ya yaptığı doğrulamada savunmasız instance’lardaki azalmanın olumlu bir gelişme olduğunu, ancak bunun bir eğilim mi yoksa geçici bir dalgalanma mı olduğunu anlamak için daha fazla zamana ihtiyaç bulunduğunu belirtti.

GitLab CVE-2023-7028 uzlaşma göstergeleri

  • GitLab Community Edition ve GitLab Enterprise Edition’ın self-hosted instance’larını kullanan GitLab müşterileri, günlükleri inceleyerek CVE-2023-7028’in istismar edilip edilmediğini kontrol etmeli.
  • gitlab-rails/production_json.log içinde /users/password yoluna yapılan HTTP istekleri kontrol edilmeli ve params.value.email alanının birden fazla e-posta adresi içeren bir JSON dizisi olup olmadığı doğrulanmalı.
  • gitlabs-rails/audit_json.log içinde meta.caller.id değeri PasswordsController#create olan ve target_Details alanı birden fazla e-posta adresi içeren JSON dizisi şeklinde olan kayıtlar kontrol edilmeli.
  • GitLab.com veya GitLab Dedicated instance’larında bu hatanın istismar edildiğine dair bir tespit yapılmadı.
  • GitLab ayrıca iki faktörlü kimlik doğrulamanın (2FA) etkinleştirilmesini öneriyor; bu, CVE-2023-7028 üzerinden hesap ele geçirilmesini engellese de yamalanmamış instance kullanıcıları, saldırganların açığı kullanarak parolayı sıfırlaması sonucu yine de hesaplarından kilitlenme riskiyle karşı karşıya kalabilir.

GN⁺ görüşü

  • Bu makale, GitLab’ın kritik güvenlik açığıyla ilgili önemli bilgiler sunuyor. CVE-2023-7028, yazılım geliştiricilerinin hesap güvenliği için doğrudan bir tehdit olabilir ve uygun önlemler alınmasını gerektirir.
  • Yama sunulmuş olmasına rağmen dünya genelinde çok sayıda sunucu hâlâ savunmasız durumda; bu da güvenlik farkındalığının ve zamanında güncelleme yapmanın önemini vurguluyor.
  • İki faktörlü kimlik doğrulamanın (2FA) önemini öne çıkararak kullanıcılara ek güvenlik önlemlerinden yararlanmayı tavsiye ediyor ve güvenlik konusunda farkındalığın artmasına katkı sağlıyor.

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-29
Hacker News yorumları

  • "Hesap tabanlı web uygulamalarında 'e-posta adresini hesaba bağlama' işlevinin risklerinden bahsetmek istiyorum. Bu, pentester'ların anında kurcalamaya çalıştığı şeylerden biridir ve 2000'lerin başından beri zafiyetler bulunuyor. GitLab'da da bu sorun yeniden ortaya çıktı. GitLab'ın harika bir güvenlik ekibi var ama bu tür hatalardan kaçınmak zor görünüyor. Bu hikâyeyle ilgilenen sıradan bir Hacker News okuruysanız, kendi parola sıfırlama işlevinizi, özellikle de e-posta bağlama mantığını kontrol etmenizi öneririm."

  • "Bu zafiyeti Rails kod tabanında bulan commit bağlantısını paylaşıyorum: GitLab commit bağlantısı"

  • "Bu hata yüzünden etkilendim. Saldırının mümkün olması için kullanıcının e-posta adresini bilmek gerekiyor ama GitLab kullanıcı ID'sine (1'den başlayarak artan sayı) bağlı gizli bir e-posta adresi var. ID 1 ya da 2 büyük olasılıkla yöneticidir, bu yüzden iyi bir hedef olur. E-posta biçimi '1-user@mail.noreply.<gitlabhost>' gibi. Otomatikleştirilmiş bir saldırı gibi görünüyordu ve bizi 2FA kurtardı."

  • "E-posta üzerinden parola sıfırlama, doğru uygulanmış olsa bile bir güvenlik kâbusudur. Çoğu hizmette bu işlev devre dışı bırakılamaz ve alternatif çoğu zaman yalnızca kurumsal SSO'dur. Bazı hizmetlerde SMS token'ları için bir telefon numarası ayarlayabiliyorsunuz ama hem e-posta hem SMS token'ını birlikte zorunlu kılan bir seçenek hiç görmedim."

  • "Bir zamanlar giriş formuna parola dizisi girerek hesaba brute-force saldırısı yapılabilen bir hata bulmuştum. Bu, spam appliance için berbat bir web arayüzüydü; bunun kasıtlı mı olduğunu yoksa bir PHP acemisinin mi yazdığını bilmiyorum. O sırada özel karakter içeren parola kullanan bir kullanıcı bunu fark etmişti."

  • "GitLab gibi iç servislerin, yalnızca güvenilir kullanıcıların erişebildiği bir VPN arkasında çalıştırılmasının iyi bir fikir olduğunu hatırlatıyor."

  • "GitLab güncellemelerini otomatikleştirmek çok kolay. GitLab'ı Docker+Compose üzerinde kullanıp Watchtower vb. ile her gün güncelleyebilirsiniz. GitLab sunucularını 7 yıldan uzun süredir bu şekilde işletiyorum ve hiç sorun yaşamadım. Etrafa bakınca pek çok GitLab'ın eski sürümde olduğunu görüyorsunuz; yöneticiler ne yapıyor?"

  • "Her tür iç sunucuyu genel internete açık bırakmama gibi bir ilkem var. Yalnızca VPN üzerinden erişilebilir yaparak ikinci bir savunma hattı kuruyorum."

  • "Her zaman SSO kullanmak ve 2FA kullanmayı unutmamak gerektiğine dair bir başka hatırlatma."

  • "Güvenli olması gereken yazılımlar için Ruby/Rails'in uygun bir seçim olduğu fikrini artık bırakalım. GitLab'ın bunu yönetmek zorunda olduğunu anlıyorum ama gelecekte, akıllı ve gizli kontrol akışını önceleyen dil ve framework'ler yerine daha basit şeylerin daha iyi olduğunu kabul etmeliyiz. Üretimde çalışan bir Ruby kod tabanında çalışıyorum ve birkaç katman soyutlamanın kodu çok genişletilebilir hâle getirdiğini düşünen biri yüzünden benzer sorunların ortaya çıkmasının gayet mümkün olduğunu açıkça görebiliyorum."