SESNSploit: Red Team Exploitation of AWS SES and SNS Misconfigurations

SESNSploit: Red Team Exploitation of AWS SES and SNS Misconfigurations

Speakers: Mohd. Arif; Gaurav Joshi

Conference: Cloud Village

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

Overview

This talk introduces SESNSploit, a specialized red team tool designed to identify and exploit common misconfigurations within Amazon Web Services' Simple Notification Service (SNS) and Simple Email Service (SES). Presented by Mohd. Arif, standing in for the tool's ideators Gaurav Joshi and HK, the session highlights how these often-overlooked messaging and email services can become critical attack vectors when improperly secured. The tool streamlines the process of reconnaissance, policy analysis, and exploitation, allowing security professionals to simulate real-world attacks.

The significance of SESNSploit lies in its focus on active exploitation, a capability often missing in traditional cloud security auditing tools. While many tools can identify policy misconfigurations, SESNSploit goes a step further by enabling red teams to demonstrate the tangible impact of these flaws, such as hijacking sensitive communication channels, orchestrating phishing campaigns, or escalating privileges across AWS services. This practical approach provides invaluable insights for organizations to understand their true risk posture and implement robust defensive strategies against sophisticated cloud attacks.

Background

▶ Watch: Introduction to SESNSploit and AWS SNS fundamentals (0:00)

Amazon Web Services (AWS) provides a vast array of services, two of which are fundamental for inter-service communication and external notifications: Simple Notification Service (SNS) and Simple Email Service (SES). SNS acts as a managed message broker, facilitating application-to-person (A2P) and application-to-application (A2A) communication. It operates on a publish/subscribe model, where messages are published to a central topic, and various subscribers (e.g., email addresses, AWS Lambda functions, SQS queues, HTTP/S endpoints) receive these messages. Common use cases include triggering alerts for billing thresholds, automating S3 bucket backups, or synchronizing data across services. SES, on the other hand, is a cloud-based email sending service designed for marketing, transactional, and bulk email communications.

Despite their utility, SNS and SES are frequently subject to misconfigurations, largely due to the complexity of AWS Identity and Access Management (IAM) policies. A common pitfall is the use of overly permissive policies, particularly specifying Principal: *, which grants access to "anyone in the AWS account" or even "anyone with an AWS account" if not properly scoped. This broad permission often arises from developers or administrators seeking quick functionality without fully grasping the security implications, especially in testing environments that later migrate to production.

Existing cloud security tools, such as Prowler, excel at identifying policy misconfigurations in services like SNS. However, they typically stop at reporting the vulnerability. The gap identified by the SESNSploit team was the lack of tools that could actively exploit these misconfigurations to demonstrate actual impact. This often left red teams manually crafting AWS API calls using boto3 or AWS CLI, a laborious and error-prone process. SESNSploit was developed to bridge this gap, offering a simplified, automated approach to simulate attacks and provide concrete proof of concept for identified vulnerabilities.

Key Findings

▶ Watch: Overview of SESNSploit's core modules and functionalities (3:20)

The development and demonstration of SESNSploit revealed several critical findings regarding the security posture of AWS SNS and SES implementations:

1. Prevalence of Overly Permissive SNS Policies: A significant and recurring vulnerability is the configuration of SNS topic policies with a **wildcard Principal (*)**. This allows any authenticated AWS user, or even any AWS account globally, to perform actions such as Subscribe or Publish to a topic, depending on the specific policy actions granted. This often stems from a lack of security awareness or a desire for convenience during development, leading to policies that are "least taken care of" in terms of security hardening.

1. SNS Topic Hijacking: When an SNS topic has a Principal: * policy allowing sns:Subscribe, an attacker can subscribe their own email address or an attacker-controlled endpoint to receive all messages published to that topic. This enables data exfiltration if sensitive information (e.g., cloud metadata, logs, internal alerts, cloud formation results) is being published. Furthermore, if sns:Publish is also permitted, the attacker can inject malicious messages into the topic, potentially distributing phishing links or fake alerts to all legitimate subscribers.

1. Cross-Service Privilege Escalation via Lambda Integration: A more advanced attack vector involves SNS topics that trigger AWS Lambda functions. If a vulnerable SNS topic allows an attacker to publish messages, and the associated Lambda function has overly permissive IAM roles or contains exploitable code (e.g., vulnerable to command injection), the attacker can achieve privilege escalation. By sending specially crafted messages to the SNS topic, the attacker can force the Lambda to execute arbitrary commands, list secrets, assume roles, or read from sensitive S3 buckets, effectively leveraging the Lambda's permissions.

