 Nice to meet you. My name is Barak and I'm going to speak about extension land in my DevCon talk, which is exploits and root hits 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 offer at Sentinel One Labs. I also did published a research regarding smart devices and hacking smart devices in the DevCon. And I also have a BSE 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 mail wires in the wild and combining it all and focus on this presentation on the extension land. I also love to DJ and party, so check out also my mix cloud 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 two 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 this extension with XSS, UXSS, etc. The second reason is that, well, extensions are cross-platform, of course only for the desktop, but a cross-platform. They are generic in a sense, this just JavaScript malicious thing to develop and they have so many more permissions than just regular sites or even, you know, render or exploit and stuff like that. They have permissions to access any origin sometime and they can control the entire browser among 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 in research. So the syllabus we have contains a couple of subjects. First of all, I'm going to introduce you to 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 services I observe are also applicable to many other platforms as well. Next, I'm going to tackle the 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 you how I managed to jump from one good Chrome app which seemingly doesn't do nothing in your computer, just open TCP sockets and kind of that it and from there to really own the browser by owning and pulling the Zotero extension, managing to jump from one Chrome app to another. After that, I'm going to explore VINUM and reach UxSS in VINUM because of some communication interesting problem and I will finish with developing and implementing my own extension rootkit and I tell you how to really modify any good extension that is previously installed in your PC to make all of these extensions go bad. I'm excited. Let's get started. First thing first, when I tackle the extension world, I tackle, of course, the extension autonomy and I reach to observe the multiple layers inside the extensions themselves. Extensions actually include a couple of, well, in a high-level manner, they include a couple of components. The first component is the content strip. The content strip is actually the extensions font and it includes a specific type of component 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 strips are loaded, but compared to the background scripts, the content strips 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 strips are gone. The background is actually the back end of the extensions. There is like one dedicated process which is really cool and is like behind it all and it manages all the things related to the extensions, main APIs and it has many more APIs that are accessible and also it can do more things compared to the front end content strip and it actually communicates the back end scripts and the content strips communicate between each other. If you know maybe Chrome, it's considered to be like the content strip is the renderer process which is in every site and the background strip might be like the Godfather process which is like the browser context which controls these tiny content strips in a sense. Cool. And at least but not last, we have the extension there 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 our 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 scripts, what are the content strips, 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 categorized directory, I mean by that directory that includes all the hashes, shawans that are signed by the public key of their extensions developer or the web store dependent from where you have downloaded this extension from. And the most important point to know about it is that every time you open an extension or 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 come automatically check the signatures for extensions dynamically. Cool. So let's go for the manifest autonomy. The autonomy of the extensions include these parts. 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 defined which are the background, whether it's persistent or not. Usually, most of the background is persistent, meaning the process runs all the time of the background process, content strip with all the definitions inside of them. And one of the most important things inside the content strip is actually the sites that are matched with. So for example, if you go to Google, you don't automatically load all the content strip for all the extensions, you just load the content strips 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 strip, and that will tell the browser to load this content strip 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'll 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 iLevel overview. So you can see the iLevel diagram here, and communication-wise and iLevel-wise, you can see that 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 all the DOM HTML elements of Google, the page sweeps of the Google sites, and many more that are loaded are accessible, of course, to this DOM, but not just these page sweeps, but also the content strips and all the other sides of the extension itself. So the extension is also accessible to the DOM, of course, if it should be loaded in this site, and the content strips can access the DOM page of these Google sites. The content strips, which are the font that I already told you, use messaging platform to communicate to the background, to the back end of the extension itself. So the background page is the background context of the extension, and it doesn't directly communicate with from the site, only, well, mostly indirectly by the content strip itself. So this is like the all communication between these things in the extension world. So a quick, maybe reminder, maybe example for a couple of you, content strips and background strips. 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 strips 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 web request proxy. So it just adds specific hook to the web request 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 routine 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 the DOM changes in events like extension, the content strip can intercept and hook their own click events on focus. They can search for specific divs 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 from the minds of the content strip 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 its manifest 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 for form cross-origin messaging or maybe many more features that you can have. So this is like the three main options I've been tackled in the website versus extensions, content strip, communication routines. So how about, well, I talk about content scripts, how about the background scripts? So the background scripts have cool way of communication in actually many other and non-suspectable ways. So first of all, there is the web request proxy. The exact web request proxy actually handles request and also the responses from the server side. So if we are maybe a malicious server wants to attack in a specific extension, we can maybe inject headers and or specific response that will be analyzed through 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 an indirect way with the background scripts. Another way for the background script 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 can query the info, the data, cookies and much, much more. And we can affect them. Of course, if you control specific sites, we can make a user access to these sites. And the last thing, which is not the web accessible pages, it's a new and a cool feel. 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 doesn't, I don't mean just embed an iframe of this extension page, but also like really communicate with the background scripts through specific websites. So when you open specific websites, that the extensions defined as a valid one and an extension like trust on these sites, it can actually use the site to send messages to the background. So for example, in the following, in the following screen, you can see that if I surf 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 open, is fully open to me to access 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 have communication between them. And it's, well, it can includes 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 or fake maybe a new website and open a new tab and like fake this communication. So all what I showed you in the website communication is available, but also more things are available sometimes to 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 is API is available to you as remote extension. The other thing is also TCP and UDP connection is dependent on permissions, whether you can open TCP server, TCP socket and much, much more. And well, for example, let's say I'm, I want to do an injection from one extension to another extension. And the way I can do it is actually with this externalable connectable fins. What I can actually do is to make the first extension to inject a code into a legitimate site. So the second extension will actually think that this extension and this code that was injected in this site is actually is 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 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, you know, 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've been tackled the Zutera extension. Zutera extension is a popular academic extension commonly used to organize citations and share research. It works really and suits completely with the Zutera desktop edition and the Zutera desktop edition save your data locally on the PC and it's plugging together usually as their extension and the Zutera desktop, not always. Many people actually use only the Zutera extension because it's easier to use. You don't need to configure anything really easy and they communicate the desktop version and the Zutera 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 that I'm going to exploit this kind of thing and try to manage to run JavaScript code inside Zutera extension. So I have also found that there is the Zutera translators. Zutera translators are cool features. Well, more than 500 JavaScript translators that can get executed every site you enter within the Zutera extension. Of course, they are really susceptible to supply chain attacks. They are like open source and inside your public GitHub in the Zutera 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 helped me to run code. They helped 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 the Zutera 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 Selavi. So it's perfect to maybe try to manipulate and maybe try, I don't know, open and listen to specific port, listen to localhost maybe. Can we do these kind of things? Well, apparently, yes. We can actually put new listener on the localhost. We can do it by, well, of course, my legitimate MAPI Chrome app. My MAPI 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 has some more capabilities. One of these capabilities is to open TCP server on, well, on a high port, of course, but it's actually good enough for me. I just open a new port on this, put a listener and send a new JavaScript and execute code on the content scripts inside this terror extension. So this old mechanism and the code is being run, after all, is actually being run in the content scripts context. So the content scripts actually try to run my code. You can see in this presentation that like in these slides, you can see the eval, the eval considered 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's 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 content, 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, content script itself, let's, well, let's be more greedy, right? Let's, the content script, it's fine, but it's not persistent. We have a little bit of problems. Let's try to attack also the background strips, right? So from the content strip 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 sweep, 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, you know, easy peasy, let's go from the evas and, you know, the bad things that are doing in the background and try to trace back and found the attack surface that is reaching there and actually found something. So in the Zotero records, there is an interesting info relates 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 the next, 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 downloaded and executed in the background context. So you ask yourself, how can we control these ones, right? So we managed to control these ones because if we are in the content strips, we are 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 and 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 strip to the background strip 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 site permission at all, no site permission at all. And I'm going to show you, it's going to 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 you 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, and while I was speaking it was already doing the injection from content strip to the background script and code was running the background script and send it back to my server. Here you can see I'm searching for something, it will also appear in my site 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 DevTools. I'm not sending anything from this VM context, it's totally Eden. So I'm actually tracing the user from another different context inside the Zotero context and you can see that all the data is being received back to me and I'm fully controlled of this browser by exmitrating data back to my PC. And my code is actually running inside this good beautiful extension, the Zotero extension, and I jump from one extension to another. The mappy extension is actually not relevant now, 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 controlled, nothing in the DevTools, nothing in the network. You can see it all happens in separate VM context and execution. Okay, let's go now to another extension. Let's go to the VM extension. So the VM extension make your browser a VM-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, you know, you 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 link 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 an extension, but it might be a little bit harder thing to do. So let's consider now only a 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 routines and stuff, but includes much, much more. For example, it includes the volume, the bar 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 opened an 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 Vomli bar iframe. The Vomli bar iframe was seemingly the most interesting widget I've been found out. So how the Vomli bar iframe works is actually quite interesting. So the user clicks enter, O and enter, and then the content scripts catch this event, the on click event, the enter event, and adds an iframe. It adds the Vomli bar iframe, and when this Vomli bar iframe is being added, it's not enough. This iframe is actually a widget page from the extension that is accessibility 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 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 Vomli bar iframe. The Vomli bar iframe, because it runs under the page extension, is also accessible to this current secret, the Vimium secret. So it can verify that the one context, the browser that is going to access him and try to communicate with him have the relevant secret. So it verifies also this secret. And after it verifies the secret, 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 contexts. So now the content script and the Vimium Vomli bar communicate between each other, all cool, all good. They know that if I am an attacker, I can actually put the Vomli bar iframe in my site and maybe try to authorize myself, right? But I still need, yes, you're right, I still need to break this Vimium secret. So how does the Vimium secret is being generated? How does the token we've talked that used for authorization is being generated? Well, apparently it's a very, very state of the art random number generation. As you can see here, they just use math dot random. And math dot 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 this secret is contained, well, only 31 bits of entropy, then we can manage to use that and actually do brute force and maintain this brute force to succeed in our operation of breaking this secret. This is like an example of a brute force. We inject our own Vomli bar iframe. We place a new element, a new iframe element. We then set this iframe element to point to the Vomli bar, HTML I showed you. And then we try to authenticate with this to authorize us between this iframe. We use the secret that we want to brute force. For example, in this code, it's the dead beef. So I tried to guess that the secret is dead beef. 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 brute force, but we have a couple of problems I've been tackled with it. First of all, this is not scalable because if the 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 front end. So what I managed to do is actually, well, why not web workers? Web workers is an amazing opportunity to just do whatever you want because they are suitable to run in the background. So when I use the web workers, I trigger the brute force routines from the background of the web workers themselves. So I use the background web workers to actually periodically interval, trigger the brute force routine, which lays inside the context I open, inside the iFrame. So the flow was like web worker triggers at every two milliseconds, the fronted routine that do the brute force attempt and going on and on and on stays up even when 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 I'm an advertisement, I can like place my own things and you won't even notice it and I can run it days and days until you close your browser. So it's really, really cool thing. I use web workers and now we've broken the vomnibar secret. So let's now focus on the vomnibar communication. The vomnibar communication well includes well a couple of things they can do. So I assume now we broke the secret, the fume secret and I'm trying to communicate between this iFrame, this real 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 ints. It does auto completion for things and stuff. Yeah, I don't really care about these things, right? And the last thing it used 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 this 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 in that is that I run code inside this website's 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 if you come to rescue some communication problem, yes, I managed to run JavaScript, cool. This gets into the picture, the communication problem. So how the vomnibar and the JavaScript scheme, so we're trying to find autocompletion, it calls some background script. So the vomnibar iFrame called the context script, the context script called the background script. The background script returns with a send message to the current tab, the result. 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 to him, okay, execute JavaScript. Okay. But what happens actually if we place one more iFrame in this area? So because Vmune is actually run inside all of the iFrame inside current tab and the content scripts are inside every tab inside these iFrames. So if the background context do send message to the content script inside specific tab, it actually sends message to all of the content script inside this tab. And if it does send message, for example, evaluate and execute JavaScript in this content script, 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 concept 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, and you usually don't know which one was actually triggering this send message. Okay. So the reason that it works is that when you place Ender in the content script, the own message, which is the Ender 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 Ender. So that way we can manipulate other content script and inject to them our own data and evaluate inside them our should be messages. So let's see now how it works in the content script and the background script context. And I'll show you the communication between them and 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 to a form a specific iPhone to the background script. After it does that, then the point background script send a message back to this tab. So he sends a message to this tab, we've the send message API. And when it happens, the content strips inside where you can see that I have here two iframes like one iframe and one top frame. So you need to consider that I have in one iframe, which is ABC.com and the top frame, which is the example.com. And when the background send the message, both of them receive the message, the content script that runs inside this iframe runs as well. And also the content stream that is an 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 now 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 pull request and I update 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 side, 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 modify 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, easy thing to do is, well, the reason is that the extension directory is signed. So Chrome software actually verifies and analyze this extension directory and verifies that all the signature in the Ashes for this extension data is the same as it should be. So you can't really change in runtime, even not in afterwards and make this extension be a different one. But you can still think about the scenario where, well, I'm a developer. I'm really a 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 features. 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 unpack mode that helps developers load the extensions without verifying the signatures and without verifying anything regarding the extensions for compatibility and to checks, to check their extensions. So the scenario here is that you manage to run code of a user device. There is a post-exploitation method like, and I propose like a post-exploitation technique which consider installing new persistent JavaScript footage inside your machine. And the way we can actually do it is actually exploit this unpack mode to replace previous extension. The extension will look almost the same. The user won't even notice because its previous extension will work as suggested. All the, I don't know, antivirus and stuff will see that, well, the extension ID will stay the same or it 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, it just replace it without checking 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 modify good extension, you can actually also add any permissions you need. You can also add five 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. You can also run evenly in a separate Eden context. So now I show you how Eden 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 correct, the ID is correct, it all installed correctly. You can see that even if you go to the extension, privacy and the extension privacy area, you can see it 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 this 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, ChromeFins is installing legitimate extension and it's really cool technique to inject malware inside extensions. So finally, I will introduce you my utility, which is the Maltentions. This is like a utility to help you generate for testing, of course, of course for testing JavaScript malware inside popular extensions and actually an extension. This is the GitHub source and it has a lot of techniques. I place 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 in an unpacked mode, whatever you need and it has so many features. So to conclude, first extension can be used for 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 other because it's very hard to find out like dynamic executions and 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 extension 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.