SWF Seeking Lazy Admin for Cross-Domain Action

hello everybody how's the volume good good well thank you all very much for coming my name is seth art and i'm going to be talking about exploiting cross domain xml files today like many of you i've been playing with computers for as long as i can remember that's me currently i'm an associate at blue canopy and a member of nova hackers and also owasp dc so the purpose of this talk is to introduce you to the cross domain xml file if you haven't heard of it to hopefully convince you to start looking for it on all of your web application assessments and lastly to show you how to exploit this vulnerability when you find it

so i'm sure some of you are familiar with same origin policy but i wanted to cover it at the top really quickly anyway so same origin policy restricts how a document or script loaded on one origin can interact with a resource from another origin so basically that's saying if you have one browser window open you have two tabs on one tab you have mail.google.com you're authenticated on the other tab you have bsidesdc.org there's no code that can be loaded into your browser from b-sides dc.org that can interact with your authenticated session at mail.google.com that is control it's enforced by the browser and it's called same origin policy so what is the cross domain xml file

well let me explain it this way if a swift is embedded in site a or swift ak a flash object is embedded at site a and it tries to load data from site b the flash player will disallow this cross domain request by default and that should sound a lot like same origin policy because flash in has its own same origin possible however with flash site b can grant site a access to its data through the use of a cross domain policy file and that is the prospect domain xml so think of it as a way for site b to specify who it trusts and this is an example of a properly configured cross domain.xml

file so what we're looking for here is the allow access from directive and specifically the domains that are the domain or domains that are being trusted so in this case this policy file allows me to make the following statement any swifts loaded into a user's browser from macromedia adobe photoshop and acrobat.com are authorized to make cross-domain requests to www.adobe.com and this is an example of what could be an overly permissive cross domain xml file this is the most permissive policy that you can have and again we're looking at the allow access from but in this case the domain equals star so swift's loaded from anywhere can interact with internet internet web server for those of you who are familiar with

application security think of exploitation of this vulnerability as somewhere in between cross-site request forgery and cross-site scripting cross-site request forgery because it in every instance of exploiting this vulnerability you are making the victim make a request on your behalf however unlike normal cross-site request forgery where you can make the victim make the request but you can't see what comes back it's a blind request but with this vulnerability similar to cross-site scripting you can see the data that comes back and lastly i wanted to touch on the fact that this is a server-side vulnerability specifically it's a mis-configuration of that cross-domain.xml file on the server however it's the client or the users of that vulnerable server that are being

exploited and to illustrate that that point i wanted to use these graphics here so there's three players that are required for exploitation the vulnerable server the malicious server and the victim and the evil swift is hosted at the malicious server and i wanted to highlight that at no point does the malicious server make any direct connections to the vulnerable server when i was first reading about this vulnerability especially when you read about the swift contacting making a cross-domain request i was i got stuck on this so i wanted to make this very clear the victim is always required for exploitation which is a client-side attack so the first requirement is that the victim needs to be authenticated with the

vulnerable server or have restricted access to the vulnerable server the next requirement is that the victim needs to arrive somehow at the malicious server so think phishing watering whole attack you know something like that once the victim arrives at the malicious server and they download the evil swift that swiff is now executing in flash player which is inside of the browser running in the context of the browser now the author of the swift can code the swift to make any cross domain request that the author chooses it's up to flash player and that same origin policy determine whether those requests are actually allowed to be made and the way that the mechanism for doing that for asking permission is the

cross domain xml file flash player makes a request to the vulnerable server and as you can see here this vulnerable server is says allow access from domain equals star so flash player says i have a swift from malicious.com is it authorized to talk with you and this server is saying yes i don't care where it's from it's authorized to talk uh with me and access my data so once the victim has been authorized or that evil swift has been authorized to interact with that domain it can now make the request that has been coded and this is the response coming back so that's something that normally shouldn't happen uh the evil swift has made a request to

vulnerable.com this is the data coming back and this is the data being sent back to the attacker so before i move on from this vulnerable server and the allow access from domain equal star i wanted to you know kind of frame this a little better with just some points so i think a lot of people get stuck on this at first too the site is still vulnerable even if it doesn't use flash the cross think about it this way any site that you control if you were to put a cross domain xml file at the root and it was overly permissive and there's sensitive information on that site that site is now vulnerable to this attack

