Vulnerability Allows a Second Factor for One Account to be Used for All Accounts in an Organization
A simple vulnerability in Microsoft’s Active Directory Federation Services (ADFS) can lead to catastrophic results. The flaw (CVE-2018-8340) was discovered by Okta researcher Andrew Lee; and patched by Microsoft in this month’s Patch Tuesday security updates.
ADFS is used by third party vendors, such as Okta, Gemalto, Duo, Authlogics, RSA, and SecureAuth. It allows companies to add multi-factor authentication to their security controls. Exploiting the vulnerability allows any attacker with a valid second factor to access any other user’s account if they can obtain that user’s credentials. The flaw affects all third-party MFA vendors that use Microsoft’s ADFS.
There is obviously some work to do by the attacker; but it is not that difficult. An insider would already have one part — his or her own valid 2FA token. With that, he or she would be able to access any other employee’s account by phishing their username and password, and combining it with his or her own MFA token.
In reality, 2FA is not always difficult to crack. Earlier this month it was disclosed that Reddit had suffered a breach following an SMS intercept that gained one user’s SMS token. Alternatively, an attacker could phish for, or use a stolen database to gain ID and password, and then social engineer the help desk to reset the second factor. If he can log on as a user or process that has not yet been supplied with a second factor, then he might simply and automatically be granted one.
With just one full set of credentials (username, password and the second factor), an external attacker could phish for any other user’s credentials and gain access without that user’s second factor. If he manages to phish an admin, he has immediately hit the jackpot.
But even with lower privileges he will gain basic access to the network and can start looking for higher privileges. If he finds an admin password, this flaw will allow him to bypass any installed 2FA controls associated with the privileged account.
The flaw lies in the way in which ADFS communicates with the login process. The attacker will attempt to log in at the AD login page using two separate browsers — one for each account. He then observes the authentication flow for each login, looking for the MFA Context and the MFA token for each user. The Context is labeled such in the page’s HTML, while the MFA token appears in a script just below the context.
“By combining Bob’s MFA Context with Alice’s session cookie,” writes Andrew Lee in an associated Okta blog, “the attacker can finish logging in as Alice using Bob’s second factor and MFA Token. The attacker does not need Alice’s second factor to log into her account.”
After obtaining the session cookies, MFA Contexts, and MFA Tokens for himself and his target, the attacker first completes second-factor authentication with his owned MFA Token, then sends his MFA Context with his target’s session cookie to the AD server. The AD server confirms with the MFA provider that the attacker’s token was approved, then it logs the attacker in as the target.
The flaw is really very simple in concept. “The MFA Context contains an encrypted and signed copy of the MFA Token, using the AD server’s certificate/key pair to encrypt and sign,” writes Lee. “Therefore the AD server can verify that it issued the MFA Token. However, the AD server does not verify the relationship of the MFA Token to the identity being logged in, allowing the attacker to log in as [the target] using [the attacker’s] second factor.”
One way to verify that relationship, suggests Okta, would be for Microsoft to include the username in the signed data of the MFA Context.
The flaw was discovered by researcher Andrew Lee in March 2018. Okta first attempted to mitigate the problem within its own ADFS Agent, but found this was not possible. In April, Okta reported the issue to Microsoft, who confirmed they were able to reproduce the issue within 4 days.
Microsoft set its remediation process in action, and set a patch date in early May. In July it filed CVE-2018-8340. It arranged to release its fix on Patch Tuesday (August 14, 2018); and Okta published the vulnerability details.
Okta told SecurityWeek that it has seen nothing to suggest that this flaw has been used against any of its customers.
Related: When Multi-Factor Authentication Fails
Related: NIST Denounces SMS 2FA – What are the Alternatives?