BG - My Terrible Roommates (see description for full title)

hello everyone and welcome to my talk my terrible roommates discovering the flow fixation vulner vulnerability and the risks of sharing a cloud domain flow fixation vulnerability is a vulnerability I discovered recently in AWS mwaa managed Apache workflow uh Apache air flow uh this is a oneclick vulnerability that allows the account takeover on a victim so enough with the teaser I am Liv Matan a senior security researcher at ten I Microsoft's most valuable researcher and as you might notice I hand the major Cloud providers AWS Azure and gcp so on the on Prem word in bu Bounty when you run JavaScript on a subdomain this is a vulnerability right when you report it in a bug bug Bounty you get

xss you get paid this is a valid vulnerability but in the cloud this is something different the concept is observed differently because for example there are a lot of services that host web services or even other cloud services on the same parent domain and other customers different customers share different subdomains let's take it into a more practical scenario for example AWS elastic bin stock and keep in mind this is just one example of one service but this concept affects a lot of services in the major Cloud providers so I as a customer customer one for example will have a domain in customer one. elastic b.com and elastic bino to those of you who are not familiar is

simply a Serv service that allows web hosting and another customer for example customer 2 will host a web application on customer 2. elastic bin stock.com and uh a lot of other customers will be also hosting the same uh will be hosted on the same uh shared parent domain elastic beano.com now I as an ordinary user of the elastic bino service can run JavaScript so now it gets confusing because as you might remember from the previous slide this scenario is the exact same scenario like in the bug Bounty world when you get an xss on a subdomain of a victim because I run JavaScript on a subdomain of a victim of for example customer to. elastic beano.com so this is kind of

crazy so I will Define some definitions before we get it started so we'll be on the same page super cookie is a cookie that you as a user Define or in JavaScript code you simply Define to a parent domain and this cookie will be tossed AKA cookie tossing to all of the subdomains of the same parent domain for example if I set a cookie to the elastic bin stock.com parent domain the cookie will be set to customer one and customer 2 and so on to all of the customers of the same elastic beIN stock.com in the same browser as for session fixation this is a vulnerability or attack technique that allows an attacker to hijack a user

session by by forcing the victim into using the same retrievable session the same known session so for example an attacker will send this link the following link the https uh ww.xvideos.com

interesting some of the potential same site risk AKA uh shared parent domain risks that I can note for you uh these are a lot I'm sure I'm I'm I'm sure you're not going to see all of them I'm not going to dive deep into all of them but one of them a very notable one is Cookie tossing attacks as we said super cookie that allows csrf protection bypass and assession fixation abuse so these are a lot of risks that uh are caused uh as a result of the concept of the shared parent domain and this is very very um large also in Cloud providers as you saw in the example of elastic beIN stock and will be uh in a

lot of other services some of the past impactful vulnerabilities could also be prevented if a lesser known guardrail was utilized in that time of the vulnerabilities exploitation some of them by GAF migga and and a guy named Sirius and those uh both those two vulnerabilities uh were exploited by Cookie tossing and that technique could be prevented if the cloud providers were simply utilizing a lesser known guard rail named public suffix list so that guard rail uh is a list initiated by Mozilla this is a community collaborative list and this looks exactly as simple as this thing this simple list uh that each organization or a domain owner can register his domain to this list that will then be

treated by browsers so browsers see this list and each site that you see here is a site that is considered to be shared with different customers means that subdomains of the same site AKA shared parent domain will be shared with different customers sensitive data is shared therefore the site uh should be considered as a public suffix now this public suffix list is lesser known and I will show you exactly why in the following slides because in AWS these are all of the services some of them I reported to AWS and some of them AWS themselves uh initiated research in order to uh to find these services that their domains are not present in the public suffix list so this is the state

of AWS currently as for the public suffix list and it means that uh now it is reported and fixed these are the domains that were are now inserted into the public suffix list but it means that these domains were vulnerable to the same site risks I showed you before uh before reporting uh this risk to AWS as for Azure these are some of the domains including popular names like API management Azure front door blob storage these were all not present uh in the public suffix list now they do after the report and as for Google I reported and they simply stated that uh this issue is not considered that severe for them so they would skip that so you can go ahead

and uh search for some nice bounties with same site risks in Google Cloud so let's get it started what is exactly Apache a flow aach a flow simply is an open source system that handles data pipelines and workflows and in AWS you have the managed version of Apache airflow Amazon managed workflows for Apache airflow we did a sample in our company in table uh and we saw that 20% of the customer database we have are using the MW mwaa service so the vulnerability is rather popular and impactful so let's dive in into the flow fixation vulnerability you can see this screen uh when you visit the service you can see that each service gets attached

an airflow UI and as you can see this airflow UI I just got hosted on the parent domain of Amazon aws.com and after all the stuff that I told you it might tell you that there is going to be something interesting in that case because Amazon aws.com is a shared parent domain with other AWS services so how does it really work you log into the airflow UI and you have uh you get a cookie session to the airflow UI this is exactly how it looks like you get a cookie session to your own uh subdomain of the Apache airflow manag version and this session cookie is simply a uu ID after that you're using your AWS STS

