Hoje vou escrever sobre um assunto extremamente importante quando vamos fazer um deploy de uma aplicação na internet usando tomcat. O motivo desse post é porque eu migrei recentemente do kinghost para o digitalocean. No kinghost, você recebe um tomcat já preparado contra essa vulnerabilidade. Mas no digitalocean, como você "aluga" uma máquina, você mesmo tem que tomar esses cuidados.
Primeiramente, vou explicar como funciona essa vulnerabilidade do tomcat (na verdade não pode nem ser considerado uma vulnerabilidade pois não há falhas. O que há é falta de configuração).
Vamos supor que você baixe o tomcat do site da apache, descomente os usuários e permissões no arquivo tomcat-users.xml para ter acesso à àrea de administração (deploy de aplicativos) e coloque ele pra rodar no seu servidor. Já lascou tudo! A sua área de administração (manager) está exposta. Mas vamos desde o início... Vamos subir o tomcat sem nenhum projeto para deploy. Quando você acessar http://localhost:8080, você vai ver o index do tomcat como na imagem abaixo:
Note que no canto esquerdo tem um quadro de administração. E o segundo link é Tomcat Manager.
Essa é a área de administração que eu estava falando. Quando você clicar nesse link, ele pede usuário e senha para entrar. Essas credenciais devem ser definidas no arquivo $TOMCAT_HOME/conf/tomcat-users.xml.
Caso você esteja se perguntando qual o problema disso, vou explicar:
O atacante dentro da página de gerenciamento com credenciais de administrador, pode tirar nossa aplicação no ar. Pior que isso: ele pode adicionar uma aplicação no nosso tomcat. E essa aplicação normalmente adicionada pelo atacante, abre um shell reverso(*) que possibilita acesso ao seu servidor. Resumindo, se um atacante entrar nessa área e fazer deploy dessa aplicação, ele pode ter acesso a todos os dados do seu servidor.
Agora vamos considerar o seguinte: normalmente, as pessoas utilizam sistemas Linux como servidor. E em um sistema unix-base, você só sobe seu servidor na porta 80 se for root. O que um usuário normal faz ? Acessa o usuário root e sobe o servidor na porta 80. Quando o atacante fizer o deploy, ele vai acessar o shell com permissão do usuário que iniciou o processo, ou seja, o root!
Acho que agora já deu pra entender a gravidade da situação né ? É tenso mesmo.
Vejamos agora as formas de acabar com isso:
1) Alterando as senhas e usuários padrões (o mais lógico a se fazer)
Para isso, basta que modifique o arquivo $TOMCAT_HOME/conf/tomcat-users.xml alterando os valores padrões e colocando senhas fortes.
2) Remover a área administrativa (modo ignorante)
Nesse ponto é importante saber que a área administrativa é uma aplicação java normal como qualquer outra. E se a vulnerabilidade está nela, então basta deletá-la que a vulnerabilidade irá sumir (quanto menos código, menos bug e menos vulnerabilidade).
Para isso, basta ir na pasta $TOMCAT_HOME/webapps e deletar as pastas docs, examples, host-manager e manager. São todos aplicações do tomcat e não precisamos de nenhuma delas. Delete essas mesmas pastas dentro de $TOMCAT_HOME/work/Catalina/localhost
3) Remover a área administrativa e alterar permissões de pasta (modo ignorante nível hard)
Essa terceira opção, além de remover os aplicativos que não precisamos, funciona como uma prevenção contra outras possíveis vulnerabilidades que o tomcat possua e que ainda não foram descobertas. Não é necessário fazer esse passo pois ele é apenas preventivo.
A lógica desse ataque, é que o atacante utiliza o próprio tomcat para escrever um projeto dentro do servidor. A partir daí, ele faz o que quiser... Mas e se o tomcat não puder escrever na pasta webapps ??? Parece meio estranho mas funciona. Basta você tirar as permissões de escrita na pasta $TOMCAT_HOME/webapps após subir o tomcat. Assim, quando o atacante tentar fazer deploy na pasta, ele não vai ter permissão para escrita e não irá funcionar.
Exemplos:
Eu resolvi fazer esse post porque em 1 dia que coloquei meu tomcat desconfigurado no digitalocean, sofri 2 ataques desse tipo. Eu acho que tinha deixado usuário e senha como "admin" (vacilão). E detalhe: só fiquei sabendo porque o atacante começou a levar tudo do meu servidor e o digitalocean percebendo o grande fluxo de upload, bloqueou meu droplet.
Essa primeira imagem está o index do primeiro ataque. Olhei pouco o código mas vi que serve pra roubar dados do servidor e mandar pra um server remoto.
Nessa segunda imagem, foi o segundo ataque
Criei esse post aqui para mostrar outra forma de barrar um shell reverso.
