Weaponizing SageMaker AI: Real-World Offense in Machine Learning Platforms

Weaponizing SageMaker AI: Real-World Offense in Machine Learning Platforms

Speakers: Shani Peled, Senior Cloud Security Researcher, Sentinel One

Conference: Cloud Village

YouTube: https://www.youtube.com/watch?v=dm6vvL7HoUw

Overview

In this compelling talk from Cloud Village, Shani Peled, a Senior Cloud Security Researcher at Sentinel One, unveiled a series of critical security vulnerabilities stemming from the default configurations of AWS SageMaker. Titled "Weaponizing SageMaker AI: Real-World Offense in Machine Learning Platforms," the presentation meticulously detailed how the seemingly convenient "quick setup" mode for SageMaker can inadvertently expose an entire AWS account to significant risks, enabling attackers to perform actions ranging from data exfiltration and poisoning to remote code execution and privilege escalation.

Peled's research highlights a crucial, often overlooked aspect of modern cloud security: the inherent trust placed in managed services and their default settings. By demonstrating four distinct, yet interconnected, attack scenarios, she challenged the assumption that AI environments are isolated or inherently secure. The talk serves as a stark reminder that as organizations increasingly adopt AI/ML platforms, these new attack surfaces must be treated with the same rigorous security scrutiny applied to traditional infrastructure.

The implications of Peled's findings are profound for any organization utilizing AWS SageMaker, particularly those relying on its default configurations. The research underscores the necessity of implementing the principle of least privilege, actively monitoring AI workloads, and ensuring proper isolation from critical production systems. It transforms the abstract concept of AI security into tangible, real-world attack paths, urging immediate action from defenders.

Background

▶ Watch: Speaker introduction and talk overview (0:00)

AWS SageMaker is a fully managed cloud service designed to simplify the end-to-end machine learning workflow, from building and training models to deploying them in production. It offers a "managed lab" environment where data scientists and ML engineers can experiment with AI without the burden of setting up and managing underlying infrastructure like servers or software. A core component of SageMaker is the Jupyter notebook, an interactive environment popular for writing and running code in Jupyter cells.

The genesis of Peled's research began with a common user experience: creating a new SageMaker environment. AWS presents two primary options: a quick setup mode—a one-click solution that automatically provisions necessary resources—and a manual setup, which requires explicit configuration of VPCs, IAM roles, and other settings. Like many users seeking convenience, Peled opted for the quick setup. This "easy button," while accelerating initial deployment, proved to be the root cause of significant security exposures.

Upon exploring the environment created by the quick setup, Peled identified two critical default configurations. First, a default execution role with a specific naming convention (AmazonSageMaker-ExecutionRole-*) was automatically attached. Second, the network configuration defaulted to public internet access, meaning the SageMaker domain could reach the internet without restrictions. Further investigation within a Jupyter notebook revealed that the execution context was that of the default user created during setup. Analyzing the policies attached to this default role unveiled a highly permissive set of permissions, including broad access to AWS Glue, S3, Secrets Manager, ECR (Elastic Container Registry), and Cognito IDP (Identity Provider). These default permissions, intended for ease of use, were found to be overly broad, extending far beyond the immediate SageMaker domain and across the entire AWS account, laying the groundwork for the subsequent attack scenarios.

Key Findings

▶ Watch: SageMaker Quick Setup's hidden security risks (3:20)

Shani Peled's research exposed several critical findings regarding the security posture of AWS SageMaker environments configured using the default "quick setup" mode:

• Overly Permissive Default IAM Roles: The primary finding is that the AmazonSageMaker-ExecutionRole-* created by the quick setup mode is excessively permissive. Instead of adhering to the principle of least privilege, these roles are granted broad access to a wide array of AWS services across the entire account, making them a prime target for attackers.
• Cross-Account and Cross-Domain Access: Despite SageMaker domains being presented as logical units for isolating teams or projects, the underlying IAM permissions often flatten this isolation. The default role was found to grant access to resources (like secrets or S3 buckets) belonging to entirely different SageMaker domains or even other AWS services within the same account.
• "Day-to-Day Risks" vs. CVEs: Peled emphasized that the discovered vulnerabilities are not obscure CVEs (Common Vulnerabilities and Exposures) requiring complex exploits. Instead, they are "day-to-day risks" inherent in the common, default configurations that many organizations unwittingly adopt, making them readily exploitable by anyone with access to a SageMaker Jupyter notebook.
• Multiple Critical Attack Paths: The permissive default role enables a diverse range of high-impact attacks:
• Data Exfiltration and Enumeration: Listing and retrieving sensitive secrets and data from S3 buckets across the account.
• Data Poisoning: Altering or deleting data used by machine learning models, leading to model degradation or malicious outcomes.
• Remote Code Execution (RCE) / Backdoor Deployment: Establishing persistent backdoors outside the SageMaker notebook environment via malicious container images and SageMaker endpoints.
• Privilege Escalation: Gaining higher-privileged AWS IAM roles by manipulating Cognito IDP user pools.
• Public Internet Access as an Enabler: The default public internet access for SageMaker domains facilitates remote code execution scenarios, allowing compromised endpoints to communicate with external attacker-controlled infrastructure.

