Heartbleed Undetected For Over Two Years – Time to Stop Bleeding
The
recent discovery of a serious unknown vulnerability in OpenSLL has launched the
world into a whirlwind of information security guesswork. What is Heartbleed,
what is the impact, and what can be done both now and in the future to detect
similar zero day threats much sooner?
Zero day vulnerabilities are probably the most insidious
issue IT security has to live with day in and day out. For as long as software
and programming code are written by humans, programs and apps will have tiny
loopholes that are eventually discovered by those seeking them out. Much like
other zero day bugs, it was a simple code mistake that resulted in what we now
know as the Heartbleed flaw, labeled ‘catastrophic’ by cryptography experts.
Sporting a rather fitting name, the Heartbleed flaw was
discovered by Google and Codenomicon on April 7, 2014. The corresponding
CVE-2014-0160 is a serious fault in OpenSSL, the cryptographic core of numerous
networking and mobility products, going unnoticed since March 2012, and perhaps
longer. At this time, Heartbleed is said to affect over 60% of web servers on
the Internet, which is unprecedented in reach and magnitude.
What is OpenSSL?
OpenSSL is an open source implementation of the SSL and TLS
encryption protocols, designed for and used in protecting untold numbers of
servers and everyday online activities that involve users and their access to
the Internet: working, banking, shopping, browsing from home, and everything
that happens in between. Some examples of products that use OpenSSL are Juniper
products, Apache HTTP server, Cisco products such as AnyConnect, Nginx, IIS, a
variety of home routers, web services like Yahoo!, Google, Amazon, social
networking platforms like Pinterest, and all too many others to name. As this
post is written, vendors are issuing per-product advisories about Heartbleed,
and making sure organizations are aware of, and can remedy the related issues.
What Effect Does Heartbleed Have?
Heartbleed is an exploitable vulnerability that can allow
remote attackers to obtain sensitive information (such as private keys, user
names and passwords, or the contents of encrypted traffic) from process memory
via crafted packets that trigger a buffer over-read.
It can mean that cybercriminals and malevolent parties can
access information you do not intend for them to access under any
circumstances: personally identifiable information, user names and passwords,
confidential documentation, payment card data, and VPN communications, to name
but a few.
What Now?
At this point experts are looking for ways to patch
Heartbleed as soon as possible, before malicious actors heavily exploit it.
Some advisories are telling organizations to “assume the worst has already
happened”, preparing teams to move to detection and post-breach response plans.
The immediate thought on everyone’s mind is that when there
is a bug, there is a patch, and the first thing to do is apply it to stop the
bleeding. Although this may appear to be a solution and a way of allaying the
panic, applying patches to the many vulnerable platforms can take at least six
to twelve months. Months will pass before vulnerable vendors, and all levels of
end users, return to safe OpenSSL-dependent activity.
Unfortunately, in the case at hand, while patching will
offer some repair, the gloomy forecast is that Heartbleed will live on, well
after patches are issued and applied. The bug is so far-reaching into internal
networks, server communications, and products that were already shipped out to
end users, that it will take a very long time until it is completely fixed.
While this process takes its course, the even more troubling thought on
everybody’s mind is how malicious actors are planning to exploit this flaw and
cause maximum damage while they still have the opportunity.
Will Password Changes and 2FA Help At all?
Changing passwords is a recommended step, but it has to wait
until service providers and web resources have patched their Heartbleed flaws.
Without proper security, the site will simply get compromised again and the new
passwords will go straight to the hands of the waiting attackers.
As for two factor authentication (2FA), for those
organizations that use it for VPN access and secure activities on their online
accounts and infrastructure, 2FA can help to an extent. The issue is that when
web servers themselves are very possibly compromised by unauthorized parties,
the authentication using that second factor will also be eavesdropped on, and
can be intercepted in a Man-in-the-Middle fashion. 2FA will offer more security
only once the flaw is patched and the certainty that resources are secured is
restored.
Assuming the Damage is Done, What’s Next?
Overall, patching and password management may be the
superficial fix for many cases, but not enough for this gargantuan flaw.
According to Dan Kaminsky, a security expert who discovered and coordinated the
patching of a DNS caching flaw in 2008, Heartbleed is a whole new ballgame,
where all the damage has already been done, and organizations now have to move
to emergency remediation procedures.
Organizations that know they have been affected by
Heartbleed must move to thoroughly examining their internal infrastructure and
initiate incident response to ensure that security is fully restored. This is a
classic case where perimeter defenses, firewalls and NGFW, IPS, and IDS
defenses are all layers that offer some security, but are unable to detect the
unknown and unexpected.
Story Coverage:
Comments
Post a Comment