A lot has been said about the global impact of Heartbleed. First, we had all the descriptions of Heartbleed – my favorite one was on xkcd. Then we saw warnings that we would need to change our password on public websites. That was followed by a warning that, since the private keys of certificates could be retrieved by exploiting Heartbleed, we should change our passwords now, wait for Web sites to change their certificates and then change our passwords again.
What has received far less attention is the fact that many of our common enterprise products (e.g., routers, firewalls, web proxies) inside our infrastructure are also susceptible to Heartbleed. Bulletins from Cisco, Juniper Networks and Blue Coat indicate widespread use of OpenSSL, the software in which the Heartbleed bug exists, in these products. Even industrial control systems from companies like Siemens have this vulnerability, which Arik Hesseldahl wrote about recently on Re/code.net. And, unlike public-facing web sites, many of which have already undergone updates to fix the bug, the availability and deployment of patches for all your infrastructure systems hits you in unexpected ways, including the need to upgrade to the newer versions of software than you are probably running, necessitating testing cycles before you can deploy it.
So, how concerned should you be about Heartbleed on the inside of your network?
To start, if the IP addresses used to manage your routers, firewalls and other infrastructure systems are reachable from the Internet without VPN access (considered a bad security practice), you should be very concerned and should either have removed direct access or patched your system by now. Assuming the management IP addresses are only accessible from inside your network, the worst-case scenario reads as follows:
Let's assess the potential risk step-by-step.
Step 1: Accept that this can happen to you; organizations have malware breaches all the time, so we should assume it has or can happen. Step 2: Hopefully you have a security solution in place to detect the scans performed in the reconnaissance phase of a targeted attack. If you don't, we have one for you evaluate and deploy :-) Step 3: An attacker who is now inside your network and uses Heartbleed to gain access to your infrastructure system is obviously very worrisome. It would be great if you had a security solution that could look for such attacks inside your network. If you don’t, we’ll be glad to supply one for you to evaluate and deploy ;-) While much of the recent press reports have focused on the theft of private keys, the loss of the private key turns out to be less threatening in an enterprise network. To use the private key, the attacker either has to listen in on other connections to the same system or must be able to impersonate the system. In the very old days of hubs, when Ethernet was truly a shared medium, listening in on another machine's traffic was as simple as placing your network interface card into “promiscuous” mode. But with switches, you only see traffic that is broadcast, multi-cast or is destined to your machine. The classic way of impersonation is via ARP tricks and only works on the subnet the attacker's host is on. If the systems’ management interfaces are on a separate subnet, often even on a separate VLAN, ARP impersonation will not work. So while the attacker may gain access to the private key of the system, exploiting the availability of the private key is not as simple as it would seem. This is in stark contrast to the problem public web sites have with Heartbleed – they cannot assume that traffic cannot be snooped upstream and with all the DNS tricks out there, they also cannot assume that someone won't be able to successfully impersonate them. Step 4: This is where the real anxiety sets in. If you followed best security practices and integrated administrative authentication on your infrastructure systems with standard identity management (e.g. Active Directory) infrastructure, the credentials that were stolen will likely be the keys to the kingdom. They can be used to access the system itself or pretty much anything your system administrators can access.
The problem is that you may have trouble determining the extent of your internal Heartbleed attack surface. You may patch all your routers, switches and firewalls, but forget to patch a printer in an obscure location that has the same authentication integration as your more important infrastructure.
It's only a matter of time – actually, it's probably already happening – before we see targeted attacks that utilize Heartbleed as one of the weapons in the attackers' arsenal to acquire key account credentials and use those credentials to get to the crown jewels.
In other words, Heartbleed is just as messy on the inside as it is on the outside.
Oliver Tavakoli is chief technology officer at Vectra. Oliver is a technologist who has alternated between working for large and small companies throughout his 25-year career – he is clearly doing the latter right now. Prior to joining Vectra, Oliver spent more than seven years at Juniper as chief technical officer for the security business. Oliver joined Juniper as a result of its acquisition of Funk Software, where he was CTO and better known as developer #1 for Steel-Belted Radius. Prior to joining Funk Software, Oliver co-founded Trilogy Inc. and prior to that, he did stints at Novell, Fluent Machines and IBM. Oliver received an MS in mathematics and a BA in mathematics and computer science from the University of Tennessee.