Article Title:
Exploiting AWS IAM’s Eventual Consistency: A New Persistence Threat
In the realm of cloud security, a recent discovery has unveiled a critical persistence technique within Amazon Web Services’ (AWS) Identity and Access Management (IAM) system. This technique exploits IAM’s eventual consistency model, enabling attackers to maintain unauthorized access even after defenders have deleted compromised access keys.
Understanding Eventual Consistency in AWS IAM
AWS IAM, like many distributed systems, operates on an eventual consistency model. This design choice allows the system to scale efficiently across various regions and replicas. However, it introduces a delay—typically around 3 to 4 seconds—before updates to resources such as access keys or policies are fully propagated throughout the system. During this brief window, deleted keys remain functional, presenting a potential security loophole.
The Exploitation Process
Security firm OFFENSAI conducted tests across regions like us-east-1 and eu-central-1, confirming this consistency lag. In a simulated attack scenario, a defender deletes an access key using the command:
“`bash
aws iam delete-access-key –access-key-id AKIA… –user-name bob
“`
Immediately after, an attacker can exploit the delay by creating a new access key:
“`bash
aws iam create-access-key –user-name bob
“`
Despite the deletion, the original key remains valid for API calls during the propagation delay. This allows attackers to list keys, receive an empty array, or generate new ones before the invalidation process completes.
Implications for Incident Response
This persistence technique extends beyond access keys to other IAM components, including policy attachments, role deletions, and login profiles. Traditional incident response strategies may fall short in addressing this issue. For instance, attaching deny-all policies like AWSDenyAll during the delay period is ineffective, as attackers can detect and detach them by continuously polling APIs like ListAccessKeys.
AWS’s Response and Recommendations
AWS acknowledges the eventual consistency model and its implications. An AWS spokesperson stated:
IAM uses a distributed computing model called eventual consistency. This means any changes that you make in IAM (or other AWS services) take time to become visible across endpoints. Some delay results from the time it takes to send data from server to server, replication zone to replication zone, and Region to Region. IAM also uses caching to improve performance, but in some cases, this can add time.
To mitigate risks associated with this delay, AWS recommends:
– Avoiding long-term IAM access keys due to their indefinite validity and potential for theft or accidental disclosure.
– Utilizing temporary credentials generated via the AWS Security Token Service (STS) or leveraging IAM roles and federation for programmatic access to AWS services. These methods offer time-limited access that automatically expires.
– Following the credential cleanup procedure published on AWS re:Post to address potential security issues.
OFFENSAI’s Recommendations
OFFENSAI suggests implementing account-level Service Control Policies (SCPs) via AWS Organizations to deny all actions for compromised principals. Since attackers lack control over SCPs, this approach can effectively prevent unauthorized actions during the propagation delay. After the delay period, organizations should proceed with thorough cleanup procedures to ensure security.
Conclusion
While no in-the-wild exploits of this technique have been reported, organizations must integrate awareness of IAM’s eventual consistency into their security protocols. By favoring IAM roles and STS temporary credentials over long-term keys and implementing robust detection rules, businesses can minimize exposure to this persistence threat.
