« November 2014 | Main | January 2015 »

2 posts from December 2014

Dec 25, 2014

Increase in Possible Scan Activity from NAS Devices

Happy holidays to all, this is Tetsuya from Watch and Warning Group. Today, I would like to share a recent, remarkable trend discovered through TSUBAME sensors.


In TSUBAME, we have observed a significant increase in packets destined to 8080/TCP since December 5th, 2014. When accessing source IP addresses using a web browser, the admin login screen for NAS devices provided by QNAP was seen in many cases for IP addresses from certain regions.


[Figure 1: Scan count per hour observed at 8080/TCP from December 2nd, 2014 onwards (Source: TSUBAME)]


Below are some characteristics that we noticed from TSUBAME data:

  - Increase in packets to Port 8080/TCP since December 5th, 2014

  - The TTL value for most of the packets were between 30 - 59

  - A scan attempt sends 1 - 2 packets (the second packet is a re-send)

  - A source IP does not continuously scan a particular destination IP (The majority scans only once)



Also we were able to verify the following after checking some of the source IP addresses:

  - When accessing Port 80/TCP of the source address, a redirect to Port 8080/TCP occurs and the admin login screen of QNAP NAS is shown

  - The QNAP firmware looks to be version 4.1.0 or earlier (Information taken from the screen that is shown. 4.1.0 and earlier are affected by Shellshock) (*1)


Using an environment separate from TSUBAME to check the packets sent by an infected QNAP device, we saw the following request (there are several types of requests).


[Figure 2: Sample request from infected device (Source: JPCERT/CC)]


When a QNAP NAS device using a vulnerable version of firmware receives this request, the Shellshock vulnerability is leveraged to download a malicious attack program over the Internet and be infected by malware (*2, *3). Once infected, it begins to search for other vulnerable NAS devices. As a result of this activity, a large number of NAS devices were infected and we believe this is the reason for the sudden increase in packets to 8080/TCP.


The vendor has released firmware to address the Shellshock vulnerability. If you have yet to apply the update, we recommend that you first check (*2) whether you have been infected or not.


  JVN#55667175 QNAP QTS vulnerable to OS command injection (*1)



  The Shellshock Aftershock for NAS Administrators (*2)



  Worm Backdoors and Secures QNAP Network Storage Devices (*3)



 An Urgent Fix on the Reported Infection of a Variant of GNU Bash Environment Variable Command Injection Vulnerability (*4)



Thank you for reading, and we wish you all the best for the coming year.


- Tetsuya Mizuno

Dec 11, 2014

Year in Review - Vulnerability Handling and Changing with the Times

Hello and Happy Holiday Season to everybody.

Taki again, and today I will write about some experiences in product (software, hardware) vulnerability coordination this year.


 - Introduction -

A lot happened this year and I do not have the time to go through everything, but would like to go over some of the major issues that we handled and for those that are not familiar, provide a very brief overview of our coordination activities.

Before I move on, our vulnerability advisories are published at Japan Vulnerability Notes (JVN). Other CSIRTs across the globe have their own sites like this, such as CERT/CC and NCSC-FI. While CERT/CC publishes quite a few advisories each year, NCSC-FI only publishes several high-profile issues each year that affect a large number of users.

The number of published advisories on JVN is shown below.



[Figure 1 - Number of product vulnerability-related advisories published on JVN per quarter since the 2nd quarter of 2011 (Source: JPCERT/CC)]


What can be seen on JVN are advisories for vulnerabilities in products, which directs users to fixes, updates, patches, etc. for products in use. However, what is seen here is merely a small portion of the work that is involved in our vulnerability handling activities.

We coordinate the disclosure of product vulnerabilities with developers, researchers so that they do not become 0-days, where information about a vulnerability is disclosed without a way for the user to resolve it. Some of you may have heard the phrase "Coordinated Disclosure," which is what we attempt to do.


 - This Year -

This past year, we were involved in a few high profile cases which even received media attention.

 One of these issues was the so-called "Heartbleed" vulnerability in OpenSSL. There are quite a few articles on the web that describe the disclosure timeline, so I will not get into those details here. As an aside, here is a previous entry that describes how Japanese organizations dealt with Heartbleed.

We received information on this issue a few days prior to disclosure from one of our global counterparts. As we were about to begin the coordination process with developers the issue was disclosed by the OpenSSL team.

This case taught us (again!) that while reports may be sent to us in a confidential manner, this does not mean that we are the only ones that have this information.


[Figure 2 - Sample image of vulnerability handling information flow during a coordination effort (What a mess!) (Source: JPCERT/CC)]

This is especially true in cases that involve open-sourced software. There were quite a few high-profile advisories involving OpenSSL this year (CCS Injection, POODLE attack, etc.) which eventually led to the OpenSSL team releasing a new security policy  related to addressing vulnerabilities.

 Pre-disclosure, or notification prior to public disclosure for such open source products have been done through mailing lists or sending separate e-mails to relevant parties. Now most major open source projects only pre-disclose with certain groups of developers that need fixes first and then the rest of the world gets to know about the issue at the same time. This is also true with software provided by the Internet Systems Consortium (ISC), such as BIND.

- The next step in vulnerability handling -

The experiences that I had over this past year have shown me that not only are more and more people looking for vulnerabilities, but this information is moving around at such high speeds to a variety of parties, where in some cases, have no idea that another particular group has that information.

In general, the fewer parties involved in a coordination effort, the better. Not only does this reduce the probability that the information gets disclosed prematurely, but it also provides the developer better control as to how this non-public vulnerability information is being handled.

As a coordination center, we serve as the intermediary between the reporter and developer. If a reporter can report and communicate with the developer directly, then I believe they should do so. Our involvement in such a case is not necessary and in fact is a loss of time since each communication has to go through an additional party.

However for cases involving open sourced software that is implemented in various products, further coordination becomes necessary and this is where we can (and have been able to) provide value in a coordination effort.

Vulnerability handling has been evolving from a series of one-to-one communications to where various parties (that are often not in contact with each other) are involved in a single case at the same time. Hopefully we can continue to evolve with the times so that we can provide maximum value to a vulnerability coordination effort so that the proper information is being sent to relevant parties.

I wish everybody a safe and wonderful holiday season!

Takayuki (Taki) Uchiyama