Facebook: Another Linkshim Bypass
12:48 PM
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.
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,
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:
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:
Using that, we construct our payload:
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! :-)
0 comments
Note: Only a member of this blog may post a comment.