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

src/pentesting-ci-cd/gitblit-security/README.md

@@ -4,7 +4,7 @@
 
 ## Gitblit とは
 
-GitblitはJavaで書かれた自己ホスト型のGitサーバーです。スタンドアロンのJARとして実行するか、サーブレットコンテナ内で動作させることができ、Git over SSH用の組み込みSSHサービス（Apache MINA SSHD）を同梱しています。
+Gitblit は Java で書かれたセルフホスト型の Git サーバーです。スタンドアロンの JAR として、または servlet containers 内で動作し、Git over SSH 用の組み込み SSH サービス (Apache MINA SSHD) を同梱しています。
 
 ## トピック
 

src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md

@@ -4,34 +4,34 @@
 
 ## 概要
 
-CVE-2024-28080 は、Apache MINA SSHD と統合する際のセッション状態ハンドリングの誤りに起因する、Gitblit の組み込み SSH サービスにおける認証バイパスです。ユーザーアカウントに少なくとも 1 つの SSH public key が登録されている場合、攻撃者が該当ユーザーの username とその public key のいずれかを知っていれば、private key や password なしで認証できます。
+CVE-2024-28080 は、Gitblit の embedded SSH サービスにおける認証バイパスで、Apache MINA SSHD と統合する際の session state の誤った取り扱いが原因です。ユーザーアカウントに少なくとも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）
+- 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/<username>.keys)
 
 ## 根本原因 (state leaks between SSH methods)
 
-RFC 4252 によれば、public‑key authentication は 2 段階で進行します: サーバは最初に提示された public key が username に対して受け入れ可能かをチェックし、クライアントが署名で応答した後にユーザーを認証します。MINA SSHD では、PublickeyAuthenticator が 2 回呼ばれます: key acceptance（まだ署名なし）時と、クライアントが署名を返した後です。
+RFC 4252 によれば public‑key authentication は2段階で進行します: サーバはまず提供された public key が username に対して受け入れられるかをチェックし、その後 challenge/response による signature が検証されて初めてユーザーを認証します。MINA SSHD では、PublickeyAuthenticator が2回呼ばれます: key acceptance（まだ signature なし）の時と、クライアントが後で signature を返した後の時です。
 
-Gitblit の PublickeyAuthenticator は、署名前の最初の呼び出しでセッションコンテキストを変更し、UserModel をセッションにバインドして true（"key acceptable"）を返していました。後に認証が password にフォールバックした際、PasswordAuthenticator はその変更されたセッション状態を信頼して処理をスキップし、password の検証なしに true を返しました。その結果、同じユーザーに対して public‑key の "acceptance" が先に起きていれば、任意の password（空も含む）が受け入れられてしまいました。
+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 を提示（まだ署名なし）
-2) サーバがその key がユーザーに属すると認識し、ユーザーをセッションに早期に紐付けして true（"acceptable"）を返す
+1) クライアントが username + public key を提示する（no signature yet）
+2) サーバはその key がユーザーに属すると認識し、ユーザーを session に早期に紐付けして true を返す（"acceptable"）
 3) クライアントは署名できない（private key がない）ため、認証は password にフォールバックする
-4) PasswordAuthenticator はセッションに既にユーザーが存在するのを検出し、無条件に成功を返す
+4) Password auth は既に session にユーザーが存在するのを見て無条件に成功を返す
 
-## ステップごとの悪用
+## ステップバイステップの悪用
 
-- 被害者の username とその public key の 1 つを収集する:
-  - GitHub は公開鍵を https://github.com/<username>.keys で公開している
-  - 公開サーバはしばしば authorized_keys を公開している
-- OpenSSH を設定して public half のみを提示するようにし、署名生成を失敗させることで password へのフォールバックを強制しつつ、サーバ側では public‑key acceptance パスをトリガーさせる
+- 被害者の username とその public key の1つを収集する:
+- GitHub は public keys を https://github.com/<username>.keys で公開している
+- 公開サーバはしばしば authorized_keys を公開している
+- OpenSSH を設定して public half のみを提示し、signature の生成を失敗させることで、サーバ側の public‑key acceptance パスをトリガーしたまま password へのフォールバックを強制する
 
 Example SSH client config (no private key available):
 ```sshconfig
@@ -44,56 +44,56 @@ PreferredAuthentications publickey,password
 IdentitiesOnly yes
 IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)
 ```
