More and more organizations are continuing to outsource and fulfill needed services with third-party partners and cloud services providers. Unfortunately, this increasing reliance on third-parties can also increase the organizations’ exposure to risk, and we continue to see more breaches of third-party systems. Attackers are targeting technology providers with direct access to multiple customers, versus trying to compromise customer systems individually.
By definition (and included in basically every information security recommendation since 2015), the use of multifactor authentication (MFA) improves organizational security and reduces the risk of a data breach or of an unauthorized individual being able to gain access to an account or device. However, the amount of true risk reduction realized by implementing MFA depends greatly on how it is configured. When the technology isn’t securely implemented or shortcuts are taken, it can actually end up introducing unexpected security gaps. With the COVID-19 pandemic and the dramatic shift to remote environments, many technologies were implemented in a short time without a lot of forethought or planning. MFA may have been quickly implemented as a “check the box” compliance/security solution using the default configuration settings. Unfortunately, by doing so, additional vulnerabilities could exist and could end up allowing hackers to side-step authentication. This federal cybersecurity advisory comes at a good time, as many organizations are implementing a return to office strategy, and is a good reminder that default settings are never secure and should always be reviewed and customized.
The recent technique used by hackers involves taking advantage of accounts that have errant MFA configurations, enabling them to enroll a new device in the system. Via that new device, the attackers then leverage the known “PrintNightmare” exploit to execute code and gain unauthorized system access without being detected. The first documented attack using this technique was in May 2021 in which attackers were in possession of compromised credentials from an inactive but valid account with a password that was obtained via brute force guessing. The organization’s MFA allowed for re-enrollment of a new device on the account, which was then used to obtain a low-level authentication. Key to this attack approach is the “fail open” policy that some MFA implementations have, which instructs the system to validate a login if the MFA server proves to be unreachable.
This is an easily avoidable risk and requires organizations to enforce the following:
- Review and enforce MFA configuration policies to ensure “fail open” and device re-enrollment are not possible for inactive accounts.
- Disable accounts uniformly across the Active Directory and MFA systems.
- Keep up to date with security patching of devices, software, applications, and VPNs.
Other basic security recommendations include:
- Enforce MFA for all users without exception.
- Ensure time-out and lock-out features are in place to prevent repeated login attempts and counteract brute force and other password guessing attempts.
- Require strong and unique passwords that are not reused.
- Implement security alerting policies for all changes to security-enabled/administrative accounts or groups.
- Deploy MFA with physical security tokens or authenticator applications.
- Monitor network traffic for unapproved and unexpected protocols to identify possible malicious activity.
Enforcing MFA for all users without exception may seem like an impossible task, however, organizations should be able to take the stance that users are comfortable using technology for everyday life responsibilities like online banking, so they can also understand (and take an extra step) to securely access sensitive systems at work. The importance of securing the information far outweighs the slight delay that users may incur.
In some environments like higher education, controls may be relaxed initially to ease the roll out of MFA to allow for staff/faculty familiarity and resistance to additional security controls. Information security teams are always fighting the balance between securing systems and day-to-day business operations. This is where it can be important to recognize that an MFA deployment does not necessarily need to be a one-size-fits all. It may be necessary to apply more stringent controls and requirements to those systems and employees accessing more sensitive data.
Periodically test the effectiveness of your organization’s MFA through regular audits. It can be difficult for the team members responsible for configuring and managing the MFA deployment to identify missed steps or possible gaps in security, so an outside review can uncover potential vulnerabilities in both the security configurations as well as any human shortcomings (e.g., procedural mistakes or gaps).
For example, if a user’s initial password was compromised, would they then respond to a push notification from Duo? Do end users know to report fraudulent push notifications? Perhaps even more important is a test of your organization’s Help Desk staff. Would they willingly provide a caller with credentials if they provided a compelling story of why their access was failing? Are there specific procedures for verifying identities before granting access? Could your Help Desk potentially be phished?
Engaging a third-party to test current processes and attempt to social engineer staff to identify weaknesses in operations, can be valuable and is certainly better than waiting for a real-world attacker to exploit potential vulnerabilities. A security assessment can evaluate if MFA has been inconsistently deployed or applied across systems, and if any critical systems are at risk for compromise.
Additional guidance from the CampusGuard Offensive Security Services team below:
[Campbell]: As an ethical hacker, encountering an application that uses multifactor authentication is a pain. It takes a lot of time and a fair amount of luck with social engineering a user to bypass it. When given the choice, I’d immediately divert my attention to something less secure. Most malicious actors tend to have the same methodology when running into applications with MFA.
That series of events highlights the importance of having MFA deployed as it slows attackers down DRAMATICALLY. Although unless all of your systems and applications have MFA deployed, you’ll always only be partially protected. And as the article illustrates, your MFA must also be configured and deployed effectively to realize true risk reduction.