in order to get in exchange a web token that that is essentially a JWT that allows you to then redeem it and authenticate to the dashboard to the mwaa airflow UI then there is a session retrieval now keep in mind you see this request and this request EST is unauthenticated on the left side of the screen you can see the request and there are no credentials and nothing that authenticates you so you might say now okay so I can retrieve the session of victims and we have an unauthenticated vulnerability right like authentication bypass but not really because this session is retrievable unauthenticated but this session at that point of the authentication flow is no use you cannot use it you cannot login

with it this is just a session cookie this step is making the session verified and now you can use this session so in that step the request is using a token the JWT token we just retrieved and again the session cookie and in exchange you get the session cookie that is now verified and now you can use it in order to log in to the airflow UI but you can see something very very interesting here because the session cookie that that I got as a normal user of the airflow UI is the exact same session cookie that I just gave to the

dashboard that scenario is kind of interesting because now as an attacker I can retrieve the known session unauthenticated and I can try to force victims into redeeming this session we just saw the authentication flow and after they redeemed the session that we just retrieved we have a known session ID and I might be able to hijack the session with session fixation so this is a scenario for example I have the attacker info the attacker's bucket and I have the bucket under shared parent domain Amazon aws.com this is by default how S3 buckets work in AWS and on the other hand I have the victim MW which also hosted on Amazon aws.com we are both on

the shared per parent domain of Amazon aws.com and I can simply host an index HTML file then lure victims into my S3 bucket and run HTML JavaScript with the JavaScript I can set a cookie to my Victim and I might do some cool stuff here so this is how it looks like I set I set a cookie in the index.html this is simply JavaScript and I said the the cookie that I just retrieved from the victim's mwa pel uh and I said the cookie uh that this is the uuid cookie that I retrieved and I said it to the Amazon aws.com shared parent domain does this cookie will be shared into also the Apache airflow of

the victim because we are on the same shared parent domain and this will be in the browser of the victim but not so fast because this thing has actually failed why did it fail because the S3 bucket domain was in the public suffix list and still is so the public suffix list has prevented me from setting the cookie to the shared parent domain from the domain of S3 bucket the next order of business was to use Google Dorking in order to find services that are that are hosted under the same Amazon aws.com domain and might allow me to set a cookie from that service so I found AWS API Gateway that at that time wasn't present in the

public suffix list and allowed me to set a cookie to the Amazon aws.com shared parent domain and this is absolutely crazy because I can now lure victims into my Gateway so host the exploit code there the exploit code will set the cookie to the victim's mwaa this cookie is a cookie that I know that is retrievable this is a known session ID and with that session ID I can redirect the victim force him into logging in into his own dashboard verify the session that I know then I can use session and voila this is how it looks like this is the exploit code uh so we'll get into it in that case I simply wait for a get

request specifically to the path of the PC for AWS um and then I send an https request to the victim's airflow to the victim dashboard uh to the path to retrieve the session ID this is all unauthenticated I don't need any credentials right because this session is not yet verified then I save this session that I just got in the cookie value parameter the next step for me was to use this uh HTML I set this HTML into my attackers page and this HTML includes JavaScript that will set the retrieved cookie the retrieved session to my Victim and I set it by setting this session cookie into the domain of the Amazon aws.com which is shared as you saw then after that my

next step is to use document.location in order to redirect the victim into uh this uh nice SSL redirect URL that will uh essentially Force the victim into logging in into his own dashboard after the victim has logged in into his own dashboard he logged in with the session that I just said to him does this session is now verified and I can use it in order to take over the victims dashboard this is a nice demo I set for you so let's go over

it so here this is the victim visiting the panel this is what the victim sees gets redirected and everything he doesn't see anything that uh it's kind of suspicious this is the victim's browser you can see as the session that it was injected this is the attacker's view he saw just uh he just saw the session that was injected

this is the attacker that was uh the just use the uh hijack session the attacker is now using the hijack session after the victims uh has logged in into and verified his own

session and boom this is the attacker after we logged in into the victims panel thank you the fix was is that AWS fixed this vulnerability by refreshing the session uh of the mwaa so now after a user is logging in into the mwaa dashboard aka the airflow UI their session is refreshed after login

some of the takeaways is that shed parent domains are dangerous this is just one example of such a vulnerability that can be exploited with this in mind but we saw two vulnerabilities as a case studies uh that were exploited in the past and the public suffix list is a lesser known guardrail that people are just less aware of so let's be Community focused let's uh elaborate on the public suffix list let's use it because this is very powerful as we saw it could prevent flow fixation and it could also prevent these two impactful vulnerabilities we saw um as case studies so this is a very very interesting and important concept we should take and keep in mind also

check if the service domain that you are using is present in the public suffix list and if not please assume that same site requests are untrustworthy because samite requests are dangerous and can be risky as you saw in this this presentation thank you any

[Applause] questions no questions thank you very much