[Penetration Test] From Deploy WAR (Tomcat) to Shell (FreeBSD) 
Autor: Roberto dos Santos Soares (espreto) | Publicado: 2015-03-01T01:05:00-03:00




O objetivo deste post é 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&nbsp;[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&nbsp;[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&nbsp;(figura 7).











Figura 6 - Acessando o backdoor pela URL.

















Figura 7 - Metasploit com shell conectada.


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&nbsp;(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, 
&nbsp;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 - Nova 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 está relacionado à segurança da
 infraestrutura que o suporta, não limitando-se somente à blindagem da 
aplicação.









Até a próxima.

[1] http://tomcat.apache.org/
[2]&nbsp;http://www.freebsd.org/
[3]&nbsp;https://www.owasp.org/index.php/Testing_for_default_credentials_(OWASP-AT-003)
[4] http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html
[5] http://www.metasploit.com/
[6]&nbsp;http://www.rapid7.com/db/modules/exploit/freebsd/local/mmap
[7]&nbsp;https://www.conviso.com.br/produtos.php

Postado previamente em http://blog.conviso.com.br/2013/12/from-deploy-war-tomcat-to-shell-freebsd.html pelo mesmo autor.