Explorando arquivos de configuração de frameworks – Parte 1 – Lenon Leite
Segundo o Wikipedia framework é …
"Um framework em desenvolvimento de software, é uma abstração que une códigos comuns entre vários projetos de software provendo uma funcionalidade genérica."
Por analogia, posso sugerir o funcionamento similar ao de uma chave inglesa, pois é algo que facilita e agiliza a forma de desenvolvimento com muitas utilidades prontas e pré configuradas.
Todos eles possuem padrões, como estrutura de pastas, arquivos além dos patterns. Esse frameworks são organizados para separar tipos de arquivos por responsabilidades, como view, controller and model se for um framework que utiliza um padrão MVC e também separa arquivos de acordo suas extensões como os arquivos estáticos js, css, html, como arquivos de configurações de sistema que pode ser um ini, yaml, yml, xml, arquivos de cache e logs entre outros.
Nesse artigo vamos abordar os principais.
O problema acontece quando o framework não é implementado da forma correta, como orienta a documentação. Vale ressaltar nesse ponto, que isso não é uma falha dos frameworks, mas sim de implementação. Claro, poderia ter mudanças no framework que ajudariam a minizar o problema de segurança.
Todo framework possui uma pasta onde é para ser apontado a url principal, geralmente um arquivo index em uma pasta chamada "public".
O site https://www.example.com/ está apontado para pasta no servidor /var/html/example/public/ ( lembrando que o serviços de hospedagem dão acesso a partir da pasta do usuário de sistema nesse caso /var/html/example/ ) e não é possível voltar pastas pois o public é um nível final, apenas com pastas de arquivos estáticos geralmente.
O problema acontece quando você aponta a página principal para uma pasta anterior a pasta public. Por exemplo /var/html/example/.
O primeiro problema de você apontar para uma pasta anterior é que na mesma linha da estrutura de arquivos você tem outras pastas de sistema além dos arquivos de configurações e você consegue navegar através da url por exemplo https://www.example.com/application/config/.
O segundo problema acontece pela maioria dos arquivos de configurações não serem de sistema( nesse ponto acho que os frames poderiam ter ajudado na parte da segurança), são arquivos que se encontrados em um url comum como https://www.example.com/application/config/apllication.ini e será impresso na tela.
Outro problema comum, são inserir vários sistemas apenas inserindo em pastas após a página principal.
Temos a página principal, https://www.example.com/ que está usando algum framework e está configurada de forma correta. Mas possui uma lista de sistemas no mesmo servidor mais em patas a frente da principal.
O que vamos tentar fazer é encontrar arquivos sensíveis de sistemas abertos, pois é nele que é possível extrair dados como host user e password da base de dados ou dados de stmp, além de outros dados sensíveis como logs e caches.
Localizar pastas sem o index.php ou index.html para retornar a listagem de arquivos e pasta. Através dessa ação podemos analisar os padrões de pastas e arquivos para pode identificar o framework. Depois de identificar o framework e a versão navegando entre patas e checando arquivos o segundo passo é ir até as pastas que possuem arquivos sensíveis, ou abri-los direto.
Ataque em larga escala:
Através de sites de buscas como google, bing entre outros é usado dorks 1* específicas de acordo com cada framework, podemos listar milhares de sistemas com problemas de configuração e com dados sensíveis expostos.
Clique para continuar na Parte 2
Veja na segunda parte do artigo. Part 2
1*- Dorks: A Google dork is an employee who unknowingly exposes sensitive corporate information on the Internet. The word dork is slang for a slow-witted or in-ept person. Leia Mais…
Obs: Artigo escrito por mim com contribuição de Subsolo Vinícius
Previous Post13 / 17 Plugins para WordPress com mais de 150/270 mil downloads ativos com o mesmo problemas de segurança.