and second the cross domain xml applies to the fully qualified domain name so if there are multiple applications sharing the same fqdn and one application team drops the cross-domain xml that's overly permissive they've just affected the confidentiality of both applications and the integrity of both applications and lastly keep in mind that everywhere you see a domain equals star for the allow access from directive does not necessarily mean there's risk think about a public site with nothing but public information we call those brochure ware sites and it's just telling you about the institution there's no sensitive information so there's nothing worth stealing and there's no actions that are worth sea surfing so there's no risk even if swifts loaded

from anywhere can interact with them and a good example of all of those last couple of points is www.capitalone360.com so as you can see www has a wide-open cross-domain xml file however all of the sensitive information happens at secure.capitalone360.com and there is no cross domain xml file at that fqdn which means that it defaults the same origin policy which means a swift can't interact with that at all so the swift you can write a swift that can interact with www but it wouldn't get anything because there's nothing with stealing so i just wanted to touch really quickly on a few ways to discover this vulnerability first is just manually entering into your browser you know once i started doing this

research i kind of got in the habit of everywhere i went i just typed across domain.xml and you're looking for the allow access from directive and domain star the second a lot of the automated scanners and the manual proxy tools this is burp suite pro will alert you if a over the permissive cross domain file exists and nicto also has a specific plugin called client access policy and it will run you probably seen this if you run you know all the plugins before if there is a cross domain xml file and it contains a wild card it will alert you so at this point i wanted to touch on the history of this vulnerability this is a really old vulnerability

crossdomain.xml was introduced in 2003 by flash player 7. by 2006 chris shiflett julian corver and jeremiah grossman were talking about this vulnerability and blogging about it publicly in fact in 2008 jeremiah grossman released a video showing him exploiting this vulnerability on youtube and then in 2010 ireland affadel uh revisited this issue wrote a bunch of great blog posts and released the mallory proxy tool as well so you might ask yourself why am i at a security conference in 2014 listening to this phone or build let's talk about this vulnerability and i think this is why they're aside from jeremiah grossman's 2008 demonstration of this being exploited there are no they were when i started doing this research there were no

other real world scenarios of how to wrap your head around number one how can you exploit the vulnerability or you know how can the vulnerability be exploited and more importantly how can i go from finding the vulnerability to actually exploiting it myself that just wasn't out there when i first started doing this research but i'm here today so what changed well for me it was this blog post by gersof kaura about a year ago he he wrote this blog post and in that blog post he released this actionscript code it's a single file of actual script code and you can and he explained that you can compile this actionscript code into a swift that will exploit this

vulnerability and in fact all you need to change are the two things highlighted in yellow and i'll go over those in a little more detail the thing is i finally had i wrapped my head around this vulnerability i felt like i understood it enough to exploit it but i wasn't i didn't have an application that i was testing at work that was vulnerable to this at the time and i was impatient so i decided to look around the internet and i wasn't disappointed so these are just a few of the sites that i've responsibly disclosed this vulnerability to and they've since been fixed so i'll use these in my talk and some of the examples but there are tons out

there and i would encourage you if you have any interest into looking for some of these and responsibly disclosing them i think what the issue is that unless you can demonstrate the vulnerability and demonstrate the risk if you just tell a site well this configuration is wrong you know they might not really understand and they might say you know put up a fight so the first one uh that we'll talk about is bing and in this demonstration i'll show how you can exploit this vulnerability to see the search history of everything that that your victim has ever searched for while authenticated with bing so this was the cross domain xml file at www.bing.com as you can see the domain equals star

for the allowances from director now bing allows you to query everything you've ever searched for using this url ssl.bing.com profile history the thing is there's no cross domain xml file at ssl so our swift can make a request here but nothing would happen say flash player would respect the same origin policy until you go away however if you enter www.bing.com profile history and you're authenticated you still get your your sensitive authenticated search history at www so combine that with the fact that www is sitting on an overly permissive crossdom.xml and we can now write an exploit that will force the victim to browse without them even knowing to www.bing.com profile history and send you everything

