When a company implements multifactor authentication, the organization is usually confident that it’s using the best system possible. However, not all MFA is built the same and there are times when the MFA solution being implemented is not delivering the protection required.
Trustwave SpiderLabs teams have come across these situations while conducting penetration tests. This type of exercise, also known as a pentest or ethical hacking, is a simulated attack executed on an organization’s computer systems or physical facility to hunt for and uncover vulnerabilities. This enables security teams to identify weak spots in a company’s security posture before an adversary and one of the most important items to pentest is authentication, which leads us to the MFA problem at hand.
At Trustwave SpiderLabs we’ve found it’s generally a good idea to start in an unauthenticated position and work your way inward.
Authentication is always a good place to start for a few obvious reasons. It is literally the gateway between Internet traffic and the application/instance being assessed. If your engagement has a gaping hole in the authentication, it’s generally a really bad situation and something you’ll want to inform the development team about as soon as possible. Part of the authentication is testing an organization’s multifactor authentication solution if it’s implemented. (And if the subject being tested does not have MFA, it might be a good idea to suggest that this security measure be brought on board.)
Now, there are several very different things we can do to break through an MFA barrier. These include brute-forcing the MFA code with turbo intruder (yes you can also use the normal intruder module within burp) or getting the MFA code sent to an attacker-controlled email address. Here is one instance of a poorly implemented MFA portal that would allow an attacker to force the MFA code to their own inbox.
In the request, if it says something like:
email=client@SpiderLabs.com
you can try changing the request to something like:
email=client@SpiderLabs.com&email=attacker@SpiderLabs.com
or if it’s in a JSON request that looks like:
{“email”:”client@SpiderLabs.com”}
you can attempt to inject another email address:
{“email”:”client@SpiderLabs.com”,“email”:”attacker@SpiderLabs.com”}
There are also other methods like passing it in an array like:
{“email”:”[“client@SpiderLabs.com”,”attacker@SpiderLabs.com”]”}
Though I have had success with these methods, there are times when nothing seems to work. One assessment comes to mind when an organization’s security was hardened sufficiently to prevent these types of injections from manipulating the back end. Then I remembered a key component included with many authentication systems. It's the ability to help a user recover their login credentials. Remembering that the MFA solution had this ability enabled me to discover an MFA flaw. I found that the “Forgot Password” functionality at this organization sent a newly generated temporary password in clear text to the user via email. And… the MFA code was also sent via email.
Why is this an issue? Because in this case, MFA was not being used. This is a clear demonstration of two instances of single-factor authentication. This was clearly an oversight/misunderstanding by the development team. True MFA delivers authentication data via separate means… not using the same medium.
How is this a risk?
Let’s say an attacker gained access to a user’s email account. By having the password sent to the email address, the attacker can obtain valid credentials to trigger the first step in the login process in this application. Since the MFA code is then sent to the same email address, this implementation doesn’t provide any additional security. An attacker can log in, get the MFA code via the compromised e-mail account, and fully authenticate to the application. They can then move forward with any privileged actions (like changing the password) to establish persistence in the application.
Now the issue covered here is not something that I’ve seen often, but it did force me to get away from the technical side of the problem and look at the picture holistically. Sometimes, security issues are just based on logic and not on technical exploitation. Thinking like a hacker is just as important as being able to use tools and scripts like a hacker.
The best way to ensure that your MFA implementation is effective is to have it tested thoroughly. Self-testing does help validate some concerns, but it’s important to have a thorough assessment of the MFA controls by an offensive security team that has the tools and techniques necessary to keep application owners at ease.