-接続し、パスワードプロンプトで Enter キーを押してください（または任意の文字列を入力してください）:
+接続して、パスワードのプロンプトで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>
 ```
-認証が成功するのは、前段の public‑key フェーズがセッションを認証済みユーザーに変更（mutated）してしまい、password auth がその状態を誤って信頼するためです。
+認証が成功するのは、先行する public‑key フェーズがセッションを認証済みユーザーに変異させ、その状態を password auth が誤って信頼してしまうためです。
 
-Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.
+注意: SSH 設定で ControlMaster multiplexing が有効な場合、後続の Git コマンドが認証済みの接続を再利用し、影響が拡大する可能性があります。
 
-## Impact
+## 影響
 
-- 少なくとも1つの登録された SSH public key を持つ任意の Gitblit ユーザーの完全ななりすまし
-- 被害者の権限に応じたリポジトリへの読み書きアクセス（source exfiltration、unauthorized pushes、supply‑chain risks）
-- admin ユーザーを狙った場合、管理者権限に対する影響の可能性
-- 純粋なネットワーク脆弱性；brute force も private key も不要
+- 少なくとも1つの登録済み SSH public key を持つ任意の Gitblit ユーザーの完全な成りすまし
+- 被害者の権限に応じたリポジトリへの読み書きアクセス（ソースの持ち出し、無許可の pushes、サプライチェーンリスク）
+- 管理者ユーザーを標的にした場合の管理上の影響の可能性
+- 純粋なネットワーク脆弱性; ブルートフォースや秘密鍵は不要
 
-## Detection ideas
+## 検出のアイデア
 
-- SSH ログを確認し、publickey 試行の後に空または非常に短いパスワードでの成功した password authentication が続くようなシーケンスを探す
-- フローを探す: publickey method がサポート外／不一致のキー素材を提示した後、同じユーザー名に対して即座に password が成功する流れ
+- publickey 試行の後に、空または非常に短いパスワードで成功した password 認証が続くような一連の記録を探して SSH ログを確認する
+- 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
+- Gitblit を v1.10.0+ にアップグレードする
+- アップグレードまでの間:
+  - Gitblit 上での Git over SSH を無効にする、または
+  - SSH サービスへのネットワークアクセスを制限する、および
+  - 上記のような疑わしいパターンを監視する
+  - 侵害が疑われる場合は対象ユーザーの資格情報をローテーションする
 
-## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
+## 一般: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
 
-Pattern: If a server’s public‑key authenticator mutates user/session state during the pre‑signature "key acceptable" phase and other authenticators (e.g., password) trust that state, you can bypass authentication by:
+パターン: サーバーの public‑key authenticator が pre‑signature の "key acceptable" フェーズ中にユーザー/セッション状態を変異させ、他の authenticators（例: password）がその状態を信頼してしまう場合、次の方法で認証をバイパスできます:
 
-- 対象ユーザーの正当な public key を提示する（private key は不要）
-- クライアントに署名を失敗させてサーバが password にフォールバックするようにする
-- password authenticator が leaked state によりショートサーキットする間に任意の password を供給する
+- 対象ユーザーの正当な public key を提示する（秘密鍵は不要）
+- クライアントの署名を失敗させてサーバーを password にフォールバックさせる
+- password authenticator が leaked state によって短絡する間に任意のパスワードを供給する
 
-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 (client‑side): 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 post‑signature verification path confirms the signature
-- PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method
+- Public key を大規模に収集する: https://github.com/<username>.keys、組織のディレクトリ、チームページ、leaked authorized_keys などの一般的なソースから public key を取得する
+- 署名失敗を強制する（クライアント側）: IdentityFile を .pub のみに向け、IdentitiesOnly yes を設定し、PreferredAuthentications に publickey → password を含めたままにする
+- MINA SSHD 統合の落とし穴:
+  - PublickeyAuthenticator.authenticate(...) は post‑signature の検証経路が署名を確認するまでユーザー/セッション状態を付加してはならない
+  - PasswordAuthenticator.authenticate(...) は、前の未完了の認証メソッド中に変異した状態から成功を推測してはならない
 
-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
+- 早期受理オラクルや認証レースに関する歴史的議論（例: OpenSSH の挙動を巡る CVE‑2016‑20012 の論争）
 
 ## References