Um destinatário que abrisse o e-mail veria uma linha de assunto comum: “Your Password is About to Expire”. Nada nela parecia fora do normal. Mas quando Jan Kopriva, do SANS Internet Storm Center, desmontou os cabeçalhos brutos, o assunto não era uma frase limpa. Era uma cadeia de palavras codificadas em MIME, cada fragmento decodificado em Base64 separado por um caractere Unicode invisível, o hífen suave, U+00AD, inserido entre quase todas as letras. Nenhum cliente de e-mail chegou a renderizar esses caracteres. Nenhum destinatário notou algum espaço. E nenhum filtro de palavras-chave procurando frases como “password expire” ou “account update” conseguiu combinar com a string também, porque no nível dos bytes, a palavra “password” não estava mais lá.
Como uma Dica de Quebra de Linha dos Anos 90 Virou um Bypass de Filtros
O hífen suave nunca foi criado para isso. Ele existe no Unicode como uma dica de formatação, um marcador que diz a um renderizador onde uma palavra pode ser quebrada no fim de uma linha se faltar espaço, e deve permanecer invisível em qualquer outro contexto. A RFC 2047 dá ao e-mail um mecanismo relacionado, a palavra codificada, que permite que uma linha de assunto carregue texto não ASCII ou codificado de forma especial, embrulhado em uma sintaxe como =?charset?encoding?text?=. Clientes de e-mail decodificam isso de forma transparente antes de exibir, e é exatamente isso que torna o truque um esconderijo tão conveniente. A campanha que Kopriva documentou dividiu uma linha de assunto comum em várias palavras codificadas, entrelaçou hífens suaves entre as letras, e codificou em Base64 a string inteira. Um cliente de e-mail a decodifica, descarta os caracteres invisíveis, e mostra ao destinatário um texto limpo e legível. Um filtro que compara padrões contra essa mesma string decodificada vê algo mais parecido com “password”, fragmentado de um jeito que uma regra de palavra-chave nunca foi escrita para pegar.
Por Que o DMARC Jamais Iria Impedir Isso, e o Que Isso Diz Sobre a Camada Abaixo Dele
DMARC, SPF e DKIM autenticam uma única coisa: se o domínio que diz enviar uma mensagem realmente tem autoridade para enviá-la em seu nome. Eles não dizem nada sobre o que a linha de assunto ou o corpo da mensagem contêm. A filtragem baseada em conteúdo, a comparação de palavras e frases que sinaliza “urgente”, “verifique sua conta” ou “sua senha expira”, sempre foi uma camada separada, colocada em cima da autenticação pelo provedor de caixas de entrada ou por um gateway de segurança. Essa técnica não toca em nada a camada de autenticação. Uma mensagem que a use pode vir de um domínio com um registro DMARC limpo e em aplicação, passar em todas as verificações de autenticação sem problemas, e ainda assim carregar uma linha de assunto projetada do zero para escapar exatamente das regras de correspondência de frases que uma equipe de segurança passou anos ajustando.
O Mesmo Ponto Fraco Com Que as Equipes de Entregabilidade Sempre Conviveram
A pontuação por palavras-chave e frases não é exclusiva dos gateways de segurança. O filtro de spam de todo grande provedor de caixas de entrada ainda pesa a linguagem da linha de assunto como um sinal entre muitos ao decidir onde uma mensagem vai parar, e todo ESP comercial diz aos seus clientes para evitar frases “de spam” pelo mesmo motivo. O que a descoberta de Kopriva realmente demonstra é o quanto essa categoria inteira de filtragem se tornou frágil: um truque de codificação de cinco minutos a derrota por completo, seja a string disfarçada uma isca de phishing ou, hipoteticamente, uma frase promocional que um remetente menos escrupuloso quisesse passar despercebida por um classificador de pasta de spam. Esse segundo cenário não é hipotético o suficiente para ser ignorado. Os reguladores passaram este ano produzindo acordos multimilionários, a Costco com catorze milhões de dólares, a Lululemon com quase setecentos mil, por linhas de assunto que eram apenas enganosas, sem estarem tecnicamente alteradas com caracteres ocultos. A CAN-SPAM já trata cabeçalhos de e-mail enganosos como uma infração com penalidades civis de até $53.088 por mensagem. Um remetente que usasse caracteres invisíveis para manipular como um sistema automatizado lê uma linha de assunto estaria construindo, contra si mesmo, exatamente o tipo de acusação de cabeçalho enganoso que os reguladores já mostraram estar dispostos a processar.
O Que Isso Significa Para o Seu Programa
Decodifique antes de filtrar. Qualquer regra de conteúdo, de segurança ou de spam, que compare padrões contra uma linha de assunto bruta ou parcialmente decodificada vai deixar passar completamente os truques de palavras codificadas. A decodificação MIME precisa acontecer antes de rodar a correspondência de frases, não depois.
Trate caracteres invisíveis como um sinal por si só. Uma densidade incomum de hífens suaves, espaços de largura zero, junções de largura zero ou junções de palavra dentro de uma linha de assunto é suspeita independentemente da frase que estejam escondendo. Essa proporção já vale a pena ser sinalizada sozinha.
Pare de tratar a filtragem por palavras-chave como um controle primário. Ela sempre foi a camada mais fácil de driblar, e isso é a prova de quão fácil. Combine-a com autenticação, reputação do remetente e sinais comportamentais, em vez de depender só dela.
Audite sua própria ferramenta de envio em busca de caracteres invisíveis acidentais. Ferramentas de design, construtores de templates e copiar e colar de editores de texto rico podem deixar caracteres de largura zero ou de formatação embutidos em linhas de assunto sem que ninguém tenha feito por querer. Para um filtro receptor, um acidental parece idêntico a um deliberado, e qualquer um dos dois pode derrubar a colocação na caixa de entrada.
A Conclusão
A técnica em si é pequena: um caractere Unicode, uma RFC antiga, um envelope em Base64. O que ela expõe é maior: a filtragem de conteúdo baseada em palavras-chave, a camada que fica em cima do DMARC e não dentro dele, é bem mais fácil de vencer do que a maioria dos programas de segurança e entregabilidade supõe. O DMARC vai continuar dizendo se um domínio tinha o direito de enviar. Ele nunca iria dizer se as palavras dentro da mensagem significavam o que pareciam significar, e isso é uma demonstração clara de quanta distância ainda existe entre essas duas perguntas.
A autenticação responde quem tem permissão para enviar. Ela não pode dizer o que um filtro realmente viu depois que sua mensagem foi decodificada. A Excello Mail transforma seus relatórios agregados de DMARC em um registro claro e contínuo de cada serviço que envia e-mails em nome do seu domínio, autenticado ou não, para que a parte do seu programa que está sob seu controle continue visível. Cadastre-se gratuitamente na Excello Mail e construa a camada de visibilidade que um filtro de palavras-chave nunca iria te dar.