« APCERT Annual General Meeting and TSUBAME Workshop by JPCERT/CC | Main | TSUBAME Training in Indonesia and Laos »

Jun 03, 2014

The Heartbleed bug - How Japanese Organizations confront the issue -

Hi. This is Misaki Kimura from Watch and Warning Group.

 

Ever since the extremely critical vulnerability in recent versions of OpenSSL (known as "Heartbleed") was made public, it has been wreaking havoc across the internet. According to Netcraft, a research firm which monitors websites and certificates worldwide, more than half a million websites were affected. Such said, with no exceptions, websites in Japan were also affected, and we have been receiving various inquiries about this vulnerability. Supporting system administrators and web masters are highly recommended to take immediate mitigations.

 

Today, I would like to provide an overview about how Japanese organizations are taking actions towards this Heartbleed bug along with explanation on what this vulnerability is and how to protect yourself from being hacked.

 

 What is Heartbleed?

Heartbleed is a vulnerability found in OpenSSL, an open-source based SSL/TLS cryptographic software library. SSL/TLS is a protocol widely used for social, e-mail, e-commerce, internet banking sites and some virtual private networks (VPNs). It encrypts sensitive information and provides secure traffic flow between peer to peer devices.

 

OpenSSL contains extension dubbed as “heartbeat” - which the vulnerability's name is derived from - a type of keep-alive connection that essentially checks a “live” or “dead” status between two devices such as web server and users' PC. This mechanism is designed to keep connections alive even when there is no data being transmitted. Heartbeat messages contain random data and a payload with length of 64KB at the maximum. When a heartbeat request is sent from the sender, the receiver is intended to correspond back to the sender with a mirror of exactly the same payload data.

 

However, the problem is that the OpenSSL implementation never checks the length of the incoming payload data. Consequently, when an attacker sends a heartbeat request with smaller length of data, the receiver allocates a buffer for its response, which ends up copying data from web server’s memory giving up to 64KB to the attacker. 

Figure01_2

Figure: How the OpenSSL vulnerability works

Source: JPCERT/CC

 

An attacker can remotely exploit this vulnerability to retrieve anything in the memory including SSL private key, user ID, password, banking information. The exploit can be repeated to read different random 64KB memory. What’s more, the attack leaves no trace making it difficult to detect that the system has actually been compromised.

 

Japanese organizations' counteractions towards Heartbleed

Right after the Heartbleed vulnerability was publicly disclosed on April 7th, JPCERT/CC and Information-technology Promotion Agency (IPA) respectively released a security alert. Along with the explanation on this bug, we encouraged system administrators and web masters to immediately take actions to address the threat.

 

National Police Agency (NPA) released a report on April 10th, stating that their network traffic monitoring system has been observing “Client Hello” packet with exploit codes after the disclosure of the vulnerability. “Client Hello” packet is the first packet sent from a client PC to a web server after TCP three-way handshake establishment when SSL communication starts. NPA again released a report on May 21st explaining that the number of this packet reached its peak on April 12th by hitting 12,881 packets per day.  This was observed for 443/TCP, 995/TCP, 993/TCP, 5222/TCP, 465/TCP and 1194/TCP, which shows that attackers are not only targeting the HTTPS but as well as other SSL implemented services such as POP3S, IMAPS and so on. They stated that there was a sudden drop on these malicious packets from April 23rd. The following figure shows the observed packet flow which targets the vulnerability in OpenSSL; the vertical axis indicates the number of packets while the horizontal axis indicates the date when those packets were observed.

Figure02_2

 

Figure: Detection of access targeting vulnerability in OpenSSL

Source: Internet Monitoring Results (April 2014), National Police Agency

 

Furthermore, Ministry of Internal Affairs and Communication (MIC), and National Information Security Center (NISC) announced an alert respectively on April 15th. Making it their first security alert released to the public this year, you can acknowledge how seriously this bug is considered in Japan.

 

Private sector, in turn, has also been taking actions.

Nippon CSIRT Association, a group of CSIRTs in Japan consisting of 50 enterprise members (as of May 2014), has been sharing information related to Heartbleed issues. In fact, they have set up an information sharing website. Although it is written in Japanese, you can see a sample case in a moving image on how the data stored in the web server can be retrieved.

 

Meanwhile, many of the major financial institutions, SNS, portal sites, cloud hosting services in Japan have been announcing whether their systems are affected or not and whether any solution to address the threat has been taken.

 

Heartbleed victims come to surface

Since the vulnerable versions of OpenSSL have been around for the past two years, it is uncertain how many hackers have exploited it and how many have fallen victim. However, it is eventually coming apparent that unfortunately Japan also became one of the victims affected by the threat. According to the news released from Japan Times, Mitsubishi UFJ Nicos Co., a major credit card company in Japan acknowledged on April 11th that they came victimized by the OpenSSL vulnerability. The company said that the personal data of 894 cardholders may have been compromised.

 

As far as I know, this is the third detected case to be on the news regarding the Heartbleed bug victims, followed by Canada Revenue Agency (CRA) and Mumsnet, a popular parenting network site in U.K.

 

Measures to prevent from Heartbleed attack

From service providers and users perspectives respectively, there are several measures that need to be put in place.

 

- For service providers

If your server uses any of the affected versions of OpenSSL software (versions 1.0.1 through 1.0.1f including1.0.2-beta through 1.0.2-beta1), the first priority is to update to the appropriate version that addresses the vulnerability. For systems that cannot apply the update, you can also implement a workaround by turning on “-DOPENSSL_NO_HEARTBEATS” option and recompiling your existing version of OpenSSL. Or if your system uses OpenSSL provided by a distributer, please refer to the information provided by them and individually update the affected package itself.

For the next step, depending on the risk level and the value of the information your system is protecting, you may need to reissue and revoke any impacted SSL/TLS certificates and reset passwords on any user accounts. After this remediation, it is highly suggested to inform your users for password change.

 

- For users

Users need to check websites where your IDs are registered especially those associated with banking information, and if they have any announcements about OpenSSL issues, follow the instructions and take actions such as changing your password and confirming auto update for certificate revocation lists in your web browser for proper certification validation.

 

If you have any inquiries on this post, please contact us at info(at)jpcert.or.jp.

Thank you!

-        Misaki Kimura