Según Gartner, el mercado global de servicios de infraestructura en la nube creció un 30% en 2022, superando los 100 mil millones de dólares por primera vez. AWS y Azure representan casi dos tercios de este número. Si bien muchas organizaciones se benefician de estas plataformas, la popularidad de la nube también puede plantear importantes desafíos de seguridad. El hackeo ético de Azure y AWS por parte de expertos proporciona información importante sobre posibles vulnerabilidades y cómo los actores de amenazas pueden explotarlas. Este artículo proporciona una descripción general de los tipos más comunes de amenazas a la seguridad en la nube en AWS y Azure y cómo protegerse contra ellas desde la perspectiva de un profesional experimentado en seguridad ofensiva.
Amenazas a la seguridad en la nube en AWS y Azure
ataque de almacenamiento en la nube
Los ataques al almacenamiento en la nube son un desafío importante para las organizaciones, ya que tienen como objetivo datos y otros activos comerciales críticos. Un primer paso importante para que los evaluadores de penetración identifiquen dichas amenazas a la seguridad en la nube es verificar el acceso de usuarios no autenticados en los depósitos enumerados. La enumeración puede descubrir vínculos de firma de acceso compartido (SAS) de Azure. Para estos enlaces, los evaluadores de penetración comienzan con una estructura de URL de Azure similar que también incluye los parámetros “ss”, “srt”, “sp”, “se” y “sig” y la cargan a través de Azure Storage Explorer.
Un ejemplo de un enlace SAS de Azure es:
https://..core.windows.net/?ss=bfqt&srt=sco&sp=rwdlacup&se=2023-09-15T13:00:00Z&sip=88.208.222.83&sig=ACNA15d%2B%2BZSzPtPO71fMS34k%2FhLf2W13hjnamoGffIm%3D
Una defensa clave contra los ataques al almacenamiento en la nube es verificar los contenedores de su organización para asegurarse de que tengan los permisos adecuados. Asegúrese de que el cubo abierto esté abierto. Al utilizar SAS, también es importante asegurarse de que sus privilegios no sean demasiado amplios.
Spray de contraseña para cuentas de Azure/O365
Si está dentro del alcance, un probador de penetración puede usar spray de contraseña. Esto apunta a contraseñas de uso común, como contraseñas que incluyen estaciones o años (por ejemplo, “Verano2023”). Los evaluadores de penetración eligen los tipos de contraseñas que utilizarán los usuarios finales, como ¡Otoño2023!, ¡Otoño2023! y Septiembre2023. Luego, esta contraseña se aplica a cuentas válidas utilizando una herramienta como MSOLSPray o CredMaster.
Una capa de defensa eficaz contra estas amenazas a la seguridad de la nube en los entornos de AWS y Azure es implementar y mantener políticas de contraseñas sólidas respaldadas por la autenticación multifactor (MFA). Tenga en cuenta que los atacantes pueden difundir contraseñas lentamente incluso si utilizan direcciones IP diferentes para cada solicitud. ¿Cuál es apropiado para su organización en función de si es más probable que se produzcan ataques contra una gran cantidad de inicios de sesión fallidos desde una única IP o contra inicios de sesión exitosos desde la IP de su proveedor de servicios en la nube? ¿Implementar un mecanismo de detección?
Ingeniería social
Los atacantes a menudo intentan obtener credenciales y permisos mediante phishing, bishing o smishing de credenciales de usuario a servicios en la nube. Un ejemplo de esto es un ataque fraudulento de concesión de consentimiento en Azure. En este tipo de ataque, un actor de amenazas registra una aplicación multiinquilino en su inquilino. Las aplicaciones suelen estar configuradas para los permisos user.read y user.readbasic.all. Una vez que se otorga el consentimiento, el atacante puede obtener el token de acceso del usuario.
Las sesiones periódicas de formación y sensibilización para todos los empleados son elementos clave de la defensa contra el phishing. Garantice la detección mediante la reescritura de URL con protección de correo electrónico. Aplique análisis de comportamiento del usuario, registros de seguimiento de mensajes, registros de seguimiento de auditoría y más.
Implemente métodos de autenticación resistentes al phishing, como dispositivos inscritos Fast Identity Online (FIDO), especialmente para usuarios privilegiados. Paralelamente, revisar y actualizar las políticas del servicio de asistencia técnica de TI y los procedimientos de manejo de excepciones para combatir la autenticación multifactor (MFA) y los ataques de ingeniería social destinados a registrar o deshabilitar dispositivos no autorizados.
Para reducir su superficie de ataque, utilice políticas creativas de control de acceso condicional (CAC) como:
Si su política de dispositivos corporativos incluye solo dispositivos móviles de escritorio Windows y iOS, bloquee la autenticación para Android y MacBooks. Deshabilite o limite la variedad de métodos MFA permitidos, como SMS y aprobaciones de voz, y tipos de aplicaciones MFA no utilizadas. Considere bloquear o marcar intentos de autenticación y registros de regiones fuera del alcance de su organización. Limite la cantidad de dispositivos MFA permitidos por usuario y requiera factores de autenticación adicionales al aprobar dispositivos MFA. Verifique y reduzca la vida útil de los tokens de sesión e implemente una evaluación de acceso continuo (CAE) cuando esté disponible.
Para evitar de manera efectiva la concesión de consentimiento no autorizado, asegúrese de que las políticas de consentimiento de aplicaciones de su organización se administren de manera efectiva. Limite las aplicaciones a las que sus usuarios pueden dar consentimiento o desactívelas por completo. Las aplicaciones que dieron su consentimiento previamente conservarán ese consentimiento después del cambio.
Detecte eficazmente ataques de ingeniería social en la nube mediante:
Uso del Portal de Microsoft 365 Defender (si tiene licencia) Eliminación de todas las concesiones de consentimiento de Oauth Uso de AzureADPSPermissions.ps1
ataque a aplicaciones web
Los ataques tradicionales todavía pueden ocurrir en entornos de nube. Ejemplos incluyen:
Cargas de archivos inseguras, inyección de plantillas del lado del servidor (SSTI), ejecución remota de código (RCE), recorrido de ruta, falsificación de solicitudes del lado del servidor (SSRF)
Para identificar ataques SSRF en AWS, los pentesters buscan la capacidad de llamar a otro servidor o recurso local. En un caso reciente observado por Kroll, un actor de amenazas intentaba acceder a la API de metadatos a través de la siguiente URL: Esta URL proporciona AccessKeyId y SecretAccessKey para la cuenta subyacente utilizada por la aplicación web. En este ejemplo, un atacante puede obtener esta información simplemente utilizando la URL de la entrada vulnerable.
http://169.254.169.254/latest/meta-data/iam/security-credentials/
API de metadatos
La API de metadatos de instancia es otro vector para los actores de amenazas. La API de metadatos permite que las aplicaciones accedan a información sobre instancias en ejecución. Normalmente se puede acceder a él a través de APIPA (169.254.169.254), pero su funcionalidad varía según el proveedor específico. La API de metadatos responde a solicitudes HTTP y la estructura de las solicitudes HTTP también varía según el proveedor.
Hay dos versiones de la API de metadatos de AWS: IMDSv1 e IMDSv2o, la última de las cuales se centra en la seguridad y se basa en sesiones en lugar de roles. La primera solicitud debe cambiarse a PUT y requiere encabezados adicionales. Sin embargo, se puede obtener si se puede ejecutar el comando. La URL base es:
http://169.254.169.254/latest/metadata
Las organizaciones deben desactivar IMDS v1 y utilizar únicamente IMDSv2. Aunque IMDSv2 no es completamente seguro, tiene características de seguridad mejoradas que lo hacen más difícil de explotar.
En AWS, la URL base es http://169.254.169.254/latest/meta-data/. La siguiente tabla muestra un ejemplo de puntos finales de metadatos accesibles en AWS.
Fuente: https://www.kroll.com/en/insights/publications/cyber/aws-azure-cloud-security-threats
