Nginx
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Configuração instantaneamente disponível para avaliação de vulnerabilidades e testes de penetração. Execute um pentest completo de qualquer lugar com mais de 20 ferramentas e recursos que vão de reconhecimento a relatórios. Não substituímos os pentesters - desenvolvemos ferramentas personalizadas, módulos de detecção e exploração para dar a eles mais tempo para investigar mais a fundo, explorar vulnerabilidades e se divertir.
Missing root location
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.
Alias LFI Misconfiguration
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:
Restrição de caminho inseguro
Verifique a página a seguir para aprender como contornar diretivas como:
Uso inseguro de variáveis / Divisão de Requisições HTTP
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 solicitações HTTP, e suas formas codificadas em URL são representadas como %0d%0a
. Incluir esses caracteres em uma solicitaçã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 a partir de uma perspectiva de caixa preta, você poderia usar essas requisições:
https://example.com/%20X
- Qualquer código HTTPhttps://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 HTTPhttp://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
Any variable
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.
Leitura da resposta bruta do backend
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.
merge_slashes definido como off
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, é recomendado 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.
Cabeçalhos de Resposta Maclicious
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).
Valor Padrão na Diretiva Map
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.
Vulnerabilidade de Spoofing de DNS
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 internal
proxy_pass
e Diretrizes internal
A 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.
proxy_set_header Upgrade & Connection
Se o servidor nginx estiver configurado para passar os cabeçalhos Upgrade e Connection, um ataque de h2c Smuggling poderia 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.
Tente você mesmo
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
Ferramentas de Análise Estática
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.
Referências
Configuração instantaneamente disponível para avaliação de vulnerabilidades & pentesting. Execute um pentest completo de qualquer lugar com mais de 20 ferramentas e recursos que vão de reconhecimento a relatórios. Não substituímos os pentesters - desenvolvemos ferramentas personalizadas, módulos de detecção e exploração para dar a eles mais tempo para investigar mais a fundo, explorar e se divertir.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated