GitLab parola sıfırlama hatası 5.300'den fazla sunucuyu riske atıyor

 (scmagazine.com)
1 puan yazan GN⁺ 2024-01-29 | 1 yorum | WhatsApp'ta paylaş
  • GitLab'daki CVE-2023-7028 güvenlik açığı, yama yayımlandıktan yaklaşık 2 hafta sonra bile dünya genelinde 5.379 sunucuda bulunmaya devam ediyor ve uzaktan geliştirici hesabı ele geçirilmesine yol açabilir
  • Sorun, oturum açma sistemindeki parola sıfırlama akışında yer alıyor; saldırganlar, kurbanın etkileşimi olmadan sıfırlama bağlantısının kendi doğrulanmamış e-posta adreslerine gönderilmesini sağlayabiliyor
  • GitLab, 11 Ocak 2024'te CVSS 10 puanlı güvenlik açığını duyurdu ve 16.5.6, 16.6.4, 16.7.2 ile 16.1.6~16.4.5 backport sürümlerine güvenlik güncellemeleri sağladı
  • Shadowserver Foundation, 23 Ocak'ta 5.379 savunmasız instance tespit etti; en yüksek sayılar ABD'de 964 ve Almanya'da 730 idi. 24 Ocak'ta sayı 4.652'ye düştü
  • Self-managed GitLab Community Edition ve Enterprise Edition operatörleri, loglarda çoklu e-posta dizisi biçimindeki sıfırlama isteklerini kontrol etmeli ve hesap ele geçirilme riskini azaltmak için 2FA'yı etkinleştirmeli

CVE-2023-7028'in riski

  • CVE-2023-7028, GitLab oturum açma sistemindeki bir güvenlik açığıdır ve yamalanmamış GitLab sunucularında uzaktan hesap ele geçirilmesine yol açabilir
  • GitLab, bu güvenlik açığını ilk kez 11 Ocak 2024'te duyurdu ve yamaladı
  • Güvenlik açığının CVSS puanı 10 olup en yüksek ciddiyet düzeyindedir
  • Saldırganlar, özel olarak hazırlanmış HTTP istekleriyle, kurban etkileşimi olmadan parola sıfırlama e-postasını kendi doğrulanmamış e-posta adreslerine gönderebilir
  • GitLab Community Edition 16.6.1 üzerinde test yapan bir araştırmacı, AttackerKB'de CVE-2023-7028'i “çok etkili ve istismar etmesi kolay” olarak değerlendirdi

Etkilenen sürümler ve yama

  • GitLab, aşağıdaki sürümlere güvenlik güncellemeleri sağladı
    • 16.5.6
    • 16.6.4
    • 16.7.2
  • Yama aşağıdaki sürümlere de backport edildi
    • 16.1.6
    • 16.2.9
    • 16.3.7
    • 16.4.5

Shadowserver tespit sonuçları

  • Shadowserver Foundation, yama yayımlandıktan yaklaşık 2 hafta sonra, 23 Ocak'ta dünya genelinde 5.379 savunmasız GitLab instance'ı tespit etti
  • Ülke bazında en fazla savunmasız instance ABD ve Almanya'daydı
    • ABD: 964
    • Almanya: 730
  • 24 Ocak'ta Shadowserver panosundaki savunmasız instance sayısı 4.652'ye düştü
  • Shadowserver tarafı, düşüşün kendisinin olumlu olduğunu ancak bunun gerçek bir eğilim mi yoksa taramadaki geçici bir dalgalanma mı olduğuna karar vermek için daha fazla zamana ihtiyaç olduğunu doğruladı

