Los programadores conquistan la infraestructura de seguridad mediante código: funciones de seguridad desactivadas

Hoy en día, las amenazas a la seguridad cibernética son omnipresentes y constantes. A medida que más y más aspectos de nuestras vidas se digitalizan, los ciberdelincuentes se enfrentan a un riesgo cada vez mayor: hay demasiado código que no se puede garantizar que sea seguro y los datos privados son demasiado valiosos. Además, bueno, es casi imposible intentar mantenerse al día y defender todos los aspectos de la superficie de ataque después de implementar un programa.

Hay algunas formas de mitigar algunos de estos síntomas, y una de ellas resulta evidente cuando las organizaciones inteligentes adoptan el concepto de infraestructura como código (IaC). Por supuesto, como en cualquier desarrollo, hay algunas trampas de seguridad que deben resolverse. Además, dado que los desarrolladores están generando código para la infraestructura crítica que aloja las aplicaciones, la concienciación sobre la seguridad es fundamental en cada etapa del proceso.

Entonces, ¿cómo pueden los desarrolladores que acaban de entrar en contacto con el entorno de los servidores en la nube mejorar sus habilidades, aprender nuevas habilidades y construir con una mayor conciencia de la seguridad? Hemos creado la próxima serie de Coders Conquer Security para abordar las vulnerabilidades comunes de IaC. Las próximas entradas del blogse centrarán en los pasos que tú (desarrollador) puedes seguir para empezar a implementar una infraestructura de seguridad en forma de código en tu organización.

Empecemos.

En el antiguo oeste americano hay una fábula que cuenta la historia de un hombre paranoico que creía que los bandidos iban a asaltar y robar su casa. Como compensación,invirtió en diversas medidas de seguridad, como instalar una puerta principal ultrarresistente, blindar todas las ventanas y tener un montón de armas a mano. Una noche, mientras dormía, le robaron porque se había olvidado de cerrar la puerta lateral. Los ladrones solo tuvieron que encontrar el sistema de seguridad defectuoso y aprovecharon rápidamente la situación.

Desactivar las funciones de seguridad en la infraestructura es como esto. Aunque su red cuente con una infraestructura de seguridad sólida, si se desactivan los elementos, no servirá de nada.

Antes de sumergirnos, permítanme plantear un desafío:

Al acceder al enlace anterior, se le redirigirá a nuestra plataforma de formación gamificada, donde podrá probar inmediatamente cómo superar las vulnerabilidades de las funciones de seguridad desactivadas. (Nota: se abrirá en Kubernetes, pero mediante el menú desplegable podrá elegir entre Docker, CloudFormation, Terraform y Ansible).

¿Cómo te ha ido? Si aún te queda trabajo por hacer, sigue leyendo:

Las funciones de seguridad pueden desactivarse por diversas razones. En el caso de algunas aplicaciones y marcos, es posible que estén desactivadas de forma predeterminada y que sea necesario activarlas antes de poder empezar a trabajar. Los administradores también pueden desactivar determinadas funciones de seguridad para facilitar la ejecución de ciertas tareas sin tener que enfrentarse a retos o bloqueos frecuentes (por ejemplo, hacer públicos los buckets de AWS S3). Una vez finalizado el trabajo,puede que se olviden de reactivar las funciones desactivadas. También es posible que prefieran mantenerlas desactivadas para facilitar el trabajo en el futuro.

¿Por qué son tan peligrosas las funciones de seguridad desactivadas?

Desactivar una o varias funciones de seguridad no es recomendable por dos razones. En primer lugar, las funciones de seguridad se implementan en los recursos de infraestructura para protegerlos contra vulnerabilidades, amenazas o fallos conocidos. Si se desactivan, no podrán proteger sus recursos.

