Explorando arquivos de configuração de frameworks – Parte 2

Exemplo:

Zend I
  • inurl:/application/configs/ intitle:index of
  • inurl:/application/controllers/ intitle:index of
  • filetype:ini “Bootstrap.php” (pass|passwd|password|pwd)
Zend II
  • inurl:/data/cache/ intitle:index of
  • inurl:/module/application/ intitle:index of
Laravel
  • filetype:env intext:mail_host /  “MAIL_PASSWORD” filetype:env
  • de cima procurando por email
  • filetype:env intext:REDIS_PASSWORD
  • por configuração de redis
  • filetype:env intext:”APP_ENV”
  • inurl:readme.md intext:”Laravel” -vendor -github -gitlab -bitbucket -git -node_modules
  • Troca o readme.md por .env
  • filetype:env intext:FACEBOOK_APP_ID
  • filetype:env intext:TWITTER_CONSUMER_KEY
  • filetype:env intext:PUSHER_APP_ID
  • filetype:env intext:MAILGUN_DOMAIN
  • filetype:env intext:GOOGLE_SECRET
Symfony
  • inurl:”databases.yml” ext:yml password -github
  • inurl:”apps/backend/config/” intitle:index of
  • “database_password” filetype:yml “config/parameters.yml”
  • inurl:app/config/ intext:parameters.yml intitle:index.of
  • inurl:storage/logs/ intitle:index of
  • inurl:web/frontend_dev.php -trunk
  • inurl:config/databases.yml -trac -trunk -“Google Code” -source -repository
Codigniter

Não encontrei possibilidades de explorar esse framework por possuir pasta de index.html em todas suas pastas e o arquivos de sistema ser de sistema, no caso um .php

Kohana
  • inurl:/application/cache intitle:index of
  • inurl:/application/logs intitle:index of
Slim
  • inurl:/log/error.log ext:log
  • inurl:/log/access.log ext:log
Yii I
  • inurl:/protected/data/ intitle:index of
Yii II
  • inurl:/protected/data/ intitle:index of
CakePHP
  • inurl:/cms/config/ intitle:index.of
  • inurl:/cms/logs/ intitle:index.of
  • inurl:/cms/tmp/ intitle:index.of
Geral
  • inurl:”vendor/phpunit/”

O que pode causar?

Essa falha pode causar de uma simples exposição de dados pessoais como falei nesse post ou dar início a um domínio de uma máquina se o atacante tiver o acesso aos dados de configuração de uma base de dados por exemplo.

A princípio parece ser algo superficial, mas dependendo do dado exposto a empresa / instituição / pessoa pode ter um prejuízo grande por parte da imagem e dos seus clientes com dados expostos seja de forma direta ou indireta.

Tipos de dados expostos:

    • Dados expostos:
      • Documentos Pessoais;
      • Documentos sigilosos;
      • Imagens Pessoais;
    • Sistemas
      • Erros de sistema;
      • logs de acesso;
      • Arquivos temporários;
    • Arquivos de Configuração:
      • Banco de dados;
      • SMTP;
      • REDIS;
      • Comunicação como facebook;
      • Comunicação como twitter,
      • Comunicação como linkedin
      • Comunicação como github;
      • Comunicação dom Pushs;

Solução

Muitos acham que essa responsabilidade é da infraestrutura, eu diria sim, talvez de todos, não tem uma resposta exata, como esse artigo é voltado para developers, vou tentar passar algumas dicas para esses.

Para desenvolvedores de framework.

  • Usem arquivos de sistema( .php ), para registrar os dados de configurações;
  • Coloquem index.html vazio em todas as pastas assim como Codeigniter e WordPress fazem.

Para quem implementa o framework.

  • Instalar de forma correta os frameworks, segundo os padrões que pedem. Sua maioria pede para colocar o root do sistema na pasta public, a frente das pastas com arquivos sensíveis.
  • Uso da configuração de .htaccess, inserindo apenas “Options -Indexes” no corpo do documento, para evitar indexação do google e que mostre páginas sem o index ( lembrando que não evita em sua totalidade o ataque ). Link https://stackoverflow.com/questions/2530372/how-do-i-disable-directory-browsing

Conclusão

Com as dorks publicadas acima, conseguimos ver a quantidade de sistemas que estão com dados expostos, se rodasse um scan com todas essas dorks, diria que gira em torno de milhares com problema.

Não podemos dizer que é um 0day, ou falha de sistema, eu diria que é uma falha de implementação de quem instalar o framework no server.

Apesar de dizer que não é falha de sistema, no caso dos frameworks, creio que eles possuem responsabilidades, principalmente por criarem e divulgarem arquivos de configurações que não são lidos por default como arquivos de sistemas, e fáceis de serem impressos.

Na pesquisa pude constatar, que a maioria dos novos framework e das novas versões dos frameworks antigos estão guardando configurações em arquivos de sistema apesar de sempre darem a opção de colocarem os dados sensíveis em arquivos de texto. Na contra mão dessa ação, está o laravel e o Cakephp que trabalham com arquivos env.

Então fique atento, e aí vai correr o risco?

Por: mim com contribuição de Subsolo Vinícius

Referências:

Deixe um comentário

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

Back to Top