These findings collectively paint a picture of AWS SageMaker as a powerful platform that, when configured with default settings, can become a significant attack surface, demanding immediate attention to IAM policies and network segmentation.

Technical Deep Dive

▶ Watch: Discovery of SageMaker's overly permissive default role (5:20)

Peled meticulously detailed four distinct attack scenarios, each leveraging the default permissive IAM role assigned to SageMaker environments created via the quick setup mode.

Cross-Domain Secrets Access

This attack capitalizes on the broad permissions granted to the default SageMaker execution role regarding AWS Secrets Manager. The role, by default, possesses secretsmanager:ListSecrets permission on * (all resources). This allows an attacker to enumerate every secret stored in Secrets Manager across the entire AWS account. While ListSecrets provides metadata, the role also includes secretsmanager:DescribeSecret, secretsmanager:GetSecretValue, and secretsmanager:CreateSecret for secrets whose key names start with AmazonSageMaker or have the SageMaker:true resource tag.

An attacker can leverage this by first listing all secrets, then filtering for those matching the AmazonSageMaker prefix or SageMaker:true tag based on their metadata. Once identified, the secretsmanager:GetSecretValue permission allows the attacker to retrieve the actual secret content. Peled demonstrated that this access extends beyond the immediate SageMaker domain, enabling the retrieval of secrets belonging to other SageMaker domains or even other AWS services, effectively flattening the logical isolation provided by SageMaker domains. This highlights a fundamental flaw in the default least privilege implementation, granting unnecessary visibility and access to sensitive credentials.

Glue Data Poisoning using S3 Permissions

This scenario combines permissions to AWS Glue and S3, leading to potential data integrity compromises for machine learning models. The default SageMaker execution role is automatically attached a policy granting highly privileged S3 permissions: s3:GetObject, s3:PutObject, s3:DeleteObject, and s3:ListBucket on * (all buckets in the account). Concurrently, the role also has glue:GetDatabase and glue:GetTables permissions.

The attack unfolds in several steps:

1. S3 Enumeration: The attacker first lists all S3 buckets in the account, including those potentially containing sensitive data, such as Terraform configuration files or data related to other SageMaker domains.
2. Sensitive Data Download: Using s3:GetObject, the attacker downloads sensitive files, including raw data intended for ML models or infrastructure-as-code files.
3. Glue Table Enumeration: The attacker then uses glue:GetDatabase and glue:GetTables to understand the structure and schema of data tables managed by AWS Glue. This is crucial for understanding how ML models consume and process data.
4. Data Alteration/Deletion and Upload: With knowledge of the data structure, the attacker can delete original data (s3:DeleteObject), create malicious or fake data that adheres to the expected schema, and then upload this poisoned data back to the S3 bucket using s3:PutObject. This directly impacts the integrity of ML models that rely on this data, potentially leading to biased predictions, system failures, or even enabling further attacks if the poisoned data is designed to trigger specific vulnerabilities. Peled demonstrated this by downloading "real-time predictions" data, deleting it, creating new data with the same structure, and re-uploading it.

ECR and SageMaker Backdoor Deployment

This advanced attack leverages a "toxic combination" of ECR and SageMaker permissions to establish a persistent backdoor. The default SageMaker role has broad ECR permissions, including ecr:CreateRepository (with any name) and ecr:PutImage (specifically for repositories containing "SageMaker" in their name). Additionally, it has permissions to create SageMaker models and endpoints.

The attack sequence is as follows:

1. Malicious Image Creation: The attacker crafts a malicious Docker image, for instance, containing a reverse shell designed to connect back to an attacker-controlled C2 server on the internet.
2. ECR Repository Creation: The attacker creates a new ECR repository with a name containing "SageMaker" (e.g., SageMaker-malicious-repository-123) using ecr:CreateRepository.
3. Malicious Image Push: The malicious Docker image is then pushed to this newly created ECR repository using ecr:PutImage.
4. SageMaker Model Creation: A new SageMaker model is created, configured to use the malicious image from the ECR repository.
5. SageMaker Endpoint Deployment: Finally, a SageMaker endpoint is deployed, which executes this malicious model. Crucially, because the SageMaker environment defaults to public internet access, this endpoint can initiate an outbound connection to the attacker's C2 server. This establishes a persistent backdoor within the AWS environment, operating independently of the Jupyter notebook, providing remote code execution capabilities to the attacker. Peled presented a screenshot from her C2 server confirming the successful reverse shell connection.

Abusing Cognito IDP for Privilege Escalation

This sophisticated attack exploits inexplicably permissive AWS Cognito IDP permissions granted to the default SageMaker role. While Cognito IDP manages application users (separate from AWS IAM users), it allows assigning IAM roles to these application users to control their access to AWS resources upon authentication. The default SageMaker role was found to possess extensive cognito-idp:* permissions.

The privilege escalation path involves:

1. Cognito Enumeration: The attacker enumerates Cognito user pools and groups within the AWS account using the cognito-idp:* permissions.
2. Targeting Privileged Groups: The goal is to identify user groups that are associated with high-privilege AWS IAM roles (e.g., a CognitoITAdminRole linked to an IT Admins group).
3. Malicious User Creation: A simple script is used to create a new, malicious user within the identified user pool and add them to the privileged group.
4. Authentication and JWT Retrieval: The attacker then authenticates as this newly created user, obtaining a JSON Web Token (JWT).
5. Privilege Escalation Confirmation: Decoding the JWT reveals that the malicious user has successfully been granted the high-privilege AWS IAM role associated with the Cognito group, effectively escalating privileges from the initial SageMaker execution role to a more powerful role within the AWS account. This demonstrates a critical cross-service privilege escalation path that could grant attackers broad control over the AWS environment. Peled highlighted that this puts any organization using Cognito and SageMaker in the same account at immediate risk.

These detailed attack scenarios underscore the significant security risks posed by AWS SageMaker's default configurations and the critical importance of scrutinizing IAM policies.

Demo / Proof of Concept

▶ Watch: First attack: Cross-domain secrets access explained (6:40)

Shani Peled's talk culminated in a compelling demonstration of SageStrike, a powerful post-exploitation framework she developed specifically for AWS SageMaker IAM roles. The tool's primary purpose is to help organizations evaluate, abuse, and demonstrate real-world attack paths leveraging the permissions granted to SageMaker IAM roles in their own environments. This allows security professionals to proactively identify and understand their vulnerabilities.

The demo showcased SageStrike's capabilities directly from within a SageMaker Jupyter notebook, executing commands as the default SageMaker identity.

1. Permission Enumeration: The first step involved using SageStrike to enumerate the permissions held by the SageMaker role. Peled specified that for this demonstration, only read and get permissions were enumerated to avoid unintended modifications to the environment. The tool successfully listed the available permissions and, crucially, indicated potential attack paths that could be exploited.
2. Secrets Listing and Retrieval: SageStrike then demonstrated its ability to list secrets within the environment. It not only enumerated all secrets but also intelligently highlighted which specific secrets were potentially readable by the SageMaker role, including the cross-domain secret that was discussed in the "Cross-Domain Secrets Access" scenario. The tool then successfully retrieved the value of a secret from another domain, visually confirming the vulnerability.
3. Automated Cognito IDP Privilege Escalation: The demo proceeded to automate the "Abusing Cognito IDP for Privilege Escalation" attack. Users simply needed to select the target user pool, provide a username and email, and SageStrike handled the rest. It created the evil user, added them to the privileged group, authenticated, and returned the JWT. Peled then decoded the JWT on screen, clearly showing the associated high-privilege AWS IAM role, proving the successful privilege escalation.
4. Automated Backdoor Deployment: Finally, SageStrike automated the "ECR and SageMaker Backdoor Deployment" scenario. The user specified an evil model name and endpoint name, and the tool orchestrated the creation of the malicious SageMaker model and endpoint. Peled explained that if a C2 channel had been set up, the connection would be established immediately, demonstrating the ease with which a persistent backdoor could be deployed.