İhlal göstergelerini kontrol etme yöntemi

  • Self-managed GitLab Community Edition ve GitLab Enterprise Edition müşterileri, loglarda CVE-2023-7028 istismar izlerini kontrol etmeli
  • Kontrol edilecek loglar ve koşullar şöyle
    • gitlab-rails/production_json.log: /users/password yoluna gelen HTTP isteklerinde params.value.email birden fazla e-posta adresi içeren JSON dizisiyse
    • gitlabs-rails/audit_json.log: meta.caller.id değeri PasswordsController#create ise ve target_Details birden fazla e-posta adresi içeren JSON dizisiyse

GitLab.com, GitLab Dedicated, 2FA etkisi

  • GitLab, GitLab.com veya GitLab Dedicated instance'larında bu hatanın istismar edildiğine dair bir vaka tespit etmediğini belirtti
  • Müşterilere 2FA'yı etkinleştirmeleri öneriliyor
  • 2FA, CVE-2023-7028 üzerinden hesap ele geçirilmesini engeller; ancak yamalanmamış instance'larda saldırganlar parolayı sıfırlayarak kullanıcıyı hesabından dışarıda bırakabilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-29
Hacker News görüşleri

  • Hesap tabanlı web uygulamalarında e-posta adresini hesaba bağlama özelliğinin gerçekten ürkütücü olduğunu düşünüyorum.
    Bu hatanın geçmişini bilmiyorum ama sızma testi uzmanlarının hemen yokladığı bir alan; 2000’lerin başındaki standart Unix MTA uygulamalarında parola sıfırlama e-postasını birden fazla adrese göndertmeye kandıran açıklara kadar uzanan eski bir tür.
    GitLab’da, çok özellikli bir web framework’ü bu saldırı yüzeyini yeniden canlandırmış gibi görünüyor; konuyla ilgilenen sıradan HN okurları parola sıfırlama özelliğini, özellikle de e-posta bağlama mantığını mutlaka kontrol etmeli.
    GitLab güvenlik ekibinin oldukça iyi olduğunu biliyorum, buna rağmen böyle bir hatanın çıkması bu tür hatalardan kaçınmanın ne kadar zor olduğunu gösteriyor.

    • Diğer yorumlarda anlatılan davranışa bakınca bu hata kaçınması çok kolay görünüyor.
      Statik tipli bir dil kullanılsaydı, özellikle böyle yapılmadıkça ortaya çıkması zor olurdu; kod incelemesinde de o kadar göze batardı ki bir iş arkadaşının arka kapı yerleştirmeye çalıştığından şüphelenirdim.
    • GitLab güvenlik ekibinin mükemmel olduğunu söylemek zor.
      İkincil e-posta adresi bağlama özelliği yakın zamanda eklendi ve baştan beri var olan bir özellik değildi; hesap güvenliğiyle ilgili yeni bir özelliği düzgün şekilde kötüye kullanım testinden geçirmeden kestirme yola sapmışlar gibi görünüyor.
      Üstelik bir entegrasyon özelliğinin başka bir kullanıcının yetkileriyle komut çalıştırmaya izin verdiği CVSS 9.6 CVE de varmış gibi görünüyor.
      Dışarıdan bakınca özellik çıkarma hızı, güvenli biçimde test edilebilecek hızı aşıyor gibi; bunun nedeni para kazanmanın zor olması da olabilir.
      İş açısından anlaşılır yanları var ama kendi barındırılan bir Git çözümünün özü fiilen hesap yönetimiyse, bu tür güvenlik sorunları işin kendisini de çökertebilir.
    • Tuhaf bir bakış açısı.
      E-posta değilse neye bağlanmalı? 20 yılı aşkın süredir büyük kullanıcı tabanına sahip bir site işlettim; başlangıçta kullanıcı adı kullanıyorduk ve bu bir felaketti.
      Herkes birbirinin kullanıcı adını biliyordu, bu yüzden parolaya brute-force yapmak ya da sıfırlama denemek kolaydı.
      Sorun e-posta kullanımı değil; giriş ve parola kurtarma mantığını aşırı karmaşıklaştırmak, soyutlamaları gereğinden fazla kullanmak, fazla tasarlamak ve güvenlik açısından hassas alanlarda kodu doğru dürüst doğrulamadan içeri sokmak.
      GitLab’ın güvenlik geçmişine de bakmak gerek. Yılda birkaç kez kritik exploit çıkıyor ve GitLab dağıtımını acilen yükseltmek gerekiyor; güvenlik açısından GitLab kullandığım ürünler içinde en kötüsüydü.
    • Her yanlış parola sıfırlama e-postası aldığımda, birinin hesabımı ele geçirmek için kontrolüm dışındaki bir kurtarma e-posta adresini gizlice ekleyip eklemediğinden endişeleniyorum.
      Henüz başıma gelmedi ama bu vakada olduğu gibi ne yazık ki gayet mümkün.
    • Bu exploit nasıl çalışıyor? Derli toplu bir yazı bağlantısı varsa merak ederim.

  • Rails kod tabanında bu exploit’e yol açan kısmı görmek isterseniz, düzeltme commit’i burada:
    https://gitlab.com/gitlab-org/gitlab/-/commit/c571840ba2f0e9...

    • Bu gerçek düzeltmeden çok sonradan yapılmış bir refactoring gibi görünüyor.
      Düzeltme sanırım burada: https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...
      recoverable.send_reset_password_instructions(to: email) if recoverable&.persisted? satırı recoverable.send_reset_password_instructions if recoverable&.persisted? olarak değiştirilmiş.
    • # Concern that overrides the Devise methods / # to send reset password instructions to any verified user email / module RecoverableByAnyEmail denmiş; yani bu bir özellik miydi?
      Ama düzeltilmiş sürümde bile hâlâ RecoverableByAnyEmail adı kullanılıyor. İnsanlar değiştirdikleri kodun çevresini okumuyor mu?
    • Ruby’yi pek bilmeyen biri olarak, hatanın nerede olduğunu gösterebilir misiniz?

  • Biz de bu saldırıya uğradık ve bunu maruziyeti daha da artıran ikinci bir “özellikle” birlikte kullanıldığını da gördük.
    Temelde bu saldırı için sıfırlanmak istenen kullanıcının e-postasını bilmeniz gerekiyor; GitLab kullanıcı ID’sine bağlı gizli bir e-posta adresi var. Bu ID, 1’den başlayıp artan bir sayı.
    ID 1 ya da 2’nin yönetici olma ihtimali yüksek olduğundan iyi hedef oluyor; e-posta da 1-user@mail.noreply.. gibi bir biçimde.
    Gerçekten kötüydü ve otomatikleştirilmiş gibi görünüyordu. Burada bizi 2FA kurtardı.

  • E-posta ile parola sıfırlama, doğru uygulansa bile bir güvenlik kâbusu.
    Daha da kötüsü, çoğu serviste kapatılamıyor ve etrafından dolaşmak için genellikle Enterprise SSO’dan başka yol yok.
    Bazı servisler SMS token’ı için telefon numarası ayarlamanıza izin veriyor ama hem e-posta hem SMS token’ı birlikte isteyen bir yöntem görmedim.

    • Hangi açıdan güvenlik kâbusu olduğunu merak ediyorum.

  • Giriş formuna parola dizisi koyunca hesaplara brute-force yapılabilen bir hatayı hatırlattı.
    Üstelik spam cihazının özensiz web arayüzüydü; bunun kasıtlı mı yoksa PHP’ye yeni başlayan birinin yazdığı kod mu olduğunu bilmiyorum.
    O dönemler nadir olan özel karakterleri parolasına koyan bir kullanıcı bunu keşfetmişti.

    • Ruby on Rails, ORM’in .where(...) parametresinde dizi alınca dizi değerleri arasını OR koşulu olarak işler.
      Bu yüzden kod User.where(name: name, password: password) gibi bir şeyse, böyle bir durumun yaşanması gayet mümkün görünüyor.

  • GitLab gibi dahili servislerin yalnızca güvenilir kullanıcıların erişebildiği VPN arkasında tutulması gerektiğine dair iyi bir hatırlatma

    • Dahili sürüm kontrolü ve CI/CD’yi neden açık internete koyduklarını gerçekten anlamıyorum
      VPN tam da bunun için var
    • Doğru, biz de bu sayede kurtulduk; ayrıca birkaç başka önlemimiz de vardı
      Büyük bir kamuya ait telekom şirketinde çalışıyorum ve ağdan sorumlu ekip gerçekten çok iyi. Sunucu ekiplerinin çizgiyi aşmasını engelliyorlar
      Bazı harici projeler ve danışmanlar için GitLab’ı bir ölçüde dışarı açtık ama yine de internetten serbestçe erişilebilir değil
      Kullanıcılar da AD üzerinden yönetiliyor, bu yüzden parola sıfırlama için SMTP bağlantısı bile yok
      Ancak 2FA zorunluluğunu daha da güçlendirmemiz gerekiyor. Şu anda her projenin kendi 2FA kurallarını belirlemesine izin vermiş durumdayız

  • Açıkçası hiçbir dahili sunucuyu açık internete koymazdım
    Yalnızca VPN üzerinden erişim sağlayıp ikinci bir savunma hattı koymak daha iyi

    • Özellikle GitLab gibi şeylerde, GitLab API’sini çağırması gereken harici entegrasyonlardan büyük fayda sağlanabiliyor
      Sadece tam olarak o istekleri izin listesine almak da mümkün olurdu ama epey zahmetli olabilir
    • GitLab, bir kod forge’u işletmek için en sevdiğim seçenek: git.drk.sc
      Yüksek güvenlikli bir ortamdaysa daha savunmacı taktikler kullanmaya katılıyorum; ama bence yazılım açık web üzerinde de dayanabilecek şekilde tasarlanmalı
    • Doğru, özellikle şirket kendi barındırdığı GitLab kullanıyorsa her zaman şirket VPN’i arkasında tutulmalı

  • GitLab güncellemelerini otomatikleştirmek gerçekten kolay
    Tek bir yönteme bakarsak bile, GitLab’ı Docker+Compose ile kullanmak çok kararlı; Watchtower gibi bir araçla her gün güncellenmesini sağlayabilirsiniz
    7 yıldan uzun süredir bu şekilde işlettiğim iki GitLab sunucum var ve hiç sorun yaşamadım
    Etrafa bakınca çok fazla eski GitLab görüyorum; yöneticiler ne yapıyor, gerçekten bilmiyorum

  • Ruby/Rails’in güvenli olması gereken yazılımlar için iyi bir tercihmiş gibi davranmayı artık bıraksak iyi olur
    GitLab zaten böyle olduğu için bununla yaşamak zorunda olduklarını anlıyorum; ama bundan sonra, zekâ gösterisi ve gizli kontrol akışını önceleyen dil ve framework’lerin daha sıkıcı alternatiflerden iyiymiş gibi gösterilmesini bırakmalıyız
    Fazla sinirli konuşuyormuşum gibi geliyorsa, bunun nedeni gerçekten üretimde çalışan Ruby kod tabanlarıyla uğraşmak zorunda olmam
    Birilerinin 17 katmanlı soyutlamanın kodu inanılmaz genişletilebilir kıldığını düşünmesi yüzünden, benzer bir sorunun istismar edilmeyi beklediği yeterince senaryo görüyorum

    • Çağıranın bir parametreyi string ya da string dizisi olarak belirleyebilmesine izin veren dil veya framework’lerden kaçınmak iyi olur bence
      Bu tek hatanın maliyetinin, o özelliğin kullanımından elde edilen toplam değerden daha yüksek olma ihtimali büyük

  • SSO ve 2FA’yı her zaman kullanmanız gerektiğine dair bir başka hatırlatma