Martin R. Albrecht

O problema é causado por um bug no matrix-js-sdk, no qual um invasor em conluio com um servidor doméstico malicioso poderia interferir no fluxo de verificação entre dois usuários, injetando sua própria identidade de usuário com assinatura cruzada no lugar da identidade de um dos usuários. Isso levaria o outro dispositivo a confiar/verificar a identidade do usuário sob o controle do servidor doméstico, em vez da identidade pretendida. A vulnerabilidade é parcialmente possibilitada pela decisão de design de tratar identidades de usuário com assinatura cruzada como dispositivos Matrix no lado do servidor. Nenhuma outra implementação examinada apresentou vulnerabilidade. A partir da versão 19.7.0, o matrix-js-sdk foi modificado para verificar novamente se a chave assinada é a mesma que foi verificada, em vez de apenas referenciar a chave pelo ID. Uma verificação adicional foi implementada para relatar um erro quando um dos IDs de dispositivo corresponder a uma chave de assinatura cruzada.

Um invasor em colaboração com um servidor doméstico malicioso pode criar mensagens que parecem ter sido enviadas por outra pessoa, sem qualquer indício. Essa vulnerabilidade pode ser usada para realizar ataques direcionados, enviando mensagens falsas para o dispositivo e, potencialmente, injetando segredos de backup de chaves. O problema se deve a uma vulnerabilidade de confusão de protocolo que aceita mensagens para o dispositivo criptografadas com Megolm em vez de Olm.

Um invasor em conluio com um servidor doméstico malicioso pode criar mensagens que parecem ter sido enviadas por outra pessoa. Essas mensagens serão marcadas com um escudo cinza em algumas plataformas, mas essa marcação pode não aparecer em outras. Este ataque é possível devido ao fato de o matrix-js-sdk implementar uma estratégia de encaminhamento de chaves excessivamente permissiva no lado receptor. O SDK agora define um sinalizador `trusted` na mensagem descriptografada após a descriptografia, com base no fato de a chave usada para descriptografar a mensagem ter sido recebida de uma fonte confiável. Os clientes precisam garantir que as mensagens descriptografadas com uma chave com `trusted = false` sejam sinalizadas adequadamente, por exemplo, exibindo um aviso para tais mensagens. Esse ataque requer coordenação entre um servidor doméstico malicioso e um invasor, e aqueles que confiam em seus servidores domésticos não precisam de uma solução alternativa.

A vulnerabilidade permite que um invasor, em cooperação com um servidor doméstico malicioso, crie mensagens que parecem ter sido enviadas por outra pessoa. Essas mensagens podem ser marcadas com um escudo cinza em algumas plataformas, mas esse indicador pode não aparecer em outras. Isso se deve a uma estratégia de encaminhamento de chaves excessivamente permissiva implementada no SDK do Matrix para iOS. O SDK foi atualizado para aceitar apenas chaves encaminhadas em resposta a solicitações emitidas anteriormente e somente de dispositivos próprios e verificados. Um sinalizador `trusted` é definido em mensagens descriptografadas com base no fato de a chave usada para a descriptografia ter sido proveniente de uma fonte confiável. Os clientes devem garantir que as mensagens descriptografadas com uma chave marcada como `trusted = false` sejam devidamente sinalizadas, por exemplo, exibindo um aviso. Esse ataque requer coordenação entre um servidor doméstico malicioso e um invasor.

A vulnerabilidade permite que um invasor, em cooperação com um servidor doméstico malicioso, crie mensagens que pareçam ter sido enviadas por outra pessoa, sem qualquer indicação de que se trata de uma falsificação. Um invasor experiente poderia explorar essa vulnerabilidade para realizar um ataque direcionado, enviando mensagens falsas para o dispositivo que pareçam ter sido originadas por outro usuário. Isso pode permitir a injeção do segredo de backup da chave durante a autoverificação, fazendo com que um dispositivo alvo utilize um backup de chave malicioso falsificado pelo servidor doméstico. Esses ataques são possíveis devido a uma vulnerabilidade de confusão de protocolo que aceita mensagens para o dispositivo criptografadas com Megolm em vez de Olm. O ataque requer coordenação entre um servidor doméstico malicioso e um invasor.

A vulnerabilidade permite que um invasor, em cooperação com um servidor doméstico malicioso, crie mensagens que pareçam ter sido enviadas por outra pessoa, sem qualquer indício de falsificação. Um invasor sofisticado poderia empregar essa vulnerabilidade para realizar um ataque direcionado, enviando mensagens falsas para o dispositivo que parecem ter origem em outro usuário. Isso pode permitir a injeção do segredo de backup da chave durante a autoverificação ou fazer com que um dispositivo alvo utilize um backup de chave malicioso falsificado pelo servidor doméstico. Os ataques são possíveis devido a uma vulnerabilidade de confusão de protocolo que aceita mensagens para o dispositivo criptografadas com Megolm em vez de Olm.

Existe uma falha de reordenação no Telegram, permitindo que um invasor faça com que o servidor receba mensagens em uma ordem diferente daquela em que foram enviadas ao cliente. Essa falha pode ser explorada por um invasor, levando potencialmente a consequências indesejadas.