The Secure Sockets Layer (SSL) is a specification used to protect sensitive data while communicating over the internet. In today’s context of MoSAICS (Mobility, Social, Analytics, Infrastructure, Cloud and Security) stack – the 3rd Platform, this is the standard for secured communication. With the shelf-life of products diminishing, continuous integration, agile development and infrastructure, your communication across these platforms ought to be secured and no one else should be able to see what is being sent back and forth. This specification has an implementation bug particularly in OpenSSL given that everyone has got access to the source code.
First, I’d like to clear something that has been making me cringe every time I hear someone say the heartbleed virus has attacked. It is not a virus. It is a vulnerability. A vulnerability is a loophole inherent in an already established piece of security system. And it does not attack. This vulnerability can be exploited, and potentially impacts a good 70% [Src: Internet research] of the WWW today.
In networking, when any two appliances require to communicate, they tend to use either TCP or UDP protocols. TCP (Transmission Control Protocol) is a perfectionist protocol, where the Packets (deliberately assuming that the reader knows the packet analogy) are accounted for and if there are any packets missing or out of order, TCP re-sends the missing packet or assembles them in the right order at the receiving end. UDP (User Datagram Protocol) is not a perfectionist protocol but a get-it-done protocol. It transmits packets without error recognition or order synchronization. To make networking secure, all forms of communication using either of the protocols are encrypted, mostly using SSL (Secure Sockets Layer). While TCP has a method of keeping communication methods alive with KeepAlive function (used for error checks!), UDP does not have the same requirement because it was not required where error checks are not required. Later on, a method to mirror the function of KeepAlive was added to UDP called HeartBeat (somewhere in 2012). The HeartBeat function involved an end point client machine sending a ping to a server to keep a communication alive and expecting an acknowledgement. The acknowledgment was also based on the length of the acknowledgement expected by the client machine ping. Now you know what Heartbeat does. The vulnerability of HeartBeat lies in this acknowledgement and the length of it. If asked for a longer length than required (up to 64KB), the server send the response including the memory content kept in its RAM up to 64 KB which would also include data about the recent transactions which have been made by the server (all kinds of data including password changes, SSL encryption key handshakes etc). The involuntary disclosure of information stored in the memory is called, very cleverly if I may add, HeartBleed.
The key thing to keep in mind is that the HeartBeat function was added in the OpenSSL implementation, versions of 1.0.1 to 1.0.1f. Other SSL implementation methods do not have this vulnerability. Given that this vulnerability has been around for two years, it is important to change existing credentials of users, and make sure the OpenSSL implementation is patched and SSL certificates are re-issued. The extent of damage is yet unknown. But preparing for the worst is the best way to go forward!
To resolve this issue and close the Heartbeat vulnerability, Mindtree has been following two methods. Mindtree engineers have been working round the clock in following emergency change protocols to ensure all the servers/network devices (basically any end point communication device using OpenSSL) are patched, the versions are upgraded and more importantly, renew the SSL certificates so that the encryption keys are changed. On the other hand, Mindtree has been asking end users to use specific extensions on their client browsers – Chromebleed /Foxbleed (for Chrome and Firefox browsers respectively) which warns users on the sites that still have the vulnerability alive so they can change their credentials in those sites. We can extend this professional help as part of our Managed Security Services (Unified Threat Management).
Special thanks to my colleagues Vijaya Rajan Shankar (for research and input to the blog), Mansoor Poolakkal (for sharing potentially affected sites) and Mark Masuelli (for sharing the remediation report).