A04:2025 Fallas Criptográficas

Antecedentes.

Bajando dos posiciones hasta el #4, esta debilidad se centra en fallas relacionadas con la ausencia de criptografía, criptografía insuficientemente robusta, filtración de claves criptográficas y errores relacionados. Tres de los CWEs más comunes en este riesgo involucran el uso de un generador de números pseudoaleatorios débil: CWE-327 Algoritmo Criptográfico Vulnerado o Inseguro, CWE-331: Entropía Insuficiente, CWE-1241: Uso de Algoritmo Predecible en Generador de Números Aleatorios, y CWE-338 Uso de un Generador de Números Pseudoaleatorios (PRNG Pseudo-random Number Generator) Criptográficamente Débil.

Factores.

CWEs Mapeados	Tasa Máx. de Incidencia	Tasa Prom. de Incidencia	Cobertura Máx.	Cobertura Prom.	Explotabilidad Ponderada Prom.	Impacto Ponderado Prom.	Total de Ocurrencias	Total de CVEs
32	13.77%	3.80%	100.00%	47.74%	7.23	3.90	1,665,348	2,185

Descripción.

En términos generales, todos los datos en tránsito deben cifrarse en la capa de transporte (capa 4 del modelo OSI). Obstáculos anteriores como el rendimiento de la CPU y la gestión de claves privadas/certificados ahora son manejados por CPUs con instrucciones diseñadas para acelerar el cifrado (p. ej., soporte AES), y la gestión de claves privadas y certificados se ha simplificado mediante servicios como LetsEncrypt.org, con los principales proveedores de nube ofreciendo servicios de gestión de certificados aún más integrados para sus plataformas específicas.

Más allá de asegurar la capa de transporte, es importante determinar qué datos necesitan cifrado en reposo y qué datos requieren cifrado adicional en tránsito (en la capa de aplicación, capa 7 del OSI). Por ejemplo, contraseñas, números de tarjetas de crédito, registros médicos, información personal y secretos comerciales requieren protección adicional, especialmente si esos datos están sujetos a leyes de privacidad como el Reglamento General de Protección de Datos (RGPD Règlement Général sur la Protection des Données (General Data Protection Regulation)) de la UE, o regulaciones como el Estándar de Seguridad de Datos PCI (PCI DSS). Para todos esos datos:

¿Se usan algoritmos o protocolos criptográficos antiguos o débiles, ya sea por defecto o en código heredado?
¿Se usan claves criptográficas predeterminadas, se generan claves débiles, se reutilizan claves, o falta una gestión y rotación adecuada de claves?
¿Se incluyen claves criptográficas en repositorios de código fuente?
¿No se aplica el cifrado? Por ejemplo, ¿faltan directivas o cabeceras de seguridad HTTP (del navegador)?
¿Se valida correctamente el certificado del servidor recibido y la cadena de confianza?
¿Se ignoran, reutilizan o generan de forma insegura los vectores de inicialización para el modo de operación criptográfico? ¿Se usa un modo de operación inseguro como ECB? ¿Se usa cifrado cuando el cifrado autenticado sería más apropiado?
¿Se usan contraseñas como claves criptográficas sin una función de derivación de claves basada en contraseña?
¿Se usa aleatoriedad no diseñada para cumplir requisitos criptográficos? Aunque se elija la función correcta, ¿necesita ser inicializada (seed) por el desarrollador y, de ser así, ha sobrescrito la funcionalidad de semilla fuerte incorporada con una semilla con entropía/imprevisibilidad insuficiente?
¿Se usan funciones hash obsoletas como MD5 o SHA1, o se usan funciones hash no criptográficas cuando se necesitan funciones hash criptográficas?
¿Son explotables los mensajes de error criptográficos o la información de canal lateral, por ejemplo en forma de ataques de relleno de oracle (padding oracle)?
¿Puede el algoritmo criptográfico ser degradado o eludido?

Consultar referencias ASVS: Criptografía (V11), Comunicación Segura (V12) y Protección de Datos (V14).

Cómo se previene.

Como mínimo, hacer lo siguiente y consultar las referencias:

