E-mails falsos: por que são possíveis?

Às vezes é fácil descobrir e-mails de phishing: basta checar o campo do remetente. No entanto, isso nem sempre é o suficiente. Tornar um e-mail falso indistinguível de um genuíno é realmente possível. Se um cibercriminoso sabe fazer isso, a organização alvo de um eventual ataque pode estar em apuros. Isso porque a maioria das pessoas não pensaria duas vezes antes de clicar em um link ou arquivo mal-intencionado que recebeu por e-mail, supostamente do chefe ou de um importante cliente (e é difícil culpá-las por isso, especialmente se não há como dizer que o e-mail foi falsificado).

Mas, em primeiro lugar, por que é perfeitamente possível forjar um e-mail falso? A fala de Andrew Konstantinov sobre autenticação de e-mail para analistas de invasão, durante o 36º Chaos Communication Congress, responde a questão e nos dá algumas pistas sobre a efetividade da proteção contra e-mails enganosos.

Problema 1: e-mails seguem o fluxo

O e-mail é um método básico de comunicação dos dias de hoje, e toda organização depende muito dele em suas operações diárias. Embora não pensemos muito na tecnologia quando tudo corre bem, se todos os e-mails começarem a desaparecer repentinamente, você pode ter certeza de que todo mundo vai notar. Por isso, a confiabilidade geralmente é a principal prioridade de todo administrador de servidor de e-mail. A mensagem simplesmente precisa ser enviada e entregue, não importa o que aconteça.

A implicação aqui é que o servidor de e-mail, em qualquer organização, deve ser o mais compatível possível com os outros. E aí está o problema: os padrões de e-mail estão bem desatualizados.

Problema 2: O protocolo de e-mail sem autenticação

O principal protocolo de e-mail utilizado nas comunicações “cliente-servidor” e “servidor-servidor” é o SMTP. Este protocolo foi introduzido pela primeira vez em 1982 e atualizado pela última em 2008 -mais de uma década atrás. E, assim como qualquer outro padrão antigo, o SMTP é um pesadelo em termos de segurança.

Primeiro, vamos dar uma olhada no que consiste as mensagens de e-mail mais comuns:

– Envelope SMTP: Essa parte é utilizada em comunicações do tipo “servidor-servidor” e nunca é mostrada para os clientes de e-mail. Ele especifica os endereços do remetente e do destinatário.

– Cabeçalho: os programas de e-mail mostram essa parte. E onde você vai encontrar termos familiares como “De”, “Para”, “Data” e “Assunto”, campos que você vê em qualquer mensagem.

– Corpo da mensagem: O texto do e-mail e outros conteúdos.

O que existe em uma mensagem de e-mail

O principal problema é que os provedores padrões não podem fazer autenticações. A responsabilidade pelo campo de endereço do remetente – tanto no envelope SMTP quanto no cabeçalho – é toda do servidor que envia a mensagem. O que é pior: o endereço do remetente no envelope SMTP não precisa ser o mesmo do que consta no cabeçalho (e o usuário vê apenas o último).

Além disso, embora o padrão especifique um cabeçalho por e-mail, o SMTP na verdade não impõe um limite. Se uma mensagem contiver mais de um cabeçalho, o cliente de e-mail simplesmente escolherá um deles para exibir ao usuário.

Não precisa ser um hacker profissional para perceber o tamanho desse problema.

Problema 3: Entra falso, sai falso — É preciso estar atento a ambos

Para complicar ainda mais, toda comunicação por e-mail envolve duas partes. Portanto, falta de autenticação se desdobra em dois problemas secundários.

Por um lado, você definitivamente quer ter certeza de que qualquer e-mail recebido seja realmente enviado pelo endereço indicado. Por outro lado, você provavelmente deseja impedir que outras pessoas enviem e-mails que parecem vir do seu endereço. Infelizmente, o padrão não colabora.

Não surpreende, mas o protocolo SMTP tem sido explorado com tanta frequência que as pessoas começaram a criar tecnologias para corrigir as falhas mencionadas acima.

Tentativa de conserto 1: Estrutura de Políticas do Remetente (SPF)

A ideia por trás da Estrutura de Políticas do Remetente (SPF, na sigla em inglês) é bastante simples: o servidor que recebe um e-mail deve ser capaz de checar se o endereço do servidor que enviou a mensagem bate com o do servidor de e-mail verdadeiro associado àquele domínio.

Infelizmente, é mais fácil falar do que fazer. O padrão SMTP não tem como realizar essa verificação, então qualquer método de autenticação teria de ser adicionado sobre o material existente. Demorou uma década para que essa tecnologia se tornasse um “padrão proposto”. Atualmente, apenas 55% de um milhão dos principais servidores utilizam a SPF, e a maioria utiliza políticas bastante flexíveis.

A SPF também enfrenta muitos outros problemas, como sua arquitetura bagunçada que facilita a configuração incorreta. Também é possível enganá-la usando outros servidores hospedados no mesmo endereço, e assim por diante. Mas a falha fatal desse sistema é que ele verifica apenas o endereço indicado no envelope SMTP e ignora completamente o campo “De” no cabeçalho – aquele que o usuário realmente vê.

