CVE-2025-2825/CVE-2025-31161

はじめに

このドキュメントでは、CrushFTP サーバーコンポーネントに影響する脆弱性 CVE-2025-2825 の調査結果を紹介します。CrushFTP は、ファイル転送・保存を目的とした商用ソリューションです（FTP、SFTP、HTTP/S、S3 互換インターフェースなど）。

この欠陥は 認証バイパス (authentication bypass) に分類され、リモートの未認証攻撃者が管理者権限を取得できる可能性があります。悪用に成功すると、crushadmin 権限でのアクセス、ファイルの閲覧・変更、アカウント管理、CrushFTP の Web インターフェースおよび API を介した管理操作の実行が可能になります。

報告されている影響を受けるバージョン（公開アドバイザリおよび研究者のレポートによる）:

• CrushFTP 10.0.0 — 10.8.3
• CrushFTP 11.0.0 — 11.3.0

⚠️ 注記: 一部の公開情報には CVE 識別子の重複や重複登録が見られます（例: CVE-2025-31161）。

レポートの目的

この脆弱性を段階的に分析し、以下のような調査の全サイクルを示すことを目的とします:

1. 資料の収集と分析 — CVE-2025-2825 に関するアドバイザリ、PoC、技術的な解析、公開記事を整理し、欠陥の本質とその影響を明確にします。
2. CPE と条件の特定 — 脆弱性が再現する関連 CPE・バージョン・構成（Web インターフェース、S3 互換エンドポイントなど）の一覧。
3. PoC/Exploit の開発 — 管理されたテスト環境での再現可能な PoC の作成と、アーキテクチャおよび被害を最小化するための対策の説明。
4. 大規模検証の手法 — 脆弱なホストを安全に探すための3つのアプローチ:
   • nuclei によるアクティブスキャン;
   • nuclei によるパッシブスキャン（悪用を伴わず、バージョンや間接的な兆候に基づく）;
   • 管理された検証のための自作スクリプト (Python/Go)。
5. 推奨事項と緩和策 — インスタンスの検出、パッチ適用、保護に関する実践的なアドバイス。
6. 安全なテスト実施プラクティス — 許可された環境でのみテストを実施するためのチェックリスト。

実際の影響

公開レポートによると、この脆弱性は 重大 (クリティカル) なリスク があります:

• 悪用により CrushFTP インスタンスへの管理者アクセスが可能になります。
• 影響: ファイルの窃取・改ざん、ユーザーの作成・削除、バックドアの設置、さらなる攻撃の踏み台としてのサーバー利用。
• CVSS はクリティカル（約 9.8）と評価されています。
• コミュニティでは PoC と「実環境 (in-the-wild)」での悪用の痕跡が確認されています。

対象CPE / 構成

以下の特徴を持つインスタンスが特に重要です:

• 製品: CrushFTP（Web インターフェースを備えた任意のエディション）。
• バージョン: 10.0.0 — 10.8.3、11.0.0 — 11.3.0。
• リスクが高い構成:
  • パブリックな Web 管理インターフェース（HTTP/S）が有効。
  • S3 互換 API エンドポイントが有効化されている。
  • 追加の防御策（IP フィルタリング、2FA）がない。
  • プロキシ/ロードバランサーの設定ミスにより、内部エンドポイントが外部から到達可能になっている。

脆弱性の理解

CrushFTP は S3 類似の API をサポートしています。認証には次の形式の Authorization ヘッダーが使用されます:

Authorization: AWS4-HMAC-SHA256 Credential=<AccessKey>/<Date>/<Region>/s3/aws4_request, SignedHeaders=<Headers>, Signature=<Signature>

サーバーは Credential から AccessKey を抽出し、署名を検証する必要があります。しかし、コードには lookup_user_pass フラグの処理に関する誤りがありました。

• 脆弱なコード（簡略化した抜粋）:

// ServerSessionHTTP.java, метод loginCheckHeaderAuth()
if (this.headerLookup.containsKey("AUTHORIZATION") &&
    this.headerLookup.getProperty("AUTHORIZATION").trim().startsWith("AWS4-HMAC")) {
    
    boolean lookup_user_pass = true;   // ← критическая ошибка
    
    if (s3_username3.indexOf("~") >= 0) {
        user_pass = user_name.substring(user_name.indexOf("~") + 1);
        user_name = user_name.substring(0, user_name.indexOf("~"));
        lookup_user_pass = false;
    }
    
    if (this.thisSession.login_user_pass(
            lookup_user_pass,
            false,
            user_name,
            lookup_user_pass ? "" : user_pass)) {
        // Успешная аутентификация
    }
}

• その後のロジック:

lookup_user_pass フラグはそのまま anyPass として渡されます:

if (anyPass && user.getProperty("username").equalsIgnoreCase(the_user)) {
    return user;  // аутентификация без проверки пароля
}

つまり:

• ユーザー名が ~ 記号なしで指定された場合、フラグは true のままです。
• パスワードの検証は実行されません。
• 攻撃者は既存のユーザー名（例: crushadmin）を指定するだけで認証を通過できます。
• 形式上は有効な CrushAuth クッキーと c2f パラメータを組み合わせることで、認証をバイパスして管理者アクセスを取得できます。

修正

バージョン 11.3.1 以降で開発者は次の対応を行いました:

• 脆弱なシナリオをブロックするパラメータ s3_auth_lookup_password_supported（デフォルトは false）を追加。
• ~ を含むユーザー名の早期チェックを導入。
• フラグのロジックを分離し、lookup_user_pass → anyPass のすり替えを解消。
• 推奨事項: CrushFTP を直ちに 11.3.1 以上へ更新するか、s3_auth_lookup_password_supported を無効化したワークアラウンドを適用してください。

POC/Exploit

CVE-2025-2825 の悪用は比較的簡単で、複雑な準備は必要ありません。攻撃者は、次の2つの主要要素を含む特別に細工した HTTP リクエストを送信するだけで済みます:

• AWS S3 形式の Authorization ヘッダー — 既存ユーザーの正当な名前（AccessKey/username を含む Credential フィールド）を含む。
• 期待される形式の CrushAuth クッキー と、URL/リクエストボディ内の c2f パラメータ。これらの値は論理的に一致している必要があります（クッキーの形式はサーバーが期待する構造に一致している必要があります）。

サーバーが脆弱な場合（バージョンが 10.0.0〜10.8.3 または 11.0.0〜11.3.0 の範囲にあり、修正パッチが適用されていない場合）、この組み合わせにより認証ハンドラーが脆弱な経路を辿ります。そこではパスワード検索フラグ（lookup_user_pass）が「任意のパスワードが許可される」と解釈され、パスワードを検証せずにユーザー名だけで認証されます。

重要な注意事項:

この脆弱性の悪用には、通常、2つの連続したリクエストの送信が必要です。最初の、いわゆる「ウォームアップ」リクエストは、サーバー上で脆弱な認証プロセスを起動します。サーバーが目的の状態に入った特徴的な兆候は、応答として 502 Bad Gateway エラーが返るか、単純にタイムアウトが発生することです。その直後に、サーバーが攻撃に対して脆弱な状態にある間に、2番目の主要なリクエストが送信され、実際の悪用動作（例: ユーザー作成）が実行されます。

GET /WebInterface/function/?command=getUserList&serverGroup=MainUsers&c2f=1111 HTTP/1.1
Host: target-server:8080
Cookie: CrushAuth=1743113839553_vD96EZ70ONL6xAd1DAJhXMZYMn1111
Authorization: AWS4-HMAC-SHA256 Credential=crushadmin/

テストには、最近リリースされた HTB のラボ「Soulmate」を使用しました。そこではまさに CrushFTP の悪用が求められます。

さらなる展開:

この脆弱性を利用すると、setUserItem コマンドを使用して管理者権限を持つ新しいユーザーを追加できます。これを行うには new_user.py を実行します。

python3 new_user.py --target_host http://ftp.soulmate.htb/ --port 80 --target_user crushadmin --new_user literide --password literide

