Los programadores conquistan la infraestructura de seguridad como serie de códigos: falta el control de acceso a nivel de función

Ha llegado el momento de la próxima entrega de nuestra serie Infrastructure as Code, los blogs que llevarán a los desarrolladores como usted a un nivel completamente nuevo de conciencia de seguridad al implementar una infraestructura segura en su propia organización.

Ah, por cierto... ¿cómo te fue con el desafío de mala configuración de seguridad del blog anterior? Si quieres abordar ahora mismo una vulnerabilidad de control de acceso a nivel funcional que falta, dirígete a la plataforma:

(El enlace de arriba lo llevará al desafío de Kubernetes, pero una vez que esté en la plataforma, use el menú desplegable para elegir también entre Ansible, CloudFormation, Terraform o Docker. Tu elección.)

Casi todas las aplicaciones implementadas en la actualidad tienen algún tipo de mecanismo de control de acceso que comprueba si un usuario tiene permiso para realizar las funciones solicitadas. Es prácticamente la piedra angular de una buena seguridad, así como de la funcionalidad, a la hora de crear una aplicación. De hecho, todas las aplicaciones web necesitan controles de acceso para permitir a los usuarios con diferentes privilegios utilizar el programa.

Sin embargo, pueden producirse problemas cuando esas mismas funciones de verificación para el control de acceso no se realizan a nivel de infraestructura o están mal configuradas. Sin un control de acceso a nivel de infraestructura en perfecto orden, los piratas informáticos pueden utilizar esa vulnerabilidad como puerta de entrada para espiar sin autorización o atacar a toda costa.

De hecho, aprovechar las vulnerabilidades de control de acceso a las funciones faltantes o mal configuradas es extremadamente fácil. Los atacantes ni siquiera necesitan ser demasiado hábiles. Solo necesitan saber qué comandos ejecutan funciones dentro del marco que soporte la aplicación. Si lo hacen, es solo cuestión de prueba y error. Pueden enviar continuamente solicitudes que no deberían permitirse y, tan pronto como una tenga éxito, el sitio web, la aplicación, el servidor o incluso toda la red de destino podrían quedar expuestos.

¿Cómo funcionan los exploits de control de acceso a nivel de función faltantes?

Hay varias maneras en las que los controles de acceso a nivel funcional pueden introducirse en una organización. Por ejemplo, el acceso a nivel de función puede dejarse en manos de una aplicación y no ser verificado por la infraestructura subyacente. O bien, el control de acceso a nivel de infraestructura puede estar mal configurado. En algunos casos, los administradores asumen que los usuarios no autorizados no sabrán cómo acceder a los recursos de la infraestructura que solo los usuarios de nivel superior deberían poder ver y utilizan un modelo de «seguridad por oscuridad» que rara vez funciona.

Como ejemplo de seguridad por oscuridad, es probable que la siguiente URL sea vulnerable a los ataques:

http://companywebsite.com/app/NormalUserHomepage

Si un usuario autenticado emplea una técnica denominada Navegación forzada de URL, podría intentar acceder a una página que solo se muestra a los administradores. Un ejemplo podría ser:

http://companywebsite.com/app/AdminPages

Si no existe ninguna verificación del lado del servidor, simplemente se les mostrarán las páginas de administración (si su nombre coincide con la solicitud) y, a continuación, tendrán acceso a las funciones adicionales que los administradores realicen desde la nueva página. Si el servidor muestra el error «página no encontrada», el atacante puede seguir intentándolo hasta que averigüe el nombre que se le ha dado a la página de administración.

Para los atacantes, explotar controles de acceso a nivel de función faltantes es un proceso similar. En lugar de intentar navegar por páginas no autorizadas, envían solicitudes de funciones. Por ejemplo, podrían intentar crear un nuevo usuario con derechos de administrador. Por lo tanto, su solicitud tendría un aspecto similar al siguiente, según el marco:

Publicar/Acción/Crear nombre de usuario = hacker&pw=contraseña&role=admin

