755 e 644 ? Hacking em sistemas de servidores compartilhados. Explorando falhas de permissões

Observação:
Este artigo irá demostrar os dois lado da moeda. Um lado ensinando a malícia (utilizando uma ferramenta que disponibilizarei), do outro, ensinarei como podemos mitigar os riscos.
Introdução:
Por ser um fanático por desenvolvimento e segurança, um amigo desesperado pediu ajuda para poder identificar e limpar o site que estava cheio arquivos maliciosos, afirmando que havia sido invadido algumas vezes, e por mais que tentasse, os problemas sempre voltavam. Acreditava que ele estivesse fazendo alguma coisa errada , fui analisar o que estava acontecendo.
De cara identifiquei diversos arquivos maliciosos de vários tipos e com datas diferentes, mas o que mais me chamou atenção era uma pasta que estava listado diversos outros sites e que continha arquivos de configurações de sistema e banco de dados.
Foi então que percebi que o site estava servindo de hub para outros sites. Identifiquei o arquivo que realizava esse procedimento e fiz uma uma engenharia reversa para entender como o site servia para ataque aos outros sites. Acabei verificando que o problema não era somente nesse site específico, mas em todo servidor.
Ambiente:
Inicialmente o site em questão era um cms, o WordPress, atualizado, com poucos plugins e bem organizado. Já o serviço era um servidor de revenda, desses compartilhados, mas para validação e comprovação, o mesmo procedimento foi realizado em mais 6 servidores diferentes, todos servidores compartilhados, alguns com serviços de revenda outros simples, sem planos de revenda com menos compartilhamentos. Variando entre 4 a 600 sites/sistemas por servidores.
Fato:
Depois de estudar e analisar o arquivo que varria o servidor, fiz modificações na forma que era criado, passando da utilização de link simbólico para leitura de arquivos e potencializei os resultados em 3x a 4x mais do que era capaz, além de incrementar diversos outras formas  de extração de informações como pastas de escritas e sistemas padrões como diversos cms e os mais utilizados frameworks. Foi então que nasceu o “php octopus” (Segue o link). Um pequeno e único arquivo que haje como um polvo com seus tentáculos varrendo todo servidor a procura arquivos de configurações de de sistema e banco, além de pastas com permissões de escritas.
Mas como?!
  1. Todo sistema linux possui um arquivo chamado passwd que fica na pasta / etc /. Arquivo onde é salvo todos os usuários do servidor, esse arquivo é a chave de tudo, apesar de existir outras formas menos eficiente de conseguir esses usuários, ele é a base para nosso octopus.
  2. Verifico se a pasta atual possui uma estrutura de / home / meu_usuario / public_html /, geralmente padrão para todo servidores linux.
  3.  Faço a leitura do arquivo passwd e listo todos usuários para um loop.
  4.  Tendo todos os usuários de sistema e sabendo qual a estrutura, vamos procurar por informações de configurações de sistema, banco e pastas de escritas. Por exemplo:
    1. Todo arquivo inicia com um index.html ou index.php, esse ultimo é o que nos importa, então checo se existe o arquivo / home / meu_usuario / public_html / index.php
    2. No caso de um site em WordPress ficaria / home / meu_usuario / public_html / wp-config.php
    3. No caso de um site em Joomla ficaria / home / meu_usuario / public_html / configuration.php
    4. Além de outras dezenas de padrões que identifiquei em cms e frameworks
  5.  Obtendo todas essas informações faço a leitura dos arquivos trazendo para tela, ou checando se se a pasta é de escrita.

Solução:
Muitos aqui devem dizer, solução é simples o usuário deve ter configurado errado e foi o que eu pensei também, quando comecei a analisar e ver que estava configurado de forma correta a não ser por um único detalhe, a pasta raiz, no caso a “public_html”é tratada de modo diferente, o resultado foi:

  • Serviço:
    • Eliminar visualização do / etc / passwd por parte dos usuários comuns de serviço.
    • Eliminar de alguma forma o acesso de usuários a pastas outros usuários
  • Usuário:
    • Pasta raiz, no caso public tem que ser 750
    • Não utilize 777 nem para arquivos nem para pastas.
    • Por padrão pastas internas 755 e arquivos 644.

Modo de fazer:

Baixe o arquivo do https://github.com/lenonleite/octopus e insira em seu servidor. Lembrando que possui dois arquivos um simples e outra com meta type de gif para bypass em serviços de upload, caso necessário.

Veja o vídeo:

Resultado:

OBS: Clique no check para poder ver os arquivos.

Servidor 1:

249 usuários, 111 arquivos sensíveis encontrados:

server8-e1473307784440

 

server10-1-e1473308333968

Servidor 2:

Não foi possível a leutura do arquvio passwd

server9

Servidor 3:

1 usuário encontrado, 8 arquivos sensíveis:

PHP Octopus com estegnografia para bypass sistema com uplods de arquivo

 

server6-e1473307765851

Servidor 4:

49 usuários, 18 arquivos sensíveis encontrados;

 

server5-e1473307744109

Servidor 5:

4 usuários, 11 arquivos sensíveis:

server4-e1473307723908

Servidor 6:

1 usuário, 5 arquivos sensíveis.

server3-e1473307697462

Servidor 7:

21 usuários, 35 arquivos sensíveis.

server1-e1473307674218

Clicando em um check da coluna de arquivo de configuração do Zend Framework.

server11-e1473308756190

 

6 Comments

Deixe um comentário para [email protected] Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Back to Top