Cybersecurity researchers have discovered risky default identity and access management (IAM) roles impacting Amazon Web Services that could open the door for attackers to escalate privileges, manipulate other AWS services, and, in some cases, even fully compromise AWS accounts.
“These roles, often created automatically or recommended during setup, grant overly broad permissions, such as full S3 access,” Aqua researchers Yakir Kadkoda and Ofek Itach said in an analysis. “These default roles silently introduce attack paths that allow privilege escalation, cross-service access, and even potential account compromise.”
The cloud security firm said it identified security issues in default IAM roles created by AWS services like SageMaker, Glue, EMR, and Lightsail. A similar flaw has also been unearthed in a popular open-source framework called Ray, which automatically creates a default IAM role (ray-autoscaler-v1) with the AmazonS3FullAccess policy.
What’s concerning about these IAM roles is that while they are intended for something specific, they could be abused to perform administrative actions and break isolation boundaries between services, effectively allowing an attacker who has a foothold in the environment to move laterally across services.
These attacks go beyond bucket monopoly attacks, which revolve around a scenario where a threat actor could take advantage of predictable S3 bucket naming patterns to set up buckets in unused AWS regions and ultimately gain control over the contents of the bucket when a legitimate customer starts using services like CloudFormation, Glue, EMR, SageMaker, ServiceCatalog, and CodeStar.
“In this case, an attacker who gains access to a default service role with AmazonS3FullAccess doesn’t even need to guess bucket names remotely,” the researchers explained.
“They can use their existing privileges to search the account for buckets used by other services using the naming patterns, modify assets like CloudFormation templates, EMR scripts, and SageMaker resources, and move laterally across services within the same AWS account.”
Put differently, an IAM role within an AWS account with AmazonS3FullAccess permissions has read/write access to every S3 bucket and modifies various AWS services, effectively turning the role into a powerful method for lateral movement and privilege escalation.
Some of the identified services with the permissive policy are listed below –
- Amazon SageMaker AI, which creates a default execution role named AmazonSageMaker-ExecutionRole- when setting up a SageMaker Domain that comes with a custom policy equivalent to AmazonS3FullAccess
- AWS Glue, which creates a default AWSGlueServiceRole role with the AmazonS3FullAccess policy
- Amazon EMR, which creates a default AmazonEMRStudio_RuntimeRole_ role that’s assigned the AmazonS3FullAccess policy
In a hypothetical attack scenario, a threat actor could upload a malicious machine learning model to Hugging Face that, when imported into SageMaker, can result in the execution of arbitrary code, which could then be used to seize control of other AWS services like Glue by injecting a backdoor capable of stealing IAM credentials of the Glue job.
The adversary could then escalate their privileges within the account, ultimately breaching the entire AWS environment by looking for buckets used by CloudFormation and injecting a malicious template to escalate privileges further.
In response to the disclosure, AWS has addressed the issues by modifying the AmazonS3FullAccess policy for default service roles.
“Default service roles must be tightly scoped and strictly limited to the specific resources and actions they require,” the researchers said. “Organizations should proactively audit and update existing roles to minimize risk, rather than relying on default configurations.”
The findings come as Varonis detailed a vulnerability in a utility used for mounting Azure Storage that comes preinstalled on Microsoft Azure AI and High-Performance Computing (HPC) workloads and allows an unprivileged user on a Linux machine with this utility installed to escalate their privileges to root.
“It involves a classic privilege escalation method involving a SUID binary that is part of the installation of AZNFS-mount, a utility for mounting Azure Storage Account NFS endpoints,” security researcher Tal Peleg said.
“For example, a user could elevate permissions to root and use those permissions to mount additional Azure Storage containers, install malware or ransomware on the machine, and attempt to move laterally in the network or cloud environments.”
The flaw, which affects all versions of the utility up to 2.0.10, has been addressed in version 2.0.11 released on January 30, 2025.
About The Author
Original post here