1. SES Identity Spoofing: Although not fully demonstrated due to setup time, the talk highlighted the potential for SES Identity Spoofing. If an attacker gains control over a domain's DNS records (e.g., through a separate attack or misconfiguration) and can verify an email address with SES, they can send emails on behalf of that legitimate domain. This enables highly credible phishing attacks, as the emails originate from a seemingly trusted source.

1. Simplified Red Team Operations: SESNSploit's primary contribution is simplifying the execution of these complex attack scenarios. Instead of requiring manual API calls or custom scripting, the tool provides an interactive menu-driven interface, making these sophisticated exploitations accessible and reproducible for red teams and security testers. This significantly reduces the time and effort required to identify and demonstrate the impact of SNS/SES misconfigurations.

Technical Deep Dive

▶ Watch: Motivation: Addressing existing exploitation tool gaps with SESNSploit (3:50)

SESNSploit is a Python-based command-line interface (CLI) tool designed for ease of use and automation. Its core functionality relies heavily on the boto3 library, which is the AWS SDK for Python, enabling interaction with various AWS services, including SNS and SES. The tool also incorporates Colorama for enhanced console output, making the user experience more intuitive.

The tool operates by guiding the user through a series of modules, starting with reconnaissance and moving towards active exploitation. Upon execution, main.py prompts the user to select an AWS profile, assuming that compromised credentials with appropriate SNS/SES permissions are already available.

Core Modules and Functionality:

1. Check Active Region: The first step in any enumeration is to identify the AWS regions where SNS (or SES) services are active for the given credentials. The tool iterates through all available AWS regions, attempting to query SNS/SES services. This helps narrow down the scope for further reconnaissance, as some services might not be available or active in all regions. The results are automatically saved to a file, preventing the need for manual copy-pasting.

1. List SNS Topic: Once active regions are identified, the tool can list all SNS topics within those regions. This is crucial for discovering potential targets. The output includes topic ARNs (Amazon Resource Names), which are essential for subsequent actions.

1. List Subscription for SNS Topic: For a selected topic, SESNSploit can enumerate all existing subscriptions. This reveals what endpoints (e.g., email addresses, SQS queues, Lambda functions) are currently receiving messages from the topic, providing valuable intelligence about potential data flows or linked services.

1. Get SNS Topic Attributes: This module is key for identifying misconfigurations. It retrieves the attributes of a chosen SNS topic, including its policy document. The tool specifically highlights policies that grant sns:Subscribe or sns:Publish actions to a Principal: * (wildcard), indicating a significant vulnerability. The policy document also reveals if the topic is integrated with other services, such as Lambda functions, which can lead to cross-service privilege escalation.

1. Subscribe to SNS Topic: If a topic's policy permits sns:Subscribe for a wildcard principal, the tool allows an attacker to subscribe an arbitrary endpoint. This can be an email address, an SQS queue, an HTTP/S endpoint, or even an SMS number. For email subscriptions, AWS sends a confirmation email, requiring user interaction to finalize the subscription. The tool facilitates this by providing the necessary prompts.

1. Send Message to SNS Topic: Once subscribed (or if the policy allows sns:Publish), the tool enables sending messages to the target SNS topic. This is used to demonstrate data exfiltration (by receiving messages) or message injection (by sending malicious content to all subscribers).

1. Create SNS Topic: While not central to the immediate exploitation demos, the tool also offers the capability to create new SNS topics, which could be useful for setting up custom attack infrastructure or testing.

1. SCS Operation: This module is intended for SES-related exploits, specifically SES Identity Spoofing. However, due to the time-consuming nature of email verification (requiring DNS TXT record updates and a 72-hour waiting period), this module was not demonstrated in the talk. The associated Terraform scripts are provided in the GitHub repository for users to set up and experiment with this scenario independently.

Exploitation Flows:

• SNS Topic Hijacking: The tool automates the process of identifying a vulnerable topic (e.g., red-team-test-vulnerable-notification with Principal: * and sns:Subscribe), subscribing an attacker-controlled email, confirming the subscription, and then publishing a malicious message (e.g., a phishing URL) to the topic. All existing and newly subscribed endpoints receive this message.

• Cross-Service Privilege Escalation: This scenario targets topics linked to Lambda functions (e.g., red-team-trigger subscribed by red-team-test-privilege-processor Lambda). The tool allows publishing messages containing specific commands (e.g., list secret, assume role) to the topic. The vulnerable Lambda, upon receiving the message, executes these commands within its execution environment, and the output (e.g., AWS credentials, secrets) is then exfiltrated back to the attacker, often via another subscribed endpoint (e.g., email). This demonstrates a direct path from SNS message injection to arbitrary code execution and privilege escalation within the AWS environment.

