Heartbleed: Are You Affected?

The insidious bug has caused a lot of buzz and alarm in security circles. Are Indian enterprises affected and, if so, what are they doing about it?

By Harshal Kallyanpur

Over the past few days, there has been a lot of talk about the Heartbleed bug and how it can potentially cause havoc from the data security perspective. The bug allows an attacker to exploit vulnerability in the OpenSSL cryptographic library and gain access to the system memory and steal data from it. This data could range from anything between passwords and active transaction data to even encrypted private keys that would allow an attacker to launch a phishing attack through legitimate websites.

However, the jury is still out on what is the exact impact of this bug – there have been no reported attacks that point to possibility of the vulnerability being exploited to launch the attack. There are various figures on how many systems are actually compromised, as most figures are given out by security solution vendors based on the analysis of their own customer base.

According to Surendra Singh, Regional Director, SAARC & India, Websense, Inc, industry figures suggest more than half a million vulnerable systems, but the extent of damage is still not yet known as there are no concrete reports of a direct impact.

Venkatesh Sundar, CTO, Indusface, is of the view that industry statistics indicate that two thirds of all websites may be vulnerable, though in India only 5% of Indusface customer base was affected by the bug. However, both Singh and Sundar suggest that enterprises should pro-actively look at keeping themselves protected and take both detective and preventive approaches to secure their organisations.

A low-down on Heartbleed
The biggest problem in countering the Heartbleed bug is the fact that its use is widespread but cannot be mapped with exact numbers. A lot of web servers and Internet-connected devices may be using OpenSSL as it is freely available. Therefore, there is a lot of ground to cover in terms of detection and prevention.

Nanjundeshwar Ganapathy, Chief Technology Officer, Uniken, says that the bug affects the OpenSSL library, which is in widespread use by Apache web servers as well as servers running Linux or even Solaris.

According to him, OpenSSL is an open source community based effort, where much of the focus was purely on performance. While a lot of enterprises use OpenSSL, no one really pays for its use. Most of the time, its use goes insufficiently audited from a security perspective.
The fact that OpenSSL has been in use for years on a wide scale, but the vulnerability was only discovered until recently, substantiates this view.

Ganapathy also believes that mobile devices could be potential carriers of malware that orchestrates the exploit. For instance, mobile applications that support in-app purchases can connect to servers, which use affected versions of the OpenSSL software.

Talking about the impact of OpenSSL, KK Mookhey, Principal Consultant and Founder, Network Intelligence India, says that the impact of this bug is that it allows the attacker to access the memory of the target server.

“The memory typically contains passwords and could potentially also contain the private key of the digital signature. This would mean that the SSL encryption is basically now not actually existent: the attacker – if he/she can sniff the traffic – can also easily now decrypt it with access to the private key of the server,” he adds.

According to Avinash Kadam, Advisor, ISACA India Task Force, the basis for secure communication is the private key of the web server. This private key is used to identify the server and encrypt all the traffic. “Once the private key is stolen, all security is lost. The server can be impersonated. Any encrypted communication with that site such as passwords, credit card numbers, secure transactions are now exposed,” he says.

Ashish Thapar, Head – Global Consulting & Integration Services (GCIS), India & South Asia, Verizon Enterprise Solutions, describes this bug as a ‘forever-day vulnerability.’ According to him, it could take years for this vulnerability to be completely eliminated from hardware, embedded systems and legacy applications. TLS implementations in Windows and OS X operating systems are not vulnerable. However, applications running on these OSes that were developed using a vulnerable OpenSSL library might be at risk.

“The attack code is in the wild and leaves no trace of the attack on the server. Around 66 per cent of all websites are using Apache that use OpenSSL, most TLS implementations use OpenSSL and the majority of hardware appliance vendors use OpenSSL code in their products,” adds Thapar.

He says that for mobile devices, the Heartbleed vulnerability is being referred to as “Reverse Heartbleed”. Traditional clients like web browsers, apps that use HTTP API on mobile handsets and PDAs may be vulnerable if they use OpenSSL for Transport Layer Security. “For instance, millions of mobile devices running Android 4.1.1 (Jelly Bean) use the OpenSSL version and are currently affected with the Heartbleed issue,” he says.

Protecting against Heartbleed
As the exact spread and impact of this bug is not yet known, enterprises will need to start identifying where the vulnerability exists in the organisations, and apply the necessary software patches and make the required upgrades.

Ganapathy of Uniken says that most enterprises do not know how many and which services they are running internally are using SSL encryption. This makes it extremely difficult for security teams to prepare against the malicious attacks which can be caused due to Heartbleed vulnerability.

After identifying the vulnerability, they need to fix it at their end at multiple levels. They need to identify and upgrade their servers and network infrastructure to patch this bug. They also need to fix the vulnerability across the complex set of platforms and devices because of significant BYOD population.

Giving his perspective, Mookhey says, “First identify your OpenSSL footprint. Then immediately contact your vendors, service providers and administrators to obtain the patch and implement it. Then test your site using any of the vulnerability scanning tools, which have plug-ins for this vulnerability.”

“Finally, if you’re not able to apply the patch for some reason, then either disable the heartbeat functionality in your OpenSSL implementation, or implement a blocking rule on your IPS or WAF,” he concludes.

Sundar of Indusface says that what enterprises can and should do is ensure their own mobile apps are tested and the vendors engaged for doing the mobile app security testing also includes the Heartbleed risk assessment as part of their mobile app security test suite.

“Heartbleed is an example of “server” vulnerability, but it is not impossible to find similar “client” side issue. BYOD devices introduce a litany of diverse OS and apps in the enterprise environment. Be ready to protect your assets against these known-unknowns in future. Before admitting a new device into the enterprise environment, it can be checked for Heartbleed. That would be the additional check needed in BYOD strategy,” he says.

