[20/04/2023] Cuando muchos de nosotros trasladamos nuestras necesidades de servidor y aplicaciones a la nube, nos regocijamos de ya no tener que preocuparnos por la monotonía de aplicar parches. No tuvimos que monitorear los servidores y sus implementaciones de Patch Tuesday; todo estaba en manos de Microsoft. Pero como suele ocurrir con las implementaciones en la nube, una solución que significa que ya no tiene que preocuparse por un área puede crear problemas de seguridad en otras.
Una y otra vez, en el manejo de cualquier implementación en la nube, la forma en que administramos la identidad y la autenticación debe revisarse de forma programada para garantizar que la seguridad de los activos en la nube se maneje de acuerdo con la última guía recomendada. En el peor de los casos, los atacantes se enteran primero y no nos informan para tomar medidas. En el mejor de los casos, los investigadores encuentran una falla y trabajan con los proveedores para ayudarnos a todos a tomar mejores decisiones de seguridad -Orca Security señaló recientemente dicha falla.
Orca, que revisa constantemente las configuraciones incorrectas y las vulnerabilidades de la nube, descubrió que podía abusar de las claves de cuenta de Azure Storage y usar la vulnerabilidad para obtener acceso completo a las cuentas de almacenamiento e incluso moverse lateralmente dentro de la nube. Como señala Orca en su blog, puede ser demasiado fácil configurar una cuenta de almacenamiento y activos comerciales críticos con esta autorización de clave compartida, mientras se otorgan privilegios a los administradores, que no los necesitan, inadvertidamente.
La clave compartida está habilitada de forma predeterminada
Si bien Microsoft afirma en su documentación que el uso de la autorización de clave compartida no es ideal y recomienda usar Azure Active Directory, que proporciona una seguridad superior, la autorización de clave compartida todavía está habilitada de forma predeterminada al crear cuentas de almacenamiento. Los administradores solo deben tener derechos sobre aquellos activos a los que explícitamente necesitan acceso. En este caso, la vulnerabilidad puede surgir si DevOps tiene la capacidad de obtener el permiso de Azure listKeys.
El usuario que tiene permiso para acceder a "Microsoft.Storage/storageAccounts/listkeys/action” no tiene acceso a los datos. Sin embargo, la acción otorga acceso a las claves y luego se puede acceder a los datos con las claves; de ahí la exposición al riesgo cuando se usa la autorización de clave compartida y no la autorización a través de OAuth/Azure AD.
Con demasiada frecuencia, en las implementaciones en la nube, uno hace que su proyecto funcione y tome la forma potencialmente más fácil de configurar algo. Uno no regresa y lee la guía que indica:
"No se recomienda la autorización con clave compartida, ya que puede ser menos segura. Para lograr una seguridad óptima, deshabilite la autorización a través de clave compartida para su cuenta de almacenamiento, como se describe en Impedir la autorización de clave compartida para una cuenta de Azure Storage. El uso de claves de acceso y cadenas de conexión debe limitarse a aplicaciones de prueba de concepto iniciales o prototipos de desarrollo que no acceden a datos confidenciales o de producción. De lo contrario, las clases de autenticación basadas en tokens disponibles en el SDK de Azure siempre deben preferirse al autenticarse en los recursos de Azure. Microsoft recomienda que los clientes usen Azure AD o una firma de acceso compartido (SAS) para autorizar el acceso a los datos en Azure Storage. Para obtener más información, consulte Autorizar operaciones para el acceso a datos”.
Como la documentación establece además:
"Cuando intenta acceder a los datos del blob, Azure Portal primero comprueba si se le ha asignado un rol de Azure con Microsoft.Storage/storageAccounts/listkeys/action. Si se le asignó un rol con esta acción, Azure Portal usa la clave de la cuenta para acceder a los datos del blob a través de la autorización de clave compartida. Si no se le ha asignado un rol con esta acción, Azure Portal intenta acceder a los datos mediante su cuenta de Azure AD”.
Los atacantes ya han demostrado que se dirigirán a administradores y DevOps para obtener acceso a recursos clave. Dirigirse a un desarrollador que trabaja de forma remota y que usa la computadora de su hogar para conectarse a los activos de la empresa es un medio clave para obtener credenciales y secretos corporativos.
El acceso con Shared Key puede dejar la puerta abierta para los intrusos
Dirigiéndose a los usuarios que tienen derechos Listkeys, el atacante puede identificar estas claves compartidas y pasar a acceder a esos recursos. Piense en términos de que un atacante no tiene la llave de la puerta de su casa, pero sabe dónde ha escondido la llave secreta: debajo del felpudo. El resultado final es que el atacante puede ingresar directamente, acceder a sus datos y usarlos para la infiltración corporativa o notificarle el acceso y exigir un rescate para no destruir los datos. Como señala Orca, pasar de simplemente leer las claves compartidas a realizar un aumento de privilegios de suscripción puede ser trivial para el atacante.
Si es como muchos clientes de Azure, es posible que haya configurado su organización hace años y no esté realmente seguro de cuál será el impacto de trasladar toda su autenticación a la implementación más segura de Azure Active Directory. Podría llevar tiempo y pruebas que tal vez no tenga. Por lo tanto, es posible que deba implementar una revisión de seguridad de sus activos de Azure que no solo revise este riesgo de autorización de clave compartida, sino también otras configuraciones potenciales que pueden causar problemas adicionales en el futuro.
Revise la guía de Microsoft
Revise la guía para otorgar acceso al almacenamiento de Azure y considere soluciones adicionales que supervisen el mal uso del acceso. Orca tiene específicamente un servicio para monitorear actividad inusual en el permiso de acción Microsoft.Storage/storageAccounts/listKeys/action para que pueda recibir alertas en caso de que alguien empiece a abusar de los derechos.
Revise aquellos usuarios/administradores que tienen derechos de blobs de Azure. ¿Todavía necesitan ese derecho? ¿Se han trasladado a otros roles y deberes? ¿Deberían tener derechos sobre ese lugar de almacenamiento? ¿Cuál es el mínimo de derechos que cada DevOps necesita para hacer su trabajo, pero sin poner en riesgo indebido a la organización? Asigne a alguien para que realice revisiones periódicas de la guía de mejores prácticas y determine si su organización todavía la cumple.
La confianza cero y los privilegios mínimos son conceptos clave que se enfatizan cada vez más como una solución, no solo en las instalaciones tradicionales on premise, sino también en los activos de la nube. Desde los usuarios hasta los recursos, la asignación de roles debe otorgarse y comprenderse explícitamente -los atacantes no deben saber más que usted sobre su organización y cómo acceder a sus datos.
Basado en el artículo de Susan Bradley (CSO) y editado por CIO Perú