that they've ever searched for and this is the script this is the actionscript code that does that all i've done is replaced the two portions highlighted in yellow on the top function you're specifying the target so where you want the victim to navigate to and then the bottom function that's where you're specifying where you want that you know stolen data to go to so that's where you send it to your own server and in this case i'm sending it to a file on my server called bing history.php and that file just writes everything that comes into it onto disk so once i had my authenticated victim load my swift or authenticated with bing and then they loaded my swift

this is the data that is on my attacker box and as you can see i'm just you know parsing this out and looking at everything that they ever searched for so for my next example i'll use plenty of fish or pof.com and a little story about plenty of fish before i get into the details of vulnerability so if any of you have ever responsibly disclosed a security vulnerability before you know that the best practice is to send an email to the security app and support email aliases at that organization unfortunately they didn't exist so they bounced back the next thing i tried to do was fill out the the about us you know contact us customer service page on their

website unfortunately that was just a black hole i didn't hear anything uh back there either so kind of as a last ditch effort i went to careers.pof.com found a job application and applied to it with instead of a cover letter and a resume now this is on a friday afternoon on monday morning i got an email back from the ceo marcus bryant of plenty of fish thanking me for the disclosure and telling me he did a little research and he already fixed the vulnerability i thought that was pretty cool he also told me that he created a security at least for future exposures nice guy so the reason i wanted to talk about this this vulnerability though is it allows

me to talk about a limitation in this vulnerability compared to say cross-site scripting the splash the swift your swift file that you create your evil swift it doesn't have access to the dom and it doesn't have access to the http response headers that come back to the victim all it has access to is the http response body so unlike cross-site scripting we can't just default and kind of try to send document.cookie over to us right we can steal and hijack the session that way the thing is if the application ever writes the value of those cookies into the html body that is fair game for our swift and we can make the victim make their

quest and steal that cookie and i'll show you that really quickly here so this is the cookie this is not touchable by our swift because it's in the cookie header and you see the value is highlighted in yellow but if i can create a swift that makes a request that makes the victim make a request to www.pof.com inbox.aspx that value shows up in the http uh response body or the h know the view source source of the html so at this point we can do just what we did with the bing example send the response the whole response back to the attacker at that point the attacker puts that cookie value into their browser using something you know like

fire cookie and they have now just hijacked the session even though the flash player didn't have access to the headers and that same scenario applies for cross-site scripting if you have cross-site scripting but they're using the http only header pro uh flag properly that same scenario applies okay so let's um so this is the next example imager and another little story about imager so i sent this disclosure this email to marcus uh sorry to imager at 11 29 p.m two minutes later i got an email back from alan shaft the founder and ceo saying that he'd be happy to work with me you know please send him more information i sent him uh the the proof of concept

and by 12 15 am he wrote me back saying he fixed the vulnerability uh they they didn't need the cross to over the cross domain anymore i thought that was pretty impressive that's 45 minute response time for the 48th most popular site in the world so that's a high bar also to imagers credit they are protecting against cross-site request forgery using nonces and any of you application security people in the room know that nonces come back they they're a unique value that is created by the server that is sent to the client then an attacker would normally have no way of knowing well that comes back to the client in the http response body and that now is fair game for our evil

swift that's why so now if you have both vulnerabilities in place or if you if they use knots even though they use nonces if you have the overly permissive cross domain xml file you can still bypass that not defense and execute the cross side request forgery so to show you an example of that imager has the ability to have public pictures and private pictures and in this example the user has all their album settings set to private and what we're going to do is we are going to bypass the c-surf defense and make the victim change their album privacy settings to public so if the victim makes the request themselves to make the um the privacy settings public

this is that request and as you can see you know highlighted in yellow with the arrow that's the nonce so that's the unique token that the attacker normally has no way of knowing and that's what our action strip code is going to do our action script example in this poc needs to do four things this is also based on gerstev's poc but this has been expanded to do the following four things first it makes the victim make a request to the page that will give the victim the knots then this portion in blue will extract the nonce and any other dynamic things that it needs to extract to create this url up here so once it has all the

dynamic pieces it concatenates that the dynamic pieces are in yellow and then the static pieces you know that make your album privacy public that is um up top and so it creates that post request and then sends that out to imager and um you know the victim sends that out to immature and now the victim has made without them knowing has made all of their images public and the attacker can now see those pictures so for my last example um i'm going to use think but this is actually you know quite common so we're all so in this example what i'm going to do is i'm going to completely hijack somebody's thinking account by changing

