CTF_WRITEUPS-TryHackMe-CVE-2021-41773-

CTF_WRITEUPS/TryHackMe /CVE-2021-41773/

CVE-2021-41773/42013

Uma pequena explicação de um bug de path traversal no Apache e uma correção incompleta

Tarefa 1: Um Pouco de Contexto...

Uma Breve História

No dia 5 de outubro de 2021, foi divulgado um CVE detalhando um ataque de path traversal no Apache HTTP Server v2.4.49. Atribuído o número CVE-2021-41773, foi divulgado com a seguinte descrição:

Uma falha foi encontrada numa mudança feita na normalização de caminhos no Apache HTTP Server 2.4.49. Um atacante poderia usar um ataque de path traversal para mapear URLs para ficheiros fora do document root esperado. Se os ficheiros fora do document root não estiverem protegidos por "require all denied", estes pedidos podem ser bem-sucedidos. Além disso, esta falha poderia vazar o código-fonte de ficheiros interpretados, como scripts CGI. Este problema é conhecido por ser explorado ativamente. Este problema afeta apenas o Apache 2.4.49 e não versões anteriores.

Vamos detalhar e ver o que isto realmente significa para nós:

• Do primeiro trecho, vemos que uma mudança recente expôs a falha. Normalização de caminhos significa que transformamos um determinado caminho numa forma canónica que o software possa entender e, assim, mapear para o sistema de ficheiros real. Isto já nos leva a suspeitar de um ataque de path traversal que pode potencialmente ler ficheiros não intencionados.
• A próxima parte confirma as nossas suspeitas, e somos capazes de usar um ataque de path traversal para ler recursos fora do âmbito pretendido.
• Vemos que é necessária uma configuração muito específica. Ficheiros fora do document root devem ter permissões explicitamente concedidas. Esta não é a configuração padrão e, portanto, deve tornar este exploit inútil contra uma grande percentagem dos hosts Apache (felizmente).
• A próxima parte fala sobre scripts CGI, o que erroneamente nos leva a acreditar que o CGI pode precisar estar ativado para este ataque funcionar ou que o caminho envolve CGI de alguma forma.
• Mesmo que nossa configuração não seja diretamente afetada por este bug, ainda assim vamos querer atualizar as versões vulneráveis o mais rápido possível.

Muita Correção Depois...

Então o Apache corrigiu este bug e lançou a v2.4.50. Fim da história, certo? Bem, nem tanto. Apenas 2 dias depois, no dia 7 de outubro, foi divulgado um novo CVE citando o anterior. Este menciona que a correção para o ataque de path traversal anterior foi incompleta, e ainda podíamos atravessar se o caminho em questão usasse uma diretiva alias para mapear as URLs para o sistema de ficheiros. Foi atribuído o CVE CVE-2021-42013, com a seguinte descrição:

Foi descoberto que a correção para o CVE-2021-41773 no Apache HTTP Server 2.4.50 foi insuficiente. Um atacante poderia usar um ataque de path traversal para mapear URLs para ficheiros fora dos diretórios configurados por diretivas do tipo Alias. Se os ficheiros fora destes diretórios não estiverem protegidos pela configuração padrão "require all denied", estes pedidos podem ser bem-sucedidos. Se os scripts CGI também estiverem ativados para esses caminhos com alias, isso poderia permitir a execução remota de código. Este problema afeta apenas o Apache 2.4.49 e Apache 2.4.50 e não versões anteriores.

Tal como antes, podemos aprender algumas coisas aqui:

• Embora o primeiro exploit tenha sido supostamente corrigido, existe outra entrada para permitir que a travessia funcione (lembre-se disto para mais tarde).
• Agora estamos limitados a diretivas de caminho com alias.
• Diretórios fora dos caminhos habituais ainda exigem permissões explícitas.
• Se o CGI estiver ativado, podemos obter RCE além da simples divulgação 😲

Enquanto processamos essa loucura, examinaremos a configuração necessária na próxima tarefa.

Responda às perguntas abaixo

1. Qual versão do Apache httpd foi inicialmente vulnerável a este CVE?

• 2.4.49

2. Esta vulnerabilidade requer uma configuração incorreta incomum para ser explorável (Sim/Não)

• Sim

---

Tarefa 2: O que é Path Traversal, afinal?

Um Pouco de Teoria

Um exploit de Path Traversal é um ataque que visa acessar recursos que normalmente são inacessíveis, abusando de falhas na resolução e/ou normalização de caminhos. Geralmente exploramos este tipo de ataque viajando (também conhecido como atravessando) para trás para além do suposto raiz usando a sintaxe ...

Normalização? O quê?

Normalmente, ao fornecer um caminho para algum código encontrar um ficheiro, é necessário um caminho absoluto. Vamos chamar-lhe o caminho canónico. Quando é fornecido um caminho relativo, ele deve ser normalizado para uma forma canónica para que as bibliotecas do SO que usam esse caminho possam então encontrar o recurso em questão. Isto é uma simplificação, claro, mas a ideia permanece.

Em geral, existem bibliotecas de plataforma para fazer essa normalização por nós, mas em C/C++ normalmente temos que fazer tudo nós mesmos. Embora isto possa oferecer alguma flexibilidade, também pode facilmente introduzir falhas se a nossa implementação não for perfeita.

Normalizando URLs

Um servidor HTTP tem que traduzir uma URL para um caminho canónico no sistema de ficheiros para encontrar o ficheiro correto a servir. Embora existam definitivamente alguns filtros para evitar que se consiga atravessar para além do document root, alguns casos de uso podem facilmente ser esquecidos. Neste caso, o exploit tira partido não só da codificação de URL (vamos chegar lá já) mas também de uma falha na normalização de caminhos do módulo Alias (supostamente)

Um Parêntese sobre Codificação de URL

Definido na RFC 3986, Seção 2, a Codificação de URL é um esquema usado para codificar caracteres especiais ou reservados dentro de uma URL. Por exemplo, espaços numa URL são codificados como o caractere + (notadamente em parâmetros de consulta). Se quisermos codificar um sinal de mais real, devemos codificá-lo usando o que é conhecido como "percent-encoding". Isto simplesmente envolve prefixar o código hexadecimal US-ASCII do caractere com um sinal de %. No nosso exemplo, o símbolo + pode ser codificado como %2B.

Qualquer caractere pode ser codificado em URL, e URLs que estão totalmente codificados em URL são funcionalmente equivalentes à versão não codificada. Da RFC: Se dois URIs diferem apenas no caso dos dígitos hexadecimais usados em octetos codificados por percentagem, eles são equivalentes.

Então o que Aconteceu com o Apache?

Uma mudança recente no módulo de normalização de caminhos no servidor Apache permitiu que uma URL especialmente criada contornasse os filtros e atravessasse para além do document root, permitindo leitura arbitrária de ficheiros no sistema se a configuração o permitisse. Além disso, se o módulo CGI estivesse ativado, a execução arbitrária de ficheiros também era possível!

Responda às perguntas abaixo

1. Um exploit de path traversal irá (escolha a melhor resposta):

A) Incluir ficheiros remotos arbitrários para serem processados no servidor. B) Incluir ficheiros locais arbitrários para serem processados no servidor. C) Permitir que ficheiros arbitrários sejam expostos pelo servidor. D) Nenhuma das anteriores.

• C

2. Codifique o símbolo . em URL

• %2E

3. O que este fragmento de URL decodifica: %%32%65 ?

• %2E

---

Tarefa 3: Ok, Ok; Mostre o Hax!

Hackeando o Apache por Diversão