Local File Inclusion é uma vulnerabilidade que permite “incluir” arquivos que serão incorporados à página. Caso o arquivo incluído contenha algum código, este código será executado.
Então mostrei para ele que com esta falha eu poderia ler o arquivo de senha do sistema (/etc/passwd), saber os grupos do sistema (/etc/group), etc.
Este meu colega ignorou a vulnerabilidade e me disse o seguinte: Rafael, não considero esta vulnerabilidade grave porque o invasor não poderia escrever nada no sistema e nem executar comandos. Sobre o acesso ao passwd, nos sistemas unixes de hoje, as senhas estão no arquivo shadow. Este arquivo só pode ser visualizado pelo usuário root. Então para mim não é algo grave.
Eu concordo com ele em alguns pontos. Se você, leitor deste blog, buscar no google por Local File Inclusion, 90% dos exemplos exibirão o invasor visualizando o arquivo passwd. E a visualização deste arquivo só mostrará usuários existentes naquele sistema. Então o invasor poderia tentar um ataque de força bruta para descobrir a senha de algum dos usuários. Muitos administradores já tremeriam por expor o arquivo passwd. Mas como meu colega disse, o invasor não conseguiria visualizar nenhuma senha porque estas estão contidas no arquivo shadow, não passwd. Mas isto não é o perigoso desta vulnerabilidade. O perigo está na exploração avançada. Vou explicar como um verdadeiro hacker conseguiria acesso ao seu servidor somente usando esta vulnerabilidade.
Preparação
Para acompanhar este post, é necessário que se tenha o básico de conhecimentos de PHP, Apache e Linux.
1. Arquivos de teste
Para demonstrar como funciona esta vulnerabilidade, criei dois arquivos no diretório de arquivos públicos do meu apache (/var/www). O arquivo teste.php tem o seguinte código:
Este eh o conteudo de teste.php
< ? php if (isset($_GET['page'])){ echo(" Conteudo da pagina: ".$_GET['page']." "); include($_GET['page']); } else{ echo("Parametro 'page' nao foi passado"); } ?>O outro arquivo, 1.php, contêm o seguinte código:
< ? php echo('teste'); ? >
2. Iniciei meu navegador e visualizei o conteúdo de teste.php?page=1.php. Com isto vemos que o código de 1.php é executado.
3. Para ver se a aplicação é vulnerável a LFI, testamos a seguinte URL: teste.php?page=../../../../../../../etc/passwd
Arquivos de logs e outros “controlados” pelo invasor.
O que muitos administradores ignoram é que existem arquivos do servidor que são parcialmente controlados pelo invasor. Como assim?
Por exemplo, o arquivos access.log do apache tem entradas com dados de cada requisição feita ao servidor. As seguintes informações estão neste log por default: IP de quem fez a requisição, dia e hora, arquivo solicitado (index.html, teste.php, favicon.ico, etc), User-Agent do usuário, etc.
Percebe que se o invasor fizer uma requisição chamando http://alvo/.php, o servidor retornará um erro 404 (página não encontrada), mas o código irá para o arquivo de log de qualquer forma? Se o usuário trocar o User-Agent dele por , o código novamente irá para o arquivo de log. Se o invasor usar funções como system, exec, passthru, etc, ele conseguira executar comandos diretamente no servidor!!!!
Existem diversos outros arquivos controlados parcialmente pelo invasor. Logs, /proc/self/environ, e qualquer outra coisa gerada pelo servidor com dados fornecidos (diretamente ou indiretamente) pelo atacante.
Finalizando
Para finalizar este post, deixo um vídeo de como seria um ataque completo de Local File Inclusion. Isto tudo foi feito no meu laboratório de testes caseiro. Nunca testei isto em websites e sistemas reais por aí sem a devida permissão. Então se você, leitor, quiser testar esta vulnerabilidade, virtualize um servidor para isso! ;)
Abraços a todos e até a próxima!
No comments:
Post a Comment