Serie Coders Conquer Security Infrastructure as Code: Control de acceso a nivel de función faltante

Es hora de la siguiente entrega de nuestra serie sobre Infraestructura como Código, los blogs que llevarán a desarrolladores como tú a un nivel completamente nuevo de conciencia sobre seguridad al implementar infraestructura segura dentro de tu propia organización.

Por cierto... ¿cómo te fue con el desafío de configuración de seguridad incorrecta del blog anterior? Si quieres seguir adelante y enfrentarte a una vulnerabilidad de falta de control de acceso a nivel funcional ahora mismo, dirígete a la plataforma:

(El enlace anterior te llevará al desafío de Kubernetes, pero una vez en la plataforma, usa el menú desplegable para elegir también entre Ansible, CloudFormation, Terraform o Docker. Tú eliges.)

Casi todas las aplicaciones implementadas hoy en día cuentan con algún tipo de mecanismo de control de acceso que verifica 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, al crear una aplicación. De hecho, todas las aplicaciones web necesitan controles de acceso para permitir que usuarios con diferentes privilegios utilicen el programa.

Sin embargo, pueden surgir 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. Si el control de acceso a nivel de infraestructura no está perfectamente configurado, toda la empresa queda expuesta a hackers que pueden utilizar esa vulnerabilidad como puerta de entrada para el espionaje no autorizado o un ataque completo.

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

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

Existen varias formas en las que los controles de acceso a nivel de función pueden infiltrarse en una organización. Por ejemplo, el acceso a nivel de función puede dejarse en manos de la 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 infraestructura que solo los usuarios de mayor nivel deberían poder ver y utilizar, un modelo de "seguridad por oscuridad" que rara vez funciona.

Como ejemplo de seguridad por oscuridad, la siguiente URL es probablemente vulnerable a ataques:

http://companywebsite.com/app/NormalUserHomepage

Si un usuario autenticado emplea una técnica llamada navegación forzada por 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 una verificación del lado del servidor, simplemente se le mostrarán las páginas de administración (si el nombre coincide con la solicitud) y tendrá acceso a cualquier función adicional que los administradores realicen desde esa nueva página. Si el servidor devuelve un error de "página no encontrada" al atacante, este puede seguir intentándolo hasta que descubra el nombre que se le ha dado a la página de administración.

Para los atacantes, explotar la falta de controles de acceso a nivel de función 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 se vería más o menos así, dependiendo del marco de trabajo:

POST/action/createuser name=hacker&pw=password&role=admin

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

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

Dado que es muy fácil para los atacantes explotar las vulnerabilidades de falta de control de acceso a nivel de función, es fundamental detectarlas, corregirlas y prevenirlas. Afortunadamente, esto no es demasiado difícil con los conocimientos adecuados y una formación básica en seguridad de Infraestructura como Código.

La protección principal vendrá de implementar 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 pase nada por alto. Idealmente, la autorización debe provenir de una ubicación centralizada (por ejemplo, AWS IAM, Azure IAM, etc.) que esté integrada en la rutina de su organización y aplicada a cada nueva aplicación. Estos procesos de autorización pueden provenir del propio marco de trabajo o de cualquier cantidad de módulos externos fáciles de usar.

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

Tener controles de acceso a nivel de función faltantes puede ser devastador. Pero, afortunadamente, al integrar buenas prácticas de autorización a nivel de infraestructura en su organización, puede evitar fácilmente que este problema ocurra.

¿Cree que está listo para detectar un error de control de acceso en un entorno real? Compare estos fragmentos de código de Docker; uno vulnerable y otro seguro:

Vulnerable:

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER root
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

Seguro:

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER nobody
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

Aprenda más, póngase a prueba

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 y vulnerabilidades de seguridad.

Y si se lo perdió antes, puede probar un desafío de seguridad gamificado de IaC en la plataforma de Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.

¡Esté atento al próximo capítulo!