Clasificar y etiquetar los datos procesados, almacenados o transmitidos por una aplicación. Identificar qué datos son sensibles según las leyes de privacidad, los requisitos regulatorios o las necesidades del negocio.
Almacenar las claves más sensibles en un HSM físico o basado en la nube.
Usar implementaciones bien reconocidas de algoritmos criptográficos siempre que sea posible.
No almacenar datos sensibles innecesariamente. Descartarlos lo antes posible o usar tokenización conforme a PCI DSS (Payment Card Industry Data Security Standard) (Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago) o incluso truncamiento. Los datos que no se retienen no pueden ser robados.
Asegurarse de cifrar todos los datos sensibles en reposo.
Garantizar que estén en uso algoritmos, protocolos y claves estándar actualizados y robustos; usar una gestión de claves adecuada.
Cifrar todos los datos en tránsito con protocolos >= TLS 1.2 únicamente, con cifradores de secreto hacia adelante (forward secrecy, FS), eliminar soporte para cifrados en modo CBC, soportar algoritmos de intercambio de claves cuánticos. Para HTTPS, aplicar cifrado mediante HTTP Strict Transport Security (HSTS). Verificar todo con una herramienta.
Deshabilitar el caché para respuestas que contengan datos sensibles. Esto incluye el caché en el CDN, el servidor web y cualquier caché de aplicación (p. ej., Redis).
Aplicar los controles de seguridad requeridos según la clasificación de datos.
No usar protocolos sin cifrado como FTP y STARTTLS. Evitar usar SMTP para transmitir datos confidenciales.
Almacenar contraseñas usando funciones de hashing robustas, adaptativas y con sal (salt), con un factor de trabajo (factor de retardo), como Argon2, yescrypt, scrypt o PBKDF2-HMAC-SHA-512. Para sistemas heredados que usan bcrypt, consultar la Guía de referencia rápida de OWASP: Almacenamiento de Contraseñas
Los vectores de inicialización deben elegirse apropiadamente para el modo de operación. Esto puede significar usar un CSPRNG (generador de números pseudoaleatorios criptográficamente seguro). Para modos que requieren un nonce, el vector de inicialización (IV) no necesita un CSPRNG. En todos los casos, el IV nunca debe usarse dos veces para una clave fija.
Usar siempre cifrado autenticado en lugar de solo cifrado.
Las claves deben generarse criptográficamente de forma aleatoria y almacenarse en memoria como arreglos de bytes. Si se usa una contraseña, debe convertirse en clave mediante una función de derivación de clave basada en contraseña apropiada.
Asegurarse de que se use aleatoriedad criptográfica donde corresponda y que no haya sido inicializada (seeded) de forma predecible o con baja entropía. La mayoría de las APIs modernas no requieren que el desarrollador inicialice el CSPRNG para que sea seguro.
Evitar funciones criptográficas obsoletas, métodos de construcción de bloques y esquemas de relleno (padding), como MD5, SHA1, Modo de Encadenamiento de Bloques (CBC), PKCS número 1 v1.5.
Asegurarse de que las configuraciones y ajustes cumplan los requisitos de seguridad mediante revisión por especialistas en seguridad, herramientas diseñadas para este propósito, o ambos.
Es necesario prepararse ahora para la criptografía poscuántica (PQC), ver referencia (ENISA), para que los sistemas de alto riesgo estén protegidos a más tardar a finales de 2030.

Ejemplos de escenarios de ataque.

Escenario #1: Un sitio no usa ni exige TLS en todas las páginas, o admite cifrado débil. Un atacante monitorea el tráfico de red (p. ej., en una red inalámbrica insegura), degrada las conexiones de HTTPS a HTTP, intercepta solicitudes y roba la cookie de sesión del usuario. El atacante luego reproduce esta cookie y secuestra la sesión (autenticada) del usuario, accediendo o modificando los datos privados del usuario. Alternativamente, podría alterar todos los datos transportados, por ejemplo, el destinatario de una transferencia de dinero.

Escenario #2: La base de datos de contraseñas usa hashes sin sal (salt) o hashes simples para almacenar todas las contraseñas. Un fallo de carga de archivos permite a un atacante recuperar la base de datos de contraseñas. Todos los hashes sin salt pueden quedar expuestos con una tabla arcoiris (rainbow table) de hashes precalculados. Los hashes generados por funciones hash simples o rápidas pueden ser descifrados por GPUs, incluso si tenían sal.