A04:2025 – Falhas Criptográficas (Cryptographic Failures)

Contexto

Descendo duas posições para o 4º lugar, esta fraqueza foca em falhas relacionadas à falta de criptografia, criptografia insuficientemente forte, vazamento de chaves criptográficas e erros correlatos. Três das CWEs (Common Weakness Enumerations) mais comuns neste risco envolveram o uso de geradores de números pseudoaleatórios fracos: CWE-327 Use of a Broken or Risky Cryptographic Algorithm, CWE-331: Insufficient Entropy, CWE-1241: Use of Predictable Algorithm in Random Number Generator e CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG).

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
32	13.77%	3.80%	100.00%	47.74%	7.23	3.90	1,665,348	2,185

Descrição

De modo geral, todos os dados em trânsito devem ser criptografados na camada de transporte (camada OSI 4). Obstáculos anteriores, como desempenho de CPU e gerenciamento de chaves privadas/certificados, são agora lidados por CPUs que possuem instruções projetadas para acelerar a criptografia (ex: suporte a AES) e pelo gerenciamento de chaves e certificados simplificado por serviços como o LetsEncrypt.org, com grandes provedores de nuvem oferecendo serviços de gerenciamento ainda mais integrados para suas plataformas específicas.

Além de proteger a camada de transporte, é importante determinar quais dados precisam de criptografia em repouso (at rest), bem como quais dados precisam de criptografia extra em trânsito (na camada de aplicação, camada OSI 7). Por exemplo, senhas, números de cartão de crédito, registros de saúde, informações pessoais e segredos de negócio exigem proteção extra, especialmente se esses dados estiverem sujeitos a leis de privacidade, como a Lei Geral de Proteção de Dados (LGPD) no Brasil ou o GDPR na UE, ou regulamentações como o PCI Data Security Standard (PCI DSS). Para todos esses dados:

Algum algoritmo ou protocolo criptográfico antigo ou fraco é usado por padrão ou em código legado?
Chaves criptográficas padrão estão em uso, chaves fracas são geradas, chaves são reutilizadas ou falta um gerenciamento e rotação de chaves adequados?
Chaves criptográficas foram enviadas (checked into) para repositórios de código-fonte?
A criptografia não é imposta? Por exemplo, faltam diretivas de segurança ou headers HTTP (no navegador)?
O certificado do servidor recebido e a cadeia de confiança são validados corretamente?
Vetores de inicialização (IVs) são ignorados, reutilizados ou não são gerados de forma suficientemente segura para o modo de operação criptográfico? Um modo de operação inseguro, como ECB, está em uso? A criptografia simples é usada quando a criptografia autenticada seria mais apropriada?
Senhas estão sendo usadas como chaves criptográficas na ausência de uma função de derivação de chave baseada em senha (password-based key derivation function)?
É utilizada aleatoriedade que não foi projetada para atender a requisitos criptográficos? Mesmo que a função correta seja escolhida, ela precisa de uma semente (seed) definida pelo desenvolvedor? E se não, o desenvolvedor sobrescreveu a funcionalidade de semente forte nativa por uma semente que carece de entropia/imprevisibilidade suficiente?
Funções de hash obsoletas, como MD5 ou SHA1, estão em uso, ou funções de hash não criptográficas são usadas quando funções criptográficas são necessárias?
Mensagens de erro criptográficas ou informações de canal lateral (side channel) são exploráveis, por exemplo, na forma de ataques de padding oracle?
O algoritmo criptográfico pode sofrer downgrade ou ser ignorado (bypass)?

Veja as referências ASVS: Criptografia (V11), Comunicação Segura (V12) e Proteção de Dados (V14).

Como Prevenir

Faça o seguinte, no mínimo, e consulte as referências:

