Security Patch for IdentityServer (CVE-2024-39694)

Today we are publishing a hotfix for all supported versions of Duende.IdentityServer that addresses CVE-2024-39694, a moderate severity open redirect security vulnerability. We encourage everyone to update to the latest patch version. Note that by itself, this vulnerability does not allow an attacker to steal tokens or user credentials. An attacker would most likely exploit this vulnerability to make phishing attacks more likely to succeed.

We have also published a security advisory with technical details about the severity, affected versions, specific APIs involved, and work-arounds for those who can’t upgrade to a patched version.

In this blog post we’ll discuss open redirect vulnerabilities more generally, the process we followed to manage disclosure of the issue and patch, and lessons learned from that process.

Open Redirects

An open redirect is a vulnerability where an attacker is able to control where an end user is redirected to. Attackers typically exploit this to make phishing attacks more realistic and therefore more likely to succeed. If the user begins in a trusted location, they will be less likely to notice if they are sent to an untrusted location.

For example, a victim might be sent a malicious Url that prompts them to log in. This user might be suspicious of the Url, so they check that the location of the login screen is what they expected and that the lock icon was present in the location bar. Satisfied with the authenticity of the login site, the user then logs in. Unfortunately, an open redirect vulnerability has allowed an attacker to control where they are sent next. Instead of my-example-bank.com, the user is redirected to my-example-bank.evil.com, which is a phishing site that looks exactly like the login screen does when the user mis-types their password. Since the user started in a trusted place, they’re less likely to notice that they are not where they should be, and may well “re-enter” their credentials, giving the attacker their password.

IdentityServer defends against open redirects extensively. For example, the redirect_uri and post_logout_redirect_uri protocol parameters must be an exact match with a configured value in order for those parameters to be used during a protocol flow. When redirecting internally (for example, between the login page and the authorize callback), IdentityServer only allows redirects that are local. The vulnerability that we’re fixing today attacks the validation that a Url is local. It is possible to construct a malicious Url that IdentityServer will treat as a local, trusted Url even though some browsers will follow those Urls to an untrusted third party site.

UI code calling the IdentityServer Interaction Service to determine if a URL is local is the most commonly used code path that will expose the vulnerability. The default UI templates rely on this behavior in the Login, Challenge, Consent, and Account Creation pages. Customized user interface code might also rely on this behavior. Other lower level APIs that are rarely used follow a similar code path. Again, see the advisory for the full details.

Process and Timeline

We were made aware of this vulnerability on June 6th and undertook a thorough analysis to understand the vulnerability in detail. We then created a fix for the issue. Normally, we do our development publicly on Github, but to avoid disclosing the vulnerability before it was fixed, we made these changes in a private repository.

In our vulnerability management process we’ve committed to make security fixes available to customers prior to public release. To make the fix available without publicly releasing it, we created a new NuGet feed on myget.org and published the packages there. We then sent e-mail to all licensed customers announcing that the security advisory would be published on July 31, and that hotfix patches were available for all supported versions of IdentityServer on the MyGet feed.

Lessons Learned

This is the first time that IdentityServer has had a CVE, and we would like to learn from the process. Our thoughts are below, but we’d love to get your feedback too. Send us email at security@duendesoftware.com or open an issue on the support forum and let us know what you think. Thanks!

MyGet Feed

The biggest lesson is that the MyGet feed was not convenient. To use it, you have to configure your build pipeline to use a different NuGet source and ensure that packages on myget.org can have their signature validated correctly. Signature validation turned out to be more difficult than we anticipated. Many build agents are configured to trust our NuGet packages because they are signed by nuget.org, not because they are signed by Duende Software. (The packages are always signed by us as a publisher, and nuget.org as a repository.) While we do recommend that everyone validate our signature, this clearly caused problems for some users. In future, we are considering using an alternative mechanism for delivering security fixes prior to public release.

Severity

Another lesson is that, in our initial email notifying customers of this vulnerability, we should have included more detail about its severity. We were attempting to not provide too many details in our email that would allow an attacker to exploit the vulnerability, but we should have included the severity to help organizations understand the urgency with which they should apply the hotfix. In future, we will include severity metrics such as a CVSS 3.1 score.

Conclusion

As of 8:00 AM Pacific Time on July 31, the fix has been published to nuget.org. Please apply the fix as soon as possible.