mgrube/cve-2019-9673Write-up
NOTA: Divulguei completamente este bug à equipe do Freenet e trabalhei com eles para verificar a correção. A correção já está implantada na versão mais recente do Freenet.
Recentemente, encontrei uma vulnerabilidade de segurança no Freenet que pode permitir que um atacante desanonimize um alvo ou envie documentos maliciosos através do Freenet.
Esta vulnerabilidade afeta usuários do Freenet que usam o Firefox como navegador. Ela permite desanonimização e outros comportamentos maliciosos no computador do usuário. Está presente em todas as versões até a 1483.
Este exploit funciona aproveitando-se de uma desconexão entre o Firefox e o Freenet no tratamento de tipos MIME. O Freenet vem com filtros para muitos tipos de conteúdo diferentes — um grande esforço foi feito para garantir que apenas conteúdo bem-formado e sem script possa ser renderizado sem uma série de avisos ao usuário.
De modo geral, o Freenet faz um bom trabalho ao lidar com os dados da maneira correta e permitir que o usuário especifique se deseja que eles sejam tratados de outra forma.
O Firefox, por outro lado, é um pouco mais sutil na forma como determina o tipo MIME de um arquivo. Especificamente, conforme documentado aqui. A maior parte do processo documentado nesta página está fora do controle do atacante, especialmente se ele precisar atacar através do Freenet.
Uma coisa que está sob o controle do atacante, no entanto, é o tipo MIME dos dados a serem inseridos. Quando os dados são inseridos na rede Freenet, um usuário pode especificar o tipo MIME — quando esse campo é deixado nulo, os dados são tratados como application/octet-stream e recebem todo o tratamento adequado em relação aos avisos.
No entanto, ao navegar para a seção HTTP da documentação da Mozilla, vemos que o Firefox na verdade faz suas próprias suposições sobre o tipo MIME dos dados quando certas condições não são atendidas pela aplicação que serve o conteúdo. Especificamente, quando o cabeçalho Content-Encoding não é enviado por uma aplicação, o Firefox faz o sniffing do conteúdo para decidir o que fazer com ele. Se o primeiro bloco de dados não for texto, o Firefox tratará o arquivo como o tipo MIME indicado pela extensão.
Descobriu-se que o Freenet não estava enviando esse cabeçalho em suas respostas, o que nos permite transformar isso em algo utilizável. Como nossos dados podem ser inseridos como tipo MIME text/plain, que obviamente não recebe filtragem sofisticada, mas podem ser entregues como qualquer tipo MIME indicado pela extensão do arquivo, agora temos uma maneira de entregar um documento HTML não filtrado (ou PDF, ou .docx...). Isso é um grande problema, pois normalmente todo conteúdo perigoso é recomendado para download em uma pasta ou espaço temporário e aberto fora do navegador.
Este é um vídeo rápido do exploit funcionando — neste caso, para entregar um arquivo HTML não filtrado.
Para um exemplo prático, instale a versão 1483 ou anterior e navegue até:
Para quem quiser acompanhar por conta própria, você pode obter a versão vulnerável mais recente do Freenet aqui.
Então, como poderíamos usar isso no mundo real?
Acontece que se você criar um link para seu conteúdo malicioso dentro do Freenet em uma página que o usuário já está navegando, o Freenet tratará o arquivo como o tipo indicado pela sua extensão. O Freenet verá que o nosso primeiro bloco de dados é binário e avisará o usuário de que o nosso arquivo é malicioso.
:(
Isso significa que, se quisermos que nosso alvo visualize nossa página maliciosa com JS ativo, precisamos criar um link externo para ela. Isso na verdade é aceitável, porque os sistemas de mensagens mais populares do Freenet não operam através do proxy web do Freenet.
Se, por exemplo, a URI de demonstração deste artigo fosse vinculada dentro do FMS, não haveria verificação extra e nosso payload poderia ser executado.
Tudo o que seria necessário para desanonimizar vários usuários do Freenet seria criar conteúdo com um título interessante, inserir um arquivo com o primeiro bloco de dados binário e depois criar uma página web convincente que relate silenciosamente o endereço IP e a atividade em segundo plano. Combine isso com um conjunto de ferramentas como o framework BeEF e você terá algumas oportunidades interessantes.
Podemos, é claro, usar isso também como vetor para entregar um PDF malicioso, .docx ou outros arquivos e obter uma posição mais permanente na máquina do usuário.
Corrigir esse bug é bastante simples — a partir de agora, o FProxy sempre passará o cabeçalho HTTP Content-Encoding ao entregar conteúdo. Esse cabeçalho instrui o navegador Firefox a tratar os tipos MIME explicitamente como definidos pelo FProxy. Como resultado, dados do tipo text/plain serão sempre renderizados como texto puro e não tratados como qualquer outro tipo MIME.
Este bug foi, no geral, bastante simples — mas tinha a capacidade de impactar a funcionalidade do Freenet de forma significativa. A verificação de tipos MIME é realmente importante, e uma grande lição deste bug é que os tipos MIME nem sempre são tratados de forma consistente quando os dados são passados de um programa para outro.
Basta inserir alguns dados no Freenet com o tipo MIME text/plain e o primeiro bloco contendo apenas dados binários. O Firefox o tratará como o tipo especificado pela extensão do arquivo, e ele será entregue diretamente ao usuário em vez de ser filtrado pelo Freenet. Envie para suas vítimas no FMS ou Frost. Colete os endereços IP delas ou faça-as executar um payload binário. Lucro!
