A02:2021 – Fallas Criptográficas

Falla criptográfica

Resumen

Subiendo una posición al #2, anteriormente conocida como Exposición de Datos Sensibles, que es más un síntoma amplio que una causa raíz, el enfoque ahora está en las fallas relacionadas con la criptografía (o la falta de ella), que a menudo conducen a la exposición de datos sensibles. Las Enumeraciones de Debilidades Comunes (CWEs) notables incluyen CWE-259: Uso de Contraseña Codificada, CWE-327: Algoritmo Criptográfico Roto o Riesgoso, y CWE-331: Entropía Insuficiente.

Descripción

The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection, mainly if that data falls under privacy laws, e.g., EU's General Data Protection Regulation (GDPR), or regulations, e.g., financial data protection such as PCI Data Security Standard (PCI DSS). For all such data:

  • ¿Se transmite algún dato en texto claro? Esto incluye protocolos como HTTP, SMTP, FTP, y también aquellos que utilizan actualizaciones TLS como STARTTLS. El tráfico externo por internet es peligroso. Verifica todo el tráfico interno, por ejemplo, entre balanceadores de carga, servidores web o sistemas de back-end.
  • ¿Se utilizan algoritmos o protocolos criptográficos antiguos o débiles, ya sea por defecto o en código antiguo?
  • ¿Se están utilizando claves criptográficas predeterminadas, generando o reutilizando claves criptográficas débiles, o falta una gestión o rotación adecuada de claves? ¿Se han registrado claves criptográficas en repositorios de código fuente?
  • ¿No se está forzando el cifrado? Por ejemplo, ¿faltan directivas de seguridad o encabezados HTTP en el navegador?
  • ¿Se valida correctamente el certificado del servidor recibido y la cadena de confianza?
  • ¿Se ignoran, reutilizan o no se generan vectores de inicialización suficientemente seguros para el modo de operación criptográfico? ¿Se está utilizando un modo de operación inseguro como ECB? ¿Se está utilizando cifrado cuando la autenticación cifrada sería más apropiada?
  • ¿Se están utilizando contraseñas como claves criptográficas en ausencia de una función de derivación de clave basada en contraseña?
  • ¿Se está utilizando aleatoriedad para propósitos criptográficos que no fue diseñada para cumplir con los requisitos criptográficos? Incluso si se elige la función correcta, ¿necesita ser inicializada por el desarrollador, y si no, el desarrollador ha sobrescrito la funcionalidad de inicialización fuerte con una semilla que carece de suficiente entropía/imprevisibilidad?
  • ¿Se están utilizando funciones hash obsoletas como MD5 o SHA1, o funciones hash no criptográficas cuando se necesitan funciones hash criptográficas?
  • ¿Se están utilizando métodos de padding criptográficos obsoletos como PKCS número 1 v1.5?
  • ¿Los mensajes de error criptográficos o la información de canal lateral son explotables, por ejemplo, en forma de ataques de oracle de padding?

Cómo prevenir las fallas criptográficas

Haz lo siguiente, como mínimo, y consulta las referencias:

  • Clasifica los datos procesados, almacenados o transmitidos por una aplicación. Identifica cuáles datos son sensibles según las leyes de privacidad, requisitos regulatorios o necesidades comerciales.
  • No almacenes datos sensibles innecesariamente. Deséchalos lo antes posible o utiliza tokenización conforme a PCI DSS o incluso truncamiento. Los datos que no se retienen no pueden ser robados.
  • Asegúrate de cifrar todos los datos sensibles en reposo.
  • Garantiza el uso de algoritmos, protocolos y claves estándar actualizados y sólidos; utiliza una gestión de claves adecuada.
  • Cifra todos los datos en tránsito con protocolos seguros como TLS con cifrados de secreto directo (FS), priorización de cifrados por el servidor y parámetros seguros. Fuerza el cifrado utilizando directivas como HTTP Strict Transport Security (HSTS).
  • Desactiva la caché para las respuestas que contienen datos sensibles.
  • Aplica los controles de seguridad necesarios según la clasificación de los datos.
  • No uses protocolos heredados como FTP y SMTP para transportar datos sensibles.
  • Almacena contraseñas utilizando funciones de hashing adaptativas fuertes y saladas con un factor de trabajo (factor de demora), como Argon2, scrypt, bcrypt o PBKDF2.
  • Los vectores de inicialización deben ser elegidos de acuerdo con el modo de operación. Para muchos modos, esto significa usar un CSPRNG (generador de números pseudoaleatorios criptográficamente seguro). Para los modos que requieren un nonce, el vector de inicialización (IV) no necesita un CSPRNG. En todos los casos, el IV nunca debe reutilizarse para una clave fija.
  • Siempre utiliza cifrado autenticado en lugar de solo cifrado.
  • Las claves deben ser generadas de manera criptográficamente aleatoria y almacenadas en memoria como arreglos de bytes. Si se utiliza una contraseña, entonces debe convertirse en una clave a través de una función adecuada de derivación de clave basada en contraseña.
  • Asegúrate de que se use aleatoriedad criptográfica donde sea apropiado y de que no haya sido inicializada de manera predecible o con baja entropía. La mayoría de las API modernas no requieren que el desarrollador inicialice el CSPRNG para obtener seguridad.
  • Evita funciones criptográficas y esquemas de padding obsoletos, como MD5, SHA1 y PKCS número 1 v1.5.
  • Verifica de manera independiente la efectividad de la configuración y los ajustes.

Escenarios de ataque (Ejemplos)

Escenario #1: Una aplicación cifra los números de tarjetas de crédito en una base de datos utilizando cifrado automático de base de datos. Sin embargo, estos datos se descifran automáticamente cuando se recuperan, permitiendo que una vulnerabilidad de inyección SQL recupere números de tarjetas de crédito en texto claro.

Escenario #2: Un sitio no usa ni impone TLS en todas las páginas o soporta cifrado débil. Un atacante monitorea el tráfico de la red (por ejemplo, en una red inalámbrica insegura), degrada las conexiones de HTTPS a HTTP, intercepta las 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. En lugar de lo anterior, podría alterar todos los datos transportados, por ejemplo, el destinatario de una transferencia de dinero.

Escenario #3: La base de datos de contraseñas utiliza hashes simples o sin sal para almacenar las contraseñas de todos. Una vulnerabilidad en la carga de archivos permite a un atacante recuperar la base de datos de contraseñas. Todos los hashes sin sal pueden ser expuestos con una tabla arcoíris de hashes pre-calculados. Los hashes generados por funciones hash simples o rápidas pueden ser descifrados por GPUs, incluso si estaban salados.

Referencias