Classifique e rotule os dados processados, armazenados ou transmitidos por uma aplicação. Identifique quais dados são sensíveis de acordo com as leis de privacidade, requisitos regulatórios ou necessidades de negócio.
Armazene suas chaves mais sensíveis em um HSM (Hardware Security Module) físico ou baseado em nuvem.
Use implementações bem confiáveis de algoritmos criptográficos sempre que possível.
Não armazene dados sensíveis desnecessariamente. Descarte-os o mais rápido possível ou use tokenização compatível com PCI DSS ou mesmo truncamento. Dados que não são retidos não podem ser roubados.
Certifique-se de criptografar todos os dados sensíveis em repouso.
Garanta que algoritmos, protocolos e chaves padrão, fortes e atualizados estejam em vigor; utilize um gerenciamento de chaves adequado.
Criptografe todos os dados em trânsito apenas com protocolos >= TLS 1.2, com cifras de sigilo direto (forward secrecy - FS), descontinue o suporte a cifras CBC (cipher block chaining) e suporte algoritmos de troca de chaves quânticas. Para HTTPS, imponha a criptografia usando HSTS (HTTP Strict Transport Security). Verifique tudo com uma ferramenta.
Desative o cache para respostas que contenham dados sensíveis. Isso inclui cache em sua CDN, servidor web e qualquer cache de aplicação (ex: Redis).
Aplique os controles de segurança exigidos conforme a classificação de dados.
Não utilize protocolos não criptografados, como FTP e STARTTLS. Evite usar SMTP para transmitir dados confidenciais.
Armazene senhas usando funções de hash adaptativas e salgadas (salted) com um fator de trabalho (fator de atraso), como Argon2, yescrypt, scrypt ou PBKDF2-HMAC-SHA-512. Para sistemas legados que usam bcrypt, obtenha mais orientações no OWASP Cheat Sheet: Password Storage.
Os vetores de inicialização (IVs) devem ser escolhidos de forma apropriada para o modo de operação. Isso pode significar o uso de um CSPRNG (cryptographically secure pseudo-random number generator). Para modos que exigem um nonce, o IV não precisa de um CSPRNG. Em todos os casos, o IV nunca deve ser usado duas vezes para uma chave fixa.
Sempre use criptografia autenticada em vez de apenas criptografia.
As chaves devem ser geradas de forma criptograficamente aleatória e armazenadas na memória como arrays de bytes. Se uma senha for usada, ela deve ser convertida em uma chave por meio de uma função de derivação de chave baseada em senha apropriada.
Garanta que a aleatoriedade criptográfica seja usada onde apropriado e que não tenha sido semeada de forma previsível ou com baixa entropia. A maioria das APIs modernas não exige que o desenvolvedor semeie o CSPRNG para ser seguro.
Evite funções criptográficas, métodos de construção de blocos e esquemas de preenchimento (padding) obsoletos, como MD5, SHA1, modo CBC e PKCS#1 v1.5.
Garanta que as definições e configurações atendam aos requisitos de segurança, fazendo com que sejam revisadas por especialistas em segurança, ferramentas projetadas para esse fim, ou ambos.
Você precisa se preparar agora para a criptografia pós-quântica (PQC), veja a referência (ENISA), para que sistemas de alto risco estejam seguros o mais tardar até o final de 2030.

Exemplos de Cenários de Ataque

Cenário #1: Um site não usa ou não impõe TLS para todas as páginas ou suporta criptografia fraca. Um atacante monitora o tráfego de rede (ex: em uma rede sem fio insegura), rebaixa (downgrade) as conexões de HTTPS para HTTP, intercepta requisições e rouba o cookie de sessão do usuário. O atacante, então, replica esse cookie e sequestra a sessão (autenticada) do usuário, acessando ou modificando seus dados privados. Em vez disso, ele poderia alterar todos os dados transportados, como o destinatário de uma transferência de dinheiro.

Cenário #2: O banco de dados de senhas usa hashes sem sal (unsalted) ou simples para armazenar as senhas de todos. Uma falha de upload de arquivos permite que um atacante recupere o banco de dados de senhas. Todos os hashes sem sal podem ser expostos com uma rainbow table de hashes pré-calculados. Hashes gerados por funções simples ou rápidas podem ser quebrados por GPUs, mesmo que tenham sido salgados.