In the Meantime
As we discussed in our previous article, The Right Way to MFA – Part 1, U2F is the “most right” answer from a strictly-security perspective…but it may not be the best business choice at this time for some organizations. At this time, very few organizations have moved to U2F and most organizations still employ a classic form of MFA. As such, we will focus the second part of this article on how to best secure MFA, if U2F is not an option.
Multi-Factor Authentication Attacks
In addition to the real-time replay attacks that we discussed in the first article, there are several other ways that cyber adversaries are exploiting multi-factor authentication login portals. Common attack vectors include:
- Guessable Security Questions – Security questions are one of the weakest forms of MFA (and as discussed in the previous article, arguably not MFA at all). Security questions are commonly bypassed through answer guessing, intelligence gathering of publicly accessible information about the target, social engineering, or even brute forcing.
- Username Enumeration – If a username is requested first (completely decoupled from a request to enter either the password or the second factor), and then one response is returned for legitimate users (such as requesting for a password, second factor token, etc.) and a different response is returned for non-legitimate users (such as prompting again to login, or rejecting the request), an attacker can easily automate the process of enumerating the usernames on that platform.
- Password Harvesting – Even if your MFA implementation does prevent attackers from gaining access to a particular service, this still does not always stop attackers from compromising passwords. If a service prompts for username/password in the first step, and then prompts for the second factor upon successful submission of those, this distinct response confirms the correctness of the guessed passwords. And those compromised passwords could potentially then be used to access other services and/or leveraged in a multi-stage attack to gain access.
- Compromise of OTP Out-of-Band Delivery Mechanism – Some platforms will use SMS or Email as a second factor. It probably goes without saying, but if either of these are compromised, MFA is effectively bypassed.
- Persistence Attacks – If a session is compromised (via a real-time replay attack), the attacker will likely try to establish persistence by either disabling and/or reconfiguring MFA, such that the token is now originated on a device controlled by the attacker.
Recommendations
To reiterate from the first article — the best way to minimize your attack surface is to adopt U2F. But in the meantime, we have offered some additional suggestions that can be used to minimize the risk and exposure to services using legacy MFA.
Do not use Security Questions, SMS, or Email
Even among legacy forms of MFA, the options of security questions, SMS, and Email have long-been considered the least secure options. Security questions are guessable. And SMS and email are independently susceptible to compromise (because of their general use beyond just authentication). So even if you are using a legacy form of MFA, these should be avoided, if at all possible.
Re-prompt for new MFA token for configuration changes
If an attacker does manage to gain access to a user’s session via a real-time replay attack…they will only have access for the duration of that session. However, if they can disable MFA, or reconfigure MFA for that account, they can potentially establish persistent access. To prevent this from happening, you should always re-prompt for a new MFA token, before authorizing any configuration changes. While an attacker can manipulate a person into logging into a fake portal (to replay their credentials), it is significantly less likely that they could then also manipulate that same person into providing another MFA token to authorize changing the configurations of the account.
Track IP address and Web Session Correlation
To create a real-time replay evil-clone web service, you have to host it on public infrastructure, and it has to be accessible on the public Internet so the victim can get to it. Because of this, it is not uncommon for attackers to host the malicious web-service on a remote server, and then subsequently attempt to access compromised sessions via a local workstation. To do this, they would need to copy the HTTP session tokens from the server and replicate them on their local browser. An easy way to detect this activity, is to alert on events where a login is executed from one IP address, and then the session is subsequently accessed (with the same session token) from a different IP address.
It’s worth noting, that a sophisticated attacker can still remain undetected by using traffic redirection, port forwarding, or SOCKS proxies to ensure that subsequent traffic originates from the same IP address as the login.
Track Anomalous Login Behaviors
Real time replay attacks can also be detected by baselining normal activities for specific users, and then alerting on anomalies. The authentication replays in these attacks will always come from a different IP address (specifically the one on which the evil-twin portal is hosted), and will likely have other unique fingerprints (such as User-Agent, or other browser headers) that are not consistent with the end-user’s usual authentication patterns. In such cases, generating alerts for and following up on anomalies can sometimes be the most effective way to identify and stop these attacks.
Order of Operations
Finally, as unusual as it may sound, the order in which a service prompts for username, password, and MFA token have a significant impact on its security hygiene. In some cases, when using inflexible COTS (Commercial Off-the-Shelf) services, you may have little control over the authentication sequence. But when you do, as is the case with custom applications and/or customizable COTS services, you should make sure to get it right. Before we address the right way, we should explain some wrong (but often-used) orders of operations.
1 Step Process (prompt for all inputs)
A system should not prompt for all 3 inputs (username, password, and MFA token) in the same step, because doing so makes it very easy for attackers to execute the real-time replay attacks that we discussed in the previous article. To execute a real-time replay attack, an attacker usually needs to map out the authentication sequence of an application, in order to replicate it on an “evil clone” web service. If all of these factors are prompted for in the same step, no level of access is needed in order to replicate the authentication sequence – because the whole process is apparent and on the surface.
2 Step Process (Prompt for username/password, followed by MFA token)
A better option (as it provides some security through obscurity) is to prompt for the username and password in the first step, and then request the MFA token in the second step. This is likely the most common order, and while its better than all-at-once, it also has its pitfalls. This approach is problematic because it still allows attackers to compromise passwords (even if they don’t necessarily gain access to the service at that time). If an attacker knows that an MFA prompt signals that a username and password combination was correct, they can still effectively compromise passwords, which could potentially be used in other attacks.
3 Step Process (Prompt for username, then password, then MFA token)
Another option would be to prompt for each of these factors in a different step. You could prompt for the username, then the password, and then the MFA token. However, this is also problematic. If you prompt for the username, then password, then the MFA token – you could still fall victim to password guessing attacks as discussed above (since a prompt for the MFA token would confirm successful username and password entry).
3 Step Process (Prompt for username, then MFA token, then password)
You could prompt for the username, then the MFA token, and then the password. This is a better option, as it would effectively mitigate password enumeration, because you would need to supply the MFA token first. An attacker could enumerate valid MFA tokens, but if an attacker compromises the MFA token, it is only valid for (in most cases) 30 seconds to a few minutes, giving them no additional edge. But ultimately, this is still problematic because it allows an attacker to enumerate usernames (which could be used in other attacks). If I guess a username, and am prompted for the MFA token, I know that it is a valid username.
The Best Order
The best option, which minimizes the risk of all of these attacks is a two-step process, where the system first prompts for the username and MFA token, and then (in a second step), requests the password. This provides a multi-step process, thereby requiring an attacker to map out the authentication sequence to construct a real-time replay attack. It also mitigates the risk of password enumeration, as the password authorization is the last step in the sequence. And it eliminates the risk of username enumeration, because a username’s validity is only confirmed if a user supplies a valid MFA token at the same time.
Conclusion
Now, more than ever, the world is moving to a remote workforce. And strong authentication practices are suddenly more important than they have ever been. We hope that these insights and recommendations have been helpful. Be on the lookout for our video series starting on Tuesday, May 5, that will go through some of these same concepts. And as always, are open to discussion on how we can help.
***
This blog was written by Justin Hutchens, Consulting Services Practice Lead at Set Solutions.