From Deploy WAR (Tomcat) to Shell (FreeBSD)
O objetivo deste artigo é demonstrar como a implementação insegura de serviços na rede, pode facilitar o comprometimento de toda a infraestrutura de sua empresa.
Let's hacking
O objetivo deste artigo, é demonstrar como a implementação insegura de serviços na rede, pode facilitar o comprometimento de toda a infraestrutura de sua empresa. Neste caso, a demonstração será com a instalação padrão do Apache Tomcat [1], em um servidor com o sistema operacional FreeBSD [2], sem nenhum ajuste nas configurações ou hardening no pós-instalação.
Durante um teste de intrusão, foi descoberto que determinado servidor executava a aplicação Tomcat (porta 8080) e que o mesmo utilizava credenciais padrão [3] (tomcat:tomcat), assim, foi possível acessar sua interface administrativa, conforme figura 1:
Figura 1 - Interface Administrativa
O Tomcat possui uma falha bem conhecida e explorada, que é a criação de arquivos WAR maliciosos, podendo realizar o seu deploy [4] e ganhar acesso ao servidor, possibilitando executar comandos internos e ter controle do servidor.
Para explorar esta falha, usamos o Metasploit [5], criando um arquivo WAR com o comando msfpayload (figura 2).
Figura 2 - Msfpayload criando arquivo WAR.
O msfpayload utiliza um nome randômico na geração do arquivo JSP. Para visualizar este nome, é necessário extrair o conteúdo de convisolabs.war e anotar seu nome (figura 3).
Figura 3 - Nome JSP gerado.
Fazemos o deploy do arquivo convisolabs.war (figura 4 e 5).
Figura 4 - Arquivo WAR em deploy.
Figura 5 - Realizado o deploy.
Acessamos nosso backdoor através do nosso browser (figura 6). Lembrando que é necessário deixar o Metasploit em modo listen (figura 7).
Figura 6 - Acessando o backdoor pela URL.
Figura 7 - Metasploit com shell conectado.
Na figura 7, ganhamos acesso ao servidor com usuário limitado (www), o próximo passo é escalar privilégios para tornarmos um usuário sem restrição (root), facilitando a expansão do comprometimento.
Para esta tarefa, usamos um módulo [6] presente no Metasploit (figura 8) que exige, ao menos, um diretório para a gravação de arquivos. Por padrão, o módulo vem configurado para usar o diretório /tmp, em nosso caso, não foi necessário alterar o diretório final. Desta forma, foi possível escalar privilégios e obter acesso irrestrito ao servidor.
Figura 8 - Novo shell com usuário root.
Os melhores hardwares e softwares não resolvem, se não há um planejamento adequado ao disponibilizar algum tipo de serviço na internet.
Resultado: FreeBSD (9.1) Owned by Tomcat.
O trabalho de segurança em uma aplicação WEB, ou qualquer outro software que está relacionado à segurança da infraestrutura que o suporta, não limitando-se somente à blindagem da aplicação.
Até a próxima.
Postado previamente, em:
Durante um teste de intrusão, foi descoberto que determinado servidor executava a aplicação Tomcat (porta 8080) e que o mesmo utilizava credenciais padrão [3] (tomcat:tomcat), assim, foi possível acessar sua interface administrativa, conforme figura 1:
Figura 1 - Interface Administrativa
O Tomcat possui uma falha bem conhecida e explorada, que é a criação de arquivos WAR maliciosos, podendo realizar o seu deploy [4] e ganhar acesso ao servidor, possibilitando executar comandos internos e ter controle do servidor.
Para explorar esta falha, usamos o Metasploit [5], criando um arquivo WAR com o comando msfpayload (figura 2).
Figura 2 - Msfpayload criando arquivo WAR.
O msfpayload utiliza um nome randômico na geração do arquivo JSP. Para visualizar este nome, é necessário extrair o conteúdo de convisolabs.war e anotar seu nome (figura 3).
Figura 3 - Nome JSP gerado.
Fazemos o deploy do arquivo convisolabs.war (figura 4 e 5).
Figura 4 - Arquivo WAR em deploy.
Figura 5 - Realizado o deploy.
Acessamos nosso backdoor através do nosso browser (figura 6). Lembrando que é necessário deixar o Metasploit em modo listen (figura 7).
Figura 6 - Acessando o backdoor pela URL.
Figura 7 - Metasploit com shell conectado.
Na figura 7, ganhamos acesso ao servidor com usuário limitado (www), o próximo passo é escalar privilégios para tornarmos um usuário sem restrição (root), facilitando a expansão do comprometimento.
Para esta tarefa, usamos um módulo [6] presente no Metasploit (figura 8) que exige, ao menos, um diretório para a gravação de arquivos. Por padrão, o módulo vem configurado para usar o diretório /tmp, em nosso caso, não foi necessário alterar o diretório final. Desta forma, foi possível escalar privilégios e obter acesso irrestrito ao servidor.
Figura 8 - Novo shell com usuário root.
Os melhores hardwares e softwares não resolvem, se não há um planejamento adequado ao disponibilizar algum tipo de serviço na internet.
Resultado: FreeBSD (9.1) Owned by Tomcat.
Conclusão
Problemas e falhas existem em qualquer aplicação. Como profissionais de segurança da informação, é nosso dever diminuir essa exposição reduzindo a superfície do ataque e corrigindo as falhas, com o objetivo de dificultar uma possível invasão.O trabalho de segurança em uma aplicação WEB, ou qualquer outro software que está relacionado à segurança da infraestrutura que o suporta, não limitando-se somente à blindagem da aplicação.
Até a próxima.
- [1]Apache Tomcat - Welcome!
- [2]The FreeBSD Project
- [3]Testing for default credentials (OTG-AUTHN-002) - OWASP
- [4]Apache Tomcat 6.0 (6.0.41) - Tomcat Web Application Deployment
- [5]Penetration Testing Software | Metasploit
- [6]CVE-2013-2171 FreeBSD 9 Address Space Manipulation Privilege Escalation | Rapid7
Postado previamente, em: