By now most of you have likely heard of the recently announced coding error in some versions OPENSSL that can expose sensitive information stored in memory to any Internet attacker.   I want to take a moment to consolidate some of the things I’ve learned about it over the last week and provide my – hopefully correct – answers to some of the questions I’ve been asked. I’ve placed a companion audio commentary here.

1)  It’s real – and serious.  Blocks of memory data can be retrieved by anyone. 

Below is a snapshot of what an exploit of an actual vulnerable Internet-facing system revealed to me – simply by connecting to to the site and taking advantage of the vulnerability (no login/password or other credentials required). 

That “PHPSESSID” string is associated with a “session id” – a string established to indicate the associated user is logged in. By collecting enough memory you can obtain the full session id of the logged in user. You then insert it in your own browser environment, point your browser at the site, and potentially “hijack” the session. You are now logged in as that user.  Anything stored in memory is potentially retrievable as a result of this vulnerability  – including login credentials and private keys.  

2) What IS OPENSSL itself?

OPENSSL is a collection of open-source software widely used by many applications, both free and commercial, to provide secure SSL-based communications of sensitive information over a network. 

Quoting from the OPENSSL project site:

“The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library”

Short answer:

For a lot of the sites you have logged into over the last few years, its what is making the “s”  ( for “secure”) in https://<yourbankingsite.com>  possible.

Software applications can use OPENSSL to ensure that the connection between your browser and the website is encrypted.   It’s used for more than just that – but that usage is the one most people have direct experience with.   Whenever an application needs to communicate over an encrypted path, affected versions of OPENSSL may be in play. Think FTPS (encrypted FTP), SMTPS (encrypted mail), etc.

If yours is a large and diverse organization, the affected versions of OPENSSL are almost certainly present.

3) Only specific versions of OPENSSL are affected

From the OPENSSL project sites advisory:

“Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1.”  

4) A fairly large number of systems are affected – 17% of Internet sites.

Internet web-sites using open-source web servers like Apache and such can be affected.  That is what I have primarily seen on the Internet. Windows systems are less likely to directly affected – but could be indirectly affected if an intervening web proxy that handles the SSL part is between the attacker an the Windows server.

But note this:  Client systems can also be affected. And by “client” I mean your PC or smart-phone or your internal applications that communicate out to third-party systems via SSL (e.g  https ).  Any of these that use affected versions of OPENSSL may be affected.  See:  http://www.theregister.co.uk/2014/04/10/many_clientside_vulns_in_heartbleed_says_sans/

5)   What’s actually happening?  

The affected versions of OPENSSL have a piece of functionality called “Heartbeat”.    The intent was to allow two systems that have established a secure SSL-based connection to maintain an awareness of one another during the connection.  An “are you there?” heartbeat request can be initiated by either side of the connection to ensure the other side is still up.  Blocks of of data are sent back and forth during the process.   As a result of a coding error in the implementation of the heartbeat check, one side or the other of the connection can specify a larger block than they actually send.  The coding error causes the responder to reply back with a block as large as what the requester claimed. So: I’ll claim to send you 64K bytes of data as part of the heartbeat but only actually send 1byte.   You’ll send me back 64K bytes.  The first byte is what I sent you – the remaining 64K bytes are random portions of YOUR memory – stuff I should never see.   That’s what you are seeing in the image that starts this post.

Here’s an amusing cartoon that explains it nicely: http://xkcd.com/1354/

Note that either side of the “secure” connection can play this game.  Attackers can harvest memory from vulnerable servers, and malicious servers can harvest memory from clients.

6)  What do I do? 

The vulnerability was just recently disclosed – but its been in place for 2 years!.   You must assume that it has been exploited by attackers for at least months and – worst case – for 2 years.   Not good.  Even sites that are fixed now may have had the flaw – and been exploited – during that period. 

For general users:

• Check to see if the “sensitive” sites you login into are patched. But remember that just because a site is OK now does not mean it was 6 months ago.  Here are some testing sites: 

http://lastpass.com/heartbleed/
http://filippo.io/Heartbleed/
http://possible.lv/tools/hb/
https://www.ssllabs.com/ssltest/

• For sites that have patched, change your passwords now. They may have been stolen. No panic – just get it done over the next week or so.
• Do not use the same login and password on sensitive sites as you use for “throwaway” sites.   This is a common mistake.  Attackers will check to see if that password you use for trivial sites is the same as the one you use for banking. 
• Make sure your mobile devices ( Android-based systems in particular) are patched.
• As with every “Internet event” – watch out for phishing campaigns that attempt you to get to download “fixes” for the problem or encourage you to visit unknown “https” sites.  Attackers will attempt to capitalize on fear and confusion.

For developers and system administrators:

•  All: Look for the presence of the vulnerable versions of OPENSSL in your environment and in any business partner environment that your application connects to.  Anywhere you rely on SSL-based encryption for security inbound OR outbound. Make sure that your business partners are on top of this.  They may need to issue new certificates after they patch affected systems. 
• Developers: 
  • Check to see if you are using a vulnerable version of OPENSSL in your code.  If so, move to a safe version or recompile with “-DOPENSSL_NO_HEARTBEATS” . Then DEPLOY!
• SysAdmins: 
  • Both nmap and Nessus have reliable tests for the vulnerability.  Use these tests now to root out all instances of the vulnerability.  Scan ALL ports, not just TCP 443.  Start with your Internet perimeter and all your business partner and customer-exposed systems first – then inside.  Upgrade OPENSSL or at least disable the heartbeat check on all affected systems. 
  • For systems that are exposed to the Internet that were affected, install new certificates.  The potential for the compromise of the private key portion of your certificates is real – and could have happened some time ago.
    
  • Ask your business partners what they are doing. Make sure they are aware and are acting.
    
  • See if your load balancers or web proxies can help.  If you use such devices to terminate SSL at your boundary, they can potentially be used to protect against incoming Heartbleed attacks.  Talk to your vendor!

Microsolved has the ability to quickly examine your environment for the presence of Heartbleed and a host of other problems common to our brave new digital word.  If you need help, we can be there for you. 

Questions?  info@microsolved.com

Additional sources of information:

http://www.databreachtoday.com/heartbleed-bug-what-you-need-to-know-a-6730

https://www.eff.org/deeplinks/2014/04/bleeding-hearts-club-heartbleed-recovery-system-administrators

http://heartbleed.com/

http://www.us-cert.gov/security-publications/Heartbleed-OpenSSL-Vulnerability

https://isc.sans.edu/diary/How+to+talk+to+your+kids+about+%22Heartbleed%22/17943