Potential Gaps in Suggested Amazon Web Services’ Security Policies for MFA
During a recent review of current guidance from Amazon Web Services (AWS) for enforcing multi-factor authentication, Duo’s Production Engineering team noticed some documentation gaps with AWS’s suggested policies. Following coordination and discussions with AWS’s security team, we’re disclosing these gaps with the aim of generating further discussion and awareness to help customers maintain the security posture of their AWS hosted resources.
The policy in question was found in a tutorial, "Enable Your Users to Configure Their Own Credentials and MFA Settings." The goal of this policy is to improve the security of AWS Identity and Access Management (IAM) users by encouraging them to initialize a multi-factor authentication (MFA) device themselves as an additional authentication step before allowing them access to their AWS resources. The intent is that IAM users would need this MFA device to be able to perform actions for which they had been granted privileges.
We noticed, however, that an attacker could circumvent this MFA step if they had compromised a user's access keys, without needing the MFA device. Given that the purpose of this policy was to enforce MFA on users, including when access keys are used, we promptly reported this to AWS's security team and have been working closely with them to resolve the gaps. We greatly appreciate the responsiveness of the AWS team and shared this post with them prior to publication.
Specifically, we identified the following three gaps:
DeactivateMFADevice
The first gap identified was that although the documented policy allowed the ability to call "CreateVirtualMFADevice" without MFA, which was largely the purpose of this policy, it also allowed the ability to call "DeactivateMFADevice" without MFA.
As a result, if an attacker compromised your AWS keys, they'd be able to deactivate your existing MFA device that you control, and activate a new one that they control. By doing this, they would be able to use their MFA device along with the stolen access keys to authenticate as you!
AWS addressed this first gap by changing the policy on their site and sending out an email on September 25 to affected customers with the subject, "Update your AWS IAM policies to require IAM users to sign in with MFA before updating their credentials and MFA devices." An example of that email can be found below:
Policy as Applied to IAM Privileges
The next gap we spotted was the result of a common use case where this MFA enforcement would be applied to the most privileged users in the account, specifically the users that had Identity and Access Management (IAM) privileges.
The original policy did not enforce MFA on any IAM actions. An attacker that compromised your AWS keys could use this weakness to remove the MFA enforcement policy from your account, create a new user without any restrictions on them, or utilize a number of other techniques to circumvent the MFA policy.
AWS has released updated guidance for this second gap today, and we recommend that you update your policies if you were using AWS's previous guidance.
Race Condition on MFA Activation
A final gap we identified with this policy is an interesting race condition that can happen with MFA devices. If the other policy gaps were fixed and an attacker compromised your AWS keys, they could repeatedly attempt to activate a new MFA device that they control.
When you get a new device and deactivate your old device in order to activate your new one, the attacker would potentially be able to activate an MFA device that they control before you're able to activate yours.
That would give an attacker control of your user account.
You would quickly notice something was wrong, but the attacker would have a short window of opportunity with control of your user account before you'd be able to regain control.
Mitigation
This final gap is not fully resolved and will take more time for a complete fix. After discussions with AWS, it was decided to disclose this gap to ensure customers are aware of it. In response to this gap, AWS has implemented rate-limiting to reduce the likelihood of this attack being successful and they continue to investigate a more secure long-term solution.
As an AWS user, you can proactively safeguard your users by actively monitoring your CloudTrail logs. You can spot an attacker attempting to use this technique by looking for failed calls to "CreateVirtualMFADevice." Since the race condition is only in effect when you switch MFA devices, an additional safeguard would be to rotate your credentials just before you replace your device. Both of these best practices will soon be included in AWS documentation.
As part of this post, we're releasing rules for StreamAlert [https://github.com/airbnb/streamalert] to detect these gaps in your CloudTrail logs.
Conclusion
We'd like to thank the AWS security team for responding to our concerns to quickly fix their guidance and taking the steps to identify and reach out to their customers to disclose these gaps.
We hope that this post provides security benefit to you and your organization. If you’re interested in the intersection between security and running a highly-available service on AWS, please contact Duo's Production Engineering team at prodeng-ext@duo.com.