Enviar e-mails em nome de uma empresa? Veja como encontrei essa vulnerabilidade em várias grandes empresas, permitindo-me ganhar recompensas facilmente.

Olá caçadores . O objetivo aqui é poder enviar e-mail(s) em nome de uma empresa — a partir de seu endereço de e-mail — com a capacidade de alterar/personalizar o conteúdo e, portanto, o modelo HTML .

Qual é o impacto de tal vulnerabilidade?

O impacto desta vulnerabilidade pode ser significativo, um invasor aproveitaria a confiança que os usuários têm na plataforma para redirecioná-los para sites fraudulentos (phishing, etc.) ou até mesmo induzi-los a realizar ações indesejáveis ​​de suas contas. Os programas geralmente consideram a gravidade dessa vulnerabilidade entre baixa e média .

Como funciona?

A injeção de HTML é uma vulnerabilidade em que um aplicativo aceita a entrada do usuário e, em seguida, incorpora a entrada no HTML. Um invasor pode injetar HTML a partir da entrada do usuário para que seu código malicioso seja incorporado ao modelo geral gerado pelo aplicativo.

Isso ocorre devido à sanitização inadequada da entrada do usuário. É muito fácil de corrigir, mas muitas vezes passa despercebido - este vetor de ataque em particular - para o deleite dos caçadores de insetos.

A famosa regra de ouro para desenvolvedores: nunca confie na entrada do usuário

Identificação de diferentes vetores de ataque e exploração

A primeira coisa a fazer para identificar essa vulnerabilidade é encontrar no aplicativo um recurso que envie e-mails: a maioria dos aplicativos possui uma seção “Fale conosco” ou uma seção “Ajuda” para enviar solicitações às equipes da empresa. Esses recursos são os mais básicos, e a lista não é exaustiva, diferentes funcionalidades de envio de e-mails podem ser encontradas dependendo da natureza do aplicativo.

Uma vez encontradas essas funcionalidades, elas devem ser testadas e verificadas quanto à presença de vários critérios :

Tomaremos como exemplo um formulário que permite enviar um pedido (pedido de ajuda) ao pessoal técnico da empresa

[1] Ao enviar o formulário, recebo um e-mail (para o endereço de e-mail indicado no formulário ou para o endereço de e-mail vinculado à conta da qual o pedido foi enviado)?

Se não - certifique-se porque isso pode levar algum tempo - então você não precisa procurar mais. Antes de injetar código em um modelo, o modelo em questão ainda deve existir.

[2] Se eu receber um e-mail ao enviar o formulário, é possível especificar algum endereço de e-mail no formulário/consulta?

Para explorar a vulnerabilidade é necessário poder direcionar outras pessoas para que o formulário em questão me permita especificar o e-mail de minha escolha ou seja necessário estar conectado para enviar o formulário e, portanto, o e-mail será enviado automaticamente para o endereço de e-mail se vincula à conta conectada:

Nesse caso, intercepte a solicitação em seu proxy preferido e verifique se seu endereço de e-mail não está na solicitação HTTP (POST em princípio) e tente alterá-lo para o endereço de e-mail de sua escolha.

[3] Algumas das informações fornecidas no formulário estão refletidas no e-mail recebido?

Se não for esse o caso, verifique se alguma de suas informações pessoais - caso você esteja conectado à sua conta - está refletida no e-mail, como nome de usuário, sobrenome ou nome, por exemplo.

Neste caso, modifique a(s) informação(s) refletida(s) e tente inserir sua carga útil lá. Mesmo que a informação em questão não seja interpretada no aplicativo, ela pode ser interpretada no e-mail , isso é chamado de injeção de segunda ordem , a injeção não é realizada diretamente a partir das entradas do usuário no formulário, mas a partir de informações registradas em outro lugar , na conta, por exemplo.

Caso contrário, não podemos tentar injetar código ou mesmo ignorar qualquer filtro.

[4] O último passo é tentar injetar código HTML que será interpretado pelo template em questão

Como mencionado anteriormente, esse tipo de vulnerabilidade geralmente passa despercebido, e alguns aplicativos não têm filtros front-end nem back-end, e uma carga útil simples, incluindo código HTML, é suficiente:

vul<strong>ne</strong>rable

Às vezes, os desenvolvedores se concentram em filtros de front-end, o que torna impossível enviar formulários contendo caracteres especiais: não pare por aí , envie o formulário com valores aleatórios, intercepte a solicitação em seu proxy e insira suas cargas diretamente do proxy. Isso explodirá todas as proteções da frente, que às vezes são o último bastião em direção à recompensa. Se também existirem proteções no verso, não desista nos primeiros minutos, tente contornar os filtros, a metodologia aqui é a mesma das vulnerabilidades XSS.

Tendo problemas para ignorar um filtro para um determinado personagem? Dê uma olhada em:https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md

Esta foi a minha primeira redação, obrigado por ler. Se você tiver alguma dúvida, sinta-se à vontade para me avisar.

Minha conta no Twitter:https://twitter.com/blank_cold