Serie de infraestructura como código para desarrolladores: Criptografía insegura

Las organizaciones inteligentes están adoptando el concepto de infraestructura como código, y son los desarrolladores como tú quienes pueden hacer contribuciones significativas en la creación de código seguro, incluso más allá del desarrollo de aplicaciones. Puede parecer un camino largo al principio, pero vale la pena recorrerlo para destacar entre tus colegas.

Antes de comenzar con este siguiente capítulo de nuestra última serie Coders Conquer Security, me gustaría invitarle a participar en un desafío gamificado sobre la vulnerabilidad de almacenamiento de datos confidenciales; juegue ahora y elija entre Kubernetes, Terraform, Ansible, Docker o CloudFormation:

¿Qué le ha parecido? Si necesita reforzar sus conocimientos, siga leyendo:

Hoy en día, aplicar hash a datos críticos como contraseñas, información personal y registros financieros cuando están en reposo es un pilar fundamental de cualquier defensa de ciberseguridad. En muchos sentidos, actúa tanto como una última línea de defensa como una de las mejores formas de protección. Esto se debe a que, incluso si un atacante logra superar otras defensas y obtener archivos críticos, si estos están correctamente almacenados y con hash, no le servirán de mucho.

Esto también actúa como una sólida protección secundaria contra usuarios internos malintencionados, ya que los archivos cifrados pueden tener claves o contraseñas independientes del resto de la red. En ese caso, alguien como un administrador de sistemas o un hacker que haya comprometido las credenciales de un administrador podría acceder a un directorio protegido, pero aun así no podría desbloquear los archivos cifrados que encuentre allí si la clave de cifrado se guarda en otro lugar.

Por supuesto, todos los métodos de protección mediante cifrado dependen de contar con estándares de cifrado robustos que no puedan ser vulnerados ni siquiera por las computadoras más potentes.

¿Por qué es peligrosa la criptografía insegura?

En el ámbito de la tecnología informática, la capacidad de crear algoritmos de cifrado robustos y la capacidad de romperlos han estado en competencia durante mucho tiempo. En 1977, el gobierno federal de los Estados Unidos desarrolló el Estándar de Cifrado de Datos (DES), un algoritmo de 56 bits que se consideraba seguro en aquel momento dada la potencia relativa de las computadoras.

Pero las computadoras evolucionaron y la gente encontró formas de conectarlas en red de manera colaborativa para aumentar aún más su potencia. En 1999, la Electronic Frontier Foundation, junto con Distributed.net, colaboraron para romper públicamente el cifrado de un documento protegido con DES en solo 22 horas. De repente, cualquier documento protegido por el cifrado DES dejó de ser seguro.

Lo creas o no, algunas organizaciones todavía protegen sus archivos críticos con el algoritmo DES o con protecciones de cifrado igualmente débiles. Y aunque en 1999 se necesitó una red distribuida para romper el cifrado de 56 bits, hoy en día casi cualquier computadora independiente lo suficientemente potente puede hacerlo en poco tiempo. Los hackers también han creado máquinas de descifrado dedicadas construidas a partir de bancos de unidades de procesamiento gráfico (GPU). Esas GPU son excepcionalmente buenas en esa tarea, son relativamente económicas de obtener y de conectar en red localmente.

Si hoy decides proteger tus archivos críticos con un algoritmo criptográfico inseguro o débil, no pasará mucho tiempo antes de que la mayoría de los hackers puedan descifrar esos archivos y hacerlos legibles. Si sufres una brecha de datos, debes asumir que los archivos terminarán siendo comprometidos si no estaban suficientemente protegidos.

Por ejemplo, el siguiente fragmento de código de Kubernetes utiliza un algoritmo de cifrado débil para proteger la información a nivel del controlador de ingreso NGINX:

apiVersion: v1
kind: ConfigMap
metadata:
 name: nginx-load-balancer-conf
 namespace: kube-system
data:
 ssl-ciphers: DES-CBC3-SHA
 ssl-protocols: "TLSv1.2"

En ese ejemplo, se ha utilizado el conjunto de cifrado DES para proteger la información. Sin embargo, un atacante podría descifrarlo fácilmente y acceder a información confidencial.

Se recomienda utilizar algoritmos de cifrado robustos. En el siguiente ejemplo de Kubernetes, se han utilizado conjuntos de cifrado robustos para proteger la información a nivel del controlador de ingreso NGINX:

apiVersion: v1
kind: ConfigMap
metadata:
 name: nginx-load-balancer-conf
 namespace: kube-system
data:
 ssl-ciphers: |
   ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
   ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:
   ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
   ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:
   ECDHE-RSA-AES128-SHA256
 ssl-protocols: "TLSv1.2"

En ese ejemplo, se ha utilizado un conjunto robusto de cifrados para evitar que los atacantes obtengan un posible acceso a información confidencial.

Protección de información crítica con cifrado robusto

Hoy en día existe un cifrado robusto que es prácticamente imposible de romper. En 2001, el Instituto Nacional de Estándares y Tecnología (NIST) creó una nueva tecnología de cifrado para reemplazar al DES. Llamado Estándar de Cifrado Avanzado (AES), utiliza tres longitudes de clave diferentes: 128, 192 o 256 bits. El cifrado AES de 256 bits es el más seguro, aunque los tres se consideran casi totalmente imposibles de romper con la tecnología actual. Las pruebas con supercomputadoras han demostrado que se necesitarían miles de años de trabajo constante para romper la mayoría de los documentos protegidos con AES.

Para proteger adecuadamente los archivos críticos, los desarrolladores deben identificarlos primero. No es necesario cifrar todo en una red, ya que el proceso constante de cifrado y descifrado podría ralentizar las operaciones. Sin embargo, los archivos críticos como los registros de personal, los datos de clientes y la información financiera requieren una protección adecuada. En esencia, es un equilibrio entre la seguridad y mantener un sistema funcional.

Y esos datos deben cifrarse siguiendo uno de los estándares AES, llegando incluso al cifrado de 256 bits para información verdaderamente crítica que nunca debería caer en manos equivocadas.

Otro aspecto a considerar es que añadir cifrado es como añadir más contraseñas a un sitio. Esto significa que los usuarios autorizados deberán gestionar las claves de cifrado. Para evitar que esto se convierta en un cuello de botella, considere implementar una plataforma de gestión de claves para realizar un seguimiento y mantenerlas seguras. Incluso si no utiliza una gestión centralizada, asegúrese de que todas las claves y contraseñas estén protegidas para evitar que usuarios no autorizados accedan a sus depósitos de datos más seguros.

Consulte las páginas del blog de Secure Code Warrior para obtener más información sobre esta vulnerabilidad y cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puede probar una demostración de un desafío de IaC dentro de la plataforma de formación de Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.