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.
Assessing Heartbleed vulnerability in internal networks
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:
- An attacker gets inside your network via malware or another form of attack;
- The attacker performs reconnaissance and finds the management interfaces of your infrastructure systems;
- The attacker uses the presence of Heartbleed in those infrastructure systems to read the systems' memory, retrieving administrative credentials recently used to log in to the system and, possibly, even the private key of the certificate securing the connection; \
- The attacker uses the stolen credentials to log in and reconfigure the system or, in case of these not being only local account credentials, access some other unrelated resources.
Step-by-step Heartbleed vulnerability risk assessment
Step 1: Assume compromise
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: Implement a threat detection solution
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: Protect against internal Heartbleed exploits
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: Manage credentials and identity security
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.
Identifying the Heartbleed attack surface in your internal networks
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.