Segurança: Se protegendo contra um Shell Reverso

Um dos ataques mais perigosos é quando uma vulnerabilidade permite o atacante abrir um shell-reverso. Com isso o atacante ganha acesso à máquina invadida e consegue executar comandos no shell (terminal, prompt). A técnica é chamada de shell-reverso pois o atacante faz com que a máquina-alvo abra uma conexão para sua máquina. Logo, o firewall (que normalmente é configurado para barrar conexões de entrada em portas "desconhecidas") não consegue impedir a conexão.

Primeiramente vamos entender o conceito de firewall de host. O objetivo dele é aplicar regras para impedir ou bloquear conexões de serem estabelecidas com a máquina em que ele está instalado. Por padrão, o firewall do WINDOWS bloqueia as conexões de entrada que não estiverem liberadas por nenhuma regra e libera as conexões de saída que não casarem com nenhuma regra. Ou seja, conexões de entrada são bloqueadas e de saída (onde se encaixa o shell-reverso) são liberadas.

OBS.:

• Conexões de entrada: conexões chegando na máquina onde o firewall está instalado
• Conexões de saída: conexões saindo da máquina onde o firewall está instalado

Vamos supor que temos um servidor windows com um IIS rodando disponibilizando um portal web. Quando um cliente acessa o endereço desse servidor, é estabelecida uma conexão na porta 80 com o servidor. Ocorre o three-way handshake, a conexão é estabelecida e o servidor escreve o index do portal web para o cliente. A conexão então é fechada. E vamos supor que exista uma falha no nosso servidor que possibilite esse tipo de ataque.

Então como impedir essa conexão do shell-reverso de ser estabelecida ? É simples. Basta barrar todas as conexões de saída da máquina (Teoricamente, nosso servidor não faz requisições em nenhum lugar. Ele só atende requisições na porta 80). Para isso, basta ir no Painel de Controles, acessar a parte de Segurança e então o Firewall. Clicar na opção avançada do firewall. Irá abrir a tela com as regras de entrada e saída para o firewall.

Ao clicar com o botão direito em cima de "Windows Firewall with Advanced Security on Local Computer" (nú! que nome foi esse ?) e acessar propriedades, aparecerá a tela acima na qual está definida as regras padrão para conexões de entrada e de saída. Basta mudarmos Outbound connections para Block. Agora nosso firewall irá bloquear todas conexões de entrada que não casarem com alguma regra de liberação. 

Dessa forma, se sofrermos algum ataque que possibilite o shell-reverso, a conexão será barrada pelo firewall e falhará. Simples assim. Pra quem usa linux como servidor (99%), essas regras são definidas pelo iptables. Depois faço uma publicação explicando. 

Abraço. E qualquer dúvida, ja sabem...

Alias lembrei de uma coisa interessante. Já viu quando você acessa uma rede wireless e o windows te pergunta se é uma rede residencial, de trabalho ou pública ? Já parou pra pensar porque aquela tela chata sempre aparece ? É justamente para uma configuração automática do firewall. Quando você diz que é uma rede residencial (rede da sua casa), o windows entende que há pouca chance de ocorrer um ataque e configura o firewall para ser mais maleável. Quando você diz que está acessando uma rede pública (Wifi Grátis), o windows entende que há uma maior chance de ocorrer um ataque à sua máquina e configura o firewall com mais regras para tentar barrar ataques. E pensar que a maioria da galera clica sempre em rede residencial e deixa o firewall sem barrar quase nada heim ??? Te falar...

Segurança: como configurar o tomcat

Boa noite a todos.

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.