Pular para conteúdo

A02:2025 – Configuração Insegura (Security Misconfiguration) icon

Contexto

Subindo da 5ª posição na edição anterior, foi constatado que 100% das aplicações testadas apresentavam alguma forma de configuração incorreta, com uma taxa média de incidência de 3,00% e mais de 719 mil ocorrências de CWEs (Common Weakness Enumeration) nesta categoria de risco. Com a migração crescente para softwares altamente configuráveis, não é surpresa ver esta categoria subir no ranking. As CWEs notáveis incluídas são CWE-16 Configuration e CWE-611 Improper Restriction of XML External Entity Reference (XXE).

Tabela de Pontuação

CWEs Mapeadas Taxa Máx. de Incidência Taxa Média de Incidência Cobertura Máxima Cobertura Média Exploit Médio Ponderado Impacto Médio Ponderado Total de Ocorrências Total de CVEs
16 27.70% 3.00% 100.00% 52.35% 7.96 3.97 719,084 1,375

Descrição

A configuração insegura ocorre quando um sistema, aplicação ou serviço de nuvem é configurado incorretamente do ponto de vista de segurança, criando vulnerabilidades.

A aplicação pode estar vulnerável se:

  • Faltar o endurecimento de segurança (security hardening) apropriado em qualquer parte da stack da aplicação ou se houver permissões configuradas incorretamente em serviços de nuvem.
  • Recursos desnecessários estiverem habilitados ou instalados (ex: portas, serviços, páginas, contas, frameworks de teste ou privilégios desnecessários).
  • Contas padrão e suas senhas ainda estiverem habilitadas e inalteradas.
  • Houver falta de uma configuração centralizada para interceptar mensagens de erro excessivas. O tratamento de erros revela stack traces ou outras mensagens de erro excessivamente informativas aos usuários.
  • Para sistemas atualizados, os recursos de segurança mais recentes estiverem desativados ou não configurados com segurança.
  • Houver priorização excessiva da compatibilidade reversa, levando a configurações inseguras.
  • As configurações de segurança nos servidores de aplicação, frameworks (ex: Struts, Spring, ASP.NET), bibliotecas, bancos de dados, etc., não estiverem definidas com valores seguros.
  • O servidor não enviar headers ou diretivas de segurança, ou se estes não estiverem configurados com valores seguros.

Sem um processo de endurecimento (hardening) de configuração de segurança de aplicação concentrado e repetível, os sistemas correm um risco maior.

Como Prevenir

Processos de instalação seguros devem ser implementados, incluindo:

  • Um processo de hardening repetível que permita a implantação rápida e fácil de outro ambiente devidamente bloqueado. Os ambientes de desenvolvimento, QA e produção devem ser configurados de forma idêntica, com credenciais diferentes usadas em cada um. Este processo deve ser automatizado para minimizar o esforço necessário para configurar um novo ambiente seguro.
  • Uma plataforma mínima, sem quaisquer recursos, componentes, documentação ou amostras desnecessárias. Remova ou não instale recursos e frameworks não utilizados.
  • Uma tarefa para revisar e atualizar as configurações de acordo com todas as notas de segurança, atualizações e patches como parte do processo de gerenciamento de patches (veja A03 Falhas na Cadeia de Suprimentos de Software). Revise as permissões de armazenamento em nuvem (ex: permissões de buckets S3).
  • Uma arquitetura de aplicação segmentada que forneça separação eficaz e segura entre componentes ou usuários (tenants), com segmentação, conteinerização ou grupos de segurança de nuvem (ACLs).
  • Envio de diretivas de segurança para os clientes, ex: headers de segurança.
  • Um processo automatizado para verificar a eficácia das configurações e definições em todos os ambientes.
  • Adição proativa de uma configuração central para interceptar mensagens de erro excessivas como reserva (backup).
  • Se essas verificações não forem automatizadas, elas devem ser verificadas manualmente, no mínimo, anualmente.
  • Utilize federação de identidade, credenciais de curta duração ou mecanismos de acesso baseados em funções (RBAC) fornecidos pela plataforma subjacente, em vez de incorporar chaves estáticas ou segredos (secrets) no código, arquivos de configuração ou pipelines.

Exemplos de Cenários de Ataque

Cenário #1: O servidor de aplicação vem com aplicações de exemplo não removidas do servidor de produção. Essas aplicações de exemplo têm falhas de segurança conhecidas que os atacantes usam para comprometer o servidor. Suponha que uma dessas aplicações seja o console de administração e as contas padrão não foram alteradas. Nesse caso, o atacante faz o login com a senha padrão e assume o controle.

Cenário #2: A listagem de diretórios não está desativada no servidor. Um atacante descobre que pode simplesmente listar os diretórios. O atacante encontra e baixa as classes Java compiladas, que ele descompila e faz engenharia reversa para visualizar o código. O atacante, então, encontra uma falha grave de controle de acesso na aplicação.

Cenário #3: A configuração do servidor de aplicação permite que mensagens de erro detalhadas, como stack traces, sejam retornadas aos usuários. Isso potencialmente expõe informações sensíveis ou falhas subjacentes, como versões de componentes que são conhecidamente vulneráveis.

Cenário #4: Um provedor de serviços de nuvem (CSP) define por padrão permissões de compartilhamento abertas para a Internet. Isso permite que dados sensíveis armazenados no armazenamento em nuvem sejam acessados.

Referências

Lista de CWEs Mapeadas