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

Reading time: 6 minutes

सारांश

CVE-2024-28080 Gitblit के embedded SSH service में एक authentication bypass है जो Apache MINA SSHD के साथ एकीकरण करते समय session state के गलत हैंडलिंग के कारण होता है। यदि किसी उपयोगकर्ता खाते में कम से कम एक SSH public key पंजीकृत है, तो कोई attacker जो username और उस उपयोगकर्ता की किसी भी public key को जानता है, private key और password के बिना authenticate कर सकता है।

• प्रभावित: Gitblit < 1.10.0 (observed on 1.9.3)
• ठीक किया गया: 1.10.0
• शोषण करने की आवश्यकताएँ:
• इंस्टेंस पर Git over SSH सक्षम होना चाहिए
• लक्षित खाते में Gitblit में कम से कम एक SSH public key पंजीकृत हो
• Attacker को लक्षित उपयोगकर्ता का username और उनकी किसी एक public key का पता होना चाहिए (आम तौर पर खोजने योग्य, उदाहरण: https://github.com/.keys)

Root cause (state leaks between SSH methods)

RFC 4252 के अनुसार, public‑key authentication दो चरणों में होता है: सर्वर पहले यह जांचता है कि दिया गया public key किसी username के लिए स्वीकार्य है या नहीं, और केवल signature के साथ challenge/response के बाद ही वह उपयोगकर्ता को authenticate करता है। MINA SSHD में, PublickeyAuthenticator दो बार कॉल किया जाता है: key acceptance पर (अभी signature नहीं) और बाद में जब client signature वापस करता है।

Gitblit का PublickeyAuthenticator पहले, pre‑signature कॉल पर session context को बदल देता था — authenticated UserModel को session से bind कर देता था और true लौटाता था ("key acceptable")। जब बाद में authentication password पर fallback हुआ, तो PasswordAuthenticator ने उस mutated session state पर भरोसा किया और short‑circuit करते हुए password को validate किए बिना true लौटाया। परिणामस्वरूप, किसी भी password (खाली भी) को उसी user के लिए पहले public‑key "acceptance" के बाद स्वीकार कर लिया गया।

उच्च‑स्तरीय त्रुटिपूर्ण प्रवाह:

1. Client username + public key पेश करता है (अभी signature नहीं)
2. Server उस key को user का मानता है और समयपूर्वक user को session से जोड़ देता है, true लौटाता है ("acceptable")
3. Client sign नहीं कर पाता (private key नहीं), इसलिए auth password पर fallback हो जाता है
4. Password auth session में पहले से मौजूद user देखता है और बिना शर्त success लौटाता है

चरण‑दर‑चरण शोषण

• लक्षित का username और उनकी किसी एक public key एकत्र करें:
• GitHub सार्वजनिक keys https://github.com/.keys पर एक्सपोज़ करता है
• सार्वजनिक सर्वर अक्सर authorized_keys एक्सपोज़ करते हैं
• OpenSSH को इस तरह कॉन्फ़िगर करें कि वह केवल public half प्रस्तुत करे ताकि signature generation विफल हो, जिससे server पर public‑key acceptance पथ ट्रिगर करते हुए auth password पर fallback मजबूर हो।

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)

कनेक्ट करें और पासवर्ड प्रॉम्प्ट पर Enter दबाएँ (या कोई भी स्ट्रिंग टाइप करें):

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.

Impact

• Full impersonation of any Gitblit user with at least one registered SSH public key
• Read/write access to repositories per victim’s permissions (source exfiltration, unauthorized pushes, supply‑chain risks)
• Potential administrative impact if targeting an admin user
• Pure network exploit; no brute force or private key required

Detection ideas

• Review SSH logs for sequences where a publickey attempt is followed by a successful password authentication with an empty or very short password
• Look for flows: publickey method offering unsupported/mismatched key material followed by immediate password success for the same username

Mitigations

• Upgrade to Gitblit v1.10.0+
• Until upgraded:
• Disable Git over SSH on Gitblit, or
• Restrict network access to the SSH service, and
• Monitor for suspicious patterns described above
• Rotate affected user credentials if compromise is suspected

General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)

Pattern: यदि किसी server का public‑key authenticator pre‑signature "key acceptable" चरण के दौरान user/session state को mutate करता है और अन्य authenticators (जैसे password) उस state पर भरोसा करते हैं, तो आप authentication को निम्न तरीके से bypass कर सकते हैं:

• Presenting a legitimate public key for the target user (no private key)
• Forcing the client to fail signing so the server falls back to password
• Supplying any password while the password authenticator short‑circuits on leaked state

Practical tips:

• Public key harvesting at scale: सामान्य स्रोतों से public keys खींचें, जैसे https://github.com/.keys, organizational directories, team pages, leaked authorized_keys
• Forcing signature failure (client‑side): IdentityFile को केवल .pub पर पॉइंट करें, IdentitiesOnly yes सेट करें, और PreferredAuthentications को publickey फिर password शामिल करने दें
• MINA SSHD integration pitfalls:
• PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature
• PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method

Related protocol/design notes and literature:

• SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
• Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior

References

• Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)
• Gitblit v1.10.0 release notes
• Apache MINA SSHD project
• PublickeyAuthenticator API
• RFC 4252: The Secure Shell (SSH) Authentication Protocol