The tool’s design prioritizes a straightforward user experience, abstracting away the complexities of AWS API calls and policy parsing. Terraform scripts are provided in the repository to set up vulnerable lab environments, allowing users to safely practice and understand these attack vectors.

Demo / Proof of Concept

▶ Watch: Executing SESNSploit and configuring AWS credentials (7:50)

The talk featured two primary live demonstrations using SESNSploit, showcasing the practical implications of SNS misconfigurations. A third scenario, SES Identity Spoofing, was detailed conceptually but could not be demonstrated live due to the 72-hour email verification period required by AWS SES.

Demo 1: SNS Topic Hijacking

1. Reconnaissance: The presenter first used SESNSploit to Check Active Region for SNS services and then List SNS Topic within those regions. This revealed a topic named red-team-test-vulnerable-notification (identified as the sixth topic in the list).
2. Policy Analysis: Using the Get SNS Topic Attributes module, the policy for red-team-test-vulnerable-notification was inspected. The key finding was a Principal: * (wildcard) combined with sns:Subscribe and sns:Receive actions. This confirmed that anyone with an AWS account could subscribe to this topic.
3. Subscription: The presenter then used the Subscribe to SNS Topic module, selecting the vulnerable topic and choosing email as the endpoint type. An attacker-controlled email address was provided. AWS sent a confirmation email, which the presenter manually confirmed, illustrating that user interaction is typically required for email subscriptions.
4. Message Injection: With the attacker's email now subscribed, the Send Message to SNS Topic module was used. A malicious message was crafted: "Hey Paul, your AWS account credit ended. please pay in this particular URL: http://aable.com".
5. Impact: The attacker's email received the phishing message, demonstrating that the topic was successfully hijacked and could be used to distribute malicious content to all subscribers. The presenter emphasized the danger of this in a "deal" (distribution list) scenario, where one careless confirmation could compromise an entire team.

Demo 2: Cross-Service Privilege Escalation

1. Target Identification: The presenter identified another topic, red-team-trigger (the seventh topic in the list), which was suspected of being linked to a Lambda function.
2. Policy Inspection & Lambda Discovery: Similar to the first demo, Get SNS Topic Attributes for red-team-trigger showed a Principal: * with sns:Publish and sns:Subscribe permissions. Crucially, List Subscription for SNS Topic revealed that a Lambda function named red-team-test-privilege-processor was subscribed to this topic. This indicated a potential path for privilege escalation if the Lambda was vulnerable.
3. Command Injection: The Send Message to SNS Topic module was used to send specially crafted messages to red-team-trigger. Initially, a benign, unknown command was sent to confirm that the Lambda was indeed executing the input (the email response indicated "unknown command").
4. Privilege Escalation: The presenter then sent a message containing the command assume role red-team-cross-account-role. The Lambda executed this, and the attacker's subscribed email received a notification containing temporary AWS credentials (access key, secret key, session token) for red-team-cross-account-role, effectively demonstrating role assumption and privilege escalation.
5. Data Exfiltration: Following this, a message containing list secret was sent. The Lambda executed this command, and the attacker's email received another notification, this time listing various AWS secrets, including access keys and session tokens, proving data exfiltration.

These demonstrations effectively illustrated how SESNSploit can be leveraged by red teams to uncover and exploit critical misconfigurations in AWS SNS, leading to significant security breaches. The provided Terraform scripts allow users to replicate these vulnerable environments, facilitating hands-on learning and testing.

Defensive Implications

▶ Watch: Live demo: Enumerating active AWS regions with SESNSploit (9:00)

The demonstrations and findings from SESNSploit underscore critical areas where AWS organizations must strengthen their security posture to prevent exploitation of SNS and SES misconfigurations. Defenders should consider the following actions:

1. Implement the Principle of Least Privilege for SNS Policies:

• **Avoid Principal: ***: Never use a wildcard Principal in SNS topic policies. Instead, explicitly define the AWS accounts, IAM users, or IAM roles that require access.
• Specific ARNs: Restrict access to specific Amazon Resource Names (ARNs). For example, specify arn:aws:iam::123456789012:user/developer instead of *.
• Conditional Access: Utilize IAM conditions (e.g., aws:SourceVpc, aws:SourceIp) to further limit who can interact with SNS topics.
• Review sns:Subscribe and sns:Publish: Ensure these permissions are only granted to necessary entities. If a topic is for internal application use, restrict subscriptions to specific service roles or SQS queues within your account, not external emails or arbitrary endpoints.

1. Regular and Automated Policy Audits:

• Proactive Scanning: Integrate tools like Prowler or even SESNSploit itself (used defensively) into your CI/CD pipelines or as part of regular security assessments to automatically identify SNS and SES policies that are overly permissive.
• Focus on Messaging Services: Given that SNS and SES are often "least taken care of," prioritize auditing these services specifically. Look for Principal: * and broad Allow statements in Statement blocks.

1. Secure Lambda Function Integrations:

• Input Validation: Lambda functions subscribed to SNS topics must rigorously validate and sanitize all incoming messages. Assume all input is malicious. This is crucial to prevent command injection vulnerabilities.
• Least Privilege for Lambda Roles: Ensure the IAM role assumed by a Lambda function has only the absolute minimum permissions required to perform its task. If a Lambda processes SNS messages and then writes to S3, it should only have S3 write permissions, not s3:* or iam:AssumeRole.
• No Sensitive Operations: Avoid having Lambda functions perform sensitive operations (like list secret or assume role) based directly on unvalidated input from SNS messages.
• Secure Coding Practices: Adhere to secure coding guidelines for all Lambda functions, especially those integrated with messaging services.

1. Enhance User Awareness and Education:

• Subscription Confirmation Vigilance: Educate users, especially those on distribution lists (DLs), to be extremely cautious about confirming unexpected AWS SNS subscription requests. Phishing attacks can leverage these legitimate-looking AWS notifications.
• Phishing Training: Regularly conduct phishing awareness training, emphasizing the tactics used in the SNS Topic Hijacking demo, where legitimate AWS notifications can precede a malicious link.

1. Strict Control Over SES Domain Verification:

• DNS Security: Implement strong security controls over your domain's DNS records. Unauthorized modification of TXT records is the primary vector for SES Identity Spoofing.
• MFA for DNS Providers: Enable Multi-Factor Authentication (MFA) for accounts managing DNS records.
• Monitor SES Verifications: Regularly monitor for new domain or email address verifications within your AWS SES configuration.

1. Comprehensive Logging and Monitoring:

• CloudTrail: Enable AWS CloudTrail for all management events and data events on SNS and SES. Monitor for unusual Subscribe, Publish, SetTopicAttributes, or SendEmail API calls.
• CloudWatch Alarms: Set up Amazon CloudWatch alarms to alert on suspicious activities, such as:
• New SNS subscriptions to critical topics.
• Changes to SNS topic policies.
• Unusually high volumes of Publish actions from unexpected sources.
• Unauthorized SES email verification attempts.
• SIEM Integration: Forward SNS/SES logs to a Security Information and Event Management (SIEM) system for centralized analysis and correlation with other security events.

By proactively addressing these defensive implications, organizations can significantly reduce their exposure to SNS and SES misconfigurations, safeguarding sensitive data, preventing unauthorized access, and mitigating the risk of sophisticated phishing and privilege escalation attacks.

Key Takeaways

• Pervasive SNS Misconfigurations: AWS SNS topics are frequently misconfigured with overly permissive policies, particularly using Principal: *, making them vulnerable to exploitation.
• Multi-Vector Exploitation: These misconfigurations enable various attack scenarios, including SNS Topic Hijacking (subscribing to sensitive topics, injecting malicious messages) and Cross-Service Privilege Escalation (leveraging vulnerable Lambda integrations for command execution and data exfiltration).
• SES Identity Spoofing Risk: Although not fully demonstrated, SES can be exploited for Identity Spoofing if an attacker can verify an email address for a target domain, enabling highly credible phishing campaigns.
• SESNSploit Simplifies Red Teaming: The SESNSploit tool streamlines the identification and exploitation of these vulnerabilities, providing an automated and user-friendly interface for red teams to demonstrate real-world impact.
• Critical Defensive Measures: Organizations must adopt the Principle of Least Privilege for SNS/SES policies, conduct regular security audits, implement robust input validation for Lambda functions, and enhance user awareness regarding subscription confirmations and phishing.
• Comprehensive Monitoring is Essential: Proactive logging and monitoring of SNS/SES API calls and subscription changes are crucial for early detection and response to potential attacks.

About the Speaker(s)

The talk was presented by Mohd. Arif, who stepped in for the original ideators, Gaurav Joshi and HK. Mohd. Arif brings approximately five years of experience in the security domain. At the time of the talk, he was transitioning to Los Angeles for his master's degree, having previously served as a manager at Poshmark. He is also actively involved in community initiatives, notably with "seit," a free, community-based security conference in India aimed at students and newcomers, offering free training and fostering new talent in the field.

The tool SESNSploit was ideated by Gaurav Joshi and HK, with significant contributions from Prashant, Suk, and Chanchchel. Prashant, mentioned as a chapter lead for the Bay Area OWASP chapter, was highlighted as a key contributor to the tool's development and ideation.