Exploiting odd behaviors in MS Edge & IE to bypass Facebook’s Linkshim

2:32 PM


The following post is inspired by an all charset unicode shazz by @insertscript. After I saw it being referred in a tweet by Gareth Heyes, I immediately started fuzzing for more characters Internet Explorer & MS Edge may interpret horribly, and confuse the anchor host parser to ultimately use and bypass Facebook's Linkshim.

Fuzzing:

<a href=”/[$]example.com” id=”fuzzmeiah”>fuzz</a>
<script>

chars = [];
for(i=0;i<=0xffff;i++){
    if(document.getElementById('fuzzmeiah').hostname==example.com) {
      chars.push(i);
      console.log(chars.join('\n'))
     }
}

</script>

Result:


Character 1: 〱- 'VERTICAL KANA REPEAT MARK' (Ux3031)


The first one works for both IE & Edge is 0xE3 0x80 0xB1 (e380b1 aka 〱) , when plugged alone or after a forward slash, confusing the parsers to misinterpret the hostname.


<a href=”/〱example.com” id=”fuzzmeiah”>fuzz</a>


This can be tested in both MS Edge and Internet Explorer by changing links Facebook expects to be relative URIs and thus not passing them to a linkshim validation endpoint, allowing redirection to a blacklisted site (in this example, user must click on continue or cancel)




Character 2: 〵- 'VERTICAL KANA REPEAT MARK LOWERHALF' (Ux3035)




Character 3: ゝ- 'HIRAGANA ITERATION MARK' (0x309d)




Character 4: ー 'KATAKANA-HIRAGANA PROLONGED SOUND MARK' (0x30fc)



Character 5: ー 'HALFWIDTH KATAKANA-HIRAGANA PROLONGED SOUND MARK' (0xff70)




This specific issue is not fixed by Facebook as they believe it is more of the browser vendors fault and shouldn't be fixed from their side. Even though I disagree with their decision, I believe a very few percent of Facebook users use IE or Edge so I didn't bother trying to change their mind. I hope this post inspires either Microsoft or Facebook to fix this issue though.

I hope you enjoyed the read. =)

Why CSP Should be carefully crafted: Twitter XSS & CSP Bypass

3:09 AM


Few months back, I came across an oauth xss accompanied by a nice CSP bypass in Twitter. While creating an application, a developer can set their terms and service URL for their app, which Twitter configured to be: ([https?:])\w+

Unfortunately the regexp is missing a ^ char in the start  making malicious URLs like data:CONTENT#https:// work -- so we got HTML Injection, but almost useless for a practical attack because of the CSP rules. After checking the header, I noticed there are multiple CSP misconfigurations in the script-src and object-src blocks, making it possible to bypass CSP in twitter.com. The CSP Rule looks like:

script-src https://connect.facebook.net https://cm.g.doubleclick.net https://ssl.google-analytics.com https://graph.facebook.com https://twitter.com 'unsafe-eval' ‘unsafe-inline’ https://*.twimg.com https://api.twitter.com https://analytics.twitter.com https://publish.twitter.com https://ton.twitter.com https://syndication.twitter.com https://www.google.com;frame-ancestors 'self';object-src https://twitter.com https://pbs.twimg.com; default-src 'self';...

Looking at this, the object-src and the script-src blocks got my immediate attention.
After some research, I saw one of the trusted domains (cdn.syndication.twimg.com aka syndication.twitter.com) hosts JSONP endpoints.

Originally I thought, by exploiting the object-src block (https://pbs.twimg.com) --  one can upload a Flash file (as picture/video extension with few bytes header) to Twitter CDN -- refer it to as an embedded Object to gain code execution. However, because of character limitation, the payload I was trying to make was too long and being cut off, so this method wasn't practical as we were working on a limited payload space. At this point, I sticked to the JSONP bypass for the script-src blocks and started playing with multiple parameters until I found a shorter version, when injected generating an alert in twitter.com.

http://syndication.twitter.com/widgets/timelines/246079887021051904?dnt=true&domain=twitter.com&lang=en&callback=alert

The above JSONP response from syndication.twitter.com comes back with a Content-Disposition header forcing a download. However, browsers like Chrome still execute the returned file even when returned as an attachment. At this point, this misconfiguration added with the ‘unsafe-inline’ CSP block -- meant we are able to execute code.

By setting the Terms & Services URL of an App to


A developer will be able to pop-up an alert.

POC

After some digging I noticed ssl.google-analytics.com, www.google.com and even graph.facebook.com host JSONP endpoints -- which I wrote to twitter over email -- but will not be fixed anytime soon because it may break the sites usage and call to these sites and performance.

Edit: Ben Hayak mentioned we can use same origin method execution (SOME) attack to manipulate the page as we like: https://syndication.twitter.com/widgets/timelines/246079887021051904?callback=document.body.firstElementChild.Reference.submit -- as used by my Instagram XSS.

I hope it was a fun read,  :) --