Sharing a similar point of view, Thapar of Verizon says, “The impacted devices would be vulnerable to a hack where a malicious server would be able to exploit the flaw in OpenSSL to grab data from the device’s browser, which could include information such as previous sessions and logins.The BYOD security strategy should ideally address this issue as part of security controls preventing data leaks, providing network protection, mobile device lock-down and sandboxing for enterprise applications.”

Giving the vendor perspective, Singh of Websense says that the company has already identified websites that are not patched and is blocking access to them.

“We have updated our solutions, but it is also necessary that enterprises intimate their employees and customers to take the necessary precautions, because if they do not change passwords, they are still vulnerable to an attack despite the patches and updates,” he adds.

This means that an enterprise might have made the necessary updates to its infrastructure but they should also issue advisories about Heartbleed to their employees, customers and other partners, so that these entities take the necessary precautions at their end.

However, customers too should pro-actively check if their vendors or service providers have made the necessary upgrades to their SSL infrastructure and applied the necessary software patches, albeit merely changing a password at their end would just leave their new passwords vulnerable to data leakage.

Since the bug can also affect security certificates for websites, enterprises would also end up going in for a security certificate refresh, while revoking their current certificates. However, Mookhey of Network Intelligence feels that unless there is a clear sign of compromise of existing user data, he doesn’t see too many organisations investing in new digital certificates.

“I believe Symantec and some others have declared that they will be issuing revised new digital certificates at no additional cost. So organisations that do go in for new digital certificates just might be able to do so without a huge cost overhead,” he adds.

Kadam of ISACA believes that there will be an increase in the number of organisations applying for digital certificates. He says, “They have to not only patch OpenSSL but also get new public/private key pair, update digital certificates and change every password that could have been stolen. If the estimate of two thirds of servers on the Internet using OpenSSL is correct, there will be a huge demand for new digital certificates.”

How are enterprises going about it?
According to Mookhey, organisations have rallied quickly to address this issue. The level of awareness is very high and organisations first focused on finding out their exposure to the bug – i.e. which of their public-facing systems were using OpenSSL. Vendors were also very quick to release patches. “In my opinion, almost every enterprise took very quick action to apply the patch and fix the issue,” he says.

Sundar of Indusface says that India was not as impacted as we thought it would be, mainly because most of them were running the older version of the technology, which helped them avert this bug. The level of awareness is very high among the techies and the CIO/ IT managers in enterprises. “The challenge for the enterprise is more to eliminate the level of confusion and panic, and gain back confidence of its non-technical consumers—so that they get back to doing online transactions again,” he adds.

Echoing this sentiment, the CISO of a reputed bank, who did not wished to be named, says that the bank does not use OpenSSL for its critical servers, but relies on Microsoft’s Internet Information Server or IIS. However, the non critical servers were running on older version of OpenSSL, which did not have the bug. Still, they have been updated to the latest version that offers a fix, just in case.

He further says that the government of India and CERT have issued advisories against Heartbleed to financial organisations. Even governing bodies for banks have issued letters informing them about the bug. However, he is of the view that there should be a national level advisory for everyone on Heartbleed, as much of what is getting reported in the media is mostly negative, with lesser focus on how to resolve the issue.

He is also of the view that any organisation following compliance standards, such as ISO 27000, would typically have an updated inventory of its software assets. Therefore identifying and patching should be easier for them.

Sunder Krishnan, Chief Risk Officer at Reliance Life Insurance, says, “We have done a vulnerability risk assessment and determined that we are not affected. We have even issued advisories and a list of FAQs to our employees and other stakeholders.” The company relies heavily on in its vendor partnerships and therefore has interfaced with all the solution vendors to ensure that they have released the necessary patches to the organisation. Simultaneously, the company is also monitoring its assets using the OpenSSL 24×7, for any apparent anomalies.

Geojit BNP Paribas, one of India’s leading stock trading companies, also offers a suite of apps on Facebook which include an online trading application. Facebook was one of the websites listedby security solution vendors among the websites that can be potentially hit by the bug.

Talking about how the company is going about protecting itself from the bug, A Balarkishnan, CTO of Geojit BNP Paribas Financial Services Ltd, says that the Facebook application has no connection with the core trading business, which runs on the broker secured network. The transaction enabled app is based on the Facebook API and runs on a separate network.

The general pages of the company on Facebook do not give access to any market data, as the company is not legally allowed to share market data with anyone who has not passed through KYC compliant processes.

“In our case, we are not running the affected versions at all. We have checked all our OpenSSL deployments and taken a letter from all vendors using OpenSSL, verifying that they have applied the necessary patches and are protected against the Heartbleed bug,” he adds.
The company is also running campaigns for its employees and other stakeholders on the disclosure of the bug and how it can affect them. These campaigns are based on the research by BNP Paribas Asia Pacific Info Security Division.

Best Practices to keep Heartbleed at bay

• Implement monitoring (e.g., IDS/IPS or similar network packet capture and examination controls).
• Update OpenSSL to 1.0.1g or disable heartbeat support on external facing systems.
• Identify applications and other systems using OpenSSL and upgrade or disable heartbeat support on the remaining vulnerable systems. In some cases (e.g., OpenVPN), this will require recompiling the application.
• After OpenSSL has been addressed via upgrade or reconfiguration, regenerate private keys and coordinate for revocation and reissue of TLS/DTLS/SSL certificates on all affected servers.
• Post adequate remediation of OpenSSL vulnerability; reset user credentials on all sensitive and affected systems.
• Work with your third party service providers (as applicable) to ensure that they have effectively remediated the OpenSSL vulnerability.