Investigating Custom Protocol Handlers

By Hayden M. Nier

Many browsers today make assumptions on behalf of the user in order to ease their web surfing experience. For example, typing ‘google.com’ into the address bar will take you to your destination even though you have provided your browser with partial information. In this example, several things have been assumed by the browser. It guesses that you had meant to prepend ‘www.’ to the url and does a DNS lookup on the concatenation of this and your given url. Also, it assumes that you are requesting the service running on port 80. Furthermore, the browser assumes that you mean to include an initial ‘http://’ as well. This initial string is the protocol to be used and is associated with a certain protocol handler. These are saved at the OS level and are associated with different applications. On windows, the ‘default browser’ is listed as the handler for http and thus all http links are opened with the browser. Therefore, when you insert a link into Microsoft Word, and click on it, Word makes an OS call in order to figure out which protocol handler to use and then opens the respective program, generally your default web browser. Other common protocols with handlers are ftp, callto and mailto. Mailto is tied to the current default email client while callto generally uses a video chat client such as Skype. When a user clicks on a link beginning with ‘mailto://‘ in their browser their email client is launched. However, these protocol handlers can be managed and custom ones can be implemented. Although it may be obscure, this opens the door for a serious vulnerability.

Cross site scripting is a web vulnerability that takes advantage of the fact that it can be difficult to discern the difference between data and code. When unvalidated or unwhitened input data from a user is treated as code, it can be executed and result in malicious activity. Most commonly, this consists of injecting javascript into a form or link which is then executed by the browser. Stored cross-site scripting is a variation of this in which the malicious data is saved on the server and later provided to users upon request. This creates the possibility for injecting malicious links that are automatically downloaded. When a browser encounters img tags, it automatically makes a request for their source in order to display them for the user. This is potentially dangerous because the link may be malicious as in the following example:

<img height=”” width=”” src=”http://badlink.com”/>

This may not seem like a big deal, as the link above is an http link and thus will be handled by the browser. However, what if we were able to inject a custom protocol handler onto a victim’s system? Then, when we force them to go to our injected link, they’ll execute the given protocol handler.

In first attempting to develop a proof of concept for this vulnerability, I began researching creating custom protocol handlers. The results were frustratingly limited however I eventually happened upon an article on msdn.mircosoft.com entitled “Registering an Application to a URI Scheme.” Using this, I wrote a quick batch script to register a custom protocol on windows:

1.png

When run, this installs a protocol handler called ‘climb’ and ties it to a file named ‘shutdown.exe’ located in the C:\Program Files\ directory. For the proof of concept I wrote a simple one line batch script that shuts down the computer:

 

C:\\Windows\\System32\\shutdown -s -f -t 00

 

I then converted it to an exe so that it can be called easily when the user clicks on the link. Next, I opened Internet Explorer, went to climb://www.google.com and sure enough my computer began to shut down.

So now that the proof of concept is working, we can begin to examine how to make this exploit more dangerous. The easiest way to get the custom protocol handler installed is through physical access to the machine. However, this is incredibly unlikely. Perhaps the next easiest way to get a user to install the necessary protocol handler is through social engineering. By sending them the script in an email and pretending that it is something harmless, we may get them to install the handler for us. By zipping the script with the protocol handler executable, we can assume that the user will keep both in their downloads. We can write the script as such and once installed, hope that they don’t delete the folder. If we wanted to be more clever, we could assume that they send it to their recycle bin and edit the path to the handler to reflect this.

Once we’ve decided upon a method for getting the handler installed, we must decide what exactly we want it to do. Many mainstream languages have programs that can compile scripts to .exe such as Peachpie for PHP and PyInstaller for Python. This presents the opportunity to do anything that we want, such as a remote shell, a keylogger, file enumeration or data collection.

Finally, we must actually take advantage of the installed protocol and handler. As discussed, cross site scripting is the perfect attack method as the user would have no idea that the broken image on their page just activated a custom handler. Besides this, we could turn to phishing or spear phishing in order to get our victim to click on the link. Unfortunately, common url shorteners such as bitly and goo.gl do not work for protocols other than http, thus the link will be in plaintext which may alert a victim.

Luckily for the good guys, this potential for exploit relies on several contingencies. As discussed, it is rather difficult to get the handler installed. Not only does this require getting the victim to change their registry, we also have to know where the handler executable is. Also, this approach is platform dependent which is also potentially problematic. The discussed technique only works for Windows, as Linux relies gconftool-2 up set up custom protocols. However, cross site scripting is less rare than it should be which poses a problem . If an attacker were to successfully get the handler and protocol installed, they would need only bide their time until an XSS vulnerability presents itself. All in all, despite being a potentially dangerous attack vector, remote code execution through custom protocol handlers is very difficult and thus not too large of a risk.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s