なぜ機能するのか

1. Authorization ヘッダーのパース: サーバーが S3 類似形式（AWS4-HMAC...）の認証ヘッダーを検出すると、Credential フィールドからクライアント ID（AccessKey / username）を抽出します。この時点でサーバーはユーザー名とみなす文字列を取得します。これは、その後の認証ロジックで使用される識別値です。

2. lookup_user_pass フラグとその役割:

コードにはブール型フラグ lookup_user_pass があり、これは検証時にパスワードをどこから取得するかを示すことを意図しています:

• 通常のシナリオでは、このフラグは、リクエストで渡されたパスワードを使用するか、ユーザーストアからパスワードを取得するかを決定するのに役立ちます;
• しかし、実装ミスにより、この同じフラグが検証関数に渡され、そこで別の意味に解釈されます — パスワード検証をスキップすることを許可するシグナルとして（実質的に「anyPass」）。

3. 呼び出しチェーンを通じたフラグの受け渡し: おおよその経路: ServerSessionHTTP.loginCheckHeaderAuth() → Session.login_user_pass(...) → UserTools.ut.verify_user(...)。フラグは入力時に動作を決定し、verify_user 内では、名前が一致した場合にパスワードを比較せずに見つかったユーザーオブジェクトを早期返却します。これにより認証チェックがバイパスされます — サーバーは名前によってユーザーを「認識」し、認証済みと見なします。

4. 付随する要素（cookie / c2f）: 公開された解析によると、ハンドラーはリクエストをセッション/コンテキストと照合するために、正しい形式の cookie/パラメータを期待します。ただし、主要な欠陥はまさに lookup_user_pass の処理における論理エラーです。その他の要素は、リクエストが標準的な処理分岐を通過するのを助けるだけです。

主な原因

• フラグの意味の過負荷: 「パスワードをどこから取得するか」を決定するはずのフラグが、「任意のパスワードを許可する」ために使用されてしまいました。これが Credential の簡素化されたパースと組み合わさり、パスワード検証なしでも正しいユーザー名が存在するだけでユーザー資格情報を取得できる状態になっていました。

Nuclei テンプレート

• パッシブテンプレート:

  ほとんどの Web サービスでは CrushFTP の正確なバージョンを特定できないため、このテンプレートはサービスが CrushFTP を使用しているかどうかのみを確認します。

  アクティブテンプレートと併用するのが最適です

• アクティブテンプレート:

  アクティブテンプレートは、getUserList コマンドが実行可能かどうかを確認します。

  

• マルチスレッドスクリプト

  このスクリプトはアクティブテンプレートとほぼ同様に動作しますが、はるかに高速で、複数のホストを同時にチェックできます。

  root@kitploit:~

  python3 scan.py -t http://ftp.soulmate.htb/ -p 80 -u crushadmin
  

  

修復と防御の推奨事項

CVE-2025-31161 に関連するリスクを軽減するには、次の手順を実行することをお勧めします:

1. 直ちに更新する:

   • すべての CrushFTP インスタンスをバージョン 11.3.1 以上に更新します。これが脆弱性を完全に排除する最も確実な方法です。

2. ワークアラウンドの適用（更新が不可能な場合）:

   • サーバー設定でパラメータ s3_auth_lookup_password_supported を false に設定します。これにより、製品全体を更新することなく脆弱な認証ロジックを無効化できます。

3. リスク補償策:

   • アクセスを制限する: ファイアウォールまたはリバースプロキシ（NGINX、Caddy）を使用して、CrushFTP の Web インターフェースへのアクセスを信頼できる IP アドレス（例: 社内ネットワークまたは VPN）のみに制限します。
   • ログの監視: CrushFTP のアクセスログを定期的に分析し、Authorization ヘッダーに AWS4-HMAC-SHA256 を含む不審なリクエストがないか確認します。特に S3 連携を使用していない場合は重要です。
   • Web Application Firewall (WAF) を使用する: WAF を設定して、S3 API 用ではないエンドポイントへの異常な Authorization ヘッダーを含むリクエストをブロックします。