Overview
Duo Security provides a range of multifactor options for developers to use in their systems. It is popular in many industries, including higher education.
Issue
The method for performing Duo MFA in a web page is called Duo Web. This is a fairly straightforward JavaScript that is added to a page, which brings in an IFRAME to perform MFA. The web application sends the username of the user to perform MFA, and Duo Web will respond back with a signed request once “MFA” has been completed.
Duo operates based off of what are called integrations. These integrations have several configuration settings that impact how MFA is performed. Some of those settings may result in what most would consider a bypass of MFA.
The key setting I found was the one that allowed usernames that weren’t enrolled in Duo to bypass MFA. This bypass of MFA has the exact same Duo Web response as someone who performed an MFA action. The Duo Web response indicates that the user got pass the integration, NOT that they performed MFA. Actually performing MFA is up to the configuration of the integration to ensure that all paths result in what that particular organization considers to be MFA.
Further complicating the issue, is that none of the documentation for Duo Web indicated that this was a potential path that could result in bypassing MFA.
Impact
This ambiguous response could result in systems that require MFA not being protected by MFA.
It is common in early deployments and large organizations such as universities to roll out their deployment of MFA in stages. So it is reasonable to assume that not everyone is enrolled. Even an ambitious university is unlikely to have their admitted students enrolled in MFA while admitted students complete early application tasks.
So we have a pool of accounts that will not have MFA enabled. If the integration is configured poorly as noted above, the protected application will let individuals through without those accounts performing MFA. However, higher education also is a heavy user of federated authentication through the various SAML, CAS, OAuth, etc protocols. The attributes released by SAML 2.0 and CAS 3.0 IdPs (identity providers) can include whether or not MFA has been performed. There is an international standard, REFEDS MFA, for asserting this fact in SAML.
If the IdP integration is incorrectly configured, it will then assert that MFA has been performed for every user at that institution. This assertion is then accepted by whatever service providers are accessible by that account. If that service provider requires MFA, any of those users would be allowed in. This takes the incorrect configuration of a single site, and turns it into a problem for external service providers.
Most would consider this to be a problem with incorrect configuration. There are certain communities out there that already knew of this issue. The issue is that the documentation in most cases isn’t clear that this could be a problem.
Solutions
Duo’s documentation hid this configuration behind words like “etc”, and “secondary authentication”. This is a problem. The only way to know about the configuration issue is to find it in testing. Duo’s documentation for Duo Web has been updated, in a way that I hope is more clear about the problem.
The best solution is to not configure the integration to allow unregistered users through. Both CAS and Shibboleth IdP have configuration options to only trigger the MFA workflow on certain accounts. My solution was to enable MFA workflow through AD group membership, and to set the integration to require MFA for all accounts presented. Individuals that aren’t enrolled for MFA never pass through the Duo Web workflow step. Therefore MFA is never asserted for those users.
What is untested is how any other configuration in Duo integrations impact this. It is possible that groups may also impact how this could be abused and how it needs to be managed.
As of CAS 5.2, CAS performs a Duo Auth API call before going to the Duo Web workflow. This preauth request is made WITHOUT an IP. An allow at this step in the process without an IP means that the user won’t do any sort of MFA. CAS then skips the MFA workflow and doesn’t assert that MFA happened. If this comes back as requiring MFA, the Duo Web workflow triggers, which may allow the user through based off of a remember for N days, or even if the user is at the correct IP behind a locked door if the integration is so configured. If preauth is called with an IP, then the allow returned may be from an unenrolled user being allowed through, or the user is required to perform MFA, but is at an allowed IP.
Notification
- Duo PSIRT Notification – 2018-11-07
- Duo PSIRT Conclusion – 2018-11-21
- Publication – 2019-03-24