AWS Pentesting: Abusing overly permissive SQS Queue.

In this blog, I have set up another custom environment(again drawing inspiration from the previous courses that I recently took) to demo a test case for an SQS that is overly permissive.

The idea of this blog is that an AWS Key is being known to the tester. This AWS key could have been obtained due to a different vulnerability e.g. a command injection in the web app or exposed .env files, etc. For assumed breach scenario, this could be given to the tester as part of the prerequisites.

After configuring the AWS key, the tester would then find out that this IAM user has permission to run some SQS commands. Further recon would shows that there is a resource based policy that allows a wildcard access to get a message from an SQS queue. This SQS queue would then disclose a sensitive API key.

We would start by configuring the AWS Key as shown in the screenshot below. The image shows that our IAM user is named “rootaddict”. We also named our profile as “rootaddict”.

While doing a manual recon, lets run aws-enumerator, a tool we can get from this link, to try to brutefoce the permissions that are allowed for the IAM user.

./aws-enumerator cred -aws_access_key_id <Key ID> -aws_secret_access_key <Secret Access Key> ac-aws_region us-east-1
./aws-enumerator enum all
./aws-enumerator dump -services all

The image above shows that our IAM user can list the SQS queues that are configured in the client organization.

./cloudfox aws --profile rootaddict inventory

We could also run Cloudfox with “inventory” option to see in high level overview the services deployed in the target client organization. The image below shows only the SQS service is used.

Lets then run “list-user-policies” command to check the policies for this IAM user. In this lab, I just set an inline policy but in production you will mostly see a customer-managed or aws-managed policies so always run “list-attached-user-policies” as well. For a comprehensive IAM enumeration. kindly refer to this blog.

aws iam list-user-policies --user-name <username> --profile <profile name>
aws iam list-user-policies --user-name rootaddict --profile rootaddict

The image above shows that there is an inline police named “sqs-demo-policy” that is attached to our current IAM user.

Lets retrieve the policy document using the get-user-policy command as shown below.

aws iam get-user-policy --user-name <user name> --policy-name <policy name> --profile <profile name> 
aws iam get-user-policy --user-name rootaddict --policy-name sqs-demo-policy --profile rootaddict

Reviewing the policy shows that our current IAM user can list all the queues in SQS and can read or get the attribute of the SQS queue named “test-sqs-queue”.

Lets discuss what is SQS first before we move on.

SQS is a fully managed message queuing service provided by AWS. It enables you to decouple and scale microservices, distributed systems, and serverless applications by transmitting messages between different parts of a system.

SQS is like SNS that sends messages. Below are their main differences.

SQS follows a queue-based, “pull” model. Producers send messages into the queue, and consumers (or workers) poll the queue to receive messages. Each message is processed by a single consumer, and once processed, it is removed from the queue. SQS is one to one communication.

SNS follows a “publish-subscribe” pattern. A message published to an SNS topic is sent (pushed) to all its subscribers. You can subscribe an endpoint (e.g., HTTP/S, email, AWS Lambda, SQS queue, etc.) to the topic, and whenever a message is published to the topic, SNS pushes the message to each subscriber. SNS is one to many communications.

Now, lets check for the available queues by running “list-queues” command as shown below.

aws sqs list-queues  --profile <profile name>
aws sqs list-queues  --profile rootaddict

Similar with the policy document, the image above shows that there is a queue that is named “test-sqs-que”.

Notice that the endpoint of this SQS starts with “queue” e.g. queue.us-east-1.amazonaws.com/xxxx/test-sqs-que instead of sqs.us-east-1.amazonaws.com/xxxx/test-sqs-que this is because we are using a legacy endpoint of SQS.

Since we saw in the policy document that our IAM user has permission to the get the attributes of one queue, lets run the get-user-attribute as shown in the command below.

aws sqs get-queue-attributes --queue-url <url> --attribute-names All --profile <profile name>
aws sqs get-queue-attributes --queue-url https://queue.amazonaws.com/<account number here>/test-sqs-que --attribute-names All --profile rootaddict

Reviewing the result below shows that, there is a resource based policy on the SQS queue named “test-sqs-que” that allows any principal or any user to receive the message. Notice the wildcard value and the “sqs:ReceiveMessage” permission.

There are two type of policies in AWS. Resource-based and Identity-Based Policies.

Resource-Based Policies are attached directly to AWS resources such as SQS queues.
Identity-Based Policies in AWS IAM are attached directly to IAM identities such as users, groups, or roles.

When I set up the lab, i just made a simple, and misconfigured resource based policy as shown below.

As a last step of this blog, lets run “receive-message” sqs command to receive a potential sensitive file from the SQS queue.

aws sqs receive-message --queue-url <value> --profile <profile name>
aws sqs receive-message --queue-url https://queue.amazonaws.com/<account number here>/test-sqs-que  --region us-east-1 --profile rootaddict

The image above shows that we received the sensitive data from the queue which is the API key, acting as a proof of concept for a sensitive file.

Conclusion:

In this blog, we demo how an overly permissive SQS queue configuration can lead to a security vulnerability by allowing anyone to retrieve messages containing sensitive information. The main permission that we abused in this blog is the “sqs:ReceiveMessage” that is set to everyone or a wildcard value.

References:

https://docs.aws.amazon.com/general/latest/gr/sqs-service.html
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html
https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.html?highlight=sqs#sqs
https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/
https://medium.com/@reach2shristi.81/identity-based-policy-vs-resource-based-policy-in-aws-iam-7f3f1caf12b