Alguns servidores com nginx permanecem vulneráveis à técnica Nginx Alias Traversal, que foi proposta na conferência Blackhat em 2018 e permite o acesso a arquivos e diretórios localizados fora do diretório raiz definido na diretiva "alias". O problema se manifesta apenas em configurações com a diretiva "alias" localizada dentro do bloco "location", cuja parábola não termina com o caractere " / ", enquanto a "alias" termina com " / ".
A essência do problema é que os arquivos para blocos com a diretiva alias são entregues através da anexação do caminho solicitado, após sua correspondência com a máscara da diretiva location e a remoção da parte do caminho definida nessa máscara. Para o exemplo acima da configuração vulnerável, um atacante pode solicitar o arquivo " /img.. /test.txt " e esse pedido ficará sob a máscara especificada na location " /img ", após o que o rabo restante " .. /test.txt " será anexado ao caminho da diretiva alias " /var/images/ " e, no final, será solicitado o arquivo " /var/images/.. /test.txt ". Assim, os atacantes podem acessar qualquer arquivo no diretório " /var ", e não apenas os arquivos em " /var/images/ ", por exemplo, para baixar o log do nginx, pode-se enviar a solicitação " /img.. /log/nginx/access.log ".
Em configurações nas quais o valor da diretiva alias não termina com o símbolo " / " (por exemplo, " alias /var/images; "), um atacante não pode navegar para o diretório pai, mas tem a possibilidade de solicitar outro diretório em /var, cujo nome comece com o especificado na configuração. Por exemplo, solicitando " /img.old /test.txt " pode-se acessar o diretório " var/images.old /test.txt ".
A análise de repositórios no GitHub mostrou que erros de configuração de nginx que levam ao problema ainda ocorrem em projetos reais. Por exemplo, a presença do problema foi identificada no backend do gerenciador de senhas Bitwarden e poderia ser usada para acessar todos os arquivos no diretório /etc/bitwarden (as solicitações /attachments eram entregues a partir de /etc/bitwarden/attachments/), incluindo o banco de dados armazenado lá com as senhas "vault.db", certificado e logs, para obter os quais era suficiente enviar solicitações " /attachments.. /vault.db ", " /attachments.. /identity.pfx ", " /attachments.. /logs/api.log ", etc.
O método também funcionou com o Google HPC Toolkit, onde as solicitações /static eram redirecionadas para o diretório " .. /hpc-toolkit /community /front-end /website /static / ". Para obter o banco de dados com a chave secreta e credenciais, o atacante poderia enviar as solicitações " /static.. / .secret_key " e " /static.. /db.sqlite3 ".
Fonte: opennet.ru
