A08:2025 Falhas de Integridade de Software ou Dados

Contexto

Falhas de Integridade de Software ou Dados continua em #8, com uma leve alteração esclarecedora no nome (de "Software and Data..." para "Software or Data..."). Esta categoria foca na falha em manter limites de confiança e verificar a integridade de artefatos de software, código e dados em um nível inferior às Falhas na Cadeia de Suprimentos de Software. Esta categoria foca em assumir pressupostos relacionados a atualizações de software e dados críticos sem verificar sua integridade. Enumerações de Fraquezas Comuns (CWEs) notáveis incluem CWE-829: Inclusion of Functionality from Untrusted Control Sphere, CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes e CWE-502: Deserialization of Untrusted Data.

Tabela de pontuação

CWEs Mapeadas	Taxa Máx. de Incidência	Taxa Méd. de Incidência	Cobertura Máxima	Cobertura Média	Exploit Ponderado Médio	Impacto Ponderado Médio	Total de Ocorrências	Total de CVEs
14	8,98%	2,75%	78,52%	45,49%	7,11	4,79	501.327	3.331

Descrição

Falhas de integridade de software e dados referem-se a códigos e infraestruturas que não protegem contra códigos ou dados inválidos ou não confiáveis que são tratados como íntegros e válidos. Um exemplo disso ocorre quando uma aplicação depende de plugins, bibliotecas ou módulos de fontes, repositórios e redes de entrega de conteúdo (CDNs) não confiáveis. Um pipeline de CI/CD inseguro, que não consome nem fornece verificações de integridade de software, pode introduzir o potencial de acesso não autorizado, código malicioso ou comprometimento do sistema. Outro exemplo é um CI/CD que extrai código ou artefatos de locais não confiáveis e/ou não os verifica antes do uso (através de assinatura digital ou mecanismo similar). Por fim, muitas aplicações agora incluem funcionalidade de atualização automática, onde atualizações são baixadas sem verificação de integridade suficiente e aplicadas à aplicação previamente confiável. Atacantes poderiam potencialmente fazer o upload de suas próprias atualizações para serem distribuídas e executadas em todas as instalações. Outro exemplo ocorre quando objetos ou dados são codificados ou serializados em uma estrutura que um atacante pode visualizar e modificar, tornando a aplicação vulnerável à desserialização insegura.

Como prevenir

Utilize assinaturas digitais ou mecanismos similares para verificar se o software ou dado provém da fonte esperada e não foi alterado.
Garanta que bibliotecas e dependências, como npm ou Maven, estejam consumindo apenas repositórios confiáveis. Se você tiver um perfil de risco mais elevado, considere hospedar um repositório interno de itens conhecidos e aprovados (vetted).
Garanta que haja um processo de revisão para alterações de código e configuração para minimizar a chance de que códigos ou configurações maliciosas sejam introduzidos em seu pipeline de software.
Garanta que seu pipeline de CI/CD possua segregação, configuração e controle de acesso adequados para assegurar a integridade do código que flui pelos processos de compilação (build) e implantação (deploy).
Garanta que dados serializados não assinados ou não criptografados não sejam recebidos de clientes não confiáveis e usados posteriormente sem algum tipo de verificação de integridade ou assinatura digital para detectar adulteração ou repetição (replay) dos dados serializados.

Exemplos de cenários de ataque

Cenário #1 Inclusão de Funcionalidade Web de Fonte Não Confiável: Uma empresa utiliza um provedor de serviços externo para fornecer funcionalidade de suporte. Por conveniência, possui um mapeamento de DNS de minhaEmpresa.ProvedorSuporte.com para suporte.minhaEmpresa.com. Isso significa que todos os cookies, incluindo cookies de autenticação configurados no domínio minhaEmpresa.com, serão enviados para o provedor de suporte. Qualquer pessoa com acesso à infraestrutura do provedor de suporte pode roubar os cookies de todos os seus usuários que visitaram suporte.minhaEmpresa.com e realizar um ataque de sequestro de sessão (session hijacking).

Cenário #2 Atualização sem assinatura: Muitos roteadores domésticos, decodificadores de TV (set-top boxes), firmwares de dispositivos e outros não verificam atualizações via firmware assinado. Firmware não assinado é um alvo crescente para atacantes e a expectativa é que a situação piore. Esta é uma preocupação importante, pois muitas vezes não há mecanismo de remediação além de corrigir em uma versão futura e esperar que as versões anteriores deixem de ser usadas.

Cenário #3 Uso de Pacote de Fonte Não Confiável: Um desenvolvedor tem dificuldade em encontrar a versão atualizada de um pacote que está procurando, então ele o baixa não do gerenciador de pacotes regular e confiável, mas de um site qualquer na internet. O pacote não está assinado e, portanto, não há oportunidade de garantir a integridade. O pacote inclui código malicioso.

Cenário #4 Desserialização Insegura: Uma aplicação React chama um conjunto de microserviços Spring Boot. Sendo programadores funcionais, eles tentaram garantir que seu código fosse imutável. A solução encontrada foi serializar o estado do usuário e passá-lo de um lado para o outro em cada requisição. Um atacante percebe a assinatura de objeto Java "rO0" (em base64) e utiliza o Java Deserialization Scanner para obter execução remota de código (RCE) no servidor da aplicação.