Nginx
Last updated
Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Obtenha a perspectiva de um hacker sobre seus aplicativos web, rede e nuvem
Encontre e relate vulnerabilidades críticas e exploráveis com impacto real nos negócios. Use nossas mais de 20 ferramentas personalizadas para mapear a superfície de ataque, encontrar problemas de segurança que permitem escalar privilégios e usar exploits automatizados para coletar evidências essenciais, transformando seu trabalho árduo em relatórios persuasivos.
Ao configurar o servidor Nginx, a diretiva root desempenha um papel crítico ao definir o diretório base a partir do qual os arquivos são servidos. Considere o exemplo abaixo:
Nesta configuração, /etc/nginx é designado como o diretório raiz. Essa configuração permite o acesso a arquivos dentro do diretório raiz especificado, como /hello.txt. No entanto, é crucial notar que apenas uma localização específica (/hello.txt) é definida. Não há configuração para a localização raiz (location / {...}). Essa omissão significa que a diretiva raiz se aplica globalmente, permitindo que solicitações para o caminho raiz / acessem arquivos sob /etc/nginx.
Uma consideração crítica de segurança surge dessa configuração. Uma simples solicitação GET, como GET /nginx.conf, poderia expor informações sensíveis ao servir o arquivo de configuração do Nginx localizado em /etc/nginx/nginx.conf. Definir a raiz para um diretório menos sensível, como /etc, poderia mitigar esse risco, mas ainda pode permitir acesso não intencional a outros arquivos críticos, incluindo outros arquivos de configuração, logs de acesso e até mesmo credenciais criptografadas usadas para autenticação básica HTTP.
Nos arquivos de configuração do Nginx, uma inspeção cuidadosa é necessária para as diretivas "location". Uma vulnerabilidade conhecida como Local File Inclusion (LFI) pode ser inadvertidamente introduzida através de uma configuração que se assemelha ao seguinte:
Esta configuração é suscetível a ataques LFI devido ao servidor interpretar solicitações como /imgs../flag.txt como uma tentativa de acessar arquivos fora do diretório pretendido, resolvendo efetivamente para /path/images/../flag.txt. Essa falha permite que atacantes recuperem arquivos do sistema de arquivos do servidor que não deveriam ser acessíveis via web.
Para mitigar essa vulnerabilidade, a configuração deve ser ajustada para:
Mais informações: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/
Testes da Accunetix:
Verifique a página a seguir para aprender como contornar diretivas como:
Variáveis vulneráveis $uri e $document_uri e isso pode ser corrigido substituindo-as por $request_uri.
Uma regex também pode ser vulnerável como:
location ~ /docs/([^/])? { … $1 … } - Vulnerável
location ~ /docs/([^/\s])? { … $1 … } - Não vulnerável (verificando espaços)
location ~ /docs/(.*)? { … $1 … } - Não vulnerável
Uma vulnerabilidade na configuração do Nginx é demonstrada pelo exemplo abaixo:
Os caracteres \r (Carriage Return) e \n (Line Feed) significam caracteres de nova linha em requisições HTTP, e suas formas codificadas em URL são representadas como %0d%0a. Incluir esses caracteres em uma requisição (por exemplo, http://localhost/%0d%0aDetectify:%20clrf) para um servidor mal configurado resulta no servidor emitindo um novo cabeçalho chamado Detectify. Isso acontece porque a variável $uri decodifica os caracteres de nova linha codificados em URL, levando a um cabeçalho inesperado na resposta:
Saiba mais sobre os riscos da injeção CRLF e divisão de resposta em https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.
Além disso, essa técnica é explicada nesta palestra com alguns exemplos vulneráveis e mecanismos de detecção. Por exemplo, para detectar essa má configuração de uma perspectiva de caixa-preta, você poderia usar essas requisições:
https://example.com/%20X - Qualquer código HTTP
https://example.com/%20H - 400 Bad Request
Se vulnerável, o primeiro retornará como "X" é qualquer método HTTP e o segundo retornará um erro, pois H não é um método válido. Assim, o servidor receberá algo como: GET / H HTTP/1.1 e isso acionará o erro.
Outros exemplos de detecção seriam:
http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x - Qualquer código HTTP
http://company.tld/%20HTTP/1.1%0D%0AHost:%20x - 400 Bad Request
Algumas configurações vulneráveis encontradas apresentadas nessa palestra foram:
Note como $uri é definido como está na URL final.
Note como novamente $uri está na URL (desta vez dentro de um parâmetro)
Agora no AWS S3
Foi descoberto que dados fornecidos pelo usuário podem ser tratados como uma variável Nginx sob certas circunstâncias. A causa desse comportamento permanece um tanto elusiva, mas não é rara nem fácil de verificar. Essa anomalia foi destacada em um relatório de segurança no HackerOne, que pode ser visualizado aqui. Uma investigação mais aprofundada na mensagem de erro levou à identificação de sua ocorrência dentro do módulo de filtro SSI do código-fonte do Nginx, apontando Server Side Includes (SSI) como a causa raiz.
Para detectar essa má configuração, o seguinte comando pode ser executado, que envolve definir um cabeçalho referer para testar a impressão de variáveis:
Scans for this misconfiguration across systems revealed multiple instances where Nginx variables could be printed by a user. However, a decrease in the number of vulnerable instances suggests that efforts to patch this issue have been somewhat successful.
Nginx oferece um recurso através de proxy_pass que permite a interceptação de erros e cabeçalhos HTTP produzidos pelo backend, visando ocultar mensagens de erro internas e cabeçalhos. Isso é realizado pelo Nginx servindo páginas de erro personalizadas em resposta a erros do backend. No entanto, desafios surgem quando o Nginx encontra uma solicitação HTTP inválida. Tal solicitação é encaminhada para o backend como recebida, e a resposta bruta do backend é então enviada diretamente ao cliente sem a intervenção do Nginx.
Considere um cenário de exemplo envolvendo uma aplicação uWSGI:
Para gerenciar isso, diretivas específicas na configuração do Nginx são usadas:
proxy_intercept_errors: Esta diretiva permite que o Nginx sirva uma resposta personalizada para respostas de backend com um código de status maior que 300. Isso garante que, para nosso exemplo de aplicação uWSGI, uma resposta de 500 Error seja interceptada e tratada pelo Nginx.
proxy_hide_header: Como o nome sugere, esta diretiva oculta cabeçalhos HTTP especificados do cliente, melhorando a privacidade e a segurança.
Quando uma solicitação GET válida é feita, o Nginx a processa normalmente, retornando uma resposta de erro padrão sem revelar cabeçalhos secretos. No entanto, uma solicitação HTTP inválida contorna esse mecanismo, resultando na exposição de respostas brutas do backend, incluindo cabeçalhos secretos e mensagens de erro.
Por padrão, a diretiva merge_slashes do Nginx está definida como on, o que comprime múltiplas barras (slashes) em uma URL em uma única barra. Este recurso, embora simplifique o processamento de URLs, pode inadvertidamente ocultar vulnerabilidades em aplicações atrás do Nginx, particularmente aquelas suscetíveis a ataques de inclusão de arquivos locais (LFI). Especialistas em segurança Danny Robinson e Rotem Bar destacaram os riscos potenciais associados a esse comportamento padrão, especialmente quando o Nginx atua como um reverse-proxy.
Para mitigar tais riscos, é recomendável desativar a diretiva merge_slashes para aplicações suscetíveis a essas vulnerabilidades. Isso garante que o Nginx encaminhe solicitações para a aplicação sem alterar a estrutura da URL, não mascarando assim quaisquer problemas de segurança subjacentes.
Para mais informações, consulte Danny Robinson e Rotem Bar.
Como mostrado em este artigo, existem certos cabeçalhos que, se presentes na resposta do servidor web, mudarão o comportamento do proxy Nginx. Você pode verificá-los na documentação:
X-Accel-Redirect: Indica ao Nginx para redirecionar internamente uma solicitação para um local especificado.
X-Accel-Buffering: Controla se o Nginx deve ou não armazenar em buffer a resposta.
X-Accel-Charset: Define o conjunto de caracteres para a resposta ao usar X-Accel-Redirect.
X-Accel-Expires: Define o tempo de expiração para a resposta ao usar X-Accel-Redirect.
X-Accel-Limit-Rate: Limita a taxa de transferência para respostas ao usar X-Accel-Redirect.
Por exemplo, o cabeçalho X-Accel-Redirect causará um redirecionamento interno no Nginx. Portanto, ter uma configuração do Nginx com algo como root / e uma resposta do servidor web com X-Accel-Redirect: .env fará com que o Nginx envie o conteúdo de /.env (Path Traversal).
Na configuração do Nginx, a diretiva map frequentemente desempenha um papel no controle de autorização. Um erro comum é não especificar um valor padrão, o que pode levar a acessos não autorizados. Por exemplo:
Sem um default, um usuário malicioso pode contornar a segurança acessando uma URI indefinida dentro de /map-poc. O manual do Nginx aconselha definir um valor padrão para evitar tais problemas.
O spoofing de DNS contra o Nginx é viável sob certas condições. Se um atacante souber o servidor DNS usado pelo Nginx e puder interceptar suas consultas DNS, ele pode falsificar registros DNS. No entanto, esse método é ineficaz se o Nginx estiver configurado para usar localhost (127.0.0.1) para resolução de DNS. O Nginx permite especificar um servidor DNS da seguinte forma:
proxy_pass e Diretrizes internalA diretriz proxy_pass é utilizada para redirecionar solicitações para outros servidores, seja internamente ou externamente. A diretriz internal garante que certos locais sejam acessíveis apenas dentro do Nginx. Embora essas diretrizes não sejam vulnerabilidades por si mesmas, sua configuração requer uma análise cuidadosa para evitar falhas de segurança.
Se o servidor nginx estiver configurado para passar os cabeçalhos Upgrade e Connection, um ataque de H2C Smuggling pode ser realizado para acessar endpoints protegidos/internos.
Essa vulnerabilidade permitiria que um atacante estabelecesse uma conexão direta com o endpoint proxy_pass (http://backend:9999 neste caso) cujo conteúdo não será verificado pelo nginx.
Exemplo de configuração vulnerável para roubar /flag de aqui:
Note que mesmo que o proxy_pass esteja apontando para um caminho específico como http://backend:9999/socket.io, a conexão será estabelecida com http://backend:9999, então você pode contatar qualquer outro caminho dentro desse endpoint interno. Portanto, não importa se um caminho é especificado na URL do proxy_pass.
A Detectify criou um repositório no GitHub onde você pode usar o Docker para configurar seu próprio servidor de teste Nginx vulnerável com algumas das configurações incorretas discutidas neste artigo e tentar encontrá-las você mesmo!
https://github.com/detectify/vulnerable-nginx
Gixy é uma ferramenta para analisar a configuração do Nginx. O principal objetivo do Gixy é prevenir configurações de segurança incorretas e automatizar a detecção de falhas.
Nginxpwner é uma ferramenta simples para procurar configurações incorretas e vulnerabilidades comuns do Nginx.
Obtenha a perspectiva de um hacker sobre seus aplicativos web, rede e nuvem
Encontre e relate vulnerabilidades críticas e exploráveis com impacto real nos negócios. Use nossas mais de 20 ferramentas personalizadas para mapear a superfície de ataque, encontrar problemas de segurança que permitem escalar privilégios e usar exploits automatizados para coletar evidências essenciais, transformando seu trabalho árduo em relatórios persuasivos.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
