Carta Kobold: os perigos dos e-mails em HTML
(lutrasecurity.com)Carta Kobold
- Quem precisa lidar tecnicamente com e-mails em HTML provavelmente já chegou ao ponto de querer largar o emprego ou incendiar todos os clientes de e-mail por causa das implementações inconsistentes entre eles.
- E-mails em HTML não são apenas uma fonte de irritação, mas também podem representar um sério risco de segurança.
- Imagine que seu chefe encaminhou um e-mail pedindo para transferir uma grande quantia em dinheiro; como você já ouviu falar de golpes do CEO, verifica se o e-mail realmente veio dele.
- O e-mail de fato veio do seu chefe e, se a empresa faz isso, pode até estar assinado com criptografia.
- Mas você ainda não está convencido, então liga para seu chefe para confirmar a autenticidade do e-mail.
- Se seu chefe confirmar, você transfere o dinheiro.
- Mas se isso não fosse um golpe, este artigo terminaria aqui.
Thunderbird
- Esse problema foi reportado à Mozilla em 5 de março de 2024, e a data de divulgação planejada junto com o rascunho da seção seguinte foram enviados à Mozilla em 20 de março de 2024.
- Possíveis medidas de mitigação foram discutidas, mas só devem ser implementadas mais tarde.
- Explorar isso no Thunderbird é simples. O Thunderbird envolve o e-mail em `
` e, fora isso, não altera nada.
- Ao encaminhar o e-mail, a mensagem citada é envolvida em outra `
` e desce um nível no DOM.
- Levando isso em conta, chega-se à seguinte prova de conceito:
.kobold-letter {
display: none;
}
.moz-text-html>div>.kobold-letter {
display: block !important;
}
This text is always visible.
This text will only appear after forwarding.
- O e-mail contém texto sempre visível e texto oculto com
display: none;. - Quando o e-mail é encaminhado, o texto oculto de repente passa a ficar visível apenas para o novo destinatário.
Outlook Web
- Esse problema foi reportado à Microsoft em 5 de março de 2024, e a data de divulgação planejada junto com o rascunho da seção seguinte foram enviados à Microsoft 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.
- No Outlook Web (OWA), a situação é um pouco mais complexa. O e-mail é envolvido por `
`, mas o nome exato da classe pode mudar.
- Para impedir que o CSS do e-mail afete os estilos do webmail, o Outlook adiciona o prefixo
x_a todos os ids e classes do e-mail e ajusta o CSS. - Levando isso em conta, chega-se à seguinte prova de conceito:
.kobold-letter {
display: none;
}
body>div>.kobold-letter {
display: block !important;
}
This text is always visible.
This text will only appear after forwarding.
- Ao exibir o e-mail no OWA, o CSS fica assim:
- Depois que o e-mail é encaminhado, a carta kobold é envolvida por outra `` e o CSS é atualizado novamente.
Gmail
- Esse problema foi reportado ao Google em 5 de março de 2024, e a data de divulgação planejada junto com o rascunho da seção seguinte foram enviados ao Google em 20 de março de 2024.
- O Gmail tecnicamente não é vulnerável à carta kobold, porque remove todos os estilos ao encaminhar um e-mail.
- Ao encaminhar o e-mail, até que o CSS seja removido, a carta kobold oculta por CSS aparece automaticamente.
Pesquisas anteriores
- A possibilidade disso não é surpreendente nem nova.
- Problemas semelhantes já foram reportados no passado.
Perspectivas
- Os usuários podem mitigar a carta kobold desativando completamente os e-mails em HTML ou visualizando-os em um modo restrito.
- Para os clientes de e-mail, é difícil implementar uma mitigação. Impedir o uso de `` pode resolver o problema, mas pode quebrar muitas soluções já existentes no ecossistema de e-mail.
- Infelizmente, é pouco realista esperar que os clientes de e-mail implementem medidas robustas de mitigação em um futuro próximo.
Opinião do GN⁺
- Este artigo mostra as vulnerabilidades dos e-mails em HTML e explica, em especial, o ataque de “carta kobold”, no qual o conteúdo pode mudar quando o e-mail é encaminhado. Isso é uma informação importante para aumentar a conscientização dos usuários sobre segurança.
- Ele mostra que vulnerabilidades de segurança podem surgir da forma como os clientes de e-mail lidam com CSS e chama a atenção de usuários e desenvolvedores para a necessidade de cautela com segurança.
- Esse tipo de ataque é especialmente perigoso porque parece vir de uma fonte em que o usuário confia. Isso reforça a necessidade de manter sempre a vigilância nas comunicações por e-mail.
- Do ponto de vista técnico, os desenvolvedores de clientes de e-mail precisam melhorar a forma como processam CSS para evitar esse tipo de ataque. No entanto, isso pode causar problemas de compatibilidade com designs de e-mail já existentes, por isso é importante encontrar um equilíbrio adequado.
- Este artigo não trata de uma nova tecnologia nem de open source, mas apresenta pontos a considerar ao adotar tecnologias relacionadas à segurança de e-mail. Desenvolvedores de clientes de e-mail precisam buscar formas de reforçar a segurança dos usuários sem comprometer a usabilidade.
1 comentários
Comentários do Hacker News
The other day I was discussing the design for an "update" email that our designer was putting together...
I long argued that we should use markdown (without the inline HTML) or a similar simple text markup...
The real risk to your organisation is that the developer you assign to generate HTML emails will go mad...
Wouldn’t this be fixable by not allowing Stylesheets but only inline style attributes on the tags?
HTML in email shouldn't be as big of a nightmare as it is.
Some possible mitigations from the top of my head (maybe ineffective):
When efail came out, I wrote a blogpost about the security risks of HTML mail.
This is really clever!
iframeem sandbox para renderizar e-mails HTML.