Shay Nahari at CyberArk describes why multi-factor authentication may be less secure than you think (and what you can do about it)
Digital transformation, widespread remote work due to the COVID-19 pandemic, and an ever-increasing reliance on cloud services have all contributed to new enterprise access challenges. As a result, multi-factor authentication (MFA) has become a must-have security control for many businesses looking to help protect themselves against credential theft and make it harder for attackers to reach their goal.
The case for MFA to be considered a foundational security control is strong. Last year, Microsoft engineers revealed 99.9% of the compromised accounts they track don’t use MFA. Meanwhile, Google found even a basic two-factor authentication method — such as a text message that generates a one-time-password through cellular networks — can stop 100% of all automated attacks, 96% of bulk phishing attacks, and three-quarters of targeted attacks.
When designed or implemented incorrectly however, MFA infrastructure can be compromised and used in the attack chain. And, as attackers continue to innovate, they’re finding new and creative ways to circumvent these critical security controls for malicious intent.
Since early 2020, CyberArk’s Red Team has received a spike in MFA bypass adversarial simulation requests from organisations across the world. Throughout these engagements four main attack vectors used by threat actors to circumvent MFA controls have been identified; architectural and design flaws, insecure channels, side channel attacks, and insufficient attack surface coverage.
Here’s a look at some real-world attack examples against MFA controls:
Manipulating architectural and design flaws
Many organisations deploy single sign-on (SSO) with MFA to mitigate the risk associated with credential theft.
In a recent engagement, a large global organisation used a third-party MFA provider to secure its VPN access. Once connected to the VPN, remote users would use SSO to access various cloud services. However, during testing it was found that, when users logged in from a trusted IP within the VPN range, they were only prompted for their domain credential before obtaining access to any cloud service.
This revealed a fundamental architectural flaw; MFA was only applied for infrastructure-based access. but not for individual user identities accessing critical assets. This practically rendered the MFA controls useless and left the organisation highly susceptible to a single-factor attack.
It also made it possible for attackers to log in to the VPN, switch out users with a single user password, and access anything they wanted. This could include everything from the CEO’s email to all-powerful cloud consoles, and all they needed to do this was to compromise a user’s workstation and obtain access to a soft token application installed on that machine, an easy process for a sophisticated attacker.
Exploiting insecure token on-boarding processes
In this same case, it was also possible for threat actors to pivot into the organisation’s sensitive industrial networks protected by MFA tokens. Those who gained initial access to the IT network and reviewed user emails would have noticed something strange about the initial on-boarding process – new users were receiving emails containing a URL to pair their phone’s MFA soft token with their user identity in the company’s MFA server.
Unfortunately, that link also contained the cryptographic seed of the user’s MFA token — or in other words, the primary cryptographic key materials used to generate the token.
The good news was the seed was protected by a PIN code. The bad? With access to these cryptographic seeds, attackers only needed the PIN code and timestamp to create duplicate MFA tokens and generate a one-time pin (OTP) code on behalf of the user. This allowed threat actors the ability to brute-force the seed to any MFA token in the organisation and replicate any user’s MFA token at will — giving them full access to the industrial network.
Targeting critical assets through secondary channels
Often, when resources can be accessed through multiple channels, organisations commonly miss securing secondary channels. This is a something we see a lot during Red Team engagements.
In one particular case, an organisation had set up MFA for an admin to access certain critical servers via Remote Desktop Protocol (RDP). When a privileged user logged in using RDP to a server, Windows OS would call the MFA provider installed as a separate module. The user would receive a push notification on their phone and would need to verify the login attempt. Once they approved the request, the user would be granted interactive access to the server through RDP.
This meant if an attacker were to obtain an admin username and password for the server, they would still be prevented from accessing it over RDP, which is great news. But RDP is only one inbound interface on the server. What about other channels?
In Active Directory (AD) environments, remote management ports are enabled by default; other protocols. These protocols are exempt from second factor, meaning the attacker would be able to log in and gain access to the server using only a username and password.
Organisations need to stay one step ahead, and having a Red Team discover real-life examples, like those we’ve mentioned in this article, is vital for this. Not only does it help organisations understand evolving threats from the attacker’s perspective, but allows them to proactively defend themselves against those with malicious intent.
This is also where MFA comes to the fore as, without a doubt, it’s a critical security mechanism for our increasingly mobile world, and something which needs to be considered in the context of multi-layered Identity Security controls. Just as with any aspect of security however, design matters. Implementation matters. And, most importantly, operational security matters. A business is only as secure as its weakest link.
Shay Nahari, CyberArk Head of Red Team Services
Main image courtesy of iStockPhoto.com