The weight of the server-side implications can’t be dismissed. However, the usefulness of stolen private keys requires the attacker to find a way to insert themselves in the middle of transactions, making the threat something short of the doomsday that has been reported. Given what I've heard about the state of ISPs, maybe this isn’t such an exaggeration. Whatever the case, the largest attack surface and the largest threat is that credentials, session tokens, and sensitive data from individuals can be exposed on vulnerable sites.
Eradication should involve patching server endpoints, testing, revoking keys that existed prior to eradication, and installing new private keys.
Once this is done, the doomsday panic is over. However, the panic has widely extended to an effort to totally eradicate the vulnerable OpenSSL libraries wherever they are found.
What’s not talked about as much (in the general public anyway) is the client-side implications of this threat. This has been referred to as “Reverse Heartbleed.” The threat is extended to the client beyond the third-party attacker client extracting data from the server. When the client itself depends on the vulnerable OpenSSL versions to establish a TLS session, a malicious or compromised server could extract data from the client using the same methods that the third-party client uses against the server.
What does this really mean to end-users? The number of clients that depend on OpenSSL reaches far and wide but is limited when you consider the colossal numbers of clients in use. Internet Explorer, Chrome, Safari, and Firefox are not vulnerable for the vast majority of people. However, Chrome on Android uses OpenSSL. Even so, this will not mean that any and all Android users are affected because they will have to have the right (should say wrong, I suppose) version of OpenSSL. Reverse Heartbleed matters to only some end-users.
Of course, clients don’t have to involve end-users. OpenSSL could be used in client software on the backend, in a B2B scenario for example.
The threat to clients is covered by The Register here:http://www.theregister.co.uk/2014/04/10/many_clientside_vulns_in_heartbleed_says_sans/.
An example that can sometimes include end-user interaction and sometimes not is VPN. However, let’s not panic too much over this. (The news about Heartbleed VPN attacks centers on vulnerable servers, not clients.) VPN clients aren’t used to browse the net after all. We know where your VPN clients are connecting most likely. It’s possible, but unlikely that your employees are connecting to VPN server endpoints outside of your control. If you’re concerned about your employees connecting in from home, you don’t really need to be if you have taken care to secure your own VPN server endpoints (including layered security, like monitoring and endpoint hardening).
Again, there is the threat of an attacker being in the middle which is actually a considerable threat when your employees connect via cafes and hotel WIFI. However, this threat should be less panic inducing than the server-side threat. We accept this threat on some level when we allow our employees to surf on their company owned laptop while connected to untrusted networks (web servers, etc.). Accordingly, this threat falls into a category that we've already considered how to manage.
Should you worry about VPN clients? It depends.
Other possible clients include a myriad of internal applications. These clients could be database connectors, internal node-to-node, appliances, automated patching, etc. Consider a client that connects to databases– it is very unlikely that these are connecting to any networks outside of your control. They are most likely connecting your reporting software to the data warehouse or an Apache server connecting an application to its databases. Similar to the VPN client concerns, the threat depends on whether there are connections to networks outside your control.
Should you worry about these clients? It depends.
I say make damn sure that your server endpoint is taken care of including detecting anyone messing with it from a lateral threat (some other attack vector, for example). From there, address the client threat the way you would any other vulnerability that doesn't get as much press and hype.
In all cases of client-side concerns, most likely the vast majority of clients have very predictable connections to things that you control. Yes, there is the possibility that these vulnerable clients could be used as a means to move laterally within your network, but that threat is true of many, many vulnerabilities that arise. In other words, this threat shouldn't be treated as the same as the panic-in-the-streets threat that Heartbleed inspires for publicly facing servers.
While I can understand the aversion to having a nuanced response to this threat, I am left wondering if there isn’t a different kind of exploitation possible. Immediately eradicating the wrong versions of OpenSSL wherever they hide in your organization will be an extremely expensive operation. Let’s call this the nuclear response to Heartbleed. Could it be that the security org is overreacting or, worse, (consciously or otherwise) exploiting the hype to justify past and future expenses?
I have an aversion to all of this cyber-warrior chatter (see RSA Conference keynotes) for this very reason. Little boys playing with guns always want bigger guns, after all.
An often repeated axiom of risk is that you don’t spend a million dollars to address the risk of losing a million dollars– otherwise you have realized your risk after all.
Those involved in the nuclear response are enjoying total support from executives who have read article after article about this apparently doomsday-level threat. However, I wonder if when the mushroom clouds disperse we won’t have some questions to answer about how smart it is to use total war in situations like this.
Reverse Heartbleed is mostly an ordinary vunerability and should be handled according to pre-April-1st-2014 practices.
This won’t be the last time we see a bug like this. Have the rules changed because of Heartbleed? I hope not.
Will we respond to the next one the same way or will we learn from this experience, including objectively measuring our response to Heartbleed to uncover mistakes, overreach, and excess spending? What if we have to respond to several like this a year? Will we go into the red and justify it by throwing around intangible threats like reputation?
Perhaps it’s easy for me to pontificate when I’m not the CISO with his job on the line. The nuanced response, after all, might leave the blind-spot that winds up being the hole that gets you a pink slip. However, with access to top-notch SMEs, intelligence feeds, quality consultants, etc. a measured response should be possible. I say this crisis is pretty much over when the server endpoints and some fraction of the client threats are addressed. After that, it’s routine vulnerability management.
Written with StackEdit.