A Simple Unauthenticated Technique to Determine if an AWS IAM or root User has MFA Enabled
During the course of a security assessment, our team was performing reconnaissance on a customer’s AWS environment. The goal was to explore ways in which the target environment could be attacked while generating as little noise as possible for defenders to pick up on. One such activity was to enumerate users that could be amenable to phishing or other credential stealing attacks.
After we had built a list of root account e-mails or IAM user IDs with console access, we needed to find which would be easier targets. As security professionals we expect most users to have Multi-Factor Authentication (MFA) enabled, but in reality this is often not strictly enforced to all. So if we can exclude users with MFA enabled from our target list, we could focus our social engineering or phishing activity on the accounts where we are more likely to succeed.
Fortunately for us, the AWS Console login page provides us with an easy way to confirm if a user has MFA enabled or not. The failed authentication workflow is different for the two following groups:
- users that have MFA enabled;
- users that don’t exist, those that exist but don’t have console access, or those that exist but don’t have MFA enabled.
In our experience all root accounts and the overwhelming majority of IAM users have Console access enabled. So starting from a list of users that are known to exist and removing those that we can determine to use MFA, should leave us with a good target list for credential theft.
This is the Console login behavior for an IAM user in Group 2 when an incorrect password is entered:
Now, if the user has MFA enabled, regardless of whether the correct or an incorrect password is entered, this is shown after the Sign In button is clicked:
The same happens for root accounts, except for the fact that this does not require knowing the AWS account ID and user ID, only an e-mail address:
This difference allows an unauthenticated attacker to determine if a Console user has MFA enabled. Based on this we could easily weaponize Burp Intruder to make the process of exploiting this for many users a little easier:
It might be possible that AWS has rate-limiting and other techniques being implemented here to mitigate this, but in the small-scale tests we performed we couldn’t identify any. The one thing we noticed is that after a full login fails due to an invalid password, a CAPTCHA is presented. But never between the password is entered and the MFA is requested, or after a full reload of the login page. So this does not prevent the Burp automation from working at all.
Before writing this blog post we reported this to AWS Security, and they responded as follows:
“Thank you for bringing your security concerns to our attention.
AWS is aware of the user enumeration concern you raised and the behavior you described is the expected behavior for the Signin form. AWS chose this behavior in a decision between usability and the value of a username that you protect with MFA. Challenging users for MFA when MFA is disabled creates confusion and a high incidence of legitimate sign-in failures.
If you discover or become aware of other security concerns specific to AWS products and services, please do not hesitate to contact us again at aws-security@amazon.com.”
Written by Rodrigo Montoro, Felipe Espósito and Alexandre Sieira.
