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;
67
68 SetIESettings("localhost:" + proxy);
69
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 0.0.0.0:your_proxy_port. 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.