by using cserf to change the email address on that account so as you're all familiar with these days even if you're authenticated with an application if you want to change your password it asks for your current password that's a great thing that that is another confirmation that a real person is the person who owns the account is making that change the thing is i rarely see an email address that field that requires the current password to change the email address and combine that with a forgot password feature and you have a hijacked scenario so this i just wanted to show you this is highlight in yellow on the top there just the name of my swift should be

self-explanatory at this point bypass see serve change email address think so anybody who is authenticated with thinking and then goes to my malicious site and loads my swift in this example will have their email address on their account change to sethsec gmail.com at that point i sweep in and go to the forgot password function enter my email address and then the password reset email address for their account comes to me i can reset that password to whatever i want and now i own their account until they realize that their password doesn't work anymore so i'm done with those type of pocs i just wanted to share with you something i came across kind of a

revelation i had halfway through my research so this should look a lot like the example at www.adobe.com there's no domain equals star anywhere in this file however this is just a snippet of the crossdomain.xml file at secure.history.com there are 89 unique domains that are trusted in this file and this is not uncommon i mean it's it so and i still that got me to think what if one of those 89 domains is has expired recently and is available for purchase what if they made a typo and this definitely i definitely saw this and the domain that they put in their white list was not something that they ever owned it's just been available for as long as

they've had that white list so to prove that point guess who owns xenonstyle.com so at this point i can load i own cnnstyle.com so if i can get somebody who's currently authenticated uh with secure.history.com and then they go to xenonstyle.com and load my swift it's the same as if it was domain equals star it's really just a race to who's the first person to purchase that you know available domain and so this is another example of a really long one this is wwe oh actually since sears and cam kmart were just recently in the news i also found the same thing so sears and kmart have almost identical cross-domain xml files and i saw that

quite a bit too so some of these sites that are owned by the same uh group share similar uh cross-domain xml files so i wanted a way to automate in the process of looking to see if these domains were available so it allowed me to create uh an nmap script called http dash cross domain so i have submitted this to nmap but it hasn't been you know reviewed and approved into the project yet so i'm going to distribute this i am distributing this in my github project now but if it ever gets accepted by map i'll remove it from my github project and it'll just come with mmap but the purpose of this script is

when you specify a domain it'll look to see if a cross domain file exists and if one does it will it will give you two pieces of information one url to dyn dot the bulk domain search lookup tool and two it'll give you a comma delimited list that now you can copy that list paste that into the dynadot bulk domain search page and if you're lucky one will be available so what this means is if you ever see a cross domain.xml file you know currently right now burp and a lot of the other tools will just tell you if there's domain equal star but really you need to start looking at every single line in those files for

for the same vulnerability just manifested in a different way and not that i don't trust all of you in this room but i did purchase searstestsite.com okay so now i'm done explaining how this vulnerability can be exploited and let's move to how you can actually create the exploit so the the github repository is called cross domain exploitation framework it's not much of a framework right now if i do more research in this area i wanted to give myself room but currently there's a tool called swift server and that will if it hasn't been run before it'll install all the prerequisites listed below and if it once all those have been met it just turns itself

into a web server that will serve your swift uh your eagle slip file so i'll show you that with a demo and for the demo we're going to be using ubiquiti's air vision product so this is a management application that manages ip cameras like ip security cameras and we're going to be using an old version a vulnerable version the version that i found these two vulnerabilities on and and sent to ubiquity this has since been fixed but for the purpose of showing me the exploit which is

all right so there's the air vision product so this screen we'll be mostly doing will be the victim on this screen and then on this screen will be the attacker

so now we are going to execute a cross-site request forgery um exploit through the our evil swift that we create so let me just log in here and what we're going to do in this example is we're going to create a new administrator so as you can see there's only one administrator right now so just like and i'm just going to go through a to z for you so right now i'm not going to be the victim i'm going to be the attacker doing research on how to pull off the cross-site request forgery so in order to do that and this is the same way you would same process you'd use for exploiting cross-request forgery i'm going to

actually make a user so i can learn what's required to make a user

