Los codificadores conquistan la infraestructura de seguridad como serie de código: El control de acceso a nivel de función que falta
Ha llegado el momento de la siguiente 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 la seguridad a la hora de desplegar una infraestructura segura dentro de su propia organización.
Ah, por cierto... ¿cómo te fue con el reto de la desconfiguración de seguridad en el blog anterior? Si quieres seguir adelante y abordar una vulnerabilidad de control de acceso de nivel funcional que falta ahora mismo, dirígete a la plataforma:
(El enlace anterior le llevará al desafío de Kubernetes, pero una vez que esté en la plataforma, utilice el menú desplegable para elegir también entre Ansible, CloudFormation, Terraform o Docker. Tú eliges).
Casi todas las aplicaciones desplegadas hoy en día tienen algún tipo de mecanismo de control de acceso que comprueba si un usuario tiene o no permiso para realizar las funciones solicitadas. Es prácticamente la piedra angular de una buena seguridad, además de la funcionalidad, cuando se crea una aplicación. De hecho, todas las aplicaciones web necesitan controles de acceso para que usuarios con diferentes privilegios puedan utilizar 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 la infraestructura, o están mal configuradas. Sin un control de acceso a nivel de infraestructura en perfecto orden, se abre toda una empresa a los piratas informáticos, que pueden utilizar esa vulnerabilidad como su puerta de entrada para el fisgoneo no autorizado o un ataque completo.
De hecho, explotar las vulnerabilidades de control de acceso a funciones ausentes o mal configuradas es extremadamente fácil. Los atacantes ni siquiera necesitan ser demasiado hábiles. Sólo necesitan saber qué comandos ejecutan funciones dentro de cualquier marco que soporte la aplicación. Si lo saben, es sólo una cuestión de prueba y error. Pueden enviar continuamente peticiones que no deberían estar permitidas, y en cuanto una de ellas tenga éxito, el sitio web, la aplicación, el servidor o incluso toda la red en cuestión podrían quedar expuestos.
¿Cómo funcionan los exploits de control de acceso a nivel de funciones faltantes?
Hay algunas formas en las que los controles de acceso a nivel de función pueden colarse 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 llegar a los recursos de la infraestructura que sólo los usuarios de nivel superior deberían poder ver y utilizan un modelo de "seguridad por oscuridad" que rara vez funciona.
Para un ejemplo de seguridad por oscuridad, la siguiente URL es probablemente vulnerable a un ataque:
http://companywebsite.com/app/NormalUserHomepage
Si un usuario autentificado emplea una técnica llamada Forced URL Browsing, podría intentar llegar a una página que sólo 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 les mostrará la página de administración (si su nombre coincide con la solicitud) y entonces tendrán acceso a cualquier función adicional que los administradores hagan desde la nueva página. Si el servidor devuelve un error de "página no encontrada" al atacante, éste puede simplemente seguir intentándolo hasta que descubra el nombre de 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. Así que su solicitud sería algo 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, entonces 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 a la falta de controles de acceso a nivel de función
Debido a que es tan fácil para los atacantes explotar las vulnerabilidades de control de acceso a nivel de funciones faltantes, es crítico que se encuentren, se arreglen y se prevengan. Afortunadamente, esto no es excesivamente difícil con algunos conocimientos y una formación básica en seguridad de la Infraestructura como Código.
La principal protección vendrá de la implementación de la autorización basada en roles a nivel de infraestructura. Nunca confíes en que las aplicaciones se encarguen de esa función. Incluso si lo hacen, tener una autorización del lado de la infraestructura garantizará que no se pierda nada. Lo ideal es que la autorización provenga de un lugar centralizado (por ejemplo, AWS IAM, Azure IAM, etc.) que se incorpore a la rutina de su organización y se aplique a cada nueva aplicación. Estos procesos de autorización pueden provenir del propio framework o de cualquier número de módulos externos fáciles de usar.
Por último, su organización debería adoptar el concepto de mínimo privilegio. Todas las acciones y funciones deben ser denegadas por defecto, y el proceso de autorización debe utilizarse para dar a los usuarios válidos permiso para hacer lo que necesiten. Sólo se les debe dar el permiso suficiente para realizar la función requerida, y sólo durante el tiempo necesario.
La falta de controles de acceso a nivel de función puede ser devastadora. Pero, afortunadamente, si incorpora a su organización buenas prácticas de autorización a nivel de infraestructura, puede evitar fácilmente que este problema se produzca.
¿Crees que estás preparado para detectar un error de control de acceso en la naturaleza? Compara 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" ]
Aprende más, desafíate a ti mismo
Consulte las páginas del Secure Code Warrior páginas del 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 otros fallos y vulnerabilidades de seguridad.
Y si te lo perdiste antes, puedes probar un reto de seguridad gamificado de IaC en la plataforma Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.
Estén atentos al próximo capítulo.
Sin un control de acceso a nivel de infraestructura en perfecto orden, se abre toda una empresa a los atacantes, que pueden utilizar esa vulnerabilidad como puerta de entrada para el fisgoneo no autorizado o para un ataque completo.
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostración
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
Ha llegado el momento de la siguiente 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 la seguridad a la hora de desplegar una infraestructura segura dentro de su propia organización.
Ah, por cierto... ¿cómo te fue con el reto de la desconfiguración de seguridad en el blog anterior? Si quieres seguir adelante y abordar una vulnerabilidad de control de acceso de nivel funcional que falta ahora mismo, dirígete a la plataforma:
(El enlace anterior le llevará al desafío de Kubernetes, pero una vez que esté en la plataforma, utilice el menú desplegable para elegir también entre Ansible, CloudFormation, Terraform o Docker. Tú eliges).
Casi todas las aplicaciones desplegadas hoy en día tienen algún tipo de mecanismo de control de acceso que comprueba si un usuario tiene o no permiso para realizar las funciones solicitadas. Es prácticamente la piedra angular de una buena seguridad, además de la funcionalidad, cuando se crea una aplicación. De hecho, todas las aplicaciones web necesitan controles de acceso para que usuarios con diferentes privilegios puedan utilizar 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 la infraestructura, o están mal configuradas. Sin un control de acceso a nivel de infraestructura en perfecto orden, se abre toda una empresa a los piratas informáticos, que pueden utilizar esa vulnerabilidad como su puerta de entrada para el fisgoneo no autorizado o un ataque completo.
De hecho, explotar las vulnerabilidades de control de acceso a funciones ausentes o mal configuradas es extremadamente fácil. Los atacantes ni siquiera necesitan ser demasiado hábiles. Sólo necesitan saber qué comandos ejecutan funciones dentro de cualquier marco que soporte la aplicación. Si lo saben, es sólo una cuestión de prueba y error. Pueden enviar continuamente peticiones que no deberían estar permitidas, y en cuanto una de ellas tenga éxito, el sitio web, la aplicación, el servidor o incluso toda la red en cuestión podrían quedar expuestos.
¿Cómo funcionan los exploits de control de acceso a nivel de funciones faltantes?
Hay algunas formas en las que los controles de acceso a nivel de función pueden colarse 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 llegar a los recursos de la infraestructura que sólo los usuarios de nivel superior deberían poder ver y utilizan un modelo de "seguridad por oscuridad" que rara vez funciona.
Para un ejemplo de seguridad por oscuridad, la siguiente URL es probablemente vulnerable a un ataque:
http://companywebsite.com/app/NormalUserHomepage
Si un usuario autentificado emplea una técnica llamada Forced URL Browsing, podría intentar llegar a una página que sólo 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 les mostrará la página de administración (si su nombre coincide con la solicitud) y entonces tendrán acceso a cualquier función adicional que los administradores hagan desde la nueva página. Si el servidor devuelve un error de "página no encontrada" al atacante, éste puede simplemente seguir intentándolo hasta que descubra el nombre de 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. Así que su solicitud sería algo 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, entonces 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 a la falta de controles de acceso a nivel de función
Debido a que es tan fácil para los atacantes explotar las vulnerabilidades de control de acceso a nivel de funciones faltantes, es crítico que se encuentren, se arreglen y se prevengan. Afortunadamente, esto no es excesivamente difícil con algunos conocimientos y una formación básica en seguridad de la Infraestructura como Código.
La principal protección vendrá de la implementación de la autorización basada en roles a nivel de infraestructura. Nunca confíes en que las aplicaciones se encarguen de esa función. Incluso si lo hacen, tener una autorización del lado de la infraestructura garantizará que no se pierda nada. Lo ideal es que la autorización provenga de un lugar centralizado (por ejemplo, AWS IAM, Azure IAM, etc.) que se incorpore a la rutina de su organización y se aplique a cada nueva aplicación. Estos procesos de autorización pueden provenir del propio framework o de cualquier número de módulos externos fáciles de usar.
Por último, su organización debería adoptar el concepto de mínimo privilegio. Todas las acciones y funciones deben ser denegadas por defecto, y el proceso de autorización debe utilizarse para dar a los usuarios válidos permiso para hacer lo que necesiten. Sólo se les debe dar el permiso suficiente para realizar la función requerida, y sólo durante el tiempo necesario.
La falta de controles de acceso a nivel de función puede ser devastadora. Pero, afortunadamente, si incorpora a su organización buenas prácticas de autorización a nivel de infraestructura, puede evitar fácilmente que este problema se produzca.
¿Crees que estás preparado para detectar un error de control de acceso en la naturaleza? Compara 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" ]
Aprende más, desafíate a ti mismo
Consulte las páginas del Secure Code Warrior páginas del 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 otros fallos y vulnerabilidades de seguridad.
Y si te lo perdiste antes, puedes probar un reto de seguridad gamificado de IaC en la plataforma Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.
Estén atentos al próximo capítulo.
Ha llegado el momento de la siguiente 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 la seguridad a la hora de desplegar una infraestructura segura dentro de su propia organización.
Ah, por cierto... ¿cómo te fue con el reto de la desconfiguración de seguridad en el blog anterior? Si quieres seguir adelante y abordar una vulnerabilidad de control de acceso de nivel funcional que falta ahora mismo, dirígete a la plataforma:
(El enlace anterior le llevará al desafío de Kubernetes, pero una vez que esté en la plataforma, utilice el menú desplegable para elegir también entre Ansible, CloudFormation, Terraform o Docker. Tú eliges).
Casi todas las aplicaciones desplegadas hoy en día tienen algún tipo de mecanismo de control de acceso que comprueba si un usuario tiene o no permiso para realizar las funciones solicitadas. Es prácticamente la piedra angular de una buena seguridad, además de la funcionalidad, cuando se crea una aplicación. De hecho, todas las aplicaciones web necesitan controles de acceso para que usuarios con diferentes privilegios puedan utilizar 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 la infraestructura, o están mal configuradas. Sin un control de acceso a nivel de infraestructura en perfecto orden, se abre toda una empresa a los piratas informáticos, que pueden utilizar esa vulnerabilidad como su puerta de entrada para el fisgoneo no autorizado o un ataque completo.
De hecho, explotar las vulnerabilidades de control de acceso a funciones ausentes o mal configuradas es extremadamente fácil. Los atacantes ni siquiera necesitan ser demasiado hábiles. Sólo necesitan saber qué comandos ejecutan funciones dentro de cualquier marco que soporte la aplicación. Si lo saben, es sólo una cuestión de prueba y error. Pueden enviar continuamente peticiones que no deberían estar permitidas, y en cuanto una de ellas tenga éxito, el sitio web, la aplicación, el servidor o incluso toda la red en cuestión podrían quedar expuestos.
¿Cómo funcionan los exploits de control de acceso a nivel de funciones faltantes?
Hay algunas formas en las que los controles de acceso a nivel de función pueden colarse 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 llegar a los recursos de la infraestructura que sólo los usuarios de nivel superior deberían poder ver y utilizan un modelo de "seguridad por oscuridad" que rara vez funciona.
Para un ejemplo de seguridad por oscuridad, la siguiente URL es probablemente vulnerable a un ataque:
http://companywebsite.com/app/NormalUserHomepage
Si un usuario autentificado emplea una técnica llamada Forced URL Browsing, podría intentar llegar a una página que sólo 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 les mostrará la página de administración (si su nombre coincide con la solicitud) y entonces tendrán acceso a cualquier función adicional que los administradores hagan desde la nueva página. Si el servidor devuelve un error de "página no encontrada" al atacante, éste puede simplemente seguir intentándolo hasta que descubra el nombre de 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. Así que su solicitud sería algo 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, entonces 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 a la falta de controles de acceso a nivel de función
Debido a que es tan fácil para los atacantes explotar las vulnerabilidades de control de acceso a nivel de funciones faltantes, es crítico que se encuentren, se arreglen y se prevengan. Afortunadamente, esto no es excesivamente difícil con algunos conocimientos y una formación básica en seguridad de la Infraestructura como Código.
La principal protección vendrá de la implementación de la autorización basada en roles a nivel de infraestructura. Nunca confíes en que las aplicaciones se encarguen de esa función. Incluso si lo hacen, tener una autorización del lado de la infraestructura garantizará que no se pierda nada. Lo ideal es que la autorización provenga de un lugar centralizado (por ejemplo, AWS IAM, Azure IAM, etc.) que se incorpore a la rutina de su organización y se aplique a cada nueva aplicación. Estos procesos de autorización pueden provenir del propio framework o de cualquier número de módulos externos fáciles de usar.
Por último, su organización debería adoptar el concepto de mínimo privilegio. Todas las acciones y funciones deben ser denegadas por defecto, y el proceso de autorización debe utilizarse para dar a los usuarios válidos permiso para hacer lo que necesiten. Sólo se les debe dar el permiso suficiente para realizar la función requerida, y sólo durante el tiempo necesario.
La falta de controles de acceso a nivel de función puede ser devastadora. Pero, afortunadamente, si incorpora a su organización buenas prácticas de autorización a nivel de infraestructura, puede evitar fácilmente que este problema se produzca.
¿Crees que estás preparado para detectar un error de control de acceso en la naturaleza? Compara 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" ]
Aprende más, desafíate a ti mismo
Consulte las páginas del Secure Code Warrior páginas del 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 otros fallos y vulnerabilidades de seguridad.
Y si te lo perdiste antes, puedes probar un reto de seguridad gamificado de IaC en la plataforma Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.
Estén atentos al próximo capítulo.
Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostración
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
Ha llegado el momento de la siguiente 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 la seguridad a la hora de desplegar una infraestructura segura dentro de su propia organización.
Ah, por cierto... ¿cómo te fue con el reto de la desconfiguración de seguridad en el blog anterior? Si quieres seguir adelante y abordar una vulnerabilidad de control de acceso de nivel funcional que falta ahora mismo, dirígete a la plataforma:
(El enlace anterior le llevará al desafío de Kubernetes, pero una vez que esté en la plataforma, utilice el menú desplegable para elegir también entre Ansible, CloudFormation, Terraform o Docker. Tú eliges).
Casi todas las aplicaciones desplegadas hoy en día tienen algún tipo de mecanismo de control de acceso que comprueba si un usuario tiene o no permiso para realizar las funciones solicitadas. Es prácticamente la piedra angular de una buena seguridad, además de la funcionalidad, cuando se crea una aplicación. De hecho, todas las aplicaciones web necesitan controles de acceso para que usuarios con diferentes privilegios puedan utilizar 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 la infraestructura, o están mal configuradas. Sin un control de acceso a nivel de infraestructura en perfecto orden, se abre toda una empresa a los piratas informáticos, que pueden utilizar esa vulnerabilidad como su puerta de entrada para el fisgoneo no autorizado o un ataque completo.
De hecho, explotar las vulnerabilidades de control de acceso a funciones ausentes o mal configuradas es extremadamente fácil. Los atacantes ni siquiera necesitan ser demasiado hábiles. Sólo necesitan saber qué comandos ejecutan funciones dentro de cualquier marco que soporte la aplicación. Si lo saben, es sólo una cuestión de prueba y error. Pueden enviar continuamente peticiones que no deberían estar permitidas, y en cuanto una de ellas tenga éxito, el sitio web, la aplicación, el servidor o incluso toda la red en cuestión podrían quedar expuestos.
¿Cómo funcionan los exploits de control de acceso a nivel de funciones faltantes?
Hay algunas formas en las que los controles de acceso a nivel de función pueden colarse 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 llegar a los recursos de la infraestructura que sólo los usuarios de nivel superior deberían poder ver y utilizan un modelo de "seguridad por oscuridad" que rara vez funciona.
Para un ejemplo de seguridad por oscuridad, la siguiente URL es probablemente vulnerable a un ataque:
http://companywebsite.com/app/NormalUserHomepage
Si un usuario autentificado emplea una técnica llamada Forced URL Browsing, podría intentar llegar a una página que sólo 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 les mostrará la página de administración (si su nombre coincide con la solicitud) y entonces tendrán acceso a cualquier función adicional que los administradores hagan desde la nueva página. Si el servidor devuelve un error de "página no encontrada" al atacante, éste puede simplemente seguir intentándolo hasta que descubra el nombre de 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. Así que su solicitud sería algo 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, entonces 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 a la falta de controles de acceso a nivel de función
Debido a que es tan fácil para los atacantes explotar las vulnerabilidades de control de acceso a nivel de funciones faltantes, es crítico que se encuentren, se arreglen y se prevengan. Afortunadamente, esto no es excesivamente difícil con algunos conocimientos y una formación básica en seguridad de la Infraestructura como Código.
La principal protección vendrá de la implementación de la autorización basada en roles a nivel de infraestructura. Nunca confíes en que las aplicaciones se encarguen de esa función. Incluso si lo hacen, tener una autorización del lado de la infraestructura garantizará que no se pierda nada. Lo ideal es que la autorización provenga de un lugar centralizado (por ejemplo, AWS IAM, Azure IAM, etc.) que se incorpore a la rutina de su organización y se aplique a cada nueva aplicación. Estos procesos de autorización pueden provenir del propio framework o de cualquier número de módulos externos fáciles de usar.
Por último, su organización debería adoptar el concepto de mínimo privilegio. Todas las acciones y funciones deben ser denegadas por defecto, y el proceso de autorización debe utilizarse para dar a los usuarios válidos permiso para hacer lo que necesiten. Sólo se les debe dar el permiso suficiente para realizar la función requerida, y sólo durante el tiempo necesario.
La falta de controles de acceso a nivel de función puede ser devastadora. Pero, afortunadamente, si incorpora a su organización buenas prácticas de autorización a nivel de infraestructura, puede evitar fácilmente que este problema se produzca.
¿Crees que estás preparado para detectar un error de control de acceso en la naturaleza? Compara 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" ]
Aprende más, desafíate a ti mismo
Consulte las páginas del Secure Code Warrior páginas del 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 otros fallos y vulnerabilidades de seguridad.
Y si te lo perdiste antes, puedes probar un reto de seguridad gamificado de IaC en la plataforma Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.
Estén atentos al próximo capítulo.
Índice
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Panorama de la gestión de riesgos de los promotores
La gestión de riesgos del desarrollador es un enfoque holístico y proactivo de la seguridad de las aplicaciones, centrado en quienes contribuyen al código y no en los bits y bytes de la propia capa de la aplicación.
Seguridad desde el diseño: Definición de las mejores prácticas, capacitación de los desarrolladores y evaluación comparativa de los resultados de la seguridad preventiva
En este documento de investigación, los cofundadores Secure Code Warrior , Pieter Danhieux y el Dr. Matias Madou, Ph.D., junto con los expertos colaboradores, Chris Inglis, ex Director Nacional Cibernético de EE.UU. (ahora Asesor Estratégico de Paladin Capital Group), y Devin Lynch, Director Senior, Paladin Global Institute, revelarán los hallazgos clave de más de veinte entrevistas en profundidad con líderes de seguridad empresarial, incluyendo CISOs, un VP de Seguridad de Aplicaciones y profesionales de seguridad de software.
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
Encontrar datos significativos sobre el éxito de las iniciativas Secure-by-Design es notoriamente difícil. Los responsables de la seguridad de la información se enfrentan a menudo al reto de demostrar el rendimiento de la inversión (ROI) y el valor empresarial de las actividades de los programas de seguridad, tanto a nivel de las personas como de la empresa. Por no mencionar que a las empresas les resulta especialmente difícil obtener información sobre cómo se comparan sus organizaciones con los estándares actuales del sector. La Estrategia Nacional de Ciberseguridad del Presidente desafió a las partes interesadas a "adoptar la seguridad y la resiliencia desde el diseño". La clave para que las iniciativas de seguridad por diseño funcionen no es sólo dotar a los desarrolladores de las habilidades necesarias para garantizar un código seguro, sino también garantizar a los reguladores que esas habilidades están en su lugar. En esta presentación, compartimos una miríada de datos cualitativos y cuantitativos, derivados de múltiples fuentes primarias, incluidos puntos de datos internos recogidos de más de 250.000 desarrolladores, opiniones de clientes basadas en datos y estudios públicos. Aprovechando esta agregación de puntos de datos, pretendemos comunicar una visión del estado actual de las iniciativas Secure-by-Design en múltiples verticales. El informe detalla por qué este espacio está actualmente infrautilizado, el impacto significativo que un programa de mejora de las competencias puede tener en la mitigación de los riesgos de ciberseguridad y el potencial para eliminar categorías de vulnerabilidades de un código base.
Servicios profesionales - Acelerar con experiencia
El equipo de servicios de estrategia de programas (PSS) de Secure Code Warriorle ayuda a crear, mejorar y optimizar su programa de codificación segura. Tanto si empieza de cero como si está perfeccionando su enfoque, nuestros expertos le proporcionarán orientación personalizada.
Recursos para empezar
Revelado: Cómo define el sector cibernético la seguridad por diseño
En nuestro último libro blanco, nuestros cofundadores, Pieter Danhieux y el doctor Matias Madou, se sentaron con más de veinte líderes de seguridad empresarial, incluidos CISO, líderes de AppSec y profesionales de la seguridad, para averiguar las piezas clave de este rompecabezas y descubrir la realidad detrás del movimiento Secure by Design. Se trata de una ambición compartida por todos los equipos de seguridad, pero no de un libro de jugadas compartido.
¿Vibe Coding va a convertir tu código en una fiesta de fraternidad?
Vibe Coding es como una fiesta de fraternidad universitaria, y la IA es la pieza central de todos los festejos, el barril. Es muy divertido dar rienda suelta a la creatividad y ver adónde te lleva tu imaginación, pero después de unas cuantas borracheras, beber (o usar IA) con moderación es, sin duda, la solución más segura a largo plazo.
Codificación orientada al desarrollador.
Con seguridad.
Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.