Si no existe ningún control de acceso a nivel de función, el ejemplo anterior se ejecutará correctamente y se creará una nueva cuenta de administrador. Una vez que el atacante vuelva a iniciar sesión como nuevo administrador, tendrá el mismo acceso y permisos que cualquier otro administrador de esa red o servidor.

La solución para los controles de acceso a nivel de función faltantes

Dado que es tan fácil para los atacantes aprovechar las vulnerabilidades de control de acceso a nivel de función que faltan, es fundamental que las encuentren, las solucionen y las prevengan. Afortunadamente, esto no es demasiado difícil con algunos conocimientos técnicos e infraestructuras básicas como Formación sobre seguridad de códigos.

La protección principal provendrá de la implementación de la autorización basada en roles a nivel de infraestructura. Nunca confíe en las aplicaciones para gestionar esa función. Incluso si lo hacen, contar con una autorización del lado de la infraestructura garantizará que no se pierda nada. Lo ideal es que la autorización provenga de una ubicación centralizada (por ejemplo, AWS IAM, Azure IAM, etc.) integrada en la rutina de la organización y que se aplique a cada nueva aplicación. Estos procesos de autorización pueden provenir del propio marco o de cualquier número de módulos externos fáciles de usar.

Por último, su organización debe adoptar el concepto de privilegio mínimo. Todas las acciones y funciones deben denegarse de forma predeterminada, y el proceso de autorización debe utilizarse para conceder a los usuarios válidos permiso para hacer lo que necesiten. Solo se les debe conceder el permiso suficiente para realizar la función requerida y solo durante el tiempo que sea necesario.

La falta de controles de acceso a nivel funcional puede ser devastador. Pero, afortunadamente, al incorporar buenas prácticas de autorización a nivel de infraestructura en su organización, puede evitar fácilmente que este problema se produzca.

¿Crees que estás listo para detectar un error de control de acceso en la naturaleza? Compara estos fragmentos de código de Docker: uno vulnerable y otro seguro:

Vulnérable :

DE quay.io/prometheus/busybox:último
VERSIÓN ARG = 0.12.1
Nombre de archivo ARG=mysqld_exporter-$ {VERSIÓN} .linux-amd64
URL de ARG = https://github.com/prometheus/mysqld_exporter/releases/download/v
EJECUTE wget $URL$version/$fileName.tar.gz &&\
tar -xvf $nombrearchivo.tar.gz &&\
mv $nombre_archivo/mysqld_exporter /bin/mysqld_exporter
COPIAR .my.cnf /home/.my.cnf
COPIAR. /scripts/entrypoint.sh ~/entrypoint.sh
USUARIO root
EXPONER 9104
PUNTO DE ENTRADA [«sh», "~/entrypoint.sh"]
CMD [«/bin/mysqld_exporter»]

Assurance :

DE quay.io/prometheus/busybox:último
VERSIÓN ARG = 0.12.1
Nombre de archivo ARG=mysqld_exporter-$ {VERSIÓN} .linux-amd64
URL de ARG = https://github.com/prometheus/mysqld_exporter/releases/download/v
EJECUTE wget $URL$version/$fileName.tar.gz &&\
tar -xvf $nombrearchivo.tar.gz &&\
mv $nombre_archivo/mysqld_exporter /bin/mysqld_exporter
COPIAR .my.cnf /home/.my.cnf
COPIAR. /scripts/entrypoint.sh ~/entrypoint.sh
USUARIO: nadie
EXPONER 9104
PUNTO DE ENTRADA [«sh», "~/entrypoint.sh"]
CMD [«/bin/mysqld_exporter»]

Obtenga más información, desafíese a sí mismo

Veuillez consulter le Secure Code Warrior pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients contre les conséquences d'autres failles et vulnérabilités de sécurité.

Y si te lo perdiste antes, puedes prueba un desafío de seguridad gamificado para iAC en la plataforma Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.

¡Estén atentos para el próximo capítulo!