Alguns servidores com nginx permanecem vulneráveis à técnica Nginx Alias Traversal, proposta na conferência Blackhat em 2018 e permite o acesso a arquivos e diretórios localizados fora do diretório raiz especificado na diretiva "alias". O problema aparece apenas em configurações com uma diretiva "alias" colocada dentro do bloco "location", cujo parâmetro não termina com o caractere "/", enquanto o "alias" termina com "/".
A essência do problema é que os arquivos para blocos com a diretiva alias são fornecidos anexando o caminho solicitado, depois de combiná-lo com a máscara da diretiva de localização e recortando a parte do caminho especificada nesta máscara. Para o exemplo de uma configuração vulnerável mostrada acima, um invasor pode solicitar o arquivo "/img../test.txt" e essa solicitação corresponderá à máscara especificada no local "/img", após o qual a cauda restante "../test.txt" será anexada ao caminho da diretiva de alias "/var/images/" e, como resultado, o arquivo "/var/images/../test.txt" será solicitado. Assim, os invasores podem acessar qualquer arquivo no diretório "/var", e não apenas arquivos em "/var/images/", por exemplo, para baixar o log nginx, você pode enviar a solicitação "/img../log/nginx/access.log".
Nas configurações em que o valor da diretiva alias não termina com um caractere "/" (por exemplo, "alias /var/images;"), o invasor não pode mudar para o diretório pai, mas pode solicitar outro diretório em /var cujo nome comece com aquele especificado na configuração. Por exemplo, solicitando "/img.old/test.txt" você pode acessar o diretório "var/images.old/test.txt".
Uma análise dos repositórios no GitHub mostrou que erros na configuração do nginx que levam ao problema ainda são encontrados em projetos reais. Por exemplo, foi detectada a presença de um problema no back-end do gerenciador de senhas Bitwarden e poderia ser usado para acessar todos os arquivos no diretório /etc/bitwarden (os pedidos de /attachments foram emitidos de /etc/bitwarden/attachments/), incluindo o banco de dados armazenado lá com senhas “vault.db”, um certificado e logs, para os quais bastava enviar solicitações “/attachments../vault.db”, “/attachments../identity.pf x”, “/atta chments../logs/api.log" etc.
O método também funcionou com o Google HPC Toolkit, onde as solicitações /static foram redirecionadas para o diretório "../hpc-toolkit/community/front-end/website/static/". Para obter um banco de dados com uma chave privada e credenciais, um invasor pode enviar consultas "/static../.secret_key" e "/static../db.sqlite3".
Fonte: opennet.ru