The SageStrike tool is designed with flexibility in mind, allowing users to define and add their own attack scenarios using TOML-based files. This extensibility ensures that the framework can adapt to new discoveries and evolving threat landscapes in SageMaker environments. The live demonstration of SageStrike provided concrete proof of concept for each attack scenario, underscoring the immediate and practical nature of the risks identified.

Defensive Implications

▶ Watch: Demonstrating cross-domain secret exfiltration from Jupyter (8:00)

The findings presented by Shani Peled carry significant defensive implications for any organization utilizing AWS SageMaker. The convenience of managed services and default configurations should not lead to complacency; rather, it demands a proactive and rigorous approach to security.

1. Strict Adherence to the Principle of Least Privilege: This is the paramount recommendation. Organizations should never assume that AWS default roles, including those for SageMaker, are secure or sufficiently constrained. Default roles are often overly broad and powerful, granting permissions far beyond what is necessary for a given task. Defenders must invest time in custom IAM policies, ensuring that SageMaker execution roles are granted only the absolute minimum permissions required to perform their specific functions. This involves granular control over actions and resources, rather than relying on wildcard (*) permissions.
2. Detect and Remediate Default Misconfigurations: The "easy button" provided by quick setup modes can introduce dangerous security gaps. While convenience is valuable for speed, it often comes at the cost of security. Defenders must actively audit and fix default misconfigurations, particularly concerning network access (e.g., public internet access) and IAM policies. SageMaker domains should ideally operate within a private VPC, with network access strictly controlled and limited to essential services.
3. Continuously Monitor Real-Time Activities: SageMaker notebooks and endpoints are live, exposed components within the cloud environment. They are not static artifacts but active compute resources that, if compromised, can be leveraged for privilege escalation, data exfiltration, or establishing persistent footholds. Real-time monitoring of SageMaker activities, including API calls, notebook executions, and endpoint behavior, is critical. Security Information and Event Management (SIEM) systems and Cloud Security Posture Management (CSPM) tools should be configured to detect anomalous behavior, unauthorized resource creation (e.g., new ECR repositories, SageMaker endpoints), or unusual data access patterns emanating from SageMaker roles.
4. Isolate AI from Critical Infrastructure: Treat AI environments, including SageMaker, as a distinct attack surface. It is imperative to separate AI environments from sensitive production infrastructure and critical data stores. This means placing SageMaker workloads in dedicated network segments, restricting cross-account or cross-VPC communication, and limiting direct access to databases or other critical services. Even seemingly "innocent" notebooks or endpoints can become launchpads for sophisticated attacks, as demonstrated by the privilege escalation and backdoor scenarios. Robust segmentation helps contain the blast radius of a potential compromise.

The overarching takeaway for defenders is that AI platforms, despite their advanced capabilities, introduce new and complex attack surfaces. They must be treated with the same level of security rigor and attention given to any other critical system within an organization's infrastructure. Proactive security measures, thorough auditing, and continuous vigilance are essential to mitigate the risks highlighted in this research.

Key Takeaways

• AWS SageMaker's "quick setup" mode, while convenient, often creates excessively permissive default IAM roles that extend broad access across the entire AWS account.
• These default configurations enable multiple critical attack paths, including cross-domain secret exfiltration, data poisoning via S3/Glue manipulation, remote code execution through ECR/SageMaker backdoors, and privilege escalation via Cognito IDP.
• The demonstrated vulnerabilities are not obscure CVEs but rather "day-to-day risks" stemming from common, default configurations that many organizations unwittingly adopt.
• Adhering strictly to the principle of least privilege is paramount for SageMaker execution roles; custom, granular IAM policies are essential over default settings.
• Organizations must actively detect and remediate default misconfigurations, particularly regarding network access (e.g., public internet access) and overly broad IAM permissions.
• Continuous, real-time monitoring of SageMaker activities and isolation of AI workloads from critical production infrastructure are crucial to detect and contain compromises.

About the Speaker(s)

Shani Peled is a Senior Cloud Security Researcher at Sentinel One, specializing in offensive cloud and AI research. Her career began in the Israeli intelligence corps, where she served as a cyber defender. Following her military service, she joined an Israeli red team company, spending four years attacking Fortune 500 companies globally. Peled then transitioned to Sentinel One, where she applies her extensive offensive security experience to research and identify vulnerabilities in cloud and AI environments.