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: