Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

Özet

CVE-2024-28080, Apache MINA SSHD ile entegrasyon sırasında oturum durumunun yanlış işlenmesinden kaynaklanan Gitblit’in embedded SSH servisi içinde bir authentication bypass’ıdır. Bir kullanıcı hesabında en az bir SSH public key kayıtlıysa, kullanıcı adını ve o kullanıcının public key’lerinden herhangi birini bilen bir saldırgan, private key ve parola olmadan authenticate olabilir.

  • Affected: Gitblit < 1.10.0 (observed on 1.9.3)
  • Fixed: 1.10.0
  • Sömürmek için gereksinimler:
  • Git over SSH örnekte etkinleştirilmiş olmalı
  • Hedef hesabın Gitblit üzerinde en az bir SSH public key’i kayıtlı olmalı
  • Saldırgan hedefin kullanıcı adını ve anahtarlarından birini bilmeli (çoğunlukla keşfedilebilir, ör. https://github.com/.keys)

Kök neden (state leaks between SSH methods)

RFC 4252’ye göre, public‑key authentication iki aşamada ilerler: sunucu önce sağlanan public key’in bir kullanıcı adı için kabul edilebilir olup olmadığını kontrol eder ve yalnızca bir challenge/response ile signature alındıktan sonra kullanıcıyı authenticate eder. MINA SSHD’de, PublickeyAuthenticator iki kere çağrılır: key acceptance aşamasında (henüz signature yok) ve daha sonra client signature’ı gönderdiğinde.

Gitblit’in PublickeyAuthenticator’ı ilk, imza öncesi çağrıda session bağlamını değiştirerek authenticate edilmiş UserModel’i session’a bağladı ve true döndürerek (“key acceptable”) anahtarı kabul etti. Kimlik doğrulama daha sonra password’a döndüğünde, PasswordAuthenticator bu değiştirilmiş session durumuna güvendi ve parolayı doğrulamadan işlemi kısalttı, true döndürdü. Sonuç olarak, aynı kullanıcı için önceki bir public‑key “acceptance” sonrası herhangi bir parola (boş dahil) kabul edildi.

Yüksek seviyeli hatalı akış:

  1. Client kullanıcı adı + public key sunar (henüz signature yok)
  2. Sunucu anahtarın kullanıcıya ait olduğunu tanır ve erken şekilde kullanıcıyı session’a iliştirir, true döner (“acceptable”)
  3. Client sign yapamaz (private key yok), bu yüzden kimlik doğrulama password’a döner
  4. Password auth session’da zaten bir kullanıcı olduğunu görür ve koşulsuz olarak başarı döndürür

Adım‑adım exploitation

  • Hedefin kullanıcı adını ve public key’lerinden birini topla:
  • GitHub public key’leri https://github.com/.keys adresinde sunar
  • Genel sunucular sıklıkla authorized_keys’i açığa çıkarır
  • OpenSSH’i sadece public yarıyı sunacak şekilde yapılandırın, böylece signature üretimi başarısız olur; bu, server tarafında public‑key acceptance yolunu tetiklerken kimlik doğrulamanın password’a geri dönmesini zorlar.

Example SSH client config (no private key available):

# ~/.ssh/config
Host gitblit-target
HostName <host-or-ip>
User <victim-username>
PubkeyAuthentication yes
PreferredAuthentications publickey,password
IdentitiesOnly yes
IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)

Bağlanın ve parola isteminde Enter tuşuna basın (veya herhangi bir dize yazın):

ssh gitblit-target
# or Git over SSH
GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>

Authentication succeeds because the earlier public‑key phase mutated the session to an authenticated user, and password auth incorrectly trusts that state.

Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.

Etkiler

  • En az bir kayıtlı SSH public key’e sahip herhangi bir Gitblit kullanıcısının tam taklidi
  • Kurbanın izinleri doğrultusunda depolara okuma/yazma erişimi (source exfiltration, unauthorized pushes, supply‑chain risks)
  • Hedeflenen kullanıcı bir admin ise potansiyel yönetici etkisi
  • Tamamen ağ üzerinden istismar; brute force veya private key gerekmez

Tespit fikirleri

  • SSH loglarını, publickey denemesinin ardından boş veya çok kısa bir parola ile başarılı bir password authentication görülen dizileri inceleyin
  • Aynı kullanıcı adı için publickey method’un unsupported/mismatched key material sunduğu ve hemen ardından parola ile doğrudan başarılı olunduğu akışları arayın

Önlemler

  • Gitblit’i v1.10.0+ sürümüne yükseltin
  • Yükseltme yapılana kadar:
  • Gitblit üzerinde Git over SSH’yi devre dışı bırakın, veya
  • SSH servisine ağ erişimini kısıtlayın, ve
  • Yukarıda tanımlanan şüpheli desenleri izleyin
  • İhlal şüphesi varsa etkilenen kullanıcı kimlik bilgilerini değiştirin

Genel: SSH auth method state‑leakage (MINA/OpenSSH‑based services) kötüye kullanımı

Desen: Eğer bir sunucunun public‑key authenticator’ı pre‑signature “key acceptable” aşamasında kullanıcı/oturum durumunu değiştirir ve diğer authenticators (ör. password) bu duruma güvenirse, kimlik doğrulamayı şu şekilde atlayabilirsiniz:

  • Hedef kullanıcı için meşru bir public key sunmak (private key yok)
  • İstemciyi imzalama başarısızlığına zorlayarak sunucunun password’a geri dönmesini sağlamak
  • Password authenticator, leaked state nedeniyle kısa devre yaparken herhangi bir password sunmak

Pratik ipuçları:

  • Büyük ölçekli public key toplama: https://github.com/.keys, organizasyon dizinleri, takım sayfaları, leaked authorized_keys gibi yaygın kaynaklardan public key’leri çekin
  • İmzalama başarısızlığına zorlamak (istemci‑tarafı): IdentityFile’ı sadece .pub dosyasına işaret edin, IdentitiesOnly yes olarak ayarlayın, PreferredAuthentications’ın publickey sonra password’u içerecek şekilde kalmasını sağlayın
  • MINA SSHD entegrasyon tuzakları:
  • PublickeyAuthenticator.authenticate(…) signature doğrulama sonrası yol imzayı teyit edene kadar kullanıcı/oturum durumunu eklememelidir
  • PasswordAuthenticator.authenticate(…) önceki, tamamlanmamış bir authentication method sırasında değiştirilen herhangi bir durumdan başarı çıkarsaması yapmamalıdır

İlgili protokol/tasarım notları ve literatür:

  • SSH userauth protokolü: RFC 4252 (publickey method iki‑aşamalı bir süreçtir)
  • Erken kabul oraklları ve auth yarışları üzerine tarihsel tartışmalar, örn. OpenSSH davranışı etrafındaki CVE‑2016‑20012 çekişmeleri

References

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin