Cartas Kobold: os riscos do e-mail em HTML

• Cartas Kobold são uma técnica de ataque que faz um e-mail em HTML parecer inofensivo a princípio, mas mudar para conteúdo de phishing para outro destinatário depois de encaminhado
• O ponto central é usar o CSS permitido pelos clientes de e-mail e a posição do DOM que muda durante o encaminhamento para ocultar ou voltar a exibir determinadas frases
• Thunderbird e Outlook on the web podem exibir frases ocultas após o encaminhamento por causa da estrutura do DOM e da forma como reescrevem CSS; no Gmail, a remoção de estilos no encaminhamento permite uma exposição em formato mais simples
• O problema foi reportado à Mozilla, Microsoft e Google em 5 de março de 2024; a Microsoft encerrou o caso em 26 de março sem ação imediata, e o Google confirmou em 9 de abril que estava trabalhando em uma correção
• Usuários podem desativar e-mails em HTML ou visualizá-los em modo restrito, mas bloquear `` pode quebrar muitos casos de uso do ecossistema atual de e-mail, o que torna difícil uma mitigação no nível do cliente

---

Cenário de ataque e ideia central

• Um e-mail encaminhado por um administrador pode inicialmente parecer uma mensagem de consulta inofensiva, mas, depois de encaminhado, mudar para uma solicitação de phishing para o novo destinatário
• O destinatário pode ser enganado porque o remetente é alguém conhecido e, em alguns casos, a mensagem pode até vir com uma assinatura criptográfica; mesmo confirmar por telefone que o e-mail foi encaminhado pode não revelar o golpe
• Como o administrador, destinatário original, não viu a frase de phishing no e-mail que encaminhou, é difícil perceber o ataque mesmo ao confirmar que fez o encaminhamento

Como as Cartas Kobold funcionam

• A maioria dos clientes de e-mail permite estilização com CSS em e-mails HTML
• Quando um e-mail é encaminhado, a posição do DOM do e-mail original normalmente muda, e o atacante aplica seletores CSS com base nessa mudança
• O atacante pode inserir no e-mail elementos que aparecem ou desaparecem dependendo do contexto
  • Normalmente ficam ocultos com display: none;
  • Após o encaminhamento, quando a estrutura do DOM muda, são exibidos com regras como display: block !important;
• Esses elementos normalmente não são vistos e aparecem apenas em situações específicas; por poderem ser explorados para phishing e afins, são chamados de cartas kobold
• Clientes de e-mail e webmails que oferecem suporte a e-mail HTML em geral podem ser afetados

Funcionamento no Thunderbird

• O problema relacionado ao Thunderbird foi reportado à Mozilla em 5 de março de 2024, e a data prevista de divulgação e o rascunho foram enviados em 20 de março de 2024
• Possíveis mitigações foram discutidas, mas a implementação deve ficar para depois
• O Thunderbird envolve o e-mail em `

` e quase não faz outras alterações

• Ao encaminhar um e-mail, o e-mail original citado é colocado novamente dentro de `

`, descendo um nível no DOM

• O CSS de exemplo oculta .kobold-letter por padrão e só a exibe na condição .moz-text-html>div>.kobold-letter
• Para quem vê o e-mail original, apenas os parágrafos sempre visíveis são exibidos, mas, para quem recebe o e-mail encaminhado, o parágrafo que estava oculto aparece de repente
• Como o atacante conhece a posição relativa no DOM e controla o CSS, ele pode ocultar ou exibir partes do e-mail e alterar todo o conteúdo
• Se a kobold letter for estilizada como uma sobreposição, ela pode até substituir comentários adicionados pelo remetente que encaminhou o e-mail original, ampliando as oportunidades de phishing

Funcionamento no Outlook on the web

• O problema no Outlook on the web foi reportado à Microsoft em 5 de março de 2024, e a data prevista de divulgação e o rascunho foram enviados em 20 de março de 2024
• Em 26 de março de 2024, a Microsoft decidiu não tomar medidas imediatas e encerrou o relatório
• Como o OWA é um webmail, a situação é mais complexa; o e-mail é colocado em um contêiner como `

`, mas os nomes exatos das classes mudam

• O Outlook prefixa IDs e classes com x_ e também ajusta o CSS para impedir que o CSS do e-mail afete os estilos da interface do webmail
• No exemplo, o CSS do e-mail original é transformado da seguinte forma na exibição do OWA
  • .rps_78fa .x_kobold-letter {display:none}
  • .rps_78fa > div > div > .x_kobold-letter {display:block!important}
• Depois do encaminhamento, a classe muda novamente para algo como x_x_kobold-letter, e o CSS também é atualizado outra vez
• Na segunda regra, o > entre .rps_78fa e div desaparece, então isso precisa ser considerado ao criar seletores complexos
• Os ajustes do OWA não impedem o ataque em si, mas se tornam uma restrição incômoda ao criar uma kobold letter que funcione simultaneamente em vários clientes

Funcionamento no Gmail

• O problema no Gmail foi reportado ao Google em 5 de março de 2024, e a data prevista de divulgação e o rascunho foram enviados em 20 de março de 2024
• O Google confirmou em 9 de abril de 2024 que estava trabalhando em uma correção
• Como o Gmail remove todos os estilos ao encaminhar e-mails, tecnicamente ele não é vulnerável às kobold letters em sua definição estrita, que mudam a visibilidade conforme o contexto por meio de seletores CSS
• Mas um ataque mais simples é possível
  • Ocultar a kobold letter no e-mail original usando CSS
  • Ao encaminhar, os estilos são removidos e o elemento oculto passa a ser exibido automaticamente
• Esse método é limitado e não permite o comportamento inverso, em que algo aparece no original e desaparece após o encaminhamento
• Como o Gmail ainda não remove o CSS no editor antes de enviar o e-mail, o parágrafo oculto continua invisível enquanto quem encaminha escreve comentários
• No e-mail resultante, os estilos são removidos e o segundo parágrafo aparece
• Se o Gmail remover o CSS já na etapa do editor, quem encaminha poderá descobrir o ataque antes de enviar, mitigando o problema

Casos semelhantes anteriores e diferenças

• Não é novidade que, em e-mails HTML, o conteúdo de respostas e encaminhamentos possa mudar via CSS
• Problemas semelhantes já foram reportados no passado
  • Thunderbird - Modification of replied mail content without knowledge of replier of the mail using CSS
  • Treat OpenPGP/SMIME email messages with certain CSS elements as unsigned
  • Composition should use inline styling so that styles from quotes don’t leak into the message
• A diferença das Cartas Kobold é que elas se concentram em um cenário de ataque específico e analisam vários clientes de e-mail em conjunto
• É necessário discutir os riscos do e-mail em HTML e os trade-offs para mitigá-los

Mitigações e limites

• Usuários podem desativar completamente e-mails em HTML ou visualizá-los em um modo restrito, como o “plain HTML” do Thunderbird
• Se o cliente de e-mail impedir o uso de ``, o problema pode ser resolvido, mas muitos casos de uso existentes no ecossistema de e-mail podem quebrar
• Uma implementação como a do Gmail, que remove estilos ao encaminhar, pode ser um meio-termo para limitar os riscos do e-mail HTML enquanto permite newsletters corporativas com estilo
• Não é realista esperar que clientes de e-mail implementem mitigações fortes em um futuro próximo
• Usuários devem estar cientes dos riscos do e-mail em HTML e tomar por conta própria as precauções necessárias

[GN⁺]

Comentários do Hacker News

• A parte de “mesmo assim, ainda não tenho certeza, então ligo para o gerente para confirmar se o e-mail é verdadeiro. O gerente diz que sim, então faço a transferência” parece uma suposição grande demais
  Normalmente, em vez de perguntar algo vago como “Você enviou este e-mail?”, a pessoa perguntaria de forma mais específica, como “É mesmo para transferir o dinheiro desse jeito?”, e aí o gerente obviamente estranharia, então há uma boa chance de o ataque ser barrado nessa conversa
  É um vetor de ataque interessante, mas fico em dúvida sobre a probabilidade real de sucesso. O texto descreve que, para esse ataque funcionar, seria necessário um fluxo de eventos bem específico e restrito, e pessoalmente isso não me convence muito
  Sei que phishing funciona na prática. Só que, para as pessoas que cairiam em phishing, talvez nem seja necessário um ataque tão sofisticado assim; na verdade, se o atacante investir tanto esforço em algo tão específico, pode até reduzir a chance de sucesso. Um e-mail de phishing comum provavelmente já teria boas chances de funcionar

  • Trabalhei em uma empresa com 10 mil funcionários, metade engenheiros, e todo ano havia alguns casos de alguém comprando cartões-presente com o cartão corporativo para o “CEO” ou outro executivo de alto escalão
    As informações desses executivos eram fáceis de achar no LinkedIn ou no site da empresa, e ainda assim isso acontecia, mesmo sendo exatamente o exemplo usado no treinamento anti-phishing, o que chega a ser surpreendente
  • É quase o contrário. Está muito bem documentado que os golpes mais óbvios e ridículos são os que funcionam melhor, porque assim fica mais fácil filtrar os potenciais alvos mais suscetíveis
    https://www.microsoft.com/en-us/research/publication/why-do-...
  • Acho que depende da pessoa. Alguns gerentes podem ter de aprovar vários desses pagamentos por dia, achar esse tipo de conversa um incômodo, e os funcionários também podem querer evitá-la
    O atacante pode incluir algo como “Estou viajando agora. Se ainda não tiver certeza, ligue para meu celular pessoal...” e depois responder com uma voz falsa
    Uma boa forma de chegar ao alvo pode ser um “encaminhamento duplo”. O remetente finge ser um funcionário encaminhando o e-mail do gerente para alguém próximo ao responsável por tarefas administrativas, e então essa pessoa reencaminha uma mensagem aparentemente inofensiva, por exemplo sobre aniversário ou aviso de licença médica, tornando difícil para o alvo real identificar a origem do e-mail
    Também é fácil imaginar outras formas criativas de abusar dessa “funcionalidade”. Por exemplo, fazer alguém totalmente inocente encaminhar conteúdo problemático e depois usar isso para chantageá-la
  • Se esse tipo de e-mail for enviado ao departamento de contas a pagar de uma grande empresa, talvez não seja tão irrealista assim
    Os responsáveis não vão ligar para o gerente de linha toda vez que chegar um pedido de pagamento por e-mail, especialmente se o valor for pequeno e não exigir aprovação prévia
    Pelo que me lembro, o Google também já caiu em um golpe em que pagou alguém por um trabalho que nunca existiu. Naquele caso havia faturas falsas, mas o princípio é o mesmo
  • Em teoria, isso poderia permitir ataques mais sofisticados e direcionados, como alterar o destinatário de uma transferência. Ataques assim seriam muito mais difíceis de detectar

• Há alguns dias eu estava vendo um design de e-mail de “atualização” feito por um designer, e por causa de um cabeçalho gráfico absurdamente grande no topo, nem dava para ver o texto do assunto sem rolar a tela
  Depois encaminhei outra versão para pedir feedback, e de repente ele ficou confuso, dizendo que a fonte parecia um pouco menor, até perceber: “Ah, ao encaminhar, ele converte para a versão desktop, não para a versão mobile!”
  Fiquei olhando sem acreditar. Isso é um e-mail; o que significa existir “versão desktop” e “versão mobile”? Como isso faz qualquer sentido? O que quer dizer ser “convertido”? É só uma cópia. O próprio fato de quebrar ao encaminhar mostra o quanto essa abordagem é absurda. Por que meu e-mail precisa ter CSS?
  Se a ideia é só expressar algo como itálico, deveriam ter adotado há muito tempo uma abordagem bem mais simples, como Markdown, e é inacreditável que isso ainda não tenha acontecido. Isso mostra como existe pouco interesse real em melhorar essa situação. Tudo isso serve apenas para atender exigências corporativas estranhas de enfiar logos e banners em todo lugar. E-mail HTML é realmente ridículo

  • Se você só quer expressar itálico e coisas do tipo, então talvez o que você queira seja text/enriched [1], de 1996. É bem provável que quase todos os clientes de e-mail tenham suporte de leitura
    [1] https://www.rfc-editor.org/rfc/rfc1896.txt
  • Frameworks de e-mail responsivo, como MJML, realmente existem

• Há muito tempo defendo que texto formatado em e-mail deveria usar, em vez de HTML, algo como Markdown sem HTML inline, ou algum tipo semelhante de marcação em texto simples
  Assim, o cliente de e-mail poderia decidir facilmente se exibe aquilo como texto formatado ou apenas como texto puro, e ainda dar suporte à maior parte da formatação de que usuários comuns precisam: negrito, itálico, citações, imagens inline, blocos de código, títulos etc.
  Talvez isso não sirva para e-mails de marketing que usam HTML muito avançado, mas não acho que esse caso de uso mereça tanta consideração

  • Existe algo parecido, o text/enriched definido na RFC 1896. Apple Mail e outros também têm suporte
    https://en.wikipedia.org/wiki/Enriched_text
    https://www.rfc-editor.org/rfc/rfc1896.html
  • Muitos parsers de Markdown permitem HTML inline. Em algumas linguagens, a maioria faz isso, e só alguns permitem desativar. Isso é realmente idiota
  • Mostrar HTML em um terminal de texto, como o navegador Lynx faz, também funciona bastante bem, então não entendo por que seria necessário outra linguagem de marcação
  • Seria difícil conseguir adoção suficiente. Padrões de e-mail são difíceis de mudar
    O e-mail ainda nem tem suporte adequado para hiperlinks, e recentemente houve uma tentativa de corrigir isso
    https://pastebin.com/kHQs50xm
  • Cor e tamanho são elementos básicos e úteis da escrita

• O verdadeiro risco para a organização é o desenvolvedor encarregado de gerar e-mails em HTML enlouquecer, se trancar na sala do servidor e sair gritando “por que o rendering no Outlook sai diferente” enquanto destrói todo o hardware
  Falando sério, porém, esta é uma vulnerabilidade muito interessante

  • Por isso, já há alguns anos decidimos simplesmente pagar por um serviço de codificação de e-mails HTML. É preciso muito conhecimento especializado para codificar templates HTML que passem nos testes do Litmus, e eu não quero mais mexer com isso nunca de novo

• Não daria para corrigir isso proibindo folhas de estilo e permitindo apenas o atributo style inline nas tags?
  Por usabilidade, o cliente de e-mail poderia até incluir uma etapa automática que “compila” todas as folhas de estilo em estilos inline
  Assim, só quebrariam seletores CSS avançados, como hover, e nem sei se isso é realmente necessário

  • Concordo. Deve dar para resolver aplicando todos os estilos de todas as classes como estilos inline antes de exibir o e-mail. De qualquer forma, isso já faz sentido
    Pseudoclasses e media queries deixariam de funcionar, mas elas podem representar risco de segurança e nem são suportadas pelos principais clientes de e-mail: https://www.caniemail.com/features/css-at-media/
  • E-mails em HTML já exigem CSS inline porque Outlook e Gmail usam motores de rendering com décadas de idade. O Outlook literalmente usa o motor HTML do MS Word de por volta de 2006
    Além disso, se você matar todos os atributos style, também mata a otimização para mobile e o modo escuro. Media queries não podem ser inlineadas
  • Isso também quebraria a abordagem atual de e-mail responsivo
    Normalmente, os estilos base/desktop já são compilados e inlineados, e os seletores com media query ficam na tag style dentro de head para facilitar a leitura em dispositivos móveis

• Realmente muito inteligente
  A premissa é que, por causa do CSS em e-mails HTML, certos textos só podem ficar visíveis depois que a mensagem é encaminhada. Isso é uma grande ameaça à confiabilidade de e-mails verificados
  Há exemplos com Thunderbird, Outlook e Gmail, e é um excelente trabalho
  Eu leio todos os meus e-mails no mutt, então oficialmente isso é “problema dos outros”
  Então, para reclamar de outra coisa, a data do reporte para a Mozilla aparece como 05.03.2024. Concordo que a data little-endian faz mais sentido do que a data middle-endian americana
  Mas, se você é técnico, considero errado não usar o formato de data ISO 8601 2024-03-05, com ou sem hífens :)

  • E mais: qualquer pessoa que use o formato de data middle-endian está errada. É a forma mais irracional possível de escrever isso
    Little-endian pelo menos tem a vantagem de ser o oposto de como todos os outros números são escritos, mas middle-endian é simplesmente um formato insano. Claro, por isso mesmo é o formato usado pelos americanos

• Dá para ver que alguns dos clientes de e-mail mencionados envolvem o conteúdo da mensagem com tags HTML adicionais e mudam o CSS e os nomes das classes
  Fico me perguntando por que os clientes de e-mail não usam um iframe com sandbox ao renderizar e-mails HTML. Ainda assim haveria risco de segurança?

  • O HTML adicional não é gerado pelo cliente que lê o e-mail encaminhado, mas no momento do encaminhamento
    É um comportamento esperado, já que a pessoa que encaminha pode querer adicionar mais texto ao e-mail
  • Antigamente usavam iframe e isso trouxe problemas. Não eram problemas de rendering nem de segurança; pelo que lembro, essa parte funcionava bem
    O problema é que, se houver um link para um site no e-mail e o iframe com sandbox não permitir JavaScript, esse contexto de segurança se estende até a página aberta ao clicar no link dentro do iframe, e o site não consegue usar JS
    A solução foi allow-popups-to-escape-sandbox, então hoje não parece haver motivo para isso não funcionar

• Esta é a solução clássica de amputar braços e pernas para curar um ferimento. O problema é a má padronização de e-mail que permitiu que esse tipo de hack dominasse
  O HTML como um todo é vulnerável a esse tipo de preocupação. Ainda assim, há muitos e-mails que usam HTML sem problema. Este texto soa como uma frustração pessoal com algo encontrado na natureza, embalada como se fosse uma questão de segurança

• As possíveis mitigaçãoes que me vêm à cabeça são estas, embora talvez não funcionem: alertar de forma bem visível sobre elementos ocultos, randomizar a quantidade de divs de encapsulamento tanto no recebimento quanto no envio, e calcular como aquilo realmente vai aparecer quando for encaminhado, pedindo confirmação se houver grande diferença
  Ou talvez tratar isso de forma inversa seja mais eficaz. Assim não depende da ajuda de outros clientes

• É só mudar para “por que e-mail é perigoso para organizações”

  • A essa altura, vira simplesmente “por que a comunicação com o mundo externo é perigosa para organizações”
    Este texto mostra um vetor de ataque específico de e-mails HTML, mas a maioria dos ataques por e-mail pode ser facilmente adaptada para WhatsApp, Slack, Jira, Zoom ou qualquer ferramenta que as pessoas usem para se comunicar com o lado de fora