hello everyone and thank you for joining
i'm ken
and i'm honored and excited to be here
today at defcon 29 and share our
research about
exploiting host document messaging
a little bit about me i'm the co-founder
and chief architect of enzo security i
live in tel aviv
i like to build things and hacking has
been my profession since 2004.
in this talk i'm going to talk about
what course document messaging
is how to hack it and how to use it
safely
but um when we looked into this
issue to this subject and try to map
what's uh the risks in it and how to
handle it from application security
perspective
we found that when we are used to having
very good tools into in introspecting
web traffic in looking at the browser
generally and being able to understand
what's going
on inside it especially in places where
our application interface with other
applications
and and from perspective of a pentester
this is a really interesting
place and because document messaging
offers communication between different
origins
different parties practically but
there is little to no tools to actually
properly look into these messaging
protocols and understand what's going
on inside them so and
we decided to build their own tool and
therefore this talk is also
about the tool and how and the results
that we made in order to
build it and and i hope you like it
so what is post document messaging
course document messaging is window to
window communication method
and that allows frames from different
origins to communicate with each other
there is no network everything happens
in the in the browser's memory it's
actually
binding functions it's actually
everything is already loaded in the
runtime
and there is actually no network stack
involved at all in these goals
and the security model that that
supports this is very straightforward in
simpler
let's talk about the functional flow of
course messaging for a moment
so inside the browsing window and
content the document that opens inside
the browsing window arrives on a
specific origin
and this document may include script
this is basically some sort of
perspective on how
every web page loads there is a
an object called window that is managed
by by the browser and offers
the api that documents and other
elements in the
in the runtime environment of the
browser requires
and this window is what hosts
particularly the document and the script
any document can open a new window
and embed another document from another
origin
or open a window we're using a window
opener and open another window in
another tab
and maintain a handle to that window so
it can communicate with it later on
the scripts that run inside windows if
they have reference to
other windows they can send
messages to these windows using the post
message command
and they can also handle incoming
messages by
registering a listener on the message
event on the window
this will this is practically allowing
duplex communication between two
different origins
say one page loaded from hacker.com and
another page loaded from
vikram.com they can still communicate
with this technology
as long as they have reference to each
other's windows
and in today more than web pages and
applications there are always
some use of framing some use of
reloading and referring another window
maybe sometimes in sso scenarios
sometimes in just embedment it's very
common
in sites that needs to tap and interact
with ad networks
so the the final result is that many web
pages are very complex in the way that
they
build a tree hierarchy of windows and
because the way this um feature is
implemented inside the browser
because of the course document messaging
is implementing inside the border the
browser
every window in the domain key can
practically
send messages to any other window or
receive messages from any other window
this brings us to the security model
because
in fact there is no way for the
developer of a specific document
to know if it's going to be loaded in
different environments everybody can try
and load them as iframe for example and
if they are implementing
some interface they are using some host
messages
um capabilities they are
exposed to some different attacks so the
security model is very straightforward
forward and simple
we have in the center in about how to
follow how to start
the uh the session some summary
security headers and configuration allow
you to prevent
the window or instruct the browser to
not load this document
in some scenarios so for example very
common very known
extreme options will tell the browser
to not load the document into an
embedded
window inside another window
when uh when even even if the iframe
points to
uh to your target window um
other security headers also restrict the
use of the window opener
but as as we all know about security
headers sometimes it's
not very simple to uh to be able to
configure them sometimes the
environments are very complex and
sometimes and
developers can override them so security
headers are
one part of the this model but it's not
in many cases sufficient to cover
everything so also on the chord level
the sender code and is responsible and
actually
actually the browser of forces the api
of the vowels of force is the sender to
specify the remote origin
but it allows to specify um any origin
and because in some scenarios you need
to still send
when you don't know who the recipient is
and in this case you're supposed to send
only
stuff that is not sensitive and on the
receiving end the browser provides
authoritative information about the
origin of the request
and all that is required from the side
of developers is to verify that this
origin is an origin that they trust and
then
follow up and only then process the
request
so this is basically an outlook of
post document messaging that explains
the playground of security in this uh
when this technology is in use and i
want to take it to a perspective of the
offense and defense to see
how how should we approach it from both
directions
so we can actually understand what kind
of tooling is the most appropriate and
what kind of method is the most
appropriate for
testing and fixing post messages problem
so on the side of defense um
we need to use security headers we need
to
only send messages to selective targets
so
don't just publish sensitive data to
everybody
and we need to authenticate incoming
messages
so defense is quite straightforward we
need to use security headers when we can
we need to instruct developers to only
send messages to selective targets
if they are sending to wildcard it must
be something that is
purely non-sensitive if such a thing
exists
and they need to authenticate incoming
messages before they process them
let's do a quick stride drilling down
so um splitted to two
different scenarios the first scenario
is that our code is
issuing a message is using post message
and then
the the risk is that the uh
the window on the other side is not the
is not coming from the origin that we
think it's coming from
and um the threats um
is the actual threat is information
leakage that we will send sensitive data
to somewhere that we're not supposed to
send it
on the ad event listener side when our
code
is handling incoming traffic so again
there is a threat that the
the sender is the sender identity is not
the uh is spoofed is not the center is
not who we think
they are and um the threat of elevation
is
that the functions um that the
message instruct function in our context
and that in this context the
instruction can give the attacker more
privileges on doing
some things triggering some forward
functions we consider this
as elevation because the attacker is
elevating from running in remote context
into running in our context our controls
for
for threats of spoofing the recipient
identity
is do not send sensitive to wildcard
and our control for
for making sure that we're not
processing unwanted messages
is to authenticate the origin of all
messages
and only allow messages that we trust
and that we have
controlled their contact with um
additional mitigation is to set up
everything
in security headers to restrict as much
as possible the loading of our origin
into other windows
so attack is also in two scenarios the
first one is to attack senders
and listen to the data that they send to
see if they send any
anything sensitive and the second is to
attack receivers by sending the messages
and trying to run thing in the remote
context
we are addressing few different
weaknesses here
and the first weakness is that in some
cases
even if a x-frame option for example
works still you can use a window opener
and in some cases it's very difficult to
propagate the security headers
everywhere that is needed
and to make sure that the window
actually
won't load in any risky scenario as
testers we have to look at this
and spot those places we need to try
and host the vulnerable the vulnerable
frame
and uh make sure that we host it in a
way that uh
that is similar to a real scenario to
actually
make sure that it won't if in most cases
it will be still possible
either to operate in opener in window
opener or in an iframe
or maybe find another frame that has
similar problems when you
explore the your target and test the
scope second weakness
is that in some cases developer might
be under the assumption that they are
protected
and sent unrestrictedly to wildcard
we need to spot these places and see if
any sensitive
data is sent to any
any uh origin this could happen because
the developers
think that they're protected but it can
also happen because they
operate in a very complex environment
where they need to work with many
origins and it's not very
it's not possible for them to actually
know which origin
loads them but still sending sensitive
data to one
origin is dangerous and this is one of
the things that we need to
track in our
the third weakness is that in some cases
developer will even skip
the authorization check completely and
or maybe implement some string matching
that is
inadequate to actually test if this if
the remote origin
is trusted or not and in addition to
that we'll do something sensitive with
the data that they receive
these are the three weaknesses we are
addressing in two different attack
scenarios
one is to spot chatty victims and listen
to the traffic and
report it back to our headquarters and
the second is to
try and send messages to victims that
implement sensitive
and sensitive message handlers
in this imaginary example the victim on
the other side will use this
on click url parameter to
update the uh the source of
the href of an a tag and then instead of
instead of updating the actual link it
will load our javascript
and when the user clicks on it it will
actually
load this javascript into the victim's
puzzle
and
so let's get into uh working our tour
on our tour so the first thing that we
need to do is we need to be able to see
senders and their messages and receiver
and messages
additionally it needs to be able to
simulate malicious senders
or receivers so we can actually check if
the window setting allows us to
actually actually implement a real
exploit in real
real life scenario
so we split the walk on the tool to a
few different milestones
and in this talk we're talking about the
few
the two first steps which is being able
to see
the clear the three of all windows in
the browser
and the release enables the messages
practically the traffic and be able to
simulate different attack scenarios to
see if we actually found a vulnerable
listener
center and
now we get into the research part so
this technology the course document
messaging technology
is really almost invisible inside the
browser as it is
the the
straightforward way to see this
communication is to
open dev tools go and
look into a window object and look it's
into its
event listeners and then follow to the
message event listeners but this is in
practical when we talk about
a lot of different test cases with a lot
of different windows it's uh
it's almost impossible to uh to
accomplish
this in large scale you have to somehow
automate this
so first thing we tried is to
inject a javascript inside every browser
session every every every document to be
precise
and and have this javascript in a hooks
some calls
inside the browser to make sure that
some of the traffic
goes flow through it and
and using this method and to be able to
see all the traffic and the frames
the problem running this user land mode
is that we didn't
get enough data to show everything that
we needed
and and the setup was also unstable and
complicated with
additional extra steps to configure your
proxy and make sure that it also
handles all the content security policy
restrictions that
won't come into effect in a in a real
world scenario because of
how cost document messaging works and
so we we tried to an approach that gives
us
a little bit more insight into the
internals of the browser
first attempt was to use home debugger
and with a home depth of protocol
connect with home remotely
and operate the debugger api
different kind of apis to uh to collect
and track the data that we need
this i was very disappointed to find
that this
wasn't very accomplishable in this
method the
debugger api if you move into debugger
mode
and it affects the user experience it
breaks many things on
some website in some cases and it also
doesn't give us
that didn't give us the data that we
needed and there is
problems in in the way that that
different frames are represented in
different apis which makes it
tremendously difficult to uh to analyze
this graph of this three of the
frames loading and and then in the third
approach we benefit from
extra additional options is by using an
extension
it also properly accommodate our need
for some ui and
the data and it was a bit more
simplistic and the data that
that is in it was better still not very
not perfect
but better for us to be able to
to to construct all the data together
and show it in
the way that that you can actually see
all the frames together
the final approach was a combination of
different
uh of different
methods together to actually
um be able to do what we need to do
um let me show the the overall
conclusion from this research
so the bottom line is that the browser
does not provide anything there's an
easy interface
right you can see web traffic can have
many tools to manipulate it and
to inspect elements and to see all the
data
um there is no good interface
not for people and not for code to look
at this data
and in different apis of the browser
frames are
represented differently with different
ids and different meaning to the id
there is no
no clear way of you you sometimes have
to
uh to assume things
and if you run in new zealand
the origin level installation limits
what you see
and then you need to find a way to uh to
walk with this
and the same goes for for extension and
context segregation
is also one obstacle in some cases
because uh
because the kind of
impact the kind of a feature that we are
looking for in our tour is to be able to
see things in all contexts
because we want to be able to to see all
this traffic and manipulate it
so with these lessons from our research
we are finally ready to think about our
tools components
the first component is the extension
content page its job is to run first
basically
we wanted to use it in order to
load the agent but we couldn't do it
directly from the extension content page
because it is isolated from the
document context and we wanted the agent
to
run in the document context but the
extension the way the way content page
works isolates it from the document
the agent itself implements a sort of a
hub that
hooks a ad event listener
and basically you wrap
every call to an event listener in a way
that we will see
the message first and only then dispatch
it to the actual event listener
and this is also why we couldn't run it
in the content page because
the content page does not see the uh
the calls to add event listener from the
document it is isolated it's constant
its
context is isolated and the agent script
is basically
injected as a script
by the content page uh to
every new document that loads inside the
browser
then the extension option page is our ui
it's a react-based
user interface for everything that we
need in this tool
the extension background page is
the backend hub and everything that the
agent sees is reported
to the background page and the
background page also exposes the data
object that the
option page needs and in addition to
that we have the test site and a
small app factory that hot build all
these components so you could actually
develop this without losing your sending
so without further ado this is posta we
have
um a place here for to see all
tabs and the windows place to see all
the messages and listeners
the control panel to use some actions
and some text a little playground
let's open our testing page
so this is the test page it holds at the
moment a
vulnerable iframe and
here we can see this is gita and this is
not us and this
is our test page and the hosted iframe
now let's take a look let's send
something
test as we can see this what this iphone
does is to add
a text here to the iphone itself
let's take a look in poster we can see
this message
let's resend it
resend us string
and go back to the testing pages we can
see that the payload is actually being
sent
let's try something else now
and let's send
as string again send
and we see another one and
this is how it works um you can
also use the exploit page so if should
go back to posta
and open it in an exploit page which
actually simulates hosting this
it's uh let's send this message again
this is not complete somehow
send us link but as we can see here
nothing happens let's
try to see what the problem is and the
problem is that the different origin
subframe try to create a javascript
dialogue
so it's basically browser blocking the
alert box
and this is exactly why for this kind of
scenarios and also to test
for window loading we have the option to
open this tab
got it and this is it
let's try again to send a string
and it's here and it works so this is
posta
you can go to benzoio or to our
it will lead you to a
please feel free to take a look download
and use
in your tests so of course one of the
first thing we did is to
put this tooling to use in finding real
bugs
like this one by enzo ctobacter really
which shows that there is an iframe
specific iframe at the
the syrian valley express that um
that's again that is used by aliexpress
that uh when sent a specific
payload would actually take this data
and uh let it affect the contact the
menu
the main menu of the of the shop and
by sending a specific payload we managed
to
override the content of this of the menu
and inject our own script that they
respond to interaction with the menu
with executing this notorious payload
let's say wrap this up so course
document messages weaknesses
are that by default windows can send
data to it to each other and we
need to add security headers to prevent
this to prevent our windows to from
loading in
in dangerous scenarios and on the
receiver script
there is no default authorization checks
developers must
implement code to do this and the sender
script can publish data without
restrictively choosing
who is going to get it and again we need
to make sure that
the developers won't send sensitive data
to other
origins and we need to of course to
always like
like in every technology in especially
in technology that interacts with other
parties we need
to make sure that we we spot
all implementations of this technology
and test them
and some conclusions for more for
engineers so we implement
security headers to protect your windows
make sure that you invest in this this
is a
fast efficient and effective way um
only send data to explicit targets if
you can
and also something very important and
when handling messages you have to look
into event origin and make sure that it
is an origin that you trust couple of
words about enzo
enzo's an application security posture
management platform it allows
upset teams to scale their upset
activity
to actually eliminate the chaos and
lead the organizations to maturity with
an autonomous discovery engine
that finds out what assets you have and
onboard them to your security tools
gives you measurable actionable
information about the performance of
your different activities
and let you control all of it in a
single pane of glass with a lot of tools
to
simplify in in your day-to-day work as
upset
also check out at the upsetmap.com our
new open initiative to map
vendors and solutions in appsec
and so vendors and petitioners can
easily find each other
and understand what kind of solutions
are available for them in their absence
forums
thank you very much for listening i hope
you enjoy it enjoy the rest of the
conference
and see you next time