okay so now i have the victim going through burp and i try to show you this post request right here this is what's required to make the user that i just made so this is the request that we're going to have our evil swift file send so what i'm going to do is i'm going to send this to the repeater and you know we use test as the attacker or just learning about it but just to be you know make it clear we're going to create it we're going to have the victim create a user called sea surf in the admin group

okay and you could do this manually but since this is a json this is json being sent to the server if we're going to use it in our poc we're going to need to escape those quotes so actually pro has a really cool tool i'm just going to use their javascript xhr because you'll see here see how all of the quotes have a backslash in front of them now so that's what we're going to put into our action script code in a second so now let's switch over to the attacker so what all i've done at this point is download the cross domain exploitation framework from github and you can see here we have the switch

server so unfortunately to create your own swifts you need to download a 340 megabyte file from adobe i'm serving this locally just to make sure that downloads go really quickly but that will take some time and right now it also takes a little time to unzip that framework so adobe flex is the compiler that's the tool that you use to compile actionscript into sql files so once all the prerequisites have been met it's going to tell you that installation is complete please compile a swift and start the server again and to do that we are going to choose a template from actionscript templates and as you see here so this bottom one is is um pretty much gurses poc with just

one small change um and that's what you would use anytime you want to steal data a lot of my first examples we're going to use sea surf but i've included the pocs that i've used in thinkgeek and some of those other sites here where you have to extract the c surf nonce you know they're more advanced so in interest of time we're going to do a very basic c surf here and even though we're doing a c-surf instead of just stealing data it's really only a few things that you need to change so this is where you set your target

and this portion right here is what sets our request to a post and then this is where we set the post body so you can see the c-surf example is that it was i added this example based on this exploit here but we're just going to start from scratch

so remember i just used this c surf generator right here to kind of do that encoding for me quickly that's not quite that's not a required

step

i learned about the you in the eyes way too late that is awesome uh okay and lastly we this is not required for c-surf right for cserv you don't require anything to come back to you but since we have the ability i'm gonna send us once the victim creates the account for us i'm just to send us feedback the the page that the victim gets

and i'm going to send that to this attacker box i'm just going to use and so this the way so swift server when it is a web server it uses base http server and python and i have i've coded the two methods get post so get will just it'll just serve the file that's you know being requested i have post it's kind of bastardized any page that you send a post to it doesn't matter if the page exists or not it'll just write that data that post data to disk so we can just call this anything and at this point we need to compile the action script and drop it into the web root

and so we're going to call it exploit.swf it can be named anything but the way the exploit works is that you first send your victim to an html file and that html file sends them to the swift file so the html file that comes stock with this tool is looking for exploit.swift so if you give it a different name just change the html file as well

okay it's my lucky day no typos so that file exists so now because that file exists we can run the swift server and now it's no longer doing any installation it's telling us it's listening on port 443 and it's instructing us to do three things and remember this is required for every exploitation of this vulnerability number one your victim has to be authenticated with the site that you're trying to attack so let's just verify that they still are okay they are the next thing convince your victim to arrive at your your server so let's do that

and so my tool uses a self-signed cert that it creates you know for you as part of the installation process obviously if you purchased a cert you wouldn't get this uh warning here but for the purpose of showing uh you know a developer the vulnerability this was fine so this is the stall the the stock index page that comes with the framework this is nice and polite telling the victim that they are being exploited you can change that if it needs to be more realistic and so we should see here actually you know before we look up a little suspense so let's look from the attacker's perspective this is what happened on the attack exact second the attacker saw that the

victim 214.1 arrived at the index the index page then sent them to exploit.swift the the swift was loaded and then i know that it was executed because it made that post request to this random string right here and sent and i'll show you so what i have it doing is writing a file on disk using the ip address of the client and you know the time frame

so that's how i know it worked but let's just go verify that right here

and here we see the c-surf administrator

all right so that's how easy it is to go from you know finding an overly permissive cross domain.xml file finding something worth sea surfing and then creating an exploit i just think it's pretty cool to see since since we're going through burke we have the luxury of kind of kind of seeing everything that went on behind the scenes and so this is what it looked from the victim's perspective so the victim was sent to index.html oh i'm sorry well yeah oh this is the phishing right so we fished the victim to index.html it then loaded the swift in the victims browser now this is what we were talking about this is flash player making the request

