XS Leaks: Client Side Attacks In A Post XSS World

so um yeah so first of all thanks to everyone for coming to my talk today um I'm zann and I'm going to be speaking about excess leaks um so yeah let's get right into it so I guess before we start um let me introduce myself I'm studying computer science at Cambridge I play ctfs um with water pedor which is part of Blue Water um we were at Defcon earlier this year um previously I was working with Tik Tok um as a security engineer um and now I'm freelan with Electro vote and cure 53 which is a penetration testing company um in my free time which is very rare I'm I'm building veos slaps which is a security

training company um yeah so I guess the question that we can start with is are we in a post accss world so what do I mean by that so it used to be the case that we could achieve xss really easily because web Frameworks just weren't secure like you could just Echo untrusted user input in PHP and that could lead to an xss because HDMI output isn't sanitized and similarly there weren't really very good Frameworks that people could use to sort of manipulate client side elements and so people had to set inner HTML um by themselves and then that and I mean that that just could lead to a lot of mistakes um so Dom access Dom xss and and basically

reflected xss was just really common because um just just it Frameworks just weren't secure um and then well Frameworks become safer by default so we have react which um you know you have your value of embedded Expressions that get automatically escaped before being rendered so um it became like basically safe by default um and while the web standard as a whole also became safer so we have things like content security policy to act as a l line of defense against xss and browsers also became smarter about mind type sniffing um so these are really good things because even if your application is coded insecurely um they can still save you from some attacks and sure there will always be

quirks and by passes and these sort of things so for example um you could still inject JavaScript URLs um if you have control over um the HRA attribute of um react components and when someone clicks on it that leads to an xss as well um and this is like more rare but like this is very interesting so if you can control the component properties of um react components then you could also easily achieve xss by specifying custom HTML attributes so for example in in this like very simple example you're just getting um whatever um whatever attributes there are in the URL search parameters and um basically expanding them out into the react component and if

you have arbitrary control over that you could essentially just specify custom HTML attributes so for example here I'm just specifying a um on Focus event handler um well but even even so um as Frameworks and standards evolved it's inevitable that basically traditional xss and csrf are becoming more and more obs Elite so how do we sort of respond to that so basically the idea of EXs leaks is that maybe we couldn't execute JavaScript right maybe we couldn't perform a full account takeover or directly steal session data but could we still somehow abuse legitimate browser apis to sort of infer information about users in a meaningful way and so this is the first example that I want to dig

into so basically there might be a scenario where we might want to detect whether a specific URL results in a redirect and why might we want to do that so for example um some URLs might serve as search endpoints right and if a result is not found it might redirect back to the main page where you started a search and if the result was found then it might not redirect so it depends on how like the application logic is coded but basically um we there might be a scenario where we where we can leak some user state by detecting whether a redirect happens or not so we could try to do this thing where sort of we open a

new window from our website to a leaky endpoint um on the Target website where we want to detect whether it redirects or not and we wait for a potential redirect to happen right um and so at this point we might be thinking so well we could just try to read the history. length property of the window that we opened and well in this case the browser would stop us because browsers have become really good at sort of um implementing these sort of cross origin defenses so we are attempting to read properties of a cross origin site so the browser would stop us but there there's like a really simple way to get around this so you you could just redirect the

window back to your own attacker control site and now suddenly both windows are the same origin and now suddenly you're able to read the property again so basically the history length would be three if um in step three the target end point that you want to test um redirected and so basically you have one redirect that that was you redirecting the window to the Target website and then a second redirect by the Target website which you want to test for for and then a third redirect back to your own site so that's free and if it didn't redirect in step three then you would just have to you would just have a length of two right so this is a really

simple technique but it's really powerful I mean like I couldn't reveal which client this was but basically this this basically this is the full POC and it allowed us to leak um team members device history connections Etc in a popular VPN service um so this is like really powerful um so let's dig into this so we we just showed that how we can detect like client site redirects but there's a problem with this so history. length is a JavaScript property it can only track client site redirects um it wouldn't work with server redirects so there used to be this sort of technique where you could use the abuse the maximum redirect limit of the fetch API to sort of detect whether um a

redirect happens but there's a problem because the fetch API is subject to quite a few security restrictions this only works for samite non cookies so basically if you have samite Lex cookies the fetch API wouldn't send the cookies in a cross origin request and therefore you wouldn't be able to send any authenticated um cookies and you won't be able to leak any authenticated state so well how do we get around this so this is like a really interesting story because I was working on a completely unrelated CTF challenge when I came up with this idea um and it led to a really interesting unintended solution so the inspir ation behind it was um basically reading the chromium documentation and

seeing that um well chromium browsers limit URLs to a maximum length of 2 MB and so the natural question here is what what happens after 2nb so we will explore that later but basically we know at this point that if we approach the 2mb limit there might be an error condition that we might be able to detect and so we know that Chrome has a URL length limit and at the same time we also know that when handling serers site redirects URL fragments are preserved so what do we mean by that so look at this um so basically we look at this um red part of the URL that's a URL fragment um and basically when example.com redirects

