« April 2015 | Main | June 2015 »

3 posts from May 2015

May 28, 2015

Fiddler Core's insecure Default flag may lead to Open Proxy Issue

NOTE: This article, originally published on May 28, 2015, was updated as of June 8, 2015 (See below).

Just 2 days ago, we published an advisory (in Japanese) on an open proxy issue of a widely used, open source, web browser game utility app called KanColleViewer. The game, Kantai Collection, has explosive popularity. Its official Twitter account has over 1 million followers, and according to its Tweet, the game has 3 million registered players as of May 2015. The issue was due to the insecure configuration of a proxy server launched in the app, allowing any Internet user to access the proxy. Due to the large user base of the app and the nature of the issue, Internet-wide scan against 37564/TCP (the app's proxy port) has been observed.

In this article, I will elaborate a bit more on the technical aspect of the issue to provide secure coding tips for developers.

KanColleViewer is a Windows Desktop app written in C# WPF. The app uses IE shell for web browsing and Fiddler Core for capturing HTTPS traffic between the client and the game server. The app was designed to improve the UI experience of the game, thus acquiring larger user base (2 million downloads as of August 2014, says the developer).

Fiddler Core is a .Net class library for C# apps. By using this library, developers can launch a web proxy in their apps, capture and modify HTTP/HTTPS traffic just like using Fiddler, a well-known web debugging proxy tool.

Now, who is going to use the web proxy launched in the app?

Because the app only needs to capture its user's (game player’s) traffic, the proxy should be exclusively used by the user. However, the proxy was launched in a way that is accessible from remote users as well, serving as an "Open Proxy".

If you take a look at the source code of the vulnerable version 3.8.1, the proxy was launched by calling FiddlerApplication.Startup() in the following way:

63  public void Startup(int proxy = 37564)
64  {
65      FiddlerApplication.Startup(proxy, false, true);
66      FiddlerApplication.BeforeRequest += this.SetUpstreamProxyHandler;
68      SetIESettings("localhost:" + proxy);
70      this.compositeDisposable.Add(this.connectableSessionSource.Connect());
71      this.compositeDisposable.Add(this.apiSource.Connect());
72  }

FiddlerApplication.Startup() is an overloaded method. There are three implementations where two, three and four arguments are taken. Those that take three and four arguments are NOT RECOMMENDED to be used according to the FiddlerCore documentation (which you can download from http://www.telerik.com/fiddler/fiddlercore).

Now, the recommended way to start the proxy instance of FiddlerCore is by calling the following two-argument version of the Startup():

public static void Startup(
       int iListenPort,
       FiddlerCoreStartupFlags oFlags

The first argument is the port number of the proxy. The second argument is the flag options passed into the Startup method.

How should we specify the flag? According to the documentation, using the 'Default' is recommended as below:

The FiddlerCoreStartupFlags option you want to set;

FiddlerCoreStartupFlags.Default is recommended

Unfortunately, the 'Default' flag is NOT SAFE. It will open the door for 'Open Proxy'.

If you use FiddlerCoreStartupFlags.Default, your app will start listening at I used the FiddlerCoreAPI SampleApp (which comes with the free download of FiddlerCore) for testing purposes and got the following result:


The 'Default' flag will enable 'AllowRemoteClients' option which may not be what you exactly want.


Going back to KanColleViewer, the issue was fixed in version 3.8.2. The app now calls Startup() method in a safer way:

63  public void Startup(int proxy = 37564)
64  {
65      FiddlerApplication.Startup(proxy, FiddlerCoreStartupFlags.ChainToUpstreamGateway);

'ChainToUpstreamGateway' option will instruct FiddlerCore to use the system proxy as an upstream gateway proxy.

It seems that there are a number of websites that show the insecure call of the Startup(). I briefly searched stackoverflow.com with the keyword 'FiddlerApplication.Startup' to find enough examples that may lead to this issue.

So tips for developers:

  • Use the two-argument Startup() method
  • Don't use FiddlerCoreStartupFlags.Default
  • Instead, specify the options you really need

Lastly, I'd like to thank the developer Mr. Manato KAMEYA for coordinating with JPCERT/CC smoothly and disclosing the security issue in a responsible manner.

Masaki Kubo @ Vulnerability Analysis Team

Update on June 8, 2015

After a few discussions with the developer of FiddlerCore@Telerik, they've decided to exclude AllowRemoteClients from the Default flag in their next release:

... out of an abundance of caution we will be making a breaking change to the next build of FiddlerCore to require developers explicitly opt-in to Allowing Remote clients.(http://www.telerik.com/forums/fiddlercorestartupflags-default-enables-allowremoteclients#1xtYFqA1LUqoNGXx-h6aKw)

I appreciate Telerik for the decision to make developers and their users more secure.

May 27, 2015

Speaking at Australian Cyber Security Centre Conference 2015

G’day all – It’s Yuka again here from Global Coordination Division.

I would like to quickly update about my recent trip to Canberra, Australia, where I attended the inaugural conference of Australian Cyber Security Centre (ACSC).

The event attracted more than 800 people mainly from the Australian Government and IT related businesses but also some delegates from neighbouring countries.

ACSC consists of the following cyber security related entities in Australia:

ACSC’s first conference took place on 22-23 April at the National Convention Centre in Canberra, Australia.

There was a range of speakers from the above-listed organisations and also some outstanding guest speakers from academia and cyber security related vendors including:


  • Attorney-General
  • ACSC Coordinator
  • Dept. of the Prime Minister and Cabinet
  • Telstra
  • Google
  • Microsoft
  • Cisco
  • University of South Wales
  • CERT Australia
  • AU Domain Administration


  • University of Washington
  • iSIGHT Partners
  • Dell SecureWorks
  • Team Cymru
  • Dutch Government
  • New Zealand Ministry of Defence

I myself was given an opportunity to speak on the second day with the title: “International Cooperation on Cyber Space from CSIRT’s perspectives – JPCERT/CC’s outreach – “. The presentation covered:

- Overview of JPCERT/CC

- Incident statistics

- Collaboration with overseas CSIRTs

My presentation highlighted the importance of “collaboration among CSIRTs”. What we need to do in case of incidents across the border is to closely work with our counterpart in the region in question. To be able to timely respond to these urgent situations, constructing "trust relationship and network" on a day-to-day basis (before the incident happens!) is the key. That is why we often participate at international conferences and get engaged in global frameworks. We JPCERT/CC have been working both multi- and bi-laterally with various counterparts.

One of such activities includes JPCERT/CC’s outreach through Asia Pacific Computer Emergency Response Team (APCERT), signing of various Memorandum of Understandings (MOU) and capacity building efforts. Especially for the last item, JPCERT/CC has dispatched experts to establish a CSIRT covering the Pacific Islands and has provided technical support and trainings. Being a close neighbour, Australia has much interest in this topic – and JPCERT/CC is also willing to assist securing the region’s cyber space in any way we can.

Me delivering the talk (Photo provided by ACSC)

There were also participants from vendors and a range of security related businesses – see how crowded the exhibition hall was!

People and booths at the Exhibition Hall (Photo provided by ACSC)

What surprised me was the event web app – it seems like some conferences these days have started using similar tools. The biggest feature is that attendees using the web app can post questions to speakers throughout the session, and other attendees can vote “like” or “dislike” to each question. Supported questions are shown on the top of the page, which will be pointed to the speakers. This saves time, visualises what’s being asked (both for speakers and attendees) and allows efficient event running. Also, feedbacks on the sessions were submitted through this app – I believe this saves paper, too!

April in Canberra is a nice autumn season. I saw beautiful tree leaves turning yellow and orange. The city really was filled with lots of trees, and I enjoyed a little bit of early autumn.

As JPCERT/CC, we feel so honoured to be invited to such an important event in Australia. We hope to further collaborate with Australian cyber security related entities.

Thank you for reading.

- Yukako Uchida

May 12, 2015

Training in Myanmar

Hello, I am Moto Kawasaki and I would like to write about my trip to Yangon, Myanmar from March 8th through 13th, 2015.

Koichiro "Sparky" Komiyama and I went there to conduct Apache Log Analysis training and “CSIRT in a Box” training for mmCERT/CC, Myanmar Computer Emergency Response Team / Coordination Center. It is the 5th time starting in 2011 that JPCERT/CC visits mmCERT/CC for technical training.

We had a total of 10 trainees from mmCERT/CC, academia and the government. They were all experts in computer and network field in general, but each of them had their own respective specialties.

Apache Log Analysis Training

Apache Log Analysis is a relatively recently developed training course at JPCERT/CC to demonstrate how to identify traces of attacks (such as XSS and SQL injection) from haystacks of Apache combined logs.

While working on the assignment, the trainees were requested to use good old UNIX commands like “grep” and “awk” only, since UNIX command line tools are, in our view, the best among many free and widely available tools for this kind of task. In order for the trainees to obtain the basic knowledge of the log analysis, they were also asked to grab the look and feel of such traces to write some regular expression to match with them.

I know some other powerful tools like Scalp, LORG or real-time log monitoring with swatch are also available for this task, but this training provides and fundamental skill set for security analysts as a cornerstone.

It seemed that some of trainees spent tough hours at this training because they were not very familiar with command line tools or even UNIX like OS. But for my happy surprise, they managed to catch up with my quick and rough cheat guides on the white board, which described some names and functionality of a minimum set of useful UNIX commands. I was quite impressed that they were extremely fast in familiarizing themselves with something new to them.

CSIRT in a Box Training

“CSIRT in a Box” is a small set of systems designed mainly for newly-established CSIRTs to gather and store as much of security information, analyse by narrowing and graphing, extract indicator/attribution and automate ticketing to handle such cases.

Current implementation of the CSIRT in a Box is composed of IFAS by HKCERT which can gather information from different sources, store and analyse them - we just need to fill the missing part: the ticketing system.

I'd like to appreciate HKCERT's kind assistance in using IFAS as a part of CSIRT in a Box. It is a great system for this purpose, but please don't forget to apply my patch ;-)

IFAS has three major functions: "Log Search", "Reporter" and "Dashboard", and I went through each of them by explaining and giving some exercise.

With Log Search we can search log entries which match to a given condition such as date-time, country name in which the IP address is located etc. Reporter enables to count the number of log entries matched to a given criteria during a specified time period.

Dashboard draws many graphs from the result of Reporter. The trainees seemed happier with IFAS GUI than the previous session in general, which made me happy, even though I like CUI much more.

Photo 1: Sparky at the training

One of the trainees surprised me during the Reporter exercise by creating a Reporter to count how many phishing sites existed in the log entries for some brand-new geek item or something. Actually, such phishing sites did exist in the log entries, so they proved that the system is really useful during the first training.

Like this, I had happy days in the tropical country 3,000 miles away from my home, with hearty hospitality of people. I felt like I had another home town there.

Thank you very much, mmCERT/CC and my dear trainees. We hope to visit again for another training session.

Photo 2: mmCERT colleagues and us

Thank you.

- Moto Kawasaki