to crossdomain.xml at the vulnerable site and you can see here the domain equals star and it's also interesting keep an eye out for this if the swift makes the request the swift is in the refer so from a defensive perspective you know you might want to keep an eye out on any of any of anything that's initiated from a swift and then same thing this is the actual c-surf payload also i refer will be the swift and then this is just the data being sent back out to the attacker all right so that's the demo

okay so i saw a lot of crossdomina.xml files and it's not as straightforward you know kind of like what i was saying across site scripting we don't have access to the dom so you have to be creative when exploiting this vulnerability and i found plenty of cross-domain xml files that even though it was vulnerable to the theoretical vulnerability there were some mitigating factors in place that either allowed me not to be able to pull off the entire attack or not you know be successful at all and i wanted to share some of those with you as uh potentially some defenders in this room so this first one isn't a defense and death strategy this just hits it the

nail on the head i mean be careful who you trust in your cross domain xml file periodically review the list of trusted third parties segment your data by subdomain so this is one that i saw where i have a really big high profile target i mean kind of like capital one 360 but there are some that are i can do quite a bit in one sub domain but then the thing that i really want to see surf is behind a different sub-domain that doesn't have a cross-domain xml file and so that's it i mean i can't i can't do anything that segmentation um protected that's that from from that site from exploitation now in terms of purely defense and depth

recommendations require your users to enter the password for any sensitive action required to account settings so not just changing password but changing email changing snail mail address you know if that is somehow related to resetting an account credit card numbers are taken care of by pci compliance and you can't show your users anything more than the last four or the first six of their credit card number but take that lesson from pci compliance to heart and apply that to any other sensitive information the idea is that i don't i never need to see my credit card number from the website to make an update right i have my credit card i can just re-enter that in

same thing you know whenever that applies restrict the showing of that information you know secure.history.com for example is a good one i could see my saved credit card as the attacker i could see but i can only see the last four numbers which really mitigated the risk there and lastly this is kind of a defense in depth um protection for cross-site press forgery it's not a silver bullet but combined with nonces you know if you're already using nonces check the refer right so if you see that the swift is coming from outside of your domain you know it's not gonna be called malicious.com but you know it's if you see that it's not originating from your domain

don't allow that request or at a minimum review those those uh referrers that are coming from other locations and to wrap up although i said that it was gursev's blog post in 2013 that finally helped me wrap my head around this vulnerability and actually a funny story the first time i had to write this vulnerability up was before that blog post and then the second time was after i mean it's just amazing just that you know he was able to share that and that what you know what we do sharing information it became possible for me in that six months in between those two fines but so although his blog post allowed me to go from a to z

it was the research and work done by all of these people here and i'll post these slides on github so please take a look at some of these links this is some really great stuff and as you can see a lot of this applies to a lot of web application concepts same origin policy process scripting crossover quest for injury etc so that's it any questions

yes it's i was hoping you'd ask that because i didn't want to derail my train of thought in the presentation um that's secure at the end is why i'm serving the swift files on https that's all it means so i mean it just adds another step for the attacker but so if you see the if if it's just here let's uh well if you see the secure at the end you have to serve your swift over hdbs if you don't you can serve it over http good question

uh that's a good question so it definitely knows where it's being loaded from uh because it won't query the cross stone it'll that same origin policy that's how it does that right so if you're loading a swift or if you're making requests to the same domain that served the swift it never even asked for the cross domain xml because it's same origin but to answer your specific question um it depends on how you're retrieving the swift if if your cross-site scripting is then changing the location to the third party it will remember that you know i think but i haven't fully researched that let me ask you a

question

they are a good delivery um for getting for that fishing type watering hole type of attack right they're a good way to get the user to authenticate or to download the switch from the evil site yeah but i'm not yeah did that answer your question not really

yeah that yeah that's just that would be another uh vector to get that person to load this with any any other questions yes

oh it does okay nicto now will look we'll list the domains

javafx so i mean any absolutely yeah that's a really good point and that's kind of why i named my framework cross domain exploitation framework this same style of attack is possible via silverlight silverlight uses something called client access xml um and then there any other the whole class of these tools are called rich uh internet applications are reas that's why it's called the mallory of proxy so all of those that have the ability to do um cross-domain requests like that and they all use this this file for trust thank you any other questions all right well thank you all very much for coming