Thank you, everyone, for coming. It was said this is going to be big data. Well, press
code, sorry. Big data approach to understanding the content security policy. At the end of
the talk I would like to share with you eight bypasses. Six of them I think that they are
not so well known. Two of them I think that maybe would be a bit known, but nevertheless
I would like to popularise them because I think they are really interesting.
Okay, starting with that, I would like everyone here to imagine a big red button. Next to
this big red button, there is a note that says, if you push this button, you are going
to get rid of every SQL injection in your life for every application that you ever develop.
Would you push that button? Wouldn't you? Yes, no? Me included? Everyone here? I guess
that would do the same. But interestingly, we are not doing the same for other impactful
vulnerabilities like cross-site scripting, which could have a really high impact on your
users. I will come back to that later and explain why I do not think that we are pushing
that button for this kind of data injection vulnerabilities.
But before that, I would like to introduce myself. I'm Felipe Molina. I've been working
with Orange Cyber Defence SensePost team for four years and something more. Ten years in
the information security industry. Proud dad, Futurama and Simpson fan, of course. You can
find me on Twitter, if you want to chat with me about Futurama. Anyway, I have divided
this talk in three different blocks. The first one is going to be the context with a bit
of history, brief. The aim of CSP, the content security policy. The second part is going
to be the big data part, with little stars there, where I explain the architecture that
I came up with to scan one million sites of internet to understand the content health
security, the content health status of content security policy. The third block is going
to be the bypasses themselves, with a bit of demo, if we have enough time.
Okay, I want to clarify what the dress code name. It comes from UI redressing attacks.
UI redressing attacks, as you may know, it comes from different kind of injection, JavaScript
injection in your pages. So I was here last year with a web application assessment that
I got with one of our clients that called iterative assessment with us. So I was reading
that they have this cross-site scripting, store one, in many places of their web pages.
And I said, okay, let's try it. I saw that it wasn't possible to exploit them anymore
because the client implemented that very strict CSP policy, content security policy. I said,
damn, I'm not going to be able to exploit them again. They didn't care about the base
code of the application, but instead implemented the CSP. So what happened? As a hacker, you
think that you have to bypass that and resurface the cross-site scripting. So yeah, what I
did is that, found a bypass on CSP policy and resurrected the old cross-site scripting.
The client was a bit sad, I was a bit happy, sorry for that. But the thing is that it made
sense at that point. I was also able to use this cross-site scripting and bypass to carry
out a UI redressing attack to exfiltrate data to some kind of phishing and exfiltrate the
data to Google Analytics site, because it was very strict and you could only connect
and send that data out to Google Analytics. So yeah, nice. Okay. This is the context.
After that assessment, I thought to myself, okay, this is like, I want to know more about
CSP. So I decided to understand how CSP works for real, how prevalent it is across
internet, how well configured. And ideally, I would like to find new bypasses to keep in my
toolbox for future assessment or whatever, if you want to keep them for your bug bounties or
whatever. So let's start with what is CSP? Define Verbatim from Mozilla.org site. It's another
layer of security to detect and mitigate injection attacks. More so if it's cross-site
scripting. So now that we know what it is, this was the aim of CSP, to tackle and to prevent
cross-site scripting, quick-jacking, data injection, many other that are not listed here.
And this could result in very ugly impacts, such as data theft, site displacement, malware
distribution. Very, very bad things could happen if you don't protect against that. So it looks
like CSP has a really good end. It's really good to implement in that. But yet, even knowing how
good could be implementing CSP, most of us are not pushing that button. Only 10% of the sites
that I scan were implementing CSP. This is a chart that indicates how many of those 1 million
sites that I scan were implementing CSP headers. These top 1 million sites were pulled from a
database. Well, the source was Majestic Million. It's a list of popular sites on the internet
constructed by a company called Majestic. They do SEO, so they know their stuff. So yeah, I target
that 1 million site list. And it was a concerning outcome. So we are implementing only 10% of the
sites are implementing this. So this is similar to the situation, to the commercial where we have
the 9 out of 10 dentists recommending you to brush your teeth, but completely opposite. We are just
doing completely opposite. The dentists being us, the security and the developers here, we are not
doing the right thing. We are just not brushing our teeth. So with that in mind, I was a bit
disappointed. And I thought, OK, but maybe this is a modern technology. No, it is not. It has been
a long time with us. It started as an idea with a snake in 2004. And then in 2009, he published
this in hacker.org saying that Mozilla was going to implement a content security policy, which was
a good new. In 2012, it was issued as a standard. And nowadays, in 2023, we have this developing
this working draft policy level 3, which is a bit sad from my perspective, because it has been
with us more than 10 years, and we are still not doing it. How does it look like if you go to a
site that has content security policy enabled, you would find this header in the response, content
security followed by the policy itself. The policy would be separated in different directives, each
directive separated by a semicolon. And each directive would have a directive name separated
by a space with one, sorry, zero or more values. So this is the structure that it has. When you go
to a random site of internet, you find this is the answer in the response. And if we structure this
by separating it by semicolons and by spaces later, this is how it would look like. The first line,
for example, well, I must say that this is just three examples. Content security policy has a lot
of other directive names, which can have a lot of other purposes here. But those are just three
examples. Script source is indicating the agent or the browser what scripts are allowed to be
running on your page. Okay, this first value is telling the agent that scripts that contain these
nouns are allowed to be executed. This or any other randomly generated nouns. The following one is a
strict dynamic. This is a value that says to the agent that these scripts that are allowed, they
can transitively create or add new scripts to the page. That would be allowed in turn to be
executed itself, means that also the self page, the same domain, is allowed to be executing their own
scripts. And the fourth one means that all scripts coming from HTTP source, this is the protocol
handle HTTPS, are also allowed to be executed. Okay, then we have two additional ones that I want
to put a bit of more attention in. Connect source and default source. Connect source is telling the
agent what pages are being allowed to be connected out from the page. And default source directive is
telling the agent what directives or what set of rules to look at in case that there are no other
specific rules in the policy. Okay, now that we know how it looks like, I wanted to see how
prevalent was CSP and how well implemented was in Internet. So I'm not a developer myself, so this is
me, the dog, not knowing what how to program. But I wanted to do something scalable and something
that could be finished in my own lifetime. So I did it, I wanted to do something that was fast. So to
scan this one million sites. So I did this approach with asynchronous programming paradigm, instead of
doing a loop with a fork and requesting every site, one million sites in turn, I would do this
asynchronous paradigm. So yeah, this is a heads up that the project is going to be released in this
repo, address code of SensePost, and you could use it yourself to scan your own sites or to
use it for your own purposes. So anyway, this is the solution that I came with. This is a
scanner using the libraries asyncio and aio-http, pmongo for managing the data with the backend
database, and pandas to managing the big set of data. The backend would be mongodatabase, and to
tap into this information and retrieve useful data, I would use a dashboard using a program with
Dash and Plotly Express for the nice charts. Okay, the process would be simple. Collecting the
headers with a scanner, two different sources are used, Majestic Million and Cisco Umbrella. Both of
them gave me the same results, 10% of the sites using it. Then parse the CSP headers from the
headers that I retrieved, and assign a country or continent, first by country code TLD, then by IP
address geolocation, and then by whois record. Then I would scan everything there, spot
weaknesses and bypasses that you can take for profit. So you want to say that for your next
assessment, or for your next bug bounty program, or whatever you want to use it for. Okay, this is how
the data looks like in the database. So you start by with an ID, URL, and final URL, because you can
be redirected multiple times. The headers that I gather, the vulnerabilities that I detected, in
this case, no CSP was defined, and whois host, IPv4, country, continent, and global rank of the
site you are looking at. Now I'm going to show you a brief view of how the dashboard is. I'm not
going to delve into details of this dashboard, it's just for you to get an idea. So the top bar
that you see there is telling the application how many sites to pull from the database, 35% or
etc, etc. Now you get down there, the pie chart that shows you how many sites are using CSP at
that moment. Then we have this line here, where you can, for example, explore weaknesses, the
status, reverse IP to sites, header names, for example, the one that I'm going to show, and CSP
directives. This is a frequency chart showing the most frequent directives that I will show you
later. I'm not going to delve too much into this, this is just to give you an idea of how it looks
like. The results of this chart would be shown here. So this is the CSP directive sort by
frequency. We can take a look at the first ones there. The most frequent ones and the most used
are upgrading secure requests and frame ancestors. Upgrading secure requests are used in 46% of the
site that define a content security policy. Frame ancestors are used similarly in the 46%.
Could be better, but it's okay. Those make sense that they are most used because they are easiest
one to implement. So it looks like when it comes to maintaining an allow list, we get a bit tired
and we stop implementing. So we just decide those are enough for our policy.
For example, defining script sources, there is only 20% of the sites that are defining
what scripts can be executed in our page. The rest are not defining. So it's not the best
configuration. Then we see that those are the less popular ones. Base URI, report URI from
action manifest. And I think that this is because we don't know what they are doing. There is not
much popularity of those. They are not being very widely used. For example, this one,
base URI, it's allowing you to prevent you against cross-site scripting that injects,
for example, a base tag on your site. This base tag is telling to the agent that all the
relative paths of scripts are going to be pulled from that base domain. In case an attacker injects
a base tag in your web, all the scripts of your page are going to be pulled from this attacker
site, from this attacker domain. So it's pretty serious, but still we're not using it enough.
Okay, so you can also take a look in this dashboard to the allowed sources for different
values. In this case, as an example, I took script source and the most allowed source for
script source were unsafe-inline and unsafe-able. This makes me a bit sad because 20% of the sites
and 21% of the sites are defining scripts source are okay with unsafe-inline and unsafe-able.
It's quite popular, this configuration. So not only this guy that is the only one that is
recommending you to brush your teeth is doing it, but he's only doing it 80% of the time. The other
20% of the time he's not brushing his teeth. Anyway, I had this other map there in the dashboard
where you can see the current status across the globe. No, we are doing it equally wrong.
This light green color here means that no more than 10% per country of the sites are
implementing CSP. There are some outliers here in Africa. I can think that those are because
we don't have enough sample data from them. If we have a couple or three sites there, it gets
rigorous, a lot of sites. But I haven't studied them very deeply. So then we can take a look to
the weaknesses. This is a way to classify the weaknesses. For example, this is the the most
frequent weakness that I found. No one is using report2. This report2 directive indicates the
agent where all those errors can be reported. So you can have if you implement this report2
directive on your site, you would have real-time feedback from all the servers that
your clients or your user are having in your site. No one is also using base URI.
So yeah, it looks like there. Yeah, it's pretty common not having those. So remember if you've
come across... make a wish if you come across a policy that contains the both of them, okay?
So the least frequent weaknesses are... yeah, and safeinline and safehabit, they are there.
But those are the two ones that get me more worried. For example, 9% of the sites that
define a content security policy, they can be abused by third parties domains. I will get
back to that later. And lenient scheme, that means that every site... sorry, 7% of the sites
are allowing HTTP handles, for example, to execute scripts on your... anything that comes from HTTPS,
for example, they are okay in executing as a script. So yeah, it's a bit worrying as well.
There are other parts in the dashboard that you can take a look at. There are some tables that
lets you to explore some weaknesses of the sites that I gather. This is, for example,
third-party orphan domains, no-csp-defined and safehavel and safeinline. So many others. Many
vulnerabilities that you can take a look at. This is how it would look like if you visit this part
of the dashboard. The orphan domains is the one that we are looking at now. The first column is
the affected domain. And the description column tells you what are the domains that are orphan,
that means not registered right now. So at the first line, for example, you see that the
domain bosh-tools-results-page.com is present in the script source directive, but it's not
registered. So it's sitting there for you to register and execute scripts on that page,
provided that you find another cross-site scripting in that site.
Now, for example, another example would be to look at the third-party abuse. In this case,
the first column is the affected domain as well. And the description is telling me, for example,
the third-party abuse that I can take advantage of. The second line, for example, is telling me
that the directive-connect-source contains asterisk-at-hotjar.com, so I can use that to
exfiltrate data. So it's at least that you can take advantage of, if you want to say that.
Now what? What do we do with this information? It comes the fun part, the exploitation part. I
wanted to find new bypasses. I found, just ahead, I wanted to find new vectors. I found a lot of
information on the internet about how to bypass CSP using JSON with padding and AngularJS outdated
libraries of AngularJS. I wanted to find different vectors, so I just forgot about them for a moment
and found different ways. I came up with this list. That does not mean that this is the only
list that exists out there. Probably there are others. Due to time restriction, I will only focus
on this first one. I will explain a bit more the following three ones, and this last will just be
mentioned by passing. But if you want to know more information about them, take a look to our
blog post in sensepost.com. Details will be published soon. So yeah, to demonstrate the
bypasses, I created a lab. This lab contains a private part where you can see the secret
ingredient for the KFC recipe, and there is also a part here where you can change your own password
and your security question, etc. So this is the lab where I want to test everything.
The objectives for me to demonstrate the CSP bypasses would be first one to exfiltrate the
security question and answer, second one to exfiltrate the secret ingredient, and third one
to change the user password, victim password. For that, I created two different vulnerabilities
on the lab. This vulnerability, just it's easier I guess to understand, gets a message parameter,
no? And directly introduce the string into this JavaScript code down there. So you would get,
if you visit the following page, secret.php, etc., msg, this is an error, and semicolon,
you get the following JavaScript generated, which of course is a nice cross-site scripting.
And the second vulnerability would be something similar, but in this case what we have is a
loud script with a nonce, etc., and gets the parameter source, okay, from URL params,
and the source gets introduced as the source of a script. This script is going to be appended
in the head of the document, okay? So those are the two vulnerabilities that I will be using
to demonstrate the CSP bypasses. So if you visit this source, you would get the script
pointing to this code, script execution.js. So, showtime. The first one with Hotjar that I
mentioned, I found 2050 sites in MyDB. This is a 2% of the sites that I have that are implementing
CSP. It's not big, but it's not small, relatively, okay? Symptoms would be, oops, sorry,
symptoms would be finding asterisk hotjar.com and askhotjar.io in the content security policy,
and can be used to exfiltrate data. This is how it would look like when you go to the site.
This is a content security policy, allowing default askhotjar.io, but for exfiltration purposes,
you can use it as well for connect source, okay? This is the payload. Now, don't pay much
attention to the mumbo-jumbo. It's just focus on those part, security question and answer,
getting exfiltrated to the attacker.local domain. But, of course, due to the content policy that
has been implemented, if we try this, to fetch this, and send out this information,
you would get the following error, thanks to the CSP, which is good, no? But you, as an attacker,
you know that they are low in Hotjar here, okay? So now what we do, as an attacker, you open
yourself an account in Hotjar, you create a poll, no? You insert that poll in your own website,
you sniff this traffic, you sniff the traffic of answering that poll in your own website,
and then you mimic this answer, but in this case, from the victim website, or from the victim
browser. So, if we take a look in BARP, for example, or your proxy of choice, we can see that
the site, this is what you will see when you answer the poll in Hotjar. askhotjar.io is the
host where we are exfiltrating this information to. This is a response content parameter, which
contains, within the comment, we get the answer of the poll, no? So we are going to take advantage
of it by introducing that in our previous proof of concept. We get now, again, the security
question and answers exfiltrated from the profile of the user, we introduce them in the comment,
and then fetch, post this information to askhotjar.io, etc. So we take all this JavaScript
and encode it in Base64. Sorry for the red color, it doesn't look very bright here.
But yeah, and you use it, and you introduce it as in the cross-site description that we saw in
the first vulnerability here, append an extra message. By the way, this is a callout that
you would need if you are going to use this eval, you need unsafe eval also allowed in the
script source. But anyway, you shorten this to look less suspicious and deliver this script,
sorry, this link to the victim, no? The victim clicks, and when the victim clicks,
you get the following on your Hotjar attacker's account. I'm going to show you a video to
demonstrate that. At the left side of the screen is the page. The victim is now logging in. On the
right side is the attacker's perspective. It's a Hotjar account. The victim is logging in right
now. There is the secret ingredient there and the profile with your password and the security
answer and whatnot. Okay, so now the victim is going to click on the link, the malicious link.
It gets redirected now to the cross-site scripting. We get that it was a success. And as attacker,
we update our dashboard and get the following exfiltrated from the page, okay? The favorite
word is the word. Anyway, so Facebook. Thank you. I found this was a bit more popular in this case,
2,750 sites in my database, just 2% of the site, 2.6% of the site implementing CSP.
They're allowing facebook.com or facebook.net to be used to exfiltrate data, okay? So you can,
as an attacker, go and create yourself a developer account in Facebook and exfiltrate data there.
I will show that later. So this is the content security policy that you would face. This or
this other configuration to exfiltrate data, okay? This is going to be shorter. In this case,
we are taking advantage of the Facebook framework, the tracking pixel. The first line is just
initiating the tracking pixel of Facebook to point to the attacker account ID. And the second line
is just creating a fake event, a fake custom event. This fake custom event is going to exfiltrate
within the data, the secret ingredient in this case, okay? So this is what you would look like,
what you would see as an attacker if you get your victim clicking on that link, okay? The secret
ingredient has been exfiltrated to your Facebook account, to your Facebook developer account
dashboard. Okay. Demo three is with jsdeliver. I found that this was a bit more known around,
but nevertheless, I think it's interesting to know. Found 1,550 sites in my database,
symptoms, cdnjsdeliver allowed, and asterisk jsdeliver allowed. Can be used in this case
to execute code instead of exfiltrating code, okay? That one is straightforward. You just host
your code in your account, GitHub account or npm, okay? And politely ask jsdeliver cdn to
cache that code, no? By using a specific URL. This URL is telling jsdeliver to go to GitHub,
to the username felmoltor, to the repo name bunchofjs, and to the path exec. And it would politely
get all your code and get it cached there. So now you only need to exploit the second
vulnerability, the one with the source parameter here. You just need to send or deliver this
script, sorry, this link to the victim. The victim clicks and gets the password changing
and security question, et cetera, et cetera. Now, this is a bit more elaborate, but interesting as
well. Not many sites, but relatively high. 550 sites in my DB, amazonaws.com, asterisk, okay?
Can be used to exfiltrate, but I'm pretty positive that you can use it to execute code as well.
So you need to define two different components here. A lambda function and an API gateway.
This is the content of the lambda function. It is easy. You just get the data parameter,
decode it, and print it in the console, which this console logs is going to be visible for you
as an attacker in your CloudWatch logs, okay? And this is the script that you need to execute
in the victim side, the code that you need to execute in the victim side. You just have your
API gateway hosted here as a subdomain of amazonaws.com, and the data contains just the
base64 encoded data that you want to exfiltrate, okay? And then just append this script,
and you would get the following on your CloudWatch logs, okay? The secret ingredient.
Okay, now this is just passing by. I found other four different vulnerabilities, sorry,
CSP bypasses with Amazon CloudFront, Azure Web Applications. Similarly, 100 sites, 100 sites.
First one would be the content security policy allowing asterisk cloudfront.com. The following
one would be azurewebsites.net and azurestaticapps.net. Both can be used to execute and exfiltrate data,
and the proof of concept would be similar. To exploit the second vulnerability, you just send
to the victim. You get the information or the script executed on the victim side.
Heroku, Firebase, those are not very popular, but you never know when they're going to be
useful for your next bug bounty. So asteriskherokuapps.com and firebaseapp.com.
Similarly, you open your account in each of those and host your code, and it could be executed by
the victim. Anyway, not going to delve too much. So now that we know how many ways they can bypass
this CSP, what do we do as defenders? First of all, push the big red button and encourage other
people to do so, please. Do not be the dentists that are not brushing their teeth. So if you're
doing that, if you're implementing CSP, do that in conjunction with self-resource integrity.
So if one of your third parties get popped and one of the JavaScripts get changed,
please, if you're using self-resource integrity, you won't get that code executed on your website.
I know some personal stories of that. So then if you're using your CSP, don't use anything
that says unsafe. Unsafe for the ones that do not know English is very bad word, okay?
And use instead nonces and hashes. You can use a strict dynamic, okay? You can use a strict
dynamic to reduce the operational load transitive property that I mentioned before, but be aware of
the risk. That means that you have to really trust those other third parties. Then reduce
the number of third parties on your content security policy, reduce it to a minimum. I'm
not saying not use them, but reduce them to a minimum. And if possible, instead of opening
pokes and poking holes on your CSP, to allow third parties, just host the libraries on your
own domain, so you don't have to poke a hole in your CSP. Do not include, of course, if you have
to do that, do not include third party domains with wildcards, such as this one. You're allowing
everyone that has an Amazon AWS domain.com API gateway to execute or retrieve code from your
site, no? Then use report two and report sample. This is going to be noisy, but it's giving you
superpowers and you are going to be able to see what is happening in real time
with your users, no? What code is being executed on your client's or user's side.
And then finally, consider available commercial solutions to monitor client-side JavaScript.
These solutions, you can search for them, they are going to tell you, they're going to highlight
and alert, tell you, hey, this script has been executed in one of your user browser and it's not
useful. So take a look to it. With all of that, thank you, everyone. Thank you for all my
colleagues. You didn't let me thanks to my colleagues in SensePost and Orange Cyber Defense,
especially Simon and Leon and John and everyone else and you guys for being here. Thank you,
everyone.