School navigation

Information Technology

OpenSSL HeartBleed Vulnerability


HeartBleed:  the openssl vulnerability

About the Vulnerability
OpenSSL is an open-source implementation of the SSL and TLS [2] protocols. SSL/TLS provides the cryptographic function for almost all secure Internet communications. One most obvious example is secure web services (https). OpenSSL is widely utilized in open-source and commercial products.


The HeartBleed bug in OpenSSL is simple and easily exploited. A “heartbeat” mechanism in the protocol allows a client to tell a server “I’m going to send you some data, echo it back to me”. The client’s request contains the data and specifies the length of the data. If the specified length is larger than the length of the data sent, the server returns an amount of data equal to the specified length with contents of server process memory making up the difference. Up to 64KB of memory can be exposed per request.

The exposed memory is in the OpenSSL service process area and can contain secret keys used certificates, user names, passwords, web cookies, and even the contents of user communications.

 

FAQ


Was LC affected?
Yes, either directly (services we operate and provide) or indirectly (services provided to us by third parties).

 

What has LC done to mitigate affected services?

We are working diligently to identify, patch, and replace certificates of affected services. 

Are LC third party services affected?

We are working with our third party service providers (vendors).

 

Should I change my password?

YES, and do not use it anywhere else (ie: your LC password should not be the same as other service passwords)

 

What do I risk?
1. Your capability to deliver secure web services, accomplished by the compromise of the secret keys associated with security certificates used by the web server that allow an attacker to intercept and decrypt all traffic and/or impersonate the server.
2. User names and passwords used to access vulnerable servers.
3. Session keys and cookies used in sessions with vulnerable servers.
4. Content of communications that occurred over vulnerable servers.
5. Other information exposed in the memory leak that could allow an attacker to mount additional attacks against the server (likely becomes irrelevant when you upgrade OpenSSL).

What other systems are vulnerable? Is my home router affected? 

Check your vendor manufacturer’s website for details and mitigation steps.

https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=720951&SearchOrder=4

 

Commonly used consumer devices we have confirmation are vulnerable:

  • LaCie BigNAS, WD MyClouds

 

How do I test for a vulnerable system?

What system administrators should do:
1. Update vulnerable servers or otherwise mitigate the risk by disabling heartbeats

2. Replace the public/private keys and SSL/TLS certificate associated with the servers.

3. Revoke the earlier (potentially compromised) SSL/TLScertificate(s).

Note:  Understand that, although absolutely necessary, revocation isn’t 100% effective because of shortfalls in client use of revocation [7]. Make sure your certificate authority is not vulnerable
before obtaining new certificates.
4. Harden your webserver configuration by requiring stronger ciphers (e.g. TLS 1.2), and enabling other security capabilities (e.g. Perfect Forward Secrecy) of your SSL/TLS services [2], [3], [4], [5], [6].


Other notes

SSH is not vulnerable to this issue as far as we know at this time.

References
> [1] http://www.ren-isac.net
> [2] http://en.wikipedia.org/wiki/Transport_Layer_Security
> [3] https://www.ssllabs.com/ssltest/
> [4] http://en.wikipedia.org/wiki/Forward_secrecy
> [5] https://owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
> [6] https://www.eff.org/deeplinks/2014/04/why-web-needs-perfect-forward-secrecy
> [7] http://www.darkreading.com/endpoint/authentication/solving-the-ssl-certificate-revocation-checking-shortfall/d/d-id/1137268
> [8] http://www.ren-isac.net/about/advisory.html#technical
> [9] http://www.educause.edu/focus-areas-and-initiatives/policy-and-security/cybersecurity-initiative/about

Credits

Thanks to the REN-ISAC Technical Advisory Group [8] and members of the HEISC [9] for assistance in assembling this notification, and to REN-ISAC members for valuable shared information.