Los atacantes siempre intentan primero encontrar vulnerabilidades fáciles de explotar, e incluso pueden utilizar scripts para corregir vulnerabilidades comunes. Esto no difiere mucho de lo que hace un ladrón cuando revisa todos los coches de la calle para ver si alguna puerta está abierta, lo cual es mucho más fácil que romper una ventana. Los hackers pueden sorprenderse al descubrir que las medidas de seguridad comunes están desactivadas. Sin embargo, cuando esto ocurre, no tardan en aprovecharlo.

En segundo lugar, configurar una buena seguridad y luego desactivarla genera una falsa sensación de seguridad. Si los administradores no saben que alguien ha desactivado estas defensas, pueden pensar que están a salvo de las amenazas comunes.

Como ejemplo de cómo un atacante puede aprovechar las funciones de seguridad desactivadas, consideremos la función de seguridad de AWS S3 que bloquea el acceso público. Con Amazon S3 Block Public Access, los administradores de cuentas y los propietarios de buckets pueden configurar fácilmente un control centralizado para restringir el acceso público a sus recursos de Amazon S3.Sin embargo, algunos administradores tienen problemas para acceder a los buckets de S3 y deciden hacerlos públicos para poder completar sus tareas lo antes posible. Si se olvidan de habilitar la función de seguridad, los atacantes tendrán acceso completo a la información almacenada en el bucket de S3, lo que no solo provocará una fuga de información, sino que también generará gastos adicionales por los costes de transferencia de datos.

Comparemos algunos códigos del mundo real; veamos el siguiente fragmento de CloudFormation:

Vulnerable:

Bucket de almacenamiento empresarial:
Tipo: AWS:: S3:: Bucket
Atributos:
Configuración de bloque de acceso público:
blockPublicACLS: error
BlockPublicy: error
ignorepublicacls: error
restrictPublicBuckets:
Configuración de control de versiones:
Estado: habilitado
Cifrado de bucket:
Configuración de cifrado del lado del servidor:
- Cifrado del lado del servidor predeterminado:
Algoritmo SSE: «AES256»

Seguridad:

Bucket de almacenamiento empresarial:
Tipo: AWS:: S3:: Bucket
Propiedades:
Configuración de bloqueo de acceso público:
blockPublicACLS: Sí
BlockPublicy: Sí
ignoreRepublicacls:
restrictPublicBuckets:
Configuración de control de versiones:
Estado: Activado
Cifrado del bucket:
Configuración de cifrado del lado del servidor:
- Cifrado del lado del servidor por defecto:
Algoritmo SSE: «AES256»

Prevenir la desactivación de funciones de seguridad

Impedir que las funciones de seguridad desactivadas causen daños negativos a su organización es tanto una cuestión de política como de práctica. Se debe establecer una política firme que establezca que las funciones de seguridad solo se pueden desactivar en circunstancias muy especiales. Se deben registrar los incidentes en los que sea necesario desactivar temporalmente una función para resolver un problema o actualizar una aplicación. Una vez completado el trabajo necesario, se debe comprobar que la función se ha reactivado por completo.

Si es necesario desactivar permanentemente una función de seguridad para simplificar el funcionamiento, se deben proporcionar otras medidas de protección para los datos afectados, a fin de garantizar que los piratas informáticos no puedan acceder a la función sin la protección predeterminada. Si se ha desactivado la función de protección necesaria, es solo cuestión de tiempo que los atacantes encuentren una puerta sin cerrar y aprovechen la situación.

Más información, desafíate a ti mismo:

Visite la página del blog de Security Code Warrior para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes frente a otras vulnerabilidades y fallos de seguridad.

Ahora que ya has leído este artículo, ¿estás listo para descubrir y corregir esta vulnerabilidad? Es horade probar el desafío de seguridad gamificado de iMac en Secure Code Warrior podrás perfeccionar y mantener al día todas tus habilidades en ciberseguridad.

Esta es una serie semanal que cubre nuestras ocho vulnerabilidades principales de «infraestructura como código». ¡Vuelve la semana que viene para obtener más información!