Multifactor solutions have become the end all and be all of remote access security control. Thanks to password reuse, poor password selection and phishing attacks, the username and password combination is just not good enough.
In fact, multi-factor authentication is such an expected security standard now that I would be surprised if an organization could get cyber insurance if they did not have an MFA solution in place, assuming they were not already completely compromised with ransomware.
So, what if I told you that I have observed, through security data, seeing upwards of 4% or more percent of your employees could be negating the value of MFA by accepting unsolicited push notifications – effectively allowing a malicious actor to bypass the controls offered by that second factor?
This might not seem like a lot, but when combined with poor password selection, password reuse, or password spraying attacks – the numbers align to create a loophole that is just big enough to be a significant concern.
Multi-Factor Authentication serves to reduce the threat to authorized access by requiring an additional form of authentication above and beyond the basic username / password combination. This add-on often takes the form of a one-time passcode delivered via fob, pre-generated list, SMS, email or USB token.
In more secure environments, there are solutions that leverage certificates, fingerprints, or smartcards. However, thanks in part to the ready availability of the smartphone platform, perceived increased security and ease of use, mobile push has become a growing piece of the MFA space to the point where, according to Gartner, “50% of enterprises using mobile authentication will by 2020 adopt out of band mobile push as a mainstay of authentication ”.
One reason that push mobile authentication is considered a secure option is because it is encrypted end to end, which prevents data tampering. In addition, since app based push interactions are tightly tied to a specific device, a PIN or biometric validation will be required before the push can be accepted.
Another aspect to push notification that provides an extra security perk is that the end user can detect and report on fraudulent unsolicited requests. With active monitoring of the fraudulent reports, a security team can be alerted to when an account is compromised and can quickly take action.
While there are some security benefits to push notification, there are still some inherent flaws that can be exploited or abused by those who wish to avoid dealing with being slowed down by MFA.
Answering app abuse. Apps like are available to those who wish to avoid having to interact with 2FA solutions. These apps will emulate or trick the app into thinking someone has answered the phone or accepted the push.
Delegated answering service. During the enrollment process, it is possible to insert someone else into the workflow and effectively delegate them to approve the 2FA push / call. For example, a significant other or secretary may be asked to just approve any request.
Unsolicited answering. As we initially stated, there are a number of people who will simply approve an unsolicited request. Much like those who click on phishing email links, this is an awareness opportunity to educate users about the potential consequences.
Registration race conditions. Depending on how a 2FA solution is rolled out, there could be users who have never remotely authenticated and triggered the 2FA solution mobile enrollment. During this gap, the account is effectively not protected, and to complicate the issue, if the account is compromised, the attacker can enter their own device as the 2FA device.
How can we detect when someone implements an automation tool to always accept a 2FA push and / or help raise awareness for those users who are likely to accept unsolicited 2FA pushes?
The answer is found in creating phushing awareness, or two-factor push phishing awareness.
In short, most enterprise level 2FA solutions have an API integration that allows them to be leveraged by third party applications. This allows an organization to create a 2FA protected experience into SaaS solutions, RDP, security and networking appliances, etc. However, it is also possible to leverage this API to perform user testing / phishing.
With the technology in place, an awareness program can be expanded to include a quarterly 2FA phush test, with close scrutiny on those who fail. While there will always be a small number of those who fail, repeated failures could be a strong indication of a negligent user or automated answering.
On the positive side, with a little notification and campaign around the exercise, the innovative security team could even reward those who report the event as ‘fraudulent’, which is a huge win in the event of a real incident.
Target phushing with recent authentications to capture people during their active hours. This will reduce issues related to off-hours employees and allow for more interactive follow up.
Create a positive awareness follow up to educate users and focus on getting them to report invalid pushes as fraudulent.
Use a dedicated API interface for phushing campaigns and name it something close to the valid ‘application’ so the logs are separate, but the view is similar to the valid push display.
Notify your security operations center and help desk before a phushing campaign, and space out the pushes so that there is not a huge impact on the help desk.
Consider funneling your phushing campaign through a foreign IP address for additional end user training points.
Helpful API tools
MFA solutions add great value to reducing risks associated with common username / password compromises. While there are numerous options, the push Mobile out of band method is growing in popularity because it is generally more secure, more user friendly, and has feedback options for fraudulent reporting.
Despite this, there remains vulnerability, thanks to clever folks who look to automate the push interaction and those users who simply accept unsolicited push requests.
Fortunately, most MFA providers have the ability to integrate via API, which allows a security team to create a phushing tool that can send fake push notifications to their users to build awareness. This will give the security team the data needed to reduce the risk associated with push vulnerabilities.
Ultimately, without assurance activities designed to test and validate, are you sure your users aren’t phushovers?
Seth Fogie is the Information Security Director at Penn Medicine.