Coders Conquer Security Infrastructure as Code Series: Mala configuración de la seguridad - Permisos inadecuados

Las amenazas a la ciberseguridad hoy en día son omnipresentes e implacables. Se ha vuelto tan grave que tratar de seguirles el paso después de desplegar los programas se ha vuelto casi imposible. En su lugar, las organizaciones astutas están adoptando el concepto de infraestructura como código, por el que los desarrolladores contribuyen a la elaboración de aplicaciones seguras mientras aún se están creando. Esta serie trata de prepararle para la seguridad, para que pueda entender los pasos que puede dar como desarrollador para empezar a desplegar una infraestructura segura como código en su propia organización.

Las desconfiguraciones de seguridad, especialmente las de la variedad de permisos inadecuados, ocurren con mayor frecuencia cuando un desarrollador crea un nuevo usuario o concede permiso a una aplicación como herramienta para realizar una tarea. Por ejemplo, esto podría hacerse para recoger información de una base de datos. Pero si los permisos para el nuevo usuario son demasiado altos, o no están configurados por defecto para la tarea en cuestión, puede introducir una grave vulnerabilidad en el código.

Antes de entrar en materia, ¿por qué no poner a prueba tus habilidades ahora mismo? Intenta encontrar y arreglar algunas vulnerabilidades de permisos inadecuados:

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

Dar a un usuario o a una aplicación todos los permisos, o simplemente no molestarse en definir lo que el nuevo usuario debe poder realizar y qué comportamientos están restringidos, es sin duda la forma más rápida de poner en marcha el nuevo código. Y si todo va perfectamente bien, la aplicación hará uso de esos permisos para llevar a cabo su tarea asignada. El peligro es que un hacker descubra este proceso y luego comprometa a ese usuario. Aunque el usuario fue creado para cumplir una función específica para una aplicación concreta, si se ve comprometido puede permitir a un atacante poner en peligro otras aplicaciones, datos o incluso la red.

¿Cómo se aprovechan los fallos de seguridad?

Para visualizar el peligro, echemos un vistazo a cómo se codifica a veces una tarea común dentro del entorno de la nube de Docker. Digamos que un desarrollador está utilizando el servicio Prometheus MySQL Exporter para recoger información de una base de datos. La forma más fácil de permitir que eso ocurra es conceder al exportador permiso para acceder a la base de datos. Así que el código podría ser algo como

FROM mysql:latest
COPY ./scripts/create_users.sh /docker-entrypoint-initdb.d/
USER 999
CREATE USER exporter@% IDENTIFIED BY $EXPORTER_PASSWORD;
GRANT ALL ON *.* TO exporter@%;
GRANT SELECT ON performance_schema.* TO exporter@%;

Esto ciertamente haría que el exportador pudiera cumplir con su tarea. Sin embargo, como los permisos no están definidos, el exportador tiene realmente 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 fuera capaz de comprometer el servicio del exportador? En ese caso, como se le han dado todos los permisos, el atacante podría realizar todo tipo de tareas no autorizadas con el servicio SQL.

Asegurar y eliminar los permisos indebidos

También en este caso, recurrimos al concepto de infraestructura como código. Si se codifica la seguridad en las aplicaciones a medida que se crean, la red siempre estará en una posición mucho mejor en lo que respecta a la ciberseguridad.

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

FROM mysql:latest
COPY ./scripts/create_users.sh /docker-entrypoint-initdb.d/
USER 999
CREATE USER exporter@% IDENTIFIED BY $EXPORTER_PASSWORD;
GRANT PROCESS, REPLICATION CLIENT ON *.* TO exporter@%;
GRANT SELECT ON performance_schema.* TO exporter@%;

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

La restricción de los permisos a nivel de código puede garantizar que los usuarios y las aplicaciones sólo tengan los permisos necesarios para la tarea en cuestión. Y eso puede contribuir en gran medida a asegurar sus redes y a adoptar el concepto de infraestructura como código.

Consulte las páginas del Secure Code Warrior 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 otros fallos de seguridad. También puede probar nuestro escaparate de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.