
well good morning I'm Carlos and today I'll be talking about uh how to bypass internet explorers cross-site scripting filter there's still a little bit about about me um I do not have a computer science networking background I'm actually uh former formerly a mechanical drafting um one of my friends is looking for work wasn't finding a whole lot in the field said hey white hat Security's hiring try this and so hello T can you hear me now should I start over or cool all right so yeah one of my friends said hey white hat security is hiring try this and so three years a little under three years later here I speaking at bsides so today we'll talking about uh
the agendas basically how I found this uh this bypass explanation of what exactly is going on on in the bypass so as a reminder as to not trust browser based security stuff and a process for everyone who's in off the offensive side of security to actually add this processes to your toolkit so first the bypass almost a year ago I was uh poking around at a website doing a vulnerability assessment as visiting the browser in various the visiting the application in various browsers to see if there's any sort of browser specific functionality that would appear I already gone through Firefox Chrome Opera Safari and last on my list was everybody's favorite Internet Explorer previously I had found a
somewhat interesting cross-site scripting vulnerability there I could get my injection onto the page however before that injection would execute there was a block of JavaScript further up on the page that would check to see is this page that has the reflection within the iframe of another page and if that if the vulnerable page was not within that larger iframe page it would automatically redirect the user to that outer page with the the uh injection stripped out I did note however in the URL for that bigger iframe page there was a parameter that allowed me to specify the page within the iframe so my injection could go from the URL to the source of the iframe definition to that vulnerable
page so just a step down vulnerability so again I initially found this in Firefox I was looking around and seeing is there any browser specific functionality I was poking around Internet Explorer didn't find anything browser specific for Internet Explorer and just for fun I decided to go back and poke at this to see you know it looks interesting might be fun to look at so as part of the standard training at Y how we get for cross-site scripting is we learned that in uh attribute space heximal encoded entities are automatically decoded by the browser so for the two of you who do not know what that is inside the uh definition of a HTML element we have the
bracket angle brackets the uh HTM ml element name and then all the various aspects of that and we talk about uh Landing in attribute space we're usually Landing talking about an injection Landing somewhere in the value part of a parameter equals value pair so just for fun and to see how clevy could be with an injection that did not look like script alert script I encoded some characters uh that would land as hexadecimal encoded inside the iframe and I sent that through and I got an alert box which is not supposed to happen my first thought was I was doing something wrong maybe I had some settings somewhere turned on turned off I was going through all the various
settings and Internet Explorer okay everything's at the default everything's at this is at the default this is at the default okay maybe there's something wrong with my virtual machine just restart it see if there's something I was doing stupid no restart the computer to see if there's some weird thing going on no showed it to the cooworker for okay am I just being completely and utterly stupid about this no it's actually happening so after that I sent a report to my management and uh I went home for the weekend because it was a Friday and Friday so over the weekend I spent some time building some deliberately vulnerable code that would demonstrate what exactly is going on uh reported it to Microsoft
got a case number and a bit over a month later Microsoft came back and said no fix so what is going on in the bypass the cross-site scripting filter has a trust model and we can abuse that trust model to bypass it the filter decides which requests are going to be subject to checking and which requests are just going to be let through so what's going on a primary request is made to the page such that it does not cause an immediate JavaScript code execution with that injected data a secondary request is made to some page on the same domain that does cause a JavaScript code execution that first request is subject to the filter the
secondary request passes through without being filtered at all so what's look for so for everybody in the offensive site of security what you're looking for is ways to induce a secondary request within the same domain so you're looking for inline frames frames form submissions uh landing and ATF attributes uh JavaScript redirects and anywhere on the page where you can get a link in and in terms of disguising your very first injection um there's various uh standard uh encodings that you can use hex decimal encoding where it's Amber sand hash X followed by an alpha numeric character ref refence semicolon um the decimal which is ERS Hash a numeric character reference semicolon named entities uh Ampersand
some sort of alphabetic string that describes a character and play Old URL URI encodings when going about testing this sort of thing the filter really does not like periods almost at all you will occasionally be able to get a period in on your primary injection but more often than not the filter will see that hey this thing has a period in it I'm just going to block it change it and your primary request will not get through it also does not like adding your own HTML elements of a form frames and if frames so possibly doing a trying to induce a secondary post request may not be all that easy sometimes the filter will let through
all your uh parentheses square brackets curly brackets and occasionally the word style and that style is actually somewhat important thing to use for the demos I should be getting to right now so
hello so this is Internet Explorer on Windows 8.1 Internet Explorer 11 latest and
greatest and our security settings are all at default level so the cross scripting filter is currently on
so I'll just jump forward a little
bit on wireless
so this is what I believe is shows the best exactly what's going on so we have this form with a parameter that lands and becomes part of the page there's our test injection and that request is then sent on to another page within the same
domain so again we can get our tags in and they are rendered in the vulnerable page that's fine yeah same domain so
so we then make a primary request that lands on the page but it's when the crossy scripting filter sees this it seemes that this will not cause an automatic JavaScript code execution it will not change anything on the page your primary injection gets on through however the browser itself will automatically decode it and so a secondary request is made and the alert box pops so you the source of the secondary page our generic script Source equals external Javascript file close script appears we can actually look at the requests themselves so this is the primary request with the injection and it lands on the page and it does not cause an automatic job code execution our secondary request is
script Source equals external Javascript file close script because the filter checked the first request it will not check the secondary request and this gets on through and lands on our page script Source equals external Javascript file close
script again talking about various encodings in addition to hex decimal
we can also use decimal encoding or instead of the Ampersand has hhx it's simply Ampersand hash numeric character reference and inside attribute space those are automatically decoded the secondary request is made to the same domain and we get our alert box to pop so again looking at the requests our primary request is made lands on the page such that it does not cause an immediate JavaScript code execution the secondary request is made to a page on the same domain and that secondary request is not filtered at all
so and this up here this is a actually a mockup of where I first found this so we have a page and there's a definition for the iframe in the page and a parameter in the URL that defines what page is being sourced into this iframe
so we can then use for example a named entity
injection oops just typed the uh that's why copied the wrong thing
okay this time with the correct copied and paste so we Define the page the page has a vulnerability in it the iframe automatically makes that secondary request for you without any user interaction so again the primary request lands with characters encoded such that this does not cause an immediate JavaScript code execution because we're Landing in iframe the secondary request to the same domain happens automatically without user interaction and are injected script then executes so once more we looking at the requests our primary injection lands with characters encoded and the secondary request to the same domain script equals external javascri Source equals external Javascript file Clos script the secondary request is not checked at all
then just before the demos I mentioned the use of the word style so in this demo what I have is a vulnerable page where that's all you get you can get angle brackets in onto the page
so our injection lands on the
page we can render our tags on the
page so we can do is because we can inject tags onto the page is inject a division element with a bunch of CSS that completely covers the page and now you have for the user hey the page you really want is right here you should click this link to go get it however when you look at the source of the page here's our division element Style with our CSS element elements here defining the division element to completely cover the page so that user that's what they see and then a link back to the very same page with our injection and since we're Landing an attribute space this all these characters will be automatically decoded for the secondary request so the
user says hey I really want to be over here clicks the link and our script is injected onto the page
script Source equals external Javascript file close script once again looking at the requests our primary injection lands on lands on the page completely covers the page so the users user sees that all they want to do is click that link secondary request is made script equals external Javascript file close script that secondary request is not filtered and your injection lands on the page and is
executed okay I believe I have time for one more demo so for examples of a page where we actually have there's a JavaScript redirection to another page on the same domain so in this secondary page there's a parameter that lands on the page and as
before we can get our tags in so we can use in this case is that when we look at the source let me oops not fast
enough so our injection lands on the page there's a JavaScript that will redirect it to the landing page with a scripting and our injection is simple simply URL encoded with some characters such that will not cause the immediate JavaScript code execution however when it gets redirected to the secondary page it does execute everything's decoded in our script Source equals external Javascript file close script is executed and again looking at the requests our first page lands our injection lands is simply URL encoded in JavaScript fa space the redirection happens without user interaction to the secondary page where injection script Source equals external Javascript file Clos script plans and is executed by the browser
oops so when I first got word that Microsoft was not going to fix this I was actually given two separate reasons why this would not be fixed once in the immediate aftermath of my report and then a second reason several months later when this became public um initially it was because it requires special functionality um that's not actually true everything that we've used here is part of the HML standard and has been since at least 1998 if not sooner um second was that this is the later reason was because it requires user interaction that's partially true in the case where you uh inject links or maybe there's some form that needs to be submitted but in the case of JavaScript
redirects or frames or iframes those are action that are automatically taken by the browser without user interaction so the website that I had up there um I have a bunch of cards up here they'll give you access to that site so you can poke around it yourself um the PHP code that's running on the server is up on my GitHub page so you can go there download it run it on your own server to show that I'm you know this is Vegas but there's nothing up my sleeves so are there any questions so you coded your web page correctly and you before I believe there AC cross filter and and previously you have to like speciically
pagetic would vulner that is correct if you code your page to make sure that the generic primary injection JavaScript uh cross scripting is not possible this is not possible at all okay one more thinging in a long time what doil apply um what the the cross-site scripting filter does that's the question so the cross-site scripting filter checks the requests and responses checked by sent by the browser to see does this uh request that is made cause the reflection of code on the page such that it would cause an immediate JavaScript code execution again again in Internet Explorer there's this trust model of which requests are filtered and which requests are not and we can use
that trust model abuse it and get our injections past the filter uh this does not work in Chrome it does not work in Firefox with no script it just works an Internet
Explorer I believe the question is will this work with content security policy I have not tested it but my guess is that this will be not work with content security policy
so the question is when is the uh injection decoded the injection is decoded automatically by the browser at the start of the secondary request after the first request is made the filter just checks the fil the first request not the second request yeah thank you [Applause]