ShutterGap Flaw Exposes AWS Resources Between Security Scans

Key Takeaways

• A new “ShutterGap” blind spot allows attackers to exploit temporary public AWS resource exposures before security scans detect them.
• This issue stems from customer misconfigurations of AWS public-sharing features, not an AWS vulnerability.
• Attackers can copy sensitive data from temporarily exposed AWS resources like RDS snapshots, AMIs, and DocumentDB snapshots to their own accounts.
• Many exposures last only minutes, far shorter than typical daily security scan cycles.
• Prevention through AWS Service Control Policies and proactive logging is crucial, as detection alone is often too late.

While Cloud Security Posture Management (CSPM) and Cloud-Native Application Protection Platform (CNAPP) tools are critical for identifying risky cloud configurations, a new analysis by Aryon Security reveals a significant gap in their protective capabilities. This blind spot, dubbed “ShutterGap,” allows for the exploitation of AWS resources that are publicly exposed for short periods, often disappearing before traditional security scans can register their presence.

The ShutterGap phenomenon occurs when an AWS cloud resource is briefly made public, sometimes for mere minutes. During this narrow window, adversaries can continuously monitor public AWS listings, quickly identify newly exposed assets, and initiate a copy to their own cloud accounts, effectively bypassing conventional defensive measures.

ShutterGap: The Ephemeral Exposure Threat

This vulnerability does not originate from a flaw within AWS itself but rather from customer configuration errors related to AWS’s public-sharing functionalities. Although AWS explicitly advises against storing sensitive information in publicly shared resources, Aryon discovered that real-world public exposures remain a frequent occurrence.

Researchers closely monitored various AWS resource types that support public sharing, including Amazon Relational Database Service (RDS) snapshots, Amazon DocumentDB snapshots, Amazon Machine Images (AMIs), and AWS Systems Manager (SSM) documents. Their observations revealed a continuous cycle of resources appearing and subsequently vanishing from public view.

For instance, within a 90-minute period in the us-east-1 region, the number of publicly accessible RDS snapshots fluctuated 12 times, with six new snapshots appearing and six being removed. This dynamic activity suggests that organizations frequently, and often inadvertently, expose resources during routine cloud infrastructure creation, testing, or modification processes.

Aryon’s investigation highlighted that a significant 20% of publicly shared RDS snapshots remained visible for less than two minutes. Furthermore, 99% of deleted RDS and DocumentDB snapshots disappeared within 30 minutes of their creation. These brief exposure windows are considerably shorter than the typical daily scan intervals employed by many CSPM platforms, creating a critical detection gap.

Crucially, an attacker does not need to fully download an entire database during its brief public exposure. Instead, they can initiate a snapshot copy to another AWS account as long as the resource is publicly accessible. Once this copy is complete, the attacker can restore and analyze the database at their leisure, even if the original owner swiftly revokes public access. A small sample of 24 publicly shared RDS snapshots tested by Aryon contained substantial sensitive data, including AWS account identifiers, email addresses, potential secrets, patterns resembling private keys, and indicators of financial information. Aryon halted further data extraction once it confirmed the presence of valuable business data in these public snapshots.

The report underscores that detection alone is insufficient to mitigate exposures that attackers can exploit in mere seconds. A security alert generated hours after the fact holds little value if a snapshot has already been copied. Aryon strongly advocates for the implementation of preventative AWS controls, particularly AWS Service Control Policies (SCPs).

What You Should Do

• Implement Service Control Policies (SCPs): Utilize SCPs to block changes to snapshot-sharing attributes, enforce encryption for new RDS instances, maintain blocks on public sharing for AMIs, and prevent public sharing of SSM documents across your AWS accounts.
• Review CloudTrail Logs: Regularly examine AWS CloudTrail logs for public-sharing events. Key actions to monitor include RDS ModifyDBSnapshotAttribute, EC2 ModifyImageAttribute, and SSM ModifyDocumentPermission.
• Prioritize Prevention: Recognize that for instant exploitation scenarios, preventative controls are paramount. Configure your AWS environment to prevent public exposure by default rather than relying solely on post-facto detection.
• Minimize Exposure Windows: If temporary public sharing is unavoidable for specific workflows, ensure the exposure window is as short as absolutely possible and that the shared resource contains no sensitive data.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.