Full Report
There are many, many ways to login to AWS. The console and the CLI via Access Keys and Secret Keys is one of them. Multi Factor Authentication (MFA) can be setup to work on the CLI as well. To do this, a user needs to get temporary credentials via the AWS STS service, as documented in the AWS official documentation. There's a slight oversight with the IAM policy being used for this though: a user can call iam:CreateVirtualMFADevice on the user being logged in! This is the capability to add an MFA device for the user. The author of the post bought a Hardware OTP and enabled this. Now, they had just bypassed the AWS CLI based MFA from the default policy in the documentation. Principle of least principle really bit them on this one. It's a good reminder how important writing tight permissions is. Overall, good string of tweets for a interesting MFA bypass on AWS.
Analysis Summary
# Vulnerability: MFA Bypass via Overprivileged IAM Policy Documentation
## CVE Details
- **CVE ID**: N/A (Cloud Service Provider Configuration Issue)
- **CVSS Score**: Estimated 8.1 (High) - `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N`
- **CWE**: CWE-280 (Reading/Identity Management Errors), CWE-732 (Incorrect Permission Assignment)
## Affected Systems
- **Products**: Amazon Web Services (AWS) Identity and Access Management (IAM).
- **Versions**: N/A (Cloud Service).
- **Configurations**: AWS accounts utilizing the specific "Condition" logic documented in official AWS guides to enforce MFA for CLI/API access (specifically those using the `aws:MultiFactorAuthPresent` key).
## Vulnerability Description
The vulnerability stems from a "Principle of Least Privilege" failure in AWS's own documentation for enforcing MFA on the CLI. The recommended IAM policy templates included a logic flaw: while they restricted most actions until an MFA token was provided, they inadvertently allowed users to call `iam:CreateVirtualMFADevice` and `iam:EnableMFADevice` on their own user identity *before* MFA was established.
An attacker or compromised user with valid Access Keys—but lacking the physical MFA device required by the policy—could programmatically register a *new* MFA device (like a hardware token or a virtual TOTP app) to that account. Once this second device was registered, the user could satisfy the MFA requirement, effectively bypassing the security control intended by the original administrator.
## Exploitation
- **Status**: PoC available/Demonstrated.
- **Complexity**: Low (Requires valid Access Key/Secret Key).
- **Attack Vector**: Network (API-based).
## Impact
- **Confidentiality**: High (Allows access to resources protected by MFA).
- **Integrity**: High (Allows modification of resources and security settings).
- **Availability**: Low.
## Remediation
### Patches
- **AWS Internal Fix**: AWS has updated their official documentation and the underlying service behavior to prevent this specific bypass in their recommended policy templates.
### Workarounds
- **Policy Audit**: Review IAM policies for statements that use `Bool: {"aws:MultiFactorAuthPresent": "false"}`. Ensure that sensitive `iam:*MFA*` actions are explicitly denied unless the user has *already* authenticated with a pre-existing, administrator-approved MFA device.
- **Service Control Policies (SCPs)**: Implement an SCP at the Organization level to restrict who can create or enable MFA devices, limiting it to specific administrative roles or trusted IP ranges.
## Detection
- **CloudTrail Logging**: Monitor for `CreateVirtualMFADevice`, `EnableMFADevice`, or `ResyncMFADevice` API calls that originate from CLI/SDK sessions not already authenticated with MFA.
- **IAM Credential Report**: Regularly audit the `mfa_active` and `mfa_device_configured` status for all IAM users to identify unexpected new devices.
## References
- **Original Research**: hxxps[://]x[.]com/junorouse/status/1652730902412398592
- **AWS Documentation (Updated)**: hxxps[://]docs[.]aws[.]amazon[.]com/IAM/latest/UserGuide/reference_policies_examples_aws_my-sec-creds-self-manage.html