- Nice to meet you, my name is Barak,
and I'm going to speak about:
Extension-Land in my DEFCON talk which is:
Exploits and Rootkits for your Browser Extensions.
So let's get into it.
First, a little bit about me;
so my name is Barak Sternberg.
I'm a Senior Security Researcher,
and I'm previously an Author at SentinelOne Labs.
I also did published research regarding smart devices
and hacking smart-devices in the (indistinct) DEFCON.
And I also have a BSC and MSC in algorithms,
specialized in bioinformatics.
But today I'm going to really focus on my main appetite
for vulnerability research,
and also to analyze malwares in the wild,
and combining it all and focus on these validation
on the extension-land.
I also love to DJ and party,
so check out also my mixcloud for mixes and such.
So concluding that, let's continue.
So, what is the motivation for our talk?
First of all, attackers are pushing harder and harder.
There are more than 2 millions extensions
inside the web stores,
inside the Chrome stores or the Mozilla store.
And it's a widely popular target,
both for developing malicious extensions
and attacking these extensions
with XSS uXXS, et cetera.
The second reason is that,
well, extensions are cross-platform,
of course, only for the desktop,
but are cross platform, they are generic in a sense,
these just JavaScript a malicious thing to develop.
And they have so many more permission
than just regular sites or even,
render or exploit and stuff like that.
They have permissions to access any origins sometime,
and they can control the entire browser,
and more on cookies and many other things as well.
So the cross-platform abilities
and the easy thing to develop,
make them a really popular target,
and also an interesting one to investigate and research.
So the syllabus we have contains couple of the subjects.
First of all, I'm going to introduce you
the Chrome extensions in general,
I'm going to focus on the Chrome extensions,
in my windows desktop, but it doesn't applicable only
to these Chrome extensions in my desktop.
It's applicable to any kind of extensions
which are desktop related.
It's this kind of research and attack surfaces I observe,
are also applicable to many other platforms as well.
Next, I'm going to tackle the communication,
communication routines between the extensions,
beneath, besides, above,
and in so many other places.
After that, I'm going to go into the Zotero extension.
I'm going to tell how I managed to jump
from one good Chrome app which seemingly doesn't do nothing
in your computer, just, I don't know,
open TCP sockets and kind of that it.
And from there to really own the browser,
by owning and owning the Zotero extension,
managing to jump from one Chrome app to another.
After that I'm going to exploit Vimium
in which you accesses Vimium,
because of some communication, interesting problem,
And I will finish with developing and implementing,
implanting my own extension rootkit,
and I'll tell you how to really modify any good extension,
that is previously installed in your PC,
to make all of these extensions go bad.
So I'm excited, let's get started.
So first things first,
when I tackle the extension
or I tackle, of course, the extension anatomy,
and I reach to absorb the multiple layers
inside the extensions themselves.
So, extensions actually include couple of,
well in an eye-level manner.
They include couple of components.
The first component is the content script.
The content script is the actually the extensions frontend.
It includes a specific type of compound
of JavaScript and HTML code,
that can be loaded in the matching sites for example,
if you're an ad-blocker so, for every site,
every site you are into, the content scripts are loaded,
but compared to the background scripts,
the content scripts are loaded only inside specific sites,
and they are not persistent,
meaning they are not the same for every site,
and they disappear when you close the site,
when you close the tab, these content scripts are gone.
The background is actually the backend of the extensions.
There is like one dedicated process which is really cool
and it's like, behind it all,
and it manages all the things related
to the extensions main APIs.
And it has many more APIs that is accessible.
And also we can do more things compared
to the frontend content Script
and it actually communicate the background script,
and the content script communicate between each other.
So, if you know maybe Chrome, it's considered to be like,
the content script is the rendering process
which is in every site.
And the background script might be
like the godfather process,
which is like the browser context,
which is like controllers of this tiny content script
in a sense, cool.
And least, but not last,
we have the Extension-Dir, which is in my PC
in the local app data.
And also one more important thing is the Manifest.
So, if you maybe remember the manifest XML inside Android,
it's actually exactly the same.
The Manifest XML in the Android is quite similar in a sense
that is defining the whole approach about
how extension is built.
And this is the Manifest JSON,
which is inside every extension.
So the Manifest JSON, defines truly
what will be the background script,
what are the content script,
what are the permissions the extension have
and so much more.
The last thing is the signature.
So, every extension also have its own signatures
in a calculated directory,
I mean, calculated directory, I mean by that directory
that includes all the hashes, (indistinct)
that are assigned by the public key
of the extensions developer or the web store
dependent from where you have download this extension from.
And the most important point to know about it,
is that every time you open an extension,
or you use an extension, this extension gets verified
and this extension gets verified
and analyzed fully in a sense that if the data
and the JavaScript inside these extensions are not valid
and are not the same as published out there in the web
and not signed, then the extension
would be considered invalid, and will not work.
So, Chrome automatically check the signatures
for extensions dynamically, cool.
So, let's go for the Manifest Anatomy.
The anatomy of the extensions include the spots,
as I told you already.
It defined in the first part in a cool JSON kind of way.
The first part is like a key values,
the first part is like the background scripts.
So we define which are the background,
whether it persistent or not.
Usually most of the background is persistent,
meaning the process runs all the time
of the background process.
Content script with all the definitions inside of them.
And one of the most important things
inside the content script is actually the sites
that are matched with.
So for example, if you go to Google,
you don't automatically load all the content script
for all the extensions.
You just load the content scripts
that used to work on this site.
So if you have an extension that works only on Google,
you can tell in the Manifest,
I'm working only on Google in the matches key.
You can see the matches key inside the content script
and that will tell the browser
to load this content script only there.
The last thing is that, well, the last important one
is the web accessible resources,
which are extension pages that are accessible.
And I will show you later on how to, other websites
and you can implement, embed them, sorry,
inside as an iframe in your website,
and also the permissions themselves,
which mean the permissions that the extension can use.
So, concluding it all in some cool eye-level overview.
So we can see the eye-level diagram here
and communication-wise and eye-level wise.
You can see the DOM is,
when you go for example to Google site,
there is the DOM which is the main site,
the main context we have.
This is like the all the DOM HTML elements of Google,
the page scripts of the Google sites
and many more that are loaded are accessible
of course in this DOM, but not just the page scripts,
but also the content scripts
and all the other sites of the extension itself.
So, the extension is also accessible to the DOM.
Of course, if it's should be loaded in the site
and the content scripts can access the DOM page
of these Google sites.
The content scripts which are the frontend
and I already told, use messaging platform
to communicate to the background,
to the backend of the extension itself.
So the background page is the background context
of the extension, and it doesn't directly communicated
with from the site.
Only, well, mostly indirectly by the content script itself.
So this is like the old communication between these things
in the extension world.
So, a quick, maybe a reminder,
or maybe example for couple of few
content scripts and background scripts.
So, if I'm an ad-blocker,
and I want to remove all DOM elements
that are advertisements,
I can just access the DOM and remove these elements.
So this is one example for the content scripts themselves.
You can see this example over here.
And the background scripts,
if they want to remove specific Ad or URL,
that is being processed and requested by the user
and the browser's client,
it can just remove it by using the Web proxy.
Well, actually the WebRequest proxy.
So you just add specific hook to the WebRequest
and catch all the events,
the network events to redirect this URL to entirely new URL.
it owns, or just about blank if it wants to.
Therefore it blocks these advertisements in this manner.
This is the technique of the background scripts.
Okay, so let's consider now the website versus extension,
let's consider all the communication within
that are available.
So, first of all, we have the cross-origin messages.
This one is really a known way and a known technique
to just make communication between every arbitrary
like origin, cross-origin stuff,
and they are widely popular and used also in extensions.
You define your message listener, you do post message,
and they communicate between each other.
The second thing is that DOM changes
in events like extension.
The content script can intercept
and hook the onclick events, onfocus.
They can search for specific div with specific classes
and use them to do many things.
And of course, if I'm an attacker website,
I can control and define these kinds of things.
The last thing is the, well, is the most kind of unique
and interesting property that extension have.
And this is like extension pages that are accessible.
They're like in a sense reminds of a content script
that are accessible to DOM,
but they have more capabilities because you can embed
specific web accessible URLs,
which is URLs that the extensions need
to define inside this Manifests, and they are open wide,
and you can embed them in an iframe in your own website,
and access them, of course not stop breaking,
but you can access them in a manner
that they can be embedded and they can be accessed
from cross-origin messaging or maybe many more features
that you can have.
So this is like the three main options I will tackled
in the website versus extensions content scripts,
communication with thing.
So, how about, well, I talked about content scripts,
how about the background scripts.
So the background scripts have cool way of communication,
in actually many other and non-spectable ways.
So, first of all, there is the WebRequest proxy,
the exact WebRequest proxy actually handle these requests,
and also the responses from the service site.
So if where, maybe a malicious server wants
to attack in a specific extension,
we can maybe inject headers and or specific response
that will be analyzed for this extension
and therefore affect the extension background scripts.
The background scripts intercept the request
and the responses.
This is a cool way to intercept and communicate
in a indirect way with the background scripts.
Another way for the background scripts is actually,
it can access the tabs, the cookies, storage data,
and much, much more inside the websites we have.
So for example, the background scripts have access
to this API with the Chrome tabs,
and we can query the info, the data,
cookies, and much, much more.
And we can affect them of course,
if we control a specific sites,
we can make a user access these sites.
And the last thing, which is not the web accessible pages,
it's a new and a cool, well, not so new, of course,
it's a feature existing probably from 2012,
but it's worth mentioning that you can externally connect
also to pages, and by externally connect,
I don't mean just embed an iframe of this extension page,
but also like really communicate with the background scripts
for specific websites.
So when you open specific websites
that the extension defined is a valid one
and an extension like trust on these sites,
it can actually use the site to...
To send messages through the background.
So for example, in the following, in your screen,
you can see that if I serve to the X.com site
and X.com was previously defined as externally connectable,
then the API interface,
to send message to this extension ID,
which is handled in the background script
is fully open to me to access.
So it's a really cool way to access internals
if I am, of course, accessible to these sites, cool.
So, also extensions and extensions
of communication between them,
well, it includes a couple of things first of all,
all the website versus extension communication
is available of course, because any extension
usually can open specific website,
or fake maybe a new website and open a new tab
and unlike fake these communication.
So, all what they show you in the webs
if communication is available,
but also more things are available,
and sometimes the extension,
for example, the externally connectable sites,
can include also extension IDs
that are able to communicate with this extension.
Of course, it's dependent on the extension developer
to add your extension ID
and to make sure that your API is available to you
as a remote extension.
The other thing is also TCP and UDP connection.
It dependent on permissions,
whether you can open a TCP server,
a TCP socket, and much, much more.
And well, for example, let's say I want to do an injection
from one extension to another extension.
And the way I can do it is actually
with these externable, connectable things.
What I can actually do is to make the first extension
to inject the code into a legitimate site,
so the second extension will actually feel
that this extension and this code that was injected
in the site is actually its own code.
So we will think that this code is legitimate and the API,
the Chrome, will open the API to send messages
to this extension ID because my first extension
was injecting JavaScript code
to a legitimate trusted site by the second extension.
And therefore we can manage to communicate
with the background scripts from one extension to another,
even though we might not have the permission of extension ID
specific API that is accessible.
So we can inject to other site and communicate
by that in the background scripts of the other one.
It's really easy thing to do.
Cool, so this is like, this kind of injection.
Let's go now and dive into like,
we are all here for the vulnerabilities, right?
So, let's dive into the real business
and show some vulnerabilities out there.
So first of all, I will tackle the Zotero extension.
Zotero extension is a popular academic extension,
commonly used to organize citations and share research.
It works really and suits completely
with the Zotero-Desktop edition.
The Zotero-Desktop edition save your data locally in the PC.
And it's plugging together usually as Zotero extension
and Zotero-Desktop.
Not always many people actually use
only the Zotero extension because it's easier to use,
you don't need to configure anything, really easy,
and they communicate, the desktop version,
and the Zotero Connector,
they communicate for TCP ports on local host.
So, let's see what we can do with that, or actually, well,
you can understand by now, like I'm going to exploit
this kind of thing, and try to manage to run JavaScript code
inside Zotero extension.
So I have also found that there is the Zotero translators.
Zotero translators are cool features,
well, more than 500 JavaScript translators
that can get executed to every site you enter
within the Zotero extension.
Of course, they are really suspectable
to supply chain attacks.
They're like open source and inside the public GitHub
in the Zotero repo,
but I'm not going to consider and focus that.
More we need to understand that this translator job
is to actually take and extract specific data
from specific websites, and take for example, URLs,
and academic URLs and citation notes and stuff like that,
and extract them using their own JavaScript
to make citations and sharing much better.
So, I don't really know the whole way
about how this works, but I don't care.
They help me to run code,
they help me to run JavaScript code so,
that's what I'm actually in for.
And the way I managed to do it is actually by,
well, you have this Zotero translation,
also an auto-update mechanism.
This is like an auto-update system,
and it actually tries to communicate
with the standalone desktop edition,
I already told you about.
And what it tries to do is to try to get new translators,
if new translators need to be updated,
it also download the new JavaScript code from there
and, well, 'c'est la vie'
So it's perfect to maybe try to manipulate and maybe try,
I don't know, open and listen,
to specific port, listen to local host maybe.
Can we do this kind of things?
Well, apparently yes,
we can actually put new listener on the local host.
We can do it by, well,
of course, my legitimate Mappy Chrome app.
My Mappy Chrome app is a Chrome app
and not a Chrome extension,
but it's still a valid Chrome extension like,
it looks like a Chrome extension.
It have some more capabilities.
One of these capabilities is to open TCP server on,
well, on high port, of course,
but it's actually good enough for me.
I just open a new port on this,
put the listener and send the new JavaScript
and execute code on the content scripts
inside the Zotero extension.
So this all mechanism and the code has been run,
after all, is actually been run in the content scripts,
again, context.
So the content script actually try to run my code.
You can see in this presentation that like in the slides,
you can see the eval, the eval consider like,
I'm in sandbox manager kind of thing.
I'm like, I'm doing a sandbox manager execution,
yeah, it should go right.
Of course it is a sandbox.
Well, not so much sandbox.
This sandbox manager actually means nothing.
And the code I'm able to execute in JavaScript mode here
was able to access DOM elements, HTML elements,
configurations, APIs,
and it runs in the context of the Zotero.
So we won, right?
I'm like, I'm running my own JavaScript code
inside the content script.
And I will show you later on a demo of how it's all done.
So after I managed to run code
inside the content script itself,
let's, well, let's be more greedy, right?
Let's, the content script is fine, but it's not persistent.
We have a little bit of problems.
Let's try to attack also the background scripts, right?
So from the content scripts themselves,
there are a lot of APIs and attack surface I can use.
So I try to investigate these attack surfaces.
Of course there is the same message,
and the connect one that like,
this is the interface between the content
and the background script as I already told you,
and you have access to shared extension URLs.
And there is also like a storage and configuration
that might be shared.
And all of these are quite interesting,
but it's like an attack surface.
And I don't really know how to continue from there, right?
So I try to do the opposite and try to go,
easy peasy, let's go from the evals
and the bad things they're are doing in the background
and try to trace back and found the attack surface
that is reaching down, and I actually found something.
So in the Zotero background scripts
there is an interesting eval related
to the Google docs integration.
So, let's see how it is done.
So what I've observed is that in the background context
of the Zotero mechanism,
there is this weird Google docs integration system.
And by weird Google docs integration I mean that,
they actually update their integration scripts
for the Google docs operation from remote website.
And actually this remote website can be easily configured
using the Chrome storage APIs.
So on the first line here,
you can see that the preferences are gotten
from the current configuration
and then using these preferences,
the Zotero mechanism for the Google integration
loads new background scripts for this integration itself.
So as you can see on this slide,
these scripts that have been remotely fetched
from a new site, the JavaScript files,
arbitrary JavaScript files.
No validation, no verification, no signature even,
only to validate that this version
is higher than the current version
and automatically download it,
downloaded and executed in the background context.
So you ask yourself, how can we control these ones, right?
So we managed to control these one because
if we are in the content scripts,
we're actually accessible to the configuration
of the background scripts itself.
So from configuration, we inject new configuration values
inside the background scripts,
hence fully control this remote server that,
well, it's going to be downloaded in the background
then executed the JavaScript code.
And therefore we launch arbitrary JavaScript code execution
in the background.
This gives us the ability to jump from the content script
to the background script and run our arbitrary code,
which is also persistent.
And now let me show you a video of how it's actually done.
You can see here, this is the Mappy extension,
good extension, yeah, very good absolutely.
You can see that it's have permission only to TCP sockets
and stuff like that, but no sites permission at all,
no site permission at all.
And I'm going to show you, it gonna be a little bit quicker.
I'm going to skip to the way that I managed
to run code in the background script.
And I will show you how this data
has been transmitted back to my PC.
So we can see this is the Zotero extension.
This is property, it's accessible to all sites.
I'm going to use the Zotero extension
in order to do privilege of elevation P
from my extension to another.
You can see here, this is the background,
while I was speaking, it was already doing
the injection from content script
to the background script.
And code was run in the background script
and send it back to my server.
You can see I'm searching for something,
it'll also appear in my side because I injected
from the Mappy into the background script on the Zotero.
You can see that there's nothing showing the network
in the dev tools.
I'm not sending anything
from this VM context, it's totally hidden.
So I'm actually tracing the user
from another different context inside the Zotero context.
And you can see that all the data
has been received back to me,
and I'm fully controller of this browser
by exfiltrating data back to my PC.
And my code is actually running
inside this good, beautiful extension, the Zotero extension,
and I jumped from one extension to another.
The Mappy extension is actually not relevant,
though you can remove it,
but it won't change anything because I already injected
my configuration inside the Zotero extension.
That's it, so I'm actually fully in control,
nothing in the dev tools, nothing in the network.
You can see, it all happens in separate VM contexts
and execution.
Okay, let's go now to another extension.
Let's go to the Vimium extension.
So the Vimium extension make your browser
a theme like extension.
It helps you to easily do browser navigation
without mouse clicks and anything like that.
It has its own keyboard shortcuts like in Vim
we can do copy, edit, search, navigate,
and much, much more.
And this is for example, an example of how we do it.
You can see that when you click a couple of buttons
in the keyboard,
all of the links in the browser seems like a clickable links
by the keyboard, and for example,
when you click D you will actually go to the search bar
and you can easily navigate just with your keyboard
inside all of these browser viewable objects.
So this is a cool thing, but let's say, well,
our scenario is we are a website, not an extension.
We can consider extension,
but it might be a little bit harder thing to do.
So let's consider now only website,
and we want to attack Vimium extension
like Vimium extension users.
So, let's see what is our attack surface.
So our attack surface is actually,
includes all the things I've been talking
to you about in the communication with things and stuff,
but includes much, much more.
For example, it includes the Vomnibar widget,
which is a widget that seems like a search bar
where you can easily search inside the Vimium extension
for more data and stuff.
The helper widget which open in help thing
and visual mode, like a Vim kind of thing.
So it has a lot of possibilities to do.
And I focused on actually on the Vomnibar iframe.
The Vomnibar iframe was seemingly
the most interesting widget I've been find out.
So how the Vomnibar often works
is actually quite interesting.
So the user clicks Enter, O + Enter,
and then the content scripts catch this event,
the onclick event, the enter event and adds an iframe.
It adds the Vomnibar iframe.
And when this Vomnibar iframe has been added,
it's not enough, this iframe is actually a widget page
from the extension that is accessibly website URLs,
defined from the manifest of the Vimium.
And after you put that, you still want the content script
and this iframe to communicate between each other.
And this is like exactly what they are going to do.
On the next step they are going to authorize.
So the content script try to authorize with its own secret
to the Vomnibar iframe,
the Vomnibar iframe because it runs under the page extension
is also accessible to this current secret,
the Vimium Secret, so it can verify that one context
the browser that is going to accessing
and try to communicate with Vim have relevant secret.
So it verifies also these secret.
And after it verifies the secrets,
it opens also a message channel,
which is kind of a JavaScript kind of mechanism
to place like a TCP kind of sockets
between different website context.
So now the content script and the Vimium Vomnibar
communicate between each other, all cool, all good.
They know that if I am an attacker,
I can actually put the Vomnibar iframe in my site,
and maybe try to authorize myself, right?
But they still need, yes, you're right,
I still need to break these Vimium Secret.
So, how does the Vimium Secret is being generated?
How does the token we've talked
that's used for the authorization is being generated?
Well, apparently, it's a very, very state-of-the-art
random number generation.
As we can see here, they just use math.random,
and math.random is actually pretty predictable,
if you are in the same process of course.
Unfortunately we are not in the same process.
So does it mean we can't break it?
Not quite, because the secret is contained,
well, only 31 bits of entropy.
Then we can manage to use that and actually do bruteforce
and maintain this bruteforce to succeed
in our operation of breaking this secret.
This is like an example of a bruteforce.
We inject our own Vomnibar iframe, we place a new element,
a new iframe element.
We then set this iframe element
to point to the Vomnibar HTML, I showed you.
And then we try to authenticate with these,
to authorize us between this iframe.
We use the secret that we want to bruteforce,
for example, in this code, it's the deadbeef.
So I tried to guess that the secret is deadbeef
and I'm sending data to this content window.
If I get success, the port is open,
if not, no response and nothing goes on.
So this is like cool opportunity to do bruteforce,
but we have couple of problems I've been tackled with it.
First of all, these are not scalable because
if their browser is hidden, the tab is hidden,
you go to another website, you close the screen.
Then the JavaScript gets suspended
because it runs on the frontend.
So what I managed to do is actually,
well, why not WebWorkers?
WebWorkers is, well, amazing opportunity
to just do whatever we want because they are suitable
to run in the background.
So when I use the WebWorkers,
I trigger the brute-force routines from the background
of the WebWorkers themselves.
So I use the background WebWorkers to actually
in periodically interval, trigger the bruteforce routine,
which lays inside the context I open inside the iframe.
So, the flow was like WebWorkers triggers
at every two milliseconds,
the frontend routine that do the bruteforce attempt,
and going on and on and on, stays up even when,
and it also stays up even if the tab
or the window is hidden.
It stays up at all time, it's such an awesome thing.
So it's like, even if the screen is closed,
even if an advertisement, I can like place my own things
and you won't even notice it, a
and I could run it days and days,
until you close your browser.
So it's really, really cool thing.
I use WebWorkers and now we've broken the Vomnibar Secret.
So, let's now focus on the Vomnibar communication.
The Vomnibar communication, well, includes,
well, couple of things they can do.
So, I assume now we've broke the secret, the Vimium Secret.
And I'm trying to communicate between this iframe,
this Vimium iframe and try to manipulate them.
First operation is it search for URL completion.
The second thing it activates search
and jumps to new URLs.
It also helps you search for hints.
It does auto-completion for things and stuff.
Yeah, I don't really care about these things, right?
And the last thing, it's use to run JavaScript code.
This is the main course, right?
Cool, so how it works.
So for example, let's say I have this Vomnibar Vimium
which seems like the search bar,
this is the Vimium widget.
And I write inside JavaScript scheme,
and then I click Enter and 'voila'
So I actually can also inject JavaScript using,
like JavaScript scheme is inside this Vomnibar browser text,
it's really cool, but the main problem with that is that
I run code inside those websites context.
So, I can't really get out of my context, right?
I stay in my context, in this example.com
that triggers originally this iframe,
this Vomnibar iframe.
And here come to rescue some communication problem.
Yes, well, I managed to run JavaScript code.
This gets into the picture, the communication problem.
So how the Vomnibar and the JavaScript scheme.
So it tried to find the auto-completion,
it calls some background script.
So, the Vomnibar iframe calls the content script,
the content script calls the background script,
the background script returned with the send message
to the con tab, the results.
So it returns data to the content script
running currently in this tab.
This is how we do it, and the last send message
is from the background to the context.
And it says, "Okay, execute JavaScript."
Okay, but what happens actually
if we place one more iframe in this area.
So, because Vimium is actually run inside all of the iframe,
inside Con tab and the content scripts
are inside every tab inside this iframes.
So if the background context do send message
to the content scripts inside specific tab,
it actually send message to all of the contents scripts
inside this tab.
And if it does send message, for example,
evaluate and execute JavaScript in this content scripts,
so it's actually mean we can manage to run JavaScript code
inside another website, and this is the whole thing.
The reason is that there is no validation,
you get a send message,
you get a message from the background script,
and the content script doesn't really know
which one was actually the trigger.
Well, in our scenario,
of course you can add defenses for that.
But in our scenario,
you don't know when you usually don't know
which one was actually triggering these send message.
Okay, so the reason that it works is that
when you place handler in the content script,
the own message, which is the handler for send messages
from the background, runs inside every content script
inside this tab.
So every content script inside this tab
will run its own message handler.
So that way we can manipulate other content script
and inject them our own data and evaluate inside them,
how well should be messages.
So, let's see now how it works in the content script
and in the background script context.
And I show you the communication between them
and I show what is problematic,
and later on, I will also show you the demo
that concludes it all.
So first thing first, the content script
actually sends a message from a specific iframe
to the background script.
After it does that, then the background script
send a message back to this tab.
So, it sends a message to this tab
with the send message API.
And when it happens, the content script inside,
well you can see that I have here two iframes,
like one iframe and one tall frame.
So you need to consider that I have one iframe
which is abc.com and the tall frame, which is example.com.
And when the background send the message,
both of them received the message.
The content script that runs inside this iframe
runs as well, and also the content script
that is in example.com also receive this message.
So this is the problem.
We can trigger the JavaScript scheme handling message,
and then when the response gets back from the background,
it will be sent to all iframe and execute our JavaScript
in another context, that's really cool.
So let's go see a demo of it.
So, now we can see this is my Chrome version,
and you can see, well, this was the latest one
before I update, I did a full request
and I updated there, and fix this bug.
So we can see this is the site.
And whenever the user will click on Enter,
it will inject the code in facebook.com.
You can see that the site is local host.
So whenever the user click Enter,
JavaScript will be executed, not on the attacker side,
not on the local host site, but on the facebook.com,
which of course you can see is invisible over here.
So, and this happens exactly because
the communication problem I told you about before, cool?
So to conclude it all, we show now a technique
that will be able to any attacker to modified previously,
good extension in your machine,
and also make them persistent with some generic techniques
which are available to any conversion.
And it's a really cool thing because in that way,
you can also add permissions,
change extension and modify it.
And why it's not an easy peasy thing to do is well,
the reason is that the extension director is signs,
so Chrome software actually verifies
and analyze these extension directory,
and verifies that all the signature in the hashes
for this extension data is the same as it should be.
So we can't really change in run time,
even not in afterwards,
and make these extension be a different one.
But, you can still think about the scenario where,
well, I'm in developer, I really in devoted developer
and I don't want to sign my extension
every time I do bug fix.
I want to check things, I want to add feature.
I don't want to sign my extension every time.
So, of course there is a method to load new extension
as developer, right?
So yes, you're right.
There is like an unpacked mode that helps developers
load their extensions without verifying the signatures
and without verifying anything regarding the extensions
for compatibility and to check their extensions.
So the scenario is that you manage
to run code over user device.
These are post exploitation and method like,
I propose like a post exploitation technique,
which consider installing new persistent JavaScript,
put it inside your machine.
And the way we can actually do it is actually exploit
these unpacked mode to replace previous extension.
The extension will look almost the same.
The user won't even notice because it's previous extension
we work as suggested all the, I don't know,
antivirals and stuff, we see that, well,
the extension ID will stay the same,
all will be the same, so all cool, no problem.
The way we can do it is actually by adding a new argument,
this new cool argument called load extension,
we add it to the argument in the command line,
and this argument gets the path of the extension to open up.
And when this extension is actually the same
as the previous extension,
you just replace it without check the signature,
without checking nothing, and without even warning the user.
This is really cool, and it's amazing technique to just,
you can modify specific files, add this argument,
and then you can replace every extension you want.
And when you modified with extension,
you can actually also add any permissions you need.
You can also add file system access with the file URLs.
You can add so many features that run in the Chrome context.
You can also access the cookies tabs,
and much much more as I already told you.
And you can also run hiddenly in a separate hidden context.
So now I show you how hidden we are in this context
and how it looks like to replace
and use a persistent generic technique
to replace a specific extension.
In this video, I present you the replacing
of the ad-blocker.
You can see that ad-blocker is installed in your machine.
It installed, like Google tells you it installed correctly,
no problems.
The ID is correctly, all installed correctly.
You can see that even if you go to the extension,
a privacy and the extension privacy area,
you can see it's all looks the same, but you can see here
that I injected my own JavaScript code,
and this is the main thing.
I injected and modified these persistent extension
in your PC, but I kept all its data
and all the things inside of it, almost the same.
And it looks the same, the extension ID the same,
Chrome is installing legitimate extension,
and it's really cool technique to inject malwares
inside extensions.
So finally, I would introduce you the, my utility
which is the maltensions.
These like utilities to help you generate for testing,
of course, for testing.
JavaScript malwares are inside the popular extensions,
and actually an extension.
This is the GitHub source and it has a lot of techniques.
I placed like many techniques,
you can do plug and play inside of them,
easy to comply your own JavaScript
in output of standalone JavaScript.
You can inject as a payload or as an extension,
you can open up an unpacked mode, whatever you need.
And it have so many features.
So, to conclude:
First, extension can be useful PEs.
PEs like in the extension world.
Using one extension to gain more permissions
from another permissionless extension.
The second thing is that detections will get harder
because it's very hard to find out
like dynamic executions in JavaScript evaluation
inside new extensions,
and they can do whatever they want inside of them.
The third thing is that,
well, there are more attack surfaces to explore.
Attack surfaces are not considered, only the typical ones,
but more like content scripts
to background scripts attack surface.
Background scripts to websites.
Extension to extensions attack surfaces.
Many of them haven't yet explored so far,
not in this manner before.
Well, and unfortunately it means that,
well, extensions and malicious extensions
are probably here to stay,
and this is the bullet we need to carry on with us.
Thank you very much, I'm very happy to be here
and to talk about this presentation.
I hope you learned and made the best out of it.