Misconfigured SQS Vulnerability in AWS

Play AWS Labs on this vulnerability with SecureFlag!

Misconfigured SQS Vulnerability in AWS

Description

Amazon’s Simple Queue Service (SQS) is a fully managed message queuing service that enables the decoupling and scaling of microservices, distributed systems, and serverless applications.

Impact

SQS is often used to exchange sensitive data between applications. Misconfigured SQS queues could result in data leakage and/or loss of integrity and availability of the data present in the affected queues.

Prevention

Managing Access to Resources

Implement least-privilege access

When granting permissions, you decide who receives them, which queues the permissions are for, and the specific API actions that you want to allow for these queues. Therefore, adopting standard security advice and implementing permissions on a least-privilege basis, i.e., granting only the permissions required to perform a specific task, is essential to reducing security risks and lessening the impact of errors or malicious intent.

Use IAM roles for applications and AWS services that require SQS access

Use an IAM role to manage temporary credentials for applications or services that need to access SQS. When using a role, there is no need to distribute long-term credentials (such as access keys) to an EC2 instance or AWS service. Instead, the role supplies temporary permissions that applications can use when they make calls to other AWS resources.

Understanding resource ownership

The AWS account owns the resources that are created in the account, regardless of who created the resources. Specifically, the resource owner is the AWS account of the principal entity (that is, the root account, an IAM user, or an IAM role) that authenticates the resource creation request. The following examples illustrate how this works:

If you use the root account credentials of your AWS account to create an SQS queue, your AWS account is the owner of the resource (the resource is the SQS queue).
If you create an IAM user in your AWS account and grant permissions for the user to create a queue, then the user can create the queue. However, your AWS account (to which the user belongs) owns the queue resource.
If you create an IAM role in your AWS account with permissions to create an SQS queue, anyone who can assume the IAM role can create a queue. Your AWS account (to which the role belongs) owns the queue resource.

There are two ways to give your users permissions to your SQS queues:

Using the SQS policy system.
Using the IAM policy system.

It’s possible to use either or both to attach policies to users or roles. For example, you can do the following:

Attach a permission policy to a user/group in your account: To grant user permissions to create an SQS queue, attach a permissions policy to a user or group to which the user belongs.
Attach a permission policy to a user in another AWS account: To grant user permissions to create an SQS queue, attach an SQS permissions policy to a user in another AWS account.
Attach a permission policy to a role (grant cross-account permissions): To grant cross-account permissions, attach an identity-based permissions policy to an IAM role. For example, the AWS account A administrator can create a role to grant cross-account permissions to AWS account B (or an AWS service) as follows:
- The account A administrator creates an IAM role and attaches a permissions policy that grants permissions on resources in account A to the role.
- The account A administrator attaches a trust policy to the role that identifies account B as the principal who can assume the role.
- The account B administrator delegates the permission to assume the role to any users in account B. This allows users in account B to create or access queues in account A.

Specifying policy elements: Actions, effects, resources, and principals

For each SQS resource, the service defines a set of actions. To grant permissions for these actions, SQS defines a set of procedures that you can specify in a policy. The following are the basic policy elements:

Resource: In a policy, you use an Amazon Resource Name (ARN) to identify the resource to which the policy applies. In SQS, the only resource is the queue.

Action: You use action keywords to identify resource actions that you want to allow or deny. For example, the sqs:CreateQueue permission allows the user to perform the CreateQueue action.

SQS actions
AddPermission
ChangeMessageVisibility
ChangeMessageVisibilityBatch
CreateQueue
DeleteMessage
DeleteMessageBatch
DeleteQueue
GetQueueAttributes
GetQueueUrl
ListDeadLetterSourceQueues
ListQueues
ListQueueTags
PurgeQueue
ReceiveMessage
RemovePermission
SendMessage
SendMessageBatch
SetQueueAttributes
TagQueue
UntagQueue

Effect: Specify the effect when the user requests the specific action: this can be either allow or deny. If you don’t explicitly grant access to a resource, access is implicitly denied.
Principal: In identity-based policies (IAM policies), the user to whom the policy is attached is the implicit principal. For resource-based policies, you specify the user, account, service, or other entity that you want to receive permissions (this applies to resource-based policies only).

Make sure that queues aren’t publicly accessible

Unless it is explicitly required for an SQS queue to be accessible to anyone on the internet to read or write, ensure that queues in your AWS infrastructure aren’t publicly accessible (i.e., accessible by everyone in the world or by any authenticated AWS user).

Avoid creating policies with Principal set to "".
Avoid using a wildcard (*). Instead, name a specific user or users.

Implement server-side encryption

To mitigate data leakage issues, apply encryption at rest to encrypt your messages using a key stored in a different location from the location that stores your messages. In this context, SQS’s server-side encryption (SSE) provides data encryption at rest. SQS encrypts your data at the message level when it stores it and decrypts the messages for you when you access them. SSE uses keys managed in AWS Key Management Service.

Enforce encryption of data in transit

Without HTTPS (TLS), a network-based attacker can eavesdrop on or manipulate network traffic using a man-in-the-middle attack. As such, allow only encrypted connections over HTTPS (TLS) using the aws:SecureTransport condition in the queue policy to force requests to use SSL.

Consider using VPC endpoints to access SQS

When dealing with queues that must not be exposed to the internet, VPC endpoints can be used so that queues can only be accessed by the hosts within a particular VPC. Enforce queue policies to control access to queues from specific VPC endpoints or from specific VPCs.

SQS VPC endpoints provide two ways to control access to your messages:

Control the requests, users, or groups that are allowed through a specific VPC endpoint.
Control which VPCs or VPC endpoints have access to your queue using a queue policy.

Monitor using CloudTrail

SQS is integrated with AWS CloudTrail, a service that provides a record of the SQS calls that a user, role, or AWS service makes. CloudTrail captures API calls related to SQS queues as events, including calls from the SQS console and code calls from SQS APIs. Using the information that CloudTrail collects, it’s possible to identify a specific request to an SQS API, the IP address of the requester, the requester’s identity, the date and time of the request, and so on. Configuring a trail enables continuous delivery of CloudTrail events to an S3 bucket. However, if a trail is not configured, it is only possible to view the most recent events in the event history in the CloudTrail console.

References

AWS SQS Security AWS SQS Security Best Practices AWS SQS Authentication and Access Control AWS IAM Policy Reference AWS Logging SQS Using CloudTrail AWS SQS Identity Based Policies AWS SQS Encryption at Rest AWS SQS Key Management