EFAIL -ESTARÁ O PGP EFETIVAMENTE MORTO?

Uma vulnerabilidade (https://efail.de/) foi publicada recentemente e afeta o PGP e o S/MIME, dois mecanismos usados para criptografia de e-mail. Para mitigar esta vulnerabilidade, recomenda-se desabilitar os plugins de desencriptação de mensagens incluídos nas definições e, acima de tudo, não usá-los para ler mensagens criptografadas nos próprios gestores de email.

Mas, espere … não ler as mensagens criptografadas? Não seria mais lógico aconselhar não escrever mensagens criptogafadas? Neste post iremos tentar entender o que esta vulnerabilidade representa, o porquê de acontecer e qual é lógica por detrás do problema de estar ler mensagens criptografadas.

Esta vulnerabilidade afeta a criptografia de email por meio de dois mecanismos diferentes, embora ambos dependam de um conceito semelhante. Para entender a vulnerabilidade, primeiro veremos a versão mais simples, embora seja a menos aplicável, pois exige um processamento incorreto de mensagens pelo cliente de email.

A PGP e a S/MIME são muito semelhantes. Baseiam-se num mecanismo de criptografia assimétrica, mas a criptografia real é realizada simetricamente. Como esta vulnerabilidade afeta a parte simétrica dos mecanismos de criptografia, trataremos o PGP e o S/MIME ao longo do post como se usassem criptografia simétrica.

Neste exemplo a Alice quer enviar uma password para o Bob. Como ela sabe que a Eve está interessada em obter essa password, e que a Eve está a interceptar a mensagem em trânsito, envia-a dentro de uma mensagem criptografada. A Alice encripta a mensagem e a envia-a para o Bob, que pode decodificá-la com sucesso. A Eve intercepta a mensagem, mas, como está criptografada com uma chave desconhecida (para ela), não é possível desencriptá-la e obter a senha.

Agora, a Eve sabe que Bob usa um cliente de email vulnerável à versão mais simples dessa vulnerabilidade. O que ele faz é enviar um email em HTML para Bob composto por três seções (multiparte). O primeiro e o último são claros e gerados por Eve, com os quais consegue controlar o seu conteúdo. A segunda seção envia a mensagem original gerada por Alice, que ela conseguiu interceptar (embora ela não possa lê-lo). Quando o email chega, o Bob abre. O seu gestor de e-mail detecta as três seções e a segunda é encriptada. Portanto, ele decifra e mostra a Bob o conteúdo.

E qual é o conteúdo? A Eve construiu a mensagem de tal forma que a primeira seção contém uma tag <img> que indica que uma imagem especificada pelo URL que vem naquela seção deve ser descarregada. No entanto, podemos ver que o atributo “src” não está concluído, já que as aspas estão em falta. A conclusão deste atributo é feita na terceira seção, onde estão as aspas e o fecho da tag <img>. Com isto, a Eve conseguiu que o conteúdo enviado por Alice ficasse dentro do URL da imagem. Como a Eve controla totalmente a primeira parte da mensagem, isso pode indicar que a imagem está num servidor controlado por ela. O conteúdo da mensagem desencriptada será incluído no URL e Eve terá apenas que analisar o pedido de Bob para obter a mensagem de Alice desencriptada.

Esta é a razão pela qual o perigo está na leitura de e-mails criptografados. A leitura de um email mal-intencionado pode fazer com que o gestor de email aceda a um recurso externo, enviando de forma silenciosa e transparente o conteúdo claro de qualquer outra mensagem criptografada para Eve. Por exemplo, a Eve poderia ter preparado a mensagem para que a imagem fosse carregada num iframe oculto, de modo que, a priori, não haveria nenhuma suspeita.

Nesse caso, a vulnerabilidade é que o gestor de mensagens pegou em três seções independentes da mensagem reuniu-as, gerando uma única tag HTML. Um gestor de e-mail com um bom comportamento deve mostrar as três seções independentemente, para que uma tag <img> contendo a mensagem original de Alice nunca seja obtida.

Isto se explorarmos a vulnerabilidade na sua forma mais “simples”. Agora, supondo que tenhamos um gestor de e-mail que não seja vulnerável, mas mostre as três seções independentemente … Podemos continuar a explorar essa vulnerabilidade?

Para entender melhor o outro aspecto da vulnerabilidade, devemos saber que a PGP e a S/MIME usam criptografia por blocos. Isto significa que a mensagem original é dividida em blocos de tamanho fixo. Cada bloco de entrada resulta num bloco de saída do mesmo tamanho. Relacionado a este mecanismo, a criptografia simétrica de PGP e S/MIME levanta dois problemas.

Por um lado, usam algoritmos (tecnicamente, modos de criptografia) que são “maleáveis”. Isto significa que é possível reordenar ou repetir os blocos da mensagem e, exceto para certos blocos que serão decifrados incorretamente, os blocos reordenados continuarão sendo decifrados corretamente.

Por outro lado, se um atacante souber perfeitamente o conteúdo original (não encriptado) de dois blocos consecutivos, poderá gerar pares de blocos criptografados que, quando decifrados, resultarão num bloqueio com conteúdo aleatório (que não atende ao atancante), mas o outro bloco conterá texto que pode ser controlado pelo atacante. Como a maioria das mensagens PGP e S/MIME começa com uma série de cabeçalhos fixos, o atacante conhece o conteúdo desencriptado dos primeiros blocos e pode injetar o texto controlado por ele no conteúdo que o utilizador desencripta

Conhecendo esses dois problemas, a Eve pode fazer derivar da mensagem criptografada original de Alice (e mesmo sem conhecer a chave de encriptação) uma mensagem maliciosa que, quando decifrada, contém:

  • Seções de conteúdo aleatório
  • Seções de conteúdo controlado por Eve
  • Seções da mensagem original de AliceE depois de ver o ataque anterior, podemos ter uma ideia de que tipo de conteúdo terá a mensagem maliciosa gerada por Eve …

Onde as seções “XXXX” indicam partes da mensagem que Eve não pode controlar e não vem da mensagem original de Alice. Na verdade, a mensagem não tem exatamente essa forma. As partes que a Eve controla têm um tamanho fixo, assim como as aleatórias, o que torna o trabalho de Eve muito difícil. No entanto, a imagem anterior ilustra o conceito do ataque.

Esse aspecto da vulnerabilidade afetaria qualquer cliente de e-mail que decifre mensagens PGP ou S/MIME e descarrega informações externas associadas a esses e-mails (neste caso, a “imagem” mal-intencionada). A vulnerabilidade deve-se ao fato de que os modos usados pelo PGP e pelo S/MIME são maleáveis, como já vimos, já que falamos de tecnologias que têm muitos anos. Hoje existem modos que fornecem um recurso chamado AEAD (Criptografia Autenticada com Dados Associados), como o GCM. Estes modos detectam modificações no fluxo de dados, o que impediria que a Eve gerasse uma mensagem válida sem conhecer a chave de criptografia simétrica. O gestor de e-mail de Bob detetaria que a mensagem foi modificada e não seria mostrada. Sim, é verdade que o PGP inclui um mecanismo chamado SEIP que fornece um certo nível de proteção contra modificações, mas no próprio artigo do EFAIL eles indicam que é possível evitá-lo executando um “downgrade do SEIP”.

Em resumo, apesar de todo o tumulto que foi montado, não seria justo dizer que o PGP como tal foi comprometido (há muitas discussões sobre se isso é tecnicamente uma vulnerabilidade do PGP ou dos clientes de email). Tem os seus problemas, logicamente (como o fato da maleabilidade de suas mensagens e a possibilidade de evitar a proteção do SEIP), mas até certo ponto o PGP ainda é perfeitamente válido. O problema, neste caso, surge da possibilidade de “exfiltrar” os dados, a partir de mensagens encriptadas, de funcionalidades incluídas numa grande parte dos gestores de e-mail.

É por isso que é recomendado desabilitar os plug-ins PGP e S/MIME nos gestores de e-mail, para evitar que a desencriptação de uma mensagem mal-intencionada forneça a ao atacante o conteúdo claro de uma mensagem criptografada legítima. No entanto, conhecendo essas limitações e entendendo o âmbito dessa vulnerabilidade, é perfeitamente possível continuar a utilizar estes sistemas de criptografia, tendo o cuidado de usar ferramentas externas para sua decifra, e verificar se a mensagem em claro não mostra seções com dados que induzam a erro. Estes podem sugerir que é uma mensagem maliciosa.

Desativar a exibição de HTML em mensagens recebidas também pode dificultar que um atacante explore essa vulnerabilidade facilmente. No entanto, a extração de dados utilizando tags <img> não é a única maneira aberta para um atacante, portanto, não implica que fiquemos 100% de seguros.

Recent Posts