Overlooking medium and low-severity cloud security misconfigurations can have consequences
In our “Severity Matters” series, we cover how downplayed misconfigurations can lead to compliance violations, data breaches, and legal ramifications. The takeaway: it’s easy for medium and low severity misconfigurations to get lost in the noise of CNAPP and CSPM alerts, but they can actually serve as a stepping stone to higher severity attacks.
In Part 3 of this series, we break down how allowing wildcard (*) principals in SNS policies can expose internal data to malicious players.
Allowing (*) as a Principal
Overly Permissive Policies
Such configurations can lead to unauthorized access, and bad actors can leverage them to extract sensitive data from your resources.
Sample Attack Path
Step 1: Discovery and Crafting an Attack
The attacker first identifies that a wildcard (*) is specified as the principal in your SNS policies. They may do this through various means, including manually examining your AWS resources or automated scans for vulnerable configurations.
Step 2: Creating a Rogue AWS Identity
The attacker can leverage permissions from the previous step to create a rogue AWS identity, such as an AWS user, or role. This identity can be given any name, and initially configured with minimal or no permissions.
Step 3: Subscribing to SNS Topics
The attacker subscribes the rogue AWS identity to SNS topics within your AWS account. Since the SNS policy allows ‘*’ as a principal, the subscription request is accepted without challenge.
Step 4: Unauthorized Access
Now that the attacker’s rogue identity is subscribed to one or more SNS topics within your account, they can receive all notifications which flow through those queues. The information exposed depends on the usage of those topics, but often includes system events, application notifications, and other data of various sensitivity levels.
Step 5: Data Harvesting or Disruption
The attacker can leverage the unauthorized access to harvest data, gather information about your systems, or potentially disrupt your services. For instance, they could use this access to gather sensitive business data, which can then be exploited for malicious purposes.
Step 6: Exploiting Vulnerabilities
If your SNS topics are configured to publish events related to vulnerabilities or critical events within your infrastructure, the attacker may exploit these, to gain further access or disrupt your services.
Step 7: Extracting Data
If the attacker’s goal is data extraction, they can collect sensitive information from the notifications received through their rogue identity.
How to stay secure
By manually examining your AWS resources or automatically scanning for vulnerable configurations, attackers can identify if a wildcard (*) is specified as the principal in your SNS policies. Once the attacker creates a rogue AWS identity and subscribes to SNS topics within your account, they’re poised to receive notifications from all the data flowing through your queues – including system events, application notifications, and other data of various sensitivity levels.
As we’ve seen, a medium-to-low severity issue such as overly permissive SNS policies can have high-impact consequences once an attacker gains access to your environment. The best way to stay secure is to find these potential vulnerabilities amidst a sea of alerts.
