This month, we will be covering a component that is a little older, but probably to the surprise of many, very widely used across a variety of ecosystems. Considering the type of vulnerability the attack vector leverages, use of this component could be catastrophic.
Introducing CVE-2014-3603, and the absence of hostname authentication when using OpenSAML.
Name of the Vuln/Sonatype ID: CVE-2014-3603
Type of vulnerability: Man-in-the-Middle (MitM)
Components affected: Versions of the Shibboleth Identity Provider < 2.4.1, Versions of OpenSAML Java < 2.6.2
The HttpResource and FileBackedHttpResource implementations in OpenSAML and the IdP make use of the Jakarta Commons HttpClient. When used with an HTTPS scheme, HttpClient by default does not perform verification of the server hostname against the server's X.509 certificate.
The Attack Mechanics:
The lack of hostname verification means that while the connection between the client and HTTPS server is encrypted, the client has no way to verify it's actually communicating with the appropriate HTTPS server hosting the resource data. This means a malicious actor could exploit this verification gap by crafting specific attacks to gain access to sensitive data as well as gain access to similarly authenticated applications.
In the vulnerable versions of the IdP component, `service.xml` typically utilizes the HttpResource and FileBackedHttpResource classes to retrieve remote configuration files over an HTTP connection. In certain cases, these classes may also be used within `relying-party.xml` along with ResourceBackedMetadataProvider as a part of the workflow.
A Real-world example:
Let’s use a banking application as an example.
Imagine going to HTTPS://YourPersonalBank.com in your web browser but instead of seeing the real bank, you see what the hacker has hosted on a bogus server. It LOOKS like YourPersonalBank.com, it feels like YourPersonalBank.com, but it isn't.
With proper hostname validation in place the application, for example your web browser, would warn you that the certificate from the hostname server is a mismatch and alert you to the fact that you might be compromising yourself by entering your credentials as you normally would.
Image: Typical warning generated by web browsers when there is a mismatch between the certificate hostname and the domain being visited
But with a more sophisticated spoof and no warning about the mismatch, you enter your credentials. Instead of going to the bank’s server, however, your credentials go to the hacker or the man-in-the-middle.
MitM attacks take on many forms and are certainly nothing new. However, the widespread use of components, such as this one, that don’t perform a proper hostname certificate check leave organizations wide open to this sort of hacker initiated interference.
Let’s take it one step further. When logging to a web application using your Google or Facebook credentials, if one of the authentication services is using a vulnerable version of the OpenSAML Java component, the authentication data, including your credentials may very well be going to a malicious destination, without any obvious indication of such happening.
The best remediation path:
If you are using versions of the Identity Provider < 2.4.1, and versions of OpenSAML Java < 2.6.2, upgrade to the version that supports certificate matching: IdP 2.4.1 or greater, OpenSAML Java 2.6.2 or greater. Additionally, there are some workarounds available.
DevOps-native organizations with the ability to continuously deploy software releases have an automation advantage that allows them to stay one step ahead of the hackers. Customers of Sonatype Nexus were notified of CVE-2014-3603 within days of the discovery. Their development teams automatically received instructions on how to remediate the risk.
If you're not a Sonatype customer and want to find out if you're using the vulnerable version of IdP or OpenSAML in a specific application, you can use Sonatype's free Nexus Vulnerability Scanner to quickly find out.
Visit the Nexus Intelligence Insights page for a deep dive into other vulnerabilities like this one.