Encontrou uma vulnerabilidade no servidor Apache http

Recentemente, a notícia de que encontrou um novo vetor de ataque contra o servidor HTTP Apache, que permaneceu sem patch na atualização 2.4.50 e permite acesso a arquivos de áreas fora do diretório raiz do site.

Além disso, os pesquisadores descobriram uma maneira que, na presença de certas configurações fora do padrão, não apenas ler os arquivos do sistema, mas também executar remotamente seu código no servidor.

CVE-2021-41773 no Apache HTTP Server 2.4.50 era insuficiente. Um invasor pode usar um ataque de passagem de caminho para mapear URLs para arquivos fora dos diretórios configurados por diretivas semelhantes a Aliases. Se os arquivos fora desses diretórios não estiverem protegidos pelas configurações padrão usuais de "exigir todos negados", essas solicitações podem ser bem-sucedidas. Se os scripts CGI também estiverem habilitados para esses patches com alias, isso pode permitir a execução remota de código. Esse problema afeta apenas o Apache 2.4.49 e o Apache 2.4.50 e não as versões anteriores.

Em essência, o novo problema (já listado como CVE-2021-42013) é completamente semelhante à vulnerabilidade original (CVE-2021-41773) em 2.4.49, a única diferença está em uma codificação de caracteres diferente.

E é isso em particular, na versão 2.4.50 a possibilidade de usar a sequência "% 2e" foi bloqueada para codificar um ponto, mas simperdemos a possibilidade de codificação dupla: Ao especificar a sequência "%% 32% 65", o servidor decodificado em "% 2e", e depois em ".", Ou seja, Os caracteres "../" para ir para o diretório anterior podem ser codificados como ". %% 32% 65 / ».

Ambos os CVEs são, na verdade, quase a mesma vulnerabilidade de travessia de caminho (o segundo é a correção incompleta do primeiro). O percurso de caminho só funciona a partir de um URI mapeado (por exemplo, por meio das diretivas "Alias" ou "ScriptAlias" do Apache). DocumentRoot sozinho não é suficiente

Em relação à exploração de uma vulnerabilidade por meio da execução de código, isso é possível se mod_cgi estiver habilitado e um caminho base é usado no qual os scripts CGI podem ser executados (por exemplo, se a diretiva ScriptAlias ​​estiver habilitada ou o sinalizador ExecCGI for especificado na diretiva Options).

É mencionado que um pré-requisito para um ataque bem-sucedido é também fornecer explicitamente na configuração do Apache acesso a diretórios com arquivos executáveis, como / bin, ou acesso à raiz FS "/". Como esse acesso normalmente não é fornecido, um ataque de execução de código é de pouca utilidade para sistemas reais.

Ao mesmo tempo, o ataque à obtenção de conteúdo de arquivo códigos de sistema arbitrários e textos-fonte de scripts da web que estão disponíveis para leitura do usuário sob o qual o servidor http está sendo executado ainda é relevante. Para realizar tal ataque, basta ter um diretório no site configurado usando as diretivas "Alias" ou "ScriptAlias" (DocumentRoot não é suficiente), como "cgi-bin".

Além disso, ele menciona que o problema afeta principalmente as distribuições continuamente atualizadas (Rolling Releases), como Fedora, Arch Linux e Gentoo, bem como as portas do FreeBSD.

Enquanto as distribuições Linux baseadas em branches estáveis ​​das distribuições de servidor, como Debian, RHEL, Ubuntu e SUSE, não são vulneráveis. O problema não aparece se o acesso aos diretórios for explicitamente negado usando a configuração »exigir todos negados«.

Também vale a pena mencionar que De 6 a 7 de outubro, a Cloudflare registrou mais de 300 tentativas de explorar a vulnerabilidade CVE-2021-41773 por dia. Na maioria das vezes, como resultado de ataques automatizados, eles solicitam o conteúdo de "/cgi-bin/.%2e/.git/config", "/cgi-bin/.%2e/app/etc/local.xml "," /Cgi-bin/.% 2e / app / etc / env.php "e" /cgi-bin/.%2e/%2e%2e/%2e%2e/etc/passwd ".

O problema se manifesta apenas nas versões 2.4.49 e 2.4.50, as versões anteriores da vulnerabilidade não são afetadas. Para corrigir a nova variante da vulnerabilidade, a versão Apache httpd 2.4.51 foi formada rapidamente.

Finalmente Se você estiver interessado em saber mais sobre isso, você pode verificar os detalhes no link a seguir.


O conteúdo do artigo segue nossos princípios de ética editorial. Para relatar um erro, clique Clique aqui.

Seja o primeiro a comentar

Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: Miguel Ángel Gatón
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.