to a different website um the browser keeps the URL fragment in the address bar so that part of the URL is preserved even though the redirect didn't explicitly say that I want to redirect to this fragment um but it sort of preserves the state in the browser URL um so basically the idea is that we could construct the URL with a long fragment that essentially keeps the URL just under the length limit um and so basically you could just calculate um how many like how many characters you need in the fragment in order to keep it just under 2 mbb and if a redirect causes the URL length to increase um then the total length of the URL now

exceeds 2 MB and then the chromium browsers have this really interesting thing where they just sort of like just say okay I'm going to just render an about blank page um because this is like too long for me to handle and I'm just going to um say this is this is a blank page um well otherwise um sort of if the URL if the URL length doesn't increase then um well basically nothing happens right and like it's just business as usual you just have the same site exact same page being rendered um so this leads us to like sort of another like success and failure Oracle right so if the basically if the UR stays under 2 MB

then this would be rendering like as usual and you would have like basically a cross origin site and when you try to read things like the windows origin um the browser will stop you and if you but if this if the URL did increase in length then you then because Chrome renders an about blank page um and because the browsers treat a blank page as being same origin as the original site then well you could read the properties so basically um you could detect whether a the success or failure condition kind of um when by detecting whether a JavaScript error is thrown and so this these are just like two very simple examples but the web is

like really really leaky um and this is like some research that was done like two years ago now um about they basically they listed like all of the possible leaks um so there is a problem with this though because fet because most of these leaks use Fetch apis and if frames um but because same site is now lacked by default we wouldn't be able to leak any authenticated user state so now we get into this idea of samite leaks so maybe we could take a step back and look at what is the problem that we are trying to solve here so in many scenarios we have HTML injection but we couldn't get xss due to

sanitizers and CSP so we could start thinking about whether we can try to leak the user State without any JavaScript so the first example that that is very interesting to me is um what can if frames leak right so when I have a HTML injection sometimes the first thing I think about is iframes because naturally the question is well if we're embedding a cross origin if frame that can run JavaScript what can we leak from the parent side so you have typical stuff like user agent but these are not very exciting um but it might be a surprise to you that if you just specify the allow equals to geolocation attribute the if frame code access the

users's geolocation um and so because so when the attacker site which is in the if frame tries to access the Jo location it is actually the victim site that is asking for um the permission so crucially when the prompt appears it is not the attacker site that's asking for for permission and if the victim site has previously granted permission for geolocation well guess what the attacker could just easily read it um which is like that's insane um but what else can you do with HTML injection well you could consider a scenario where the Leaky API sort of returns different status codes depending on whether a result was found so maybe if the result was found it returns a 200 status code

and if it's not found then you get a 404 right so something like that right I mean this is a gross simplification but basically just 244 status codes so we could try to use this idea of nested objects so the difference between sort of an object and an if frame is that when an object URL returns a 400 status Cod oh sorry 404 status code it is actually not rendered by the browser so even though it exists in the Dom tree it does not exist in a GUI so instead the inner object is rendered instead so if you have these sort of two nested objects if the outer object returns a 404 the inner the inner object

is actually the one that's being rendered so if we set our own server URL to the inner object then we can detect whether a 404 was returned by checking if we received a call back and so well this is interesting but what if we had CSP that sort of blocks external object objects um we could try using a responsive images so here we have an ey frame that is at least 1,000 pixels wide when it is rendered and we have specified an image source set that loads an image um when the viewport is at least 1,000 pixels and a different image otherwise so well you can see sort of see what where we're getting at here

because um if a 404 is uh return in the outdoor object then basically the I frame would be rendered and because the I frame has a width of 1,000 pixels well the responsive image matches the First Media query and loads the first callback so we can detect that the first callback was was being was being requested by the browser um and if we have a 200 status code then the outer object is being rendered the if frame is not rendered um so the responsive image matches the second um callback and well it loads the image from the second callback so by detecting whe which one of these callbacks was being rendered um that we can detect whether it returned a 404 or

a 200 status code and if we just sort of expand this idea um we could sort of basically Brute Force um basically Brute Force characters or sort of search queries and see which one works and see which one returns of 200 status code so yeah that was like the so basically that was the last example that I want to talk about um so takeaways so traditional xss and csrf are becoming increasingly obsolete um accs leaks abuse legitimate browser apis to leak the users State through sort of success and failure oracles and so one of the main problems with excess leak techniques is is like samite protections um but we could sort of get around that by trying to

weaponize HTML injections to achieve same side leaks um if the if the target site already has a HDMI injection vulnerability so yeah that brings me to the end of the presentation if you want to connect with me there's a QR code um slides for this talk is available at that link and I'll be happy to take any questions