IDENTITY PROVIDER Heartbleed recovery recommendations

Posted on Friday, 18 April 2014

The following announcement has just been sent out to everyone listed as a technical or administrative contact for one or more entities registered with the UK Access Management Federation for Education and Research. Its purpose is to provide recommendations for post-patch mitigation of the "Heartbleed" vulnerability for IDENTITY PROVIDER operators.

This advisory is for the attention of IDENTITY PROVIDER operators. It will be followed later today by an advisory for the attention of service provider operators.

If you have not seen our initial "Heartbleed" advisory, you can find it here:

 http://www.ukfederation.org.uk/content/News/2014-04-08-secadv

YOU SHOULD ENSURE that the material below is reviewed by your technical staff as soon as possible, so that you can minimise the impact of this issue on your services.

Web Server Vulnerability Impact for Identity Providers

The following web servers, among others, are known to have been affected by the Heartbleed vulnerability on systems with vulnerable versions of OpenSSL:

  • Apache
  • nginx
  • Tomcat, if configured with the APR (Apache Portable Runtime) component

If the web server hosting your identity provider was vulnerable at any time, any information visible to that web server may have been compromised. This includes:

  • All data sent to the server by a user's browser. This includes the URLs used to access content, as well as HTML form submissions and cookies used as session tokens.
  • In particular, USER IDENTIFIERS AND PASSWORDS may have been collected by attackers.
  • All credentials known to the server. This includes:
    • The private key associated with the server's browser-facing TLS certificate
    • The private key associated with the certificate used for SOAP connections, typically on port 8443, if different
    • Credentials used to access back-end services such as databases or directories

SAML Processor Vulnerability Impact for Identity Providers

The SAML processor component of your deployment may have been vulnerable to Heartbleed independently of the system's web server under the following conditions:

  • it shares memory with a vulnerable web server, (e.g., a Java application running inside a Tomcat instance configured with APR, or a simpleSAMLphp deployment sharing memory with Apache), OR
  • it uses OpenSSL to perform outbound connections.

The most common uses of outbound TLS connections from within an Identity Provider are:

  • metadata acquisition (the UK federation metadata is not served on an https:// endpoint, but some other metadata sources are)
  • access to TLS-protected back-end services such as databases or directories

If the SAML processor in your system was vulnerable at any time, any information visible to the processor may have been compromised. This includes the private keys associated with the SAML entity's KeyDescriptor elements in metadata.

Note that if the SAML entity's KeyDescriptors make use of the same RSA keys as the web server's browser-facing certificate, the SAML entity can be impersonated without the SAML processor being vulnerable to Heartbleed.

Assessing Your Risk

The Heartbleed vulnerability was introduced into the OpenSSL source code in late 2012. The window of exposure for a particular system will only begin when a vulnerable version of OpenSSL is introduced into your configuration. For example, if your vulnerability came from an upgrade of Red Hat Enterprise Linux to version 6.5 in late November 2013, that would mark the date from which your window of vulnerability would run.

At this point, it is not known whether the Heartbleed vulnerability was known before the announcement on 7th April 2014. Due to the publicity surrounding the vulnerability, however, you should in any case regard it as highly likely that your systems were attacked during the period between the announcement on 7th April and the time at which you patched your systems.

Because the attack leaves no trace in log files, it is impossible to know whether your systems have been attacked during the vulnerability window. Because of the high potential impact of the vulnerability, we therefore recommend that deployers always treat a potential compromise as an actual compromise.

Recovering From Compromises

If the private key for your browser-facing SSL/TLS certificate has been compromised:

  • Create a new 2048-bit RSA key pair
  • Use it to acquire a new certificate from your selected CA
  • Replace the certificate used by your server
  • Revoke the old certificate so that it can no longer be used to impersonate your service

If the private key for your entity's SAML credential has been compromised:

  • Create a new 2048-bit RSA key
  • Use it to construct a long-lived, self-signed certificate, see
 http://www.ukfederation.org.uk/content/Documents/SSTFCertificate
  • Contact the UK federation to arrange for a rollover of your SAML configuration and UK federation metadata

We recommend that you invalidate all identity provider application sessions to avoid session re-use by an attacker. If this is not already performed as part of the web server restart, you will need to perform this operation manually.

Any other credentials known to a vulnerable web server or SAML processor, such as back-end database credentials, should be replaced.

Further Steps

Please contact the UK federation helpdesk (service at ukfederation.org.uk) if you have any additional questions about this advisory, or if you need help in determining which actions to take to recover from the vulnerability.

-- Ian Young, UK federation

Edited by SteveGlover on 18 April 2014, at 01:53 PM (Permalink)