Los codificadores conquistan la infraestructura de seguridad como series de códigos: errores de configuración de seguridad: permisos incorrectos

Las amenazas a la ciberseguridad en estos días son omnipresentes e incesantes. La situación ha empeorado tanto que tratar de mantenerse al día con ellos después de implementar los programas se ha vuelto casi imposible. En cambio, las organizaciones inteligentes están adoptando el concepto de infraestructura como código, mediante el cual los desarrolladores contribuyen a crear aplicaciones seguras mientras aún se están creando. El objetivo de esta serie es prepararlo para la seguridad, de modo que pueda comprender los pasos que debe seguir como desarrollador para empezar a implementar una infraestructura segura como código en su propia organización.

Los errores de configuración de seguridad, especialmente los de permisos inadecuados, ocurren con mayor frecuencia cuando un desarrollador crea un nuevo usuario o concede permiso para una aplicación como herramienta para realizar una tarea. Por ejemplo, esto podría hacerse para recopilar información de una base de datos. Sin embargo, si los permisos del nuevo usuario son demasiado altos o no están configurados de forma predeterminada para la tarea en cuestión, se puede introducir una vulnerabilidad grave en el código.

Antes de empezar, ¿por qué no pones a prueba tus habilidades ahora mismo? Intente encontrar y corregir algunas vulnerabilidades de permisos incorrectas:

¿Cómo te fue? Profundicemos un poco más:

Otorgar permisos completos a un usuario o aplicación, o simplemente no molestarse en definir lo que el nuevo usuario debería poder lograr y qué comportamientos están restringidos, es sin duda la forma más rápida de implementar un nuevo código. Y si todo va perfectamente bien, la aplicación utilizará esos permisos para llevar a cabo la tarea asignada. El peligro es que un pirata informático descubra este proceso y luego comprometa a ese usuario. Aunque el usuario se creó para realizar una función específica para una aplicación en particular, si se pone en peligro, puede permitir que un atacante ponga en peligro otras aplicaciones, datos o incluso la red.

¿Cómo se aprovechan los errores de configuración de seguridad?

Para visualizar el peligro, veamos cómo a veces se codifica una tarea común en el entorno de nube de Docker. Supongamos que un desarrollador utiliza el servicio MySQL Exporter de Prometheus para recopilar información de una base de datos. La forma más sencilla de permitir que eso suceda es conceder al exportador permiso para acceder a la base de datos. Así que el código podría ser algo así como:

DE mysql:latest
COPIAR. /scripts/create_users.sh /docker-entrypoint-initdb.d/
USUARIO 999
CREAR USUARIO EXPORTADOR@% IDENTIFICADO POR $EXPORTER_PASSWORD;
CONCEDE TODO EL *.* AL EXPORTADOR@%;
OTORGUE SELECT ON performance_schema.* AL EXPORTADOR@%;

Esto sin duda permitiría que el exportador pudiera cumplir su tarea. Sin embargo, debido a que los permisos no están definidos, el exportador en realidad tiene la capacidad de hacer casi cualquier cosa. Obviamente, el propio exportador nunca actuaría fuera de sus comportamientos programados. Pero, ¿qué pasaría si un atacante pudiera comprometer el servicio al exportador? En ese caso, dado que se le concedieron todos los permisos, el atacante podría realizar todo tipo de tareas no autorizadas con el servicio SQL.

Asegurar y eliminar los permisos incorrectos

Una vez más, volvemos al concepto de infraestructura como código. Si codificas la seguridad en tus aplicaciones a medida que se crean, la red siempre tendrá una posición mucho mejor en términos generales en lo que respecta a la ciberseguridad.

En el ejemplo anterior de Docker, si un desarrollador quiere que el Prometheus MySQL Exporter pueda consultar una base de datos, puede hacerlo de forma más segura definiendo lo que se le debe permitir realizar. Un buen ejemplo de esto sería:

DE mysql:latest
COPIAR. /scripts/create_users.sh /docker-entrypoint-initdb.d/
USUARIO 999
CREAR USUARIO EXPORTADOR@% IDENTIFICADO POR $EXPORTER_PASSWORD;
PROCESO DE CONCESIÓN, CLIENTE DE REPLICACIÓN ACTIVADO *.* AL EXPORTADOR@%;
OTORGUE SELECT ON performance_schema.* AL EXPORTADOR@%;

En este caso, el usuario de MySQL configurado para el servicio MySQL Exporter de Prometheus solo tiene permisos restringidos sobre el servicio MySQL. En concreto, solo se permiten los privilegios PROCESS y REPLICATION CLIENT. Esto evitaría que un usuario malintencionado aprovechara un servicio exportador de Prometheus MySQL comprometido.

Restringir los permisos a nivel de código puede garantizar que los usuarios y las aplicaciones solo tengan los permisos suficientes para la tarea en cuestión. Y eso puede contribuir en gran medida a proteger sus redes y a adoptar el concepto de infraestructura como código.

Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba nuestro escaparate de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.