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;
- Dados expostos:
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: