A travessia de caminhos, também conhecida como travessia de diretórios, ocorre quando um utilizador malicioso manipula dados fornecidos pelo utilizador para obter acesso não autorizado a ficheiros e diretórios. Normalmente, o atacante tentará aceder a registos e credenciais que se encontram em diretórios diferentes. A passagem de caminho não é uma vulnerabilidade nova e tem sido ativamente explorada desde os anos 90, quando os servidores Web ganharam popularidade, muitos dos quais dependiam de scripts CGI (Common Gateway Interface) para executar conteúdos dinâmicos do lado do servidor.
Com uma história tão longa, o path traversal ainda é popular hoje em dia? Realizámos um estudo de projectos de código aberto e de código fechado para recolher dados e ver até que ponto o path traversal era comum em 2024 e se estamos a melhorar, Spoilersnão estamos.
Exemplo de travessia de caminho
Então, como funciona exatamente a travessia de caminhos? Vejamos um exemplo simples.
Nesta aplicação simples, é dado a um utilizador um ficheiro para descarregar através de uma variável no URL.
Existe algum código Python de backend simples que trata do pedido.
import os
def download_file(file):
base_directory = "/var/www/files"
file_path = os.path.join(base_directory, file)
if os.path.exists(file_path):
with open(file_path, 'rb') as f:
return f.read()
else:
return "File not found"
Agora, como a variável é fornecida no URL, podemos alterá-la para algo como isto ficheiro=../../../../../etc/passwd
Neste caso, o atacante está a utilizar o ../../ para percorrer a estrutura de diretórios até ao nível da raiz do sistema e aceder ao ficheiro passado, podendo obter acesso a informações sensíveis.
Se quiser ver como este método pode ser assegurado, desloque-se para baixo para ver o conteúdo do bónus.
Em cenários mais complexos que envolvem várias camadas de diretórios ou caracteres codificados (por exemplo, %2e%2e%2f), os atacantes podem contornar os filtros básicos e obter um acesso mais profundo ao sistema de ficheiros.Percurso de caminhos pelos números
- 2,7% de todas as vulnerabilidades encontradas em projectos de código aberto em 2024 até agora eram de passagem de caminho
- 3,5% para projectos de código fechado !
- Um aumento do número total de vulnerabilidades de atravessamento de caminhos em projectos de código aberto de 742 (2023) para um número esperado de 1000 (2024).
- Em termos de percentagem de todas as vulnerabilidades, a passagem do caminho está a tornar-se mais comum, com um aumento maciço de 85% nos projectos de código fechado
A nossa investigação centrou-se na pesquisa de projectos de código aberto e de código fechado para revelar quantos tinham vulnerabilidades de passagem de caminho escondidas.
Em geral, o número de vulnerabilidades de passagem de caminho é inferior ao de outras vulnerabilidades que pesquisámos, como as injecções de comando ou as injecções de SQL. Mas considerando que esta vulnerabilidade pode ser muito perigosa e tem soluções bem documentadas para a evitar, é alarmante ver os números tão elevados como são. É ainda mais alarmante ver que as tendências para esta vulnerabilidade vão na direção errada. f
Projectos de código aberto
Nos projectos de código aberto, a passagem de caminhos representou 2,6% de todas as vulnerabilidades comunicadas em 2023. Este valor registou um ligeiro aumento em 2024, subindo para 2,75%. Embora esse incremento possa parecer marginal à primeira vista, ele ressalta os desafios contínuos na proteção de software de código aberto até mesmo contra vulnerabilidades simples.
Projectos de fonte fechada
A tendência mais notável foi observada nos projectos de código fechado, em que os incidentes de passagem do caminho aumentaram de 1,9% em 2023 para 3,5% em 2024 - um aumento substancial de 85% que evidencia uma tendência alarmante deste tipo de vulnerabilidade.
Infelizmente, as más notícias não se ficam por aqui. Continuamos a assistir a um aumento do número total de vulnerabilidades comunicadas em projectos de código aberto. O número total de vulnerabilidades de injeção comunicadas em projectos de código aberto passou de 742 em 2023 para 917 até agora em 2024 (espera-se que atinja os 1.000)
Evitar a travessia de caminhos
A prevenção de vulnerabilidades de injeção de comandos requer uma abordagem multifacetada:
Validação de entrada
- Sanitizar as entradas do utilizador: Retirar ou codificar caracteres perigosos, tais como
../,..\,..%2f, ou outras variações. - Abordagem de lista de permissões: Definir um conjunto rigoroso de entradas permitidas (por exemplo, nomes de ficheiros ou caminhos) e rejeitar tudo o que estiver fora desta lista.
Restringir o acesso aos ficheiros
- Usar um chroot jail ou sandbox: Limitar o acesso a ficheiros da aplicação a um diretório restrito, assegurando que não pode atravessar para além da árvore de diretórios pretendida.
- Definir diretórios raiz: Definir diretórios de base e garantir que todos os caminhos são relativos a eles. Use APIs ou frameworks que imponham isso, como:
java.nio.file.Paths.get("baseDir").resolve(userInput).normalize()em Java.os.path.realpath()eos.path.commonpath()em Python.
APIs de acesso seguro a ficheiros
- Utilizar métodos de acesso seguro a ficheiros fornecidos por bibliotecas ou estruturas modernas:Em Java, utilizar
Ficheiros.newInputStream()ouFicheiros.newBufferedReader()para um manuseamento seguro dos ficheiros.
Em Pythoncertifique-se de que valida os caminhos dos ficheiros antes de aceder aos mesmos.
Restrições do ambiente de utilização
- Definir restritivo permissões do sistema de ficheirosAssegure-se de que a aplicação tem apenas os privilégios mínimos necessários.
Negar o acesso a diretórios sensíveis (por exemplo,,/etc,/var,/usre diretórios pessoais do utilizador). - Desativar funcionalidades desnecessárias em servidores Web ou estruturas (por exemplo, seguimento de ligações simbólicas).
Testes automatizados
- Utilize ferramentas como o Aikido para analisar o seu código fonte e a sua aplicação e descobrir estas vulnerabilidades.
- As ferramentas SAST e DAST devem ser utilizadas em conjunto com a verificação do domínio e a segurança na nuvem para garantir que não existem vulnerabilidades ocultas de passagem do caminho.
Utilizar uma firewall na aplicação
- Uma das melhores defesas contra ataques de injeção é uma firewall na aplicação que consegue apanhar e bloquear comandos maliciosos.
O caminho a seguir
O path traversal é uma vulnerabilidade que está presente desde o início das aplicações Web e, embora seja muitas vezes bastante simples, também pode ser uma exploração muito devastadora. É por isso que é tão preocupante que uma percentagem tão grande de projectos ainda esteja a debater-se com este tipo de problemas. Embora 3,5% não pareça um número elevado, é bastante notável que o número esteja a crescer em popularidade apesar da sua clara ameaça contínua e bem documentada.
A travessia de caminhos não é uma vulnerabilidade que está a desaparecer, mas a boa notícia é que existem formas claras de encontrar estas vulnerabilidades na nossa aplicação e de corrigir quaisquer problemas que encontremos.
Conteúdo de bónus
Incidentes no mundo real
Nos últimos anos, houve várias violações ou vulnerabilidades de grande visibilidade que envolveram a passagem de caminhos como ponto de entrada principal ou como parte de uma cadeia de vulnerabilidades
Exploração do Microsoft IIS Unicode (2001)
Um dos primeiros exploits de travessia de caminho de alto perfil visando servidores Microsoft IIS. Os atacantes usavam caminhos codificados para contornar mecanismos de validação (por exemplo, usando %c0%af para representar /). Isto permitiu-lhes aceder e executar ficheiros fora do diretório raiz da Web.
Isto permitiu a implantação de malware e a desfiguração de numerosos sítios Web.
Fortinet VPN Path Traversal (2019)
Descobriu-se que o SSL VPN da Fortinet tem uma vulnerabilidade de passagem de diretório (CVE-2018-13379). Os atacantes exploraram esta falha para aceder a ficheiros de sistema sensíveis, tais como palavras-passe em texto simples para utilizadores VPN.
Milhares de credenciais VPN foram divulgadas online, expondo as organizações a acessos não autorizados e a novos ataques.
Violação da Capital One (2019)
O que aconteceu: Embora a causa principal tenha sido uma vulnerabilidade SSRF, o atacante também aproveitou a travessia de diretórios para aceder aos metadados do AWS S3 bucket. O atacante explorou configurações incorrectas para obter ficheiros de configuração que deveriam estar inacessíveis.
Este facto expôs os dados pessoais de 106 milhões de requerentes de cartões de crédito.
Travessia de caminho no painel de controlo do Kubernetes (2020)
O Kubernetes Dashboard tinha uma falha de passagem de diretório (CVE-2020-8563). Os atacantes exploraram isto para ler ficheiros sensíveis no contentor, incluindo segredos armazenados em /etc.
.png)
.svg)
.png)
.png)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.png)