This week, the Internet was abuzz with HeartBleed,a vulnerability in OpenSSL. This meant many secure websites and webservices, protected by OpenSSL, suddenly became a security risk and OpenSSL (and open source software, in general) suddenly became a lot less trustworthy.

About HeartBleed

The HeartBleed bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure Internet traffic. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs). CVE-2014-0160 is the official reference to this bug.

The HeartBleed bug allows anyone to read the memory of the systems ‘protected’ by the vulnerable versions of the OpenSSL software (versions 1.0.1 through 1.0.1f). This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

HeartBleed and Microsoft

In formal communications, only when you’ve installed and configured OpenSSL you’d need to take action, when running Microsoft Operating Systems (OSs).

While this is strictly true, in the modern world of Single Sign-On and claims-based authentication, this might not necessarily be the right way to look at it…

Single Sign-On

Many organizations have implemented Single Sign-On (SSO) by integrating their applications into Active Directory Domain Services (AD DS). While Active Directory, itself, was not affected by HeartBleed, any application or service utilizing OpenSSL and integrating with said Active Directory can be used to leak information from Active Directory like usernames, passwords, SIDs  and token information.

Also, the private key used may be leaked, which, in turn, might contain information for a targeted attack against Active Directory Certificate Services (AD CS) and services relying on it, like Active Directory Rights Management Services (AD RMS).

Not until these OpenSSL implementations have been updated, the certificates in use have been replaced with different certificates (with a different private key) and users have changed passwords, the situation might be resolved.

Conclusion

Indeed, one single link in the authentication chain might cause the entire chain to fail…

Solutions

To remedy such a situation, first, the vulnerable version of OpenSSL should be upgraded to at least version 1.0.1g or recompiled with -DOPENSSL_NO_HEARTBEATS. Additionally, any certificates in use by the OpenSSL implementation need to be reissued.

From there on, you might ask or force users to reset their passwords, unless you’ve already deployed a multi-factor authentication solution. When a security token is required, a malicious party can not login to a service with just the password alone.

Claims-based authentication

So, claims-based authentication, must be safe then? Passwords can’t leak from OpenSSL, when the OpenSSL process (or deamon) doesn’t have it, right?

While it’s true that OAuth2, OpenID Connect and SAML2 endpoints at resource providers may not leak passwords, because these endpoints typically only have signed tickets, other risks are still present. Also, the endpoint of the identity provider might be protected by a vulnerable implementation of OpenSSL…

When you’re the resource provider in a claims-based authentication implementation, you should make sure the identity provider you have federated with are not running vulnerable OpenSSL implementations. Their signing key may have been compromised and, thus, a malicious party could sign tickets as if they would have originated at the identity provider.

When you’re the identity provider in a claims-based authentication implementation, you should make sure the resource providers you have federated with are not running vulnerable OpenSSL implementations. Examples of affected resource providers are Facebook, Yahoo and Google. The private key of their implementation(s) may have been compromised and a certificate may have been issued that allows a malicious party to pretend to be your resource provider to get signed tickets from you.

Conclusion

Indeed, one single link in the authentication chain might cause the entire chain to fail…

Solutions

To identify vulnerable identity and/or resource providers, use the tools at Filippo.io and/or the list on Mashable. Contact vulnerable identity and/or resource providers to have them upgrade their OpenSSL implementation(s) to at least version 1.0.1g or have their OpenSSL implementation(s) recompiled with -DOPENSSL_NO_HEARTBEATS. Additionally, they should reissue the certificates used by the implementation(s). 

From there on, you might ask or force users to reset their passwords, unless you’ve already deployed a multi-factor authentication solution.

Further reading

The Heartbleed Bug
Vulnerability Summary for CVE-2014-0160   
OpenSSL Security Advisory [07 Apr 2014]   
How to Protect Yourself From the Heartbleed Bug 
Information on Microsoft Azure and Heartbleed  
Heartbleed bug puts the chaotic nature of the Internet under the magnifying glass