Redirecting to Protocol Handlers

Originally published here: https://www.optiv.com/blog/redirecting-to-protocol-handlers

On a recent client engagement (names/URLs changed to protect the innocent), we were given a web service that handles click tracking for high volume content (think: marketing emails and social advertisements). This is certainly not new technology, but this click tracking service presented interesting behavior with URL protocol handlers.

Essentially, an html snippet full of marketing collateral would be presented to a customer, and any links on the page would be masked with the click tracker, similar to this:

<a href=”click.customer.com/track?destination=http://store.customer.com/sale">

Typically, since this is otherwise ripe for unvalidated URL redirects, trackers will implement this with the destination obfuscated or encrypted:

<a href=”click.customer.com/track?d=23a8cdea3ca2189a0332db85b7">

However, this service left the destination visible in the URL, which means an attacker can directly manipulate the destination parameter. First step, of course, is to see if the service allows redirects to any domain of our choosing. On the example above, the service would present a 302 (object moved) response to redirect to the destination URL. However, trying to inject “http://www.google.com" into the destination parameter resulted in a 404 (not found) response. After enumerating through the client’s domains, it became obvious that the service is clearly whitelisting the destination domains, as it should.

So the next step is to play with URL parser to see how well it can handle certain other scenarios. We tried:

http://click.customer.com/track?destination=http://www.customer.com@www.google.com

This is attempting to exploit the optional username:password@domain format that HTTP and HTTPS support. Again, this is not a new technique and the service properly parsed the URL, resulting in a 404 if the domain didn’t belong to the client.

Next up, we decided to play with the protocol handlers. Immediately, we noticed the service would properly redirect to ftp://user:pass@ftp.customer.com. Even though most modern browsers will support FTP, this is boring since there just isn’t that much you can do with this besides redirecting a victim to a company’s FTP server (specifying the credentials, no less) using the company’s own click tracking service. It’s possible you could put malicious content on the company’s FTP server, but then you could just direct people straight to the FTP server using an FTP:// protocol handler. The only reason to launder the URL through the click tracking service would be if your victim cannot directly click on FTP:// links (e.g. if their email filter strips them) or if they’ve been taught not to.

But this is 2015 and everything is mobile-friendly these days, so lots of mobile apps like to register their own URL schemes and protocol handlers on the mobile device’s OS. Here’s one developer’s (good but very incomplete) list of such URL schemes: http://wiki.akosma.com/IPhone_URL_Schemes.

So, the next step was to apply some of these to see if they’d get through the click tracking service’s filters. First up:

<a href=”http://click.customer.com/track?destination=tel://867-5309@customer.com>

This one bypassed the click trackers just fine, but besides the 1982 Tommy Tutone reference, this was fairly boring since it prompts you to call (Note: screenshots below are only the protocol handlers for the privacy of our client’s click tracking service):

If you touch the call button on iOS, the call attempts to complete, but fails since the number is not well-formed:

Sending an SMS message was similar, but it didn’t prompt to hit a button, which benefits the attacker:

Unfortunately, the click tracking service wanted sms:// and did not like sms: (without the slashes) so the experience was less than perfect as well (besides the victim would have to type out their own message and hit “send”):

Some of the more specific apps get much more interesting. How about laundering a link to the LinkedIn app through the click tracking service?

Which of course will launch the LinkedIn app and point to the profile page:

Or how about getting the victim to open up the local movie listings in the IMDB app?

Which breezed through the click tracking feature nicely:

Or any of the myriad of Facebook URLs which could be finessed to pass through the click tracking filters:

  • fb://album@customer.com
  • fb://chat@customer.com
  • fb://event@customer.com
  • fb://feed@customer.com
  • fb://findfriends@customer.com
  • fb://friends@customer.com
  • fb://mailbox@customer.com
  • fb://online@customer.com
  • fb://photo@customer.com
  • fb://place@customer.com
  • fb://post@customer.com
  • fb://profile@customer.com
  • fb://publish@customer.com
  • fb://upload@customer.com
  • fb://video@customer.com

At a minimum, this is a potential mobile app “rickrolling” attack vector. This may also allow for attacks against potential flaws in mobile applications, since the body of the URL scheme may be used to pass data into the mobile app. For example:

<a href=”http://click.customer.com/track?destination=some-app-handler://some-action/some-param/some-value@customer.com>

If a mobile app is vulnerable to injection flaws through its URL parser, this may be a simple way to attack that app while laundering the delivery of the attack through a trusted domain (“customer.com” in this case). The victim user may see this as a targeted marketing campaign, click the link, the click tracking service would then issue a 302 redirect to the mobile app’s URL scheme, and the malicious payload would be delivered to the mobile app.

So, while it’s important to validate domains on URL redirects against a whitelist, it’s equally important to validate the protocol handlers, or else your redirect may become complicit in an attack against mobile apps.