Participei de uma reunião do Grupo de Trabalho sobre Mensagens, Malware e Anti-Abuso Móvel (m3aawg.org) no Brooklyn, Nova York. Eu esperava um clima melhor para passear pela cidade, curtir a conferência e uma grande variedade de alimentos na área. Eu tinha tanta certeza da claridade do céu que nem levei nada da chuva comigo. E choveu a semana toda. Isso me forçou a ficar no meu quarto de hotel com Wi-Fi gratuito e meu laptop de trabalho. Decidi passar esse tempo pesquisando o Node.js e seus pacotes relacionados disponíveis em https://www.npmjs.com .
Existem milhares de pacotes de usuários disponíveis para download e instalação em seu projeto. Pesquisei no NPM nomes de pacotes populares, como arquivo, backup, download ou upload. A última pesquisa me mostrou um projeto chamado upload de arquivo jQuery do Blueimp. Sua descrição parecia interessante o suficiente para baixar e explorar.
Widget de upload de arquivos para jQuery, com suporte para seleção múltipla de arquivos, arrastar e soltar, indicador de progresso, validação e visualização de imagens, áudio e vídeo. Ele suporta solicitações entre domínios, um mecanismo parcial e renovável para baixar arquivos com redimensionamento de imagens no lado do cliente. Ele funciona em qualquer plataforma de servidor (PHP, Python, Ruby on Rails, Java, Node.js, Go, etc.), que suporta o upload de arquivo padrão via formulário HTML.
Comecei a procurar a fonte do pacote e me concentrei em alguns arquivos PHP no diretório server / php. Os arquivos foram chamados upload.php e UploadHandler.php. upload.php chamado UploadHandler.php, onde estava localizado o código de upload do arquivo principal. Também notei que os arquivos foram carregados no diretório files / na raiz do servidor web. Eu escrevi um comando simples com curl e um script PHP primitivo que me confirmou que eu posso carregar o arquivo no servidor e usá-lo para executar os comandos no servidor.
$ curl -F "files=@shell.php" http://example.com/jQuery-File-Upload-9.22.0/server/php/index.php
Onde o arquivo shell.php contém:
<?php $cmd=$_GET['cmd']; system($cmd);?>
Abrir uma página no navegador com o parâmetro cmd = id do servidor de teste retornou o ID do usuário do qual o processo do servidor foi iniciado. Supus que essa vulnerabilidade não passasse despercebida e uma rápida pesquisa no Google confirmou para mim que outros projetos que usavam esse código ou seus derivados eram vulneráveis. Havia também vários vídeos mostrando como atacar pacotes de software semelhantes.
Notifiquei o autor do jQuery File Upload e comecei a documentar o que encontrei para atribuir um número CVE. Logo no dia seguinte, um autor um tanto envergonhado me respondeu, pedindo mais informações, pois não conseguia reproduzir a vulnerabilidade em seu ambiente de teste.
Depois de comparar nossas configurações de teste por email, descobrimos que os desenvolvedores do Apache haviam desativado o suporte a arquivos .htaccess desde a versão 2.3.9. Acontece que isso foi feito para melhorar o desempenho , para que o servidor não precise verificar esse arquivo sempre que acessar o diretório correspondente. Além disso, essa alteração também foi feita para impedir que os usuários substituam as configurações de segurança que foram definidas no servidor.
Portanto, o Apache teve boas intenções ao desativar o .htaccess, mas suas alterações também colocaram em risco alguns desenvolvedores e seus projetos, principalmente se eles estivessem contando com as configurações de segurança feitas no .htaccess.
No caso desta biblioteca, para lidar adequadamente com essa situação e corrigir a vulnerabilidade de upload de arquivo CVE-2018-9206, o desenvolvedor alterou o código para permitir o download apenas de arquivos de imagem.
Esse problema é mais de um projeto.
Também é importante notar aqui que, devido às mudanças no Apache, alguns dos 7.800 projetos restantes podem estar vulneráveis a problemas de upload de arquivos.
A maioria desses garfos ainda carrega a vulnerabilidade original em seu código. Em alguns casos, a vulnerabilidade permanece mesmo depois que o desenvolvedor editou o código original do Blueimp para incorporá-lo em seu projeto, para que os projetos ainda estejam vulneráveis ao meu exemplo de ataque com pequenas variações.
Isso significa que, se algum desses projetos for usado na produção, ele estará exposto à vulnerabilidade de baixar um arquivo com sua execução subsequente. Abrindo oportunidades para roubar dados do aplicativo, injetar malware, desfigurar e outras oportunidades de causar danos.
Infelizmente, não há como determinar exatamente quantos projetos bifurcados no jQuery File Upload original ainda são ativamente suportados e aplicam as alterações feitas no projeto principal. Também não é possível determinar exatamente onde os projetos bifurcados são usados na produção, se houver. Além disso, as versões mais antigas do projeto também estavam vulneráveis a problemas com o download de arquivos, até 2010.
Conclusão
A Internet conta com muitos mecanismos de segurança para manter nossos sistemas, dados e transações seguros e protegidos. Se um desses mecanismos desaparecer repentinamente, poderá comprometer a segurança dos usuários e desenvolvedores que dependem dele.
É uma boa idéia para os desenvolvedores olhar para as mudanças nos sistemas e bibliotecas nas quais eles baseiam seu projeto. Neste artigo, o mecanismo de segurança que o Apache removeu não afetou apenas o upload do arquivo Jquery do Blueimp, mas todos os seus garfos e ramificações. A vulnerabilidade afetou muitos projetos que dependem dela, desde aplicativos da web independentes até plug-ins para WordPress e outros CMS.