« May 2014 | Main | July 2014 »

2 posts from June 2014

Jun 26, 2014

TSUBAME Training in Indonesia and Laos

Hi there! This is Tetsuya Mizuno from Watch and Warning group.

 

Today, I would like to introduce one of our activities: technical training through TSUBAME project. TSUBAME, headed by JPCERT/CC, is a project using a packet monitoring system which deploys sensors in multiple countries to detect wide-ranging malicious activities on the Internet (without collecting any sensitive data). The project is operated as one of the working groups of APCERT, and the members consist of 24 teams from 21 economies, mainly National CSIRTs in the Asia Pacific region (as of June, 2014). In order to boost up members’ capability in internet-based threat analysis, we have provided some on-site technical training. Its objective is to provide participants with sufficient knowledge of conducting investigation on global threats in order to promote data sharing as well as enhancing analysis competence among the members.

 

This article will cover how we are implementing this activity by introducing our two recent on-site trainings in Indonesia and Laos conducted by my colleague Takayuki (Taki) Uchiyama and myself.

 

Training in Indonesia

We organized training in Jakarta, Indonesia on 5-7 March 2014 for approximately 40 participants from ID-SIRTII/CC and their partner organization, ACAD-CSIRT. The training was based on hands-on exercise consisting of four phases: (1) TSUBAME sensor setup and management, (2) TSUBAME web functions, (3) analysis combining TSUBAME data and other obtained data and (4) analysis on case studies by examining various network protocols.

 

The main purpose of this training was to enhance trainees’ practical skills on analyzing network traffic and sensor management. Based on their basic knowledge on TSUBAME, we focused on advanced trainings on how to analyze various internet protocols and to identify the online behavior of the network threats.

 

I was glad to hear a lot of positive feedback from the participants – they feel that their skill has improved and would like to take it into practice in their daily job.

 

Dsc06638_tsubame

Photo taken by ID-SIRTII/CC

 

Dsc06635_

Photo taken by Tetsuya

 

Training in Laos

Followed by the training in Indonesia, we conducted another session at LaoCERT, in collaboration with ThaiCERT, on 21-22 May 2014 for approximately 20 participants. Along with the training, we installed our first sensor in Laos, which made LaoCERT our 24th member team of TSUBAME project. Since packet monitoring activity was a new challenge for some participants, we assisted in hands-on exercise by giving lectures about general network knowledge. The training consisted of five phases: (1) basic knowledge on network, (2) overview of TSUBAME, (3) TSUBAME sensor setup and management, (4) TSUBAME web functions and (5) tips for TSUBAME data analysis based on case studies.

 

During this training, we could see that the trainees were so motivated – and we were assured that the knowledge they acquired would definitely be helpful to improve their packet monitoring operation.

 

Dsc_0420

Photo taken by LaoCERT

Dsc07425_

Photo taken by Tetsuya

 

We are looking forward to continuously contributing to enhance the packet monitoring capability in order to promote collaboration among TSUBAME members and confront internet threat as a whole.

 

If you have any inquiries on this topic or TSUBAME, please contact me at tsubame-sec(at)jpcert.or.jp.

 

-        Tetsuya Mizuno

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