Resultado

• SPF ajuda a checar se um e-mail veio de um servidor genuíno
• O endereço visível aos usuários ainda pode ser falsificado.

Tentativa de Conserto 2: Identificação por Chave de Domínio (DKIM)

A Identificação por Chave de Domínio (em inglês DomainKeys Identified Mail, ou simplesmente DKIM) aborda o problema de maneira diferente: esse protocolo assina por criptografia o cabeçalho e parte do corpo da mensagem usando uma chave privada, assinatura que pode ser individualmente usando uma chave pública publicada no Sistema de Nomes de Domínio (Domain Name System).

Vale ressaltar, no entanto, que a DKIM não deve criptografar a mensagem inteira. Em vez disso, anexa um adendo assinado por criptografia, e isso é um problema. É difícil modificar a parte de criptografia, mas é fácil excluir a assinatura completamente e criaruma mensagem falsa – e os resultados são indetectáveis.

A implementação do mecanismo DKIM é difícil porque envolve a emissão e o gerenciamento de chaves criptografadas. Além disso, uma DKIM desconfigurada pode permitir que um invasor preserve a assinatura DKIM verdadeira em uma mensagem enquanto, ao mesmo tempo, modifica completamente o cabeçalho e o corpo da mesma.

Resultado

• DKIM permite que você assine digitalmente suas mensagens, ajudando o servidor destinatário a assegurar que a mensagem veio realmente de você.
• É difícil sua implementação porque envolve o gerenciamento de chaves criptografadas.
• Criminosos podem simplesmente deletar a assinatura enquanto falsificam um e-mail em seu nome
• Certas desconfigurações podem resultar em mensagens falsas contendo assinaturas DKIM genuínas.

Tentativa de conserto 3: Mensagem baseada em Domínio de Autenticação, Relatório e Conformidade (DMARC)

Apesar do nome bastante extenso, o protocolo de Mensagem baseada em Domínio de Autenticação, Relatório e Conformidade é realmente mais fácil de entender do que o SPF ou o DKIM. É na verdade uma extensão dos dois citados anteriormente, mas que corrige suas omissões mais gritantes.

Primeiro, o DMARC ajuda o administrador do domínio a especificar qual mecanismo de proteção (SPF, DKIM ou ambos) está sendo utilizado no servidor, o que realmente corrige o mecanismo DKIM. Segundo, ele também corrige o SPF, fornecendo uma verificação do endereço especificado no campo “De” do cabeçalho (o que é realmente visível ao usuário), além da verificação do endereço do remetente no envelope SMTP.

A desvantagem é que o protocolo DMARC é relativamente novo, ainda não é um padrão adequado (a RFC 7489 não o define como padrão ou mesmo padrão proposto, mas apenas como “Informativo”), e não é tão usado como deveria ser. De acordo com este estudo de 20.000 domínios, apenas 20% haviam adotado o DMARC até 2019 e apenas 8,4% tinham políticas rígidas.

Infelizmente, a adoção do DMARC ainda não é generalizada, e em muitos casos é usada com “nenhuma” política.

Resultado

• Conserta os problemas mais importantes da SPF e da DKIM;
• Não adotado de modo geral, e por isso não é efetivo como poderia ser.

Como se proteger contra e-mails falsos

Resumindo: ainda é possível falsificar  e-mails porque o protocolo SMTP não foi projetado voltado para segurança, portanto, permite que um invasor insira o endereço de qualquer remetente em um e-mail falso. Nos últimos anos, surgiram certos mecanismos de proteção – como SPF, DKIM e DMARC. No entanto, para que sejam eficazes, eles precisam ser usados ​​- e implementados corretamente – pelo maior número possível de servidores de e-mail. No mundo ideal, eles deveriam ser implementados em cada servidor de e-mail na Internet.

Além disso, é importante considerar que alguns servidores de retransmissão de e-mail podem começar a adicionar algo às mensagens devido a erros de configuração, e isso vai automaticamente gerar falhas na verificação DKIM. Além disso, não devemos esquecer que essas tecnologias ajudarão a lidar com ameaças em massa, mas para proteger sua empresa contra ataques sofisticados de e-mail, você ainda deve usar soluções de proteção adicionais tanto nas estações de trabalho quanto no servidor de e-mail.

Aqui estão algumas recomendações para proteção de e-mail:

• Adote pelo menos a SPF. Confira se foi configurado corretamente. E tenha sempre em mente que impostores com recursos podem driblar essa proteção. (Mais detalhes na palestra)
• Implemente a DKIM para melhor proteção. Pode ser um pouco difícil, mas vale a pena. E, novamente, faça a configuração correta (algumas dicas sobre o que os hackers precisam).
• De preferência, adote o padrão DMARC, porque este protocolo conserta a maior parte das falhas exploráveis da SPF e da KDIM.
• Também cheque as configurações de e-mails recebidos.
• Use soluções de segurança que suportem mecanismos modernos de autenticação. Por exemplo, use o Kaspersky Security for Mail Servers ou o Kaspersky Security for Microsoft Office 365.