AWS Defaults Could Lead to Service Takeover

AWS S3 access Aqua Security

Identity and access management (IAM) is one of the most significant factors in cybersecurity today, yet it is often overlooked or deprioritized in favor of more direct threat prevention technologies and practices. Organizations often struggle to maintain visibility and control of the many roles under their purview; systems and services frequently have “shadow roles” that are not known or understood, and these roles can carry high levels of access and privilege.

Many services under Amazon Web Services (AWS) automatically create or recommend roles when a service is set up, which many users and organizations fail to notice or manage properly. Common AWS services affected by this issue include SageMaker, Glue, EMR, and Lightsail. These default roles often have excessive access or permissions, introducing silent vulnerabilities to organizations.

Aqua Security’s Key Findings

Security platform provider Aqua Security recently discovered, during an audit of default IAM roles, that many automatically created AWS roles are granted full S3 access. Roles intended for specific use within the service can be compromised and abused by threat actors, potentially leading to extensive damage, especially with advanced permissions.

The analysis by Aqua’s team found a number of ways that this can enable lateral movement within AWS accounts, depending on which service an attacker gains access to initially.

  • From a compromised default service role in AWS Glue, an attacker can modify the script of a newly created Glue job to gain access to other S3 buckets.
  • With SageMaker AI, a bad actor can escalate privileges after opening a Jupyter notebook under the SageMaker execution role.
  • Similarly, an attacker can open an EMR notebook under the EMR runtime role in order to escalate privileges.

Once the attacker manages to achieve escalated privileges, they can target S3 buckets outside of the service that was the initial point of access. This enables access to wider attack surfaces and broader permissions.

A Hypothetical but Realistic Attack Chain

One scenario explored by Aqua’s analysis is the use of a malicious machine learning model to trigger the execution of malicious code under a privileged role. Attackers can upload a malicious model to Hugging Face, which is then imported into SageMaker. The execution role in SageMaker AI is granted ListBucket, PutObject, and GetObject permissions, allowing attackers to import the model and execute the malicious code embedded within it.

In Aqua’s example, the malicious model is able to use the SageMaker execution role with AmazonS3FullAccess permissions to inject backdoor vulnerabilities into several AWS Glue assets buckets. Through this process, the compromise can spread from the initial access point to Glue, EMR, and other services.

AWS’s Response and Policy Changes

Aqua Security reached out to AWS and disclosed the IAM risks that they had found in many of the default service roles, and AWS made a quick response, taking substantial steps to mitigate the issue. These steps include decreasing the scope of default roles, restricting permissions, and updating documentation to inform users of the importance of enforcing the principle of least privilege. AWS also notified affected users via email to inform them of the necessary action to manage the scope of their existing default roles.

Lessons for Cloud Security Teams

Teams concerned with cloud security should take steps to mitigate the underlying issues with IAM and shadow roles. “Identity types are exploding in the cloud,” says Kinnaird McQuade, Chief Security Architect at BeyondTrust. It’s not only human accounts that have identities and roles: AI agents, services like AWS, and automation "are all creating unintended downstream consequences for security teams. They're often overprivileged and under-monitored. Once created, their access rarely gets re-evaluated.”

It is important for cloud security teams to take a number of lessons away from this. Many tend to assume that cloud services contain settings that are safe by default, but this is not always true. It is necessary to achieve visibility of all roles and manage permissions according to zero-trust principles. The principle of least privilege and custom role creation are crucial to avoid excessive permissions and default settings that create security risks. It is also essential for organizations to regularly audit their IAM policies and role permissions to ensure ongoing security and resilience.

A Wake-Up Call for Cloud Governance

These discoveries about AWS default role permissions speak to the necessity for cloud service providers to implement more secure defaults and better role templates. It is vital for teams to achieve visibility and insight into all roles in order to identify and remediate shadow roles and over-permissioned roles. To mitigate the risks of the default roles within AWS services, Aqua recommends avoiding broad S3 permissions and restricting S3 access to service-specific buckets.

Author
  • Contributing Writer, Security Buzz
    PJ Bradley is a writer from southeast Michigan with a Bachelor's degree in history from Oakland University. She has a background in school-age care and experience tutoring college history students.