 Hi everyone, I'm Tomer Cohen and I work at Wix.com, currently leading the R&D security team. Me and my team are responsible for all Wix production systems, operations, security, including infrastructure, application, practically everything. And I'm here to talk about how to create a botnet by abusing Chrome extensions or browser extensions in general. So I'm going to start with my personal experience with bots. The first challenge that me and my team had with bots was on April 2016. It was a regular day in the office when suddenly the signup graph, just a second. Okay, I'm good. So suddenly the signup graph which indicates that a lot of users, new users sign up to Wix had a dramatic increase. Now we're familiar with this kind of attacks so we checked and we saw that the requests are not originated in one address or one country. But in a lot of sources and this is what we call a bot attack. Now what about bots? So according to Imperva, bots make the majority of the traffic on the internet today. And most of the bots are bad bots and most of the bad bots are impersonators. Impersonators are bots that come to re-applications and fake the activity of real humans. This causes a lot of headaches to internet companies because these bots are very hard to distinguish between these bots and legit traffic. Yeah, we were there. Okay, so after seeing, I am saying that we are under a bot attack, we started to investigate and we saw three things. The first thing that we saw is that most of the increase is originated in Latin America countries and all these clients come with Chrome browser. Now this is weird and we kept investigating. The next thing that we saw, we've noticed, is that for some reason the sign up requests to our server come from a frame, a week's sign up form within Facebook. For some reason. We didn't know yet what was the reason for that. We'll see in a second. The third thing that we've noticed is that now just a word about weeks. Weeks is a website creation platform. Everyone can come and create their own website for free. So what we've noticed is that these suspicious users, they sign up to a new account and then only 10 seconds after the sign up event, we see that they publish a new week's website. Now this is obviously weird because people don't tend to design their website in 10 seconds and publish it. So now we had a pattern we knew what to look for. So we went to one of these accounts and saw the website that was published. And this was the website that was published in all these accounts. And here it is in English. This page says that if you want to see who viewed your profile on Facebook, the same old scam, you can click on start and download a Chrome extension for doing that. Now if we click start, we actually get to the real original Google Web Store and see this extension called Viad 30 something. So we understood that there is connection between the bot attack that we are experiencing and this malicious extension or this extension at the time. So we started investigating what's inside the extension. It was very hard because the code was highly obfuscated. We got help from a lot of guys including PerimeterX, it's a bot protection company that we work with. And this is what we found. This is what the extension does. Firstly, it injects code into Facebook tabs. Now Chrome extensions with pop-up permissions have the ability to inject JavaScript code to any open tab by the user and also to control tabs, create new tabs and everything. In this case, the attackers used it to inject code into the Facebook tab. Why Facebook tab? I guess because everyone is on it and there are other reasons that we'll see in a second. The next thing the extension does is open a Wix iFrame inside using the injected code to Facebook. Inside Facebook, it opens a frame and loads Wix signup form and from this frame, from within the thread frame, it sends the signup request to our server. My question here is why would they need to open a frame? Why wouldn't they just inject the code and send the signup request to Wix? Chrome extensions are not enforced with the same origin policy. They can send the request from Facebook to Wix. The answer here is that here in Wix, we do have bot protection mechanisms and it has some features. So if that attacker just, if we just send the signup form from just any tab, this will fail because you don't have the right cookies, headers, tokens, whatever that you need to fetch from the signup form before you send the actual signup request. However, if you somehow open a frame with the signup form, like in our case inside Facebook, and you send the signup request from within this frame, it succeeds. So the attackers actually did that to bypass our bot protection mechanisms because they knew that they wouldn't be able to send the request straight from other tabs. They opened the frame. Now, I remind you that this frame is transparent and the victim user does not notice anything while he signed up to Wix and publish a new website. Okay, let's go back to the extensions across affection. We already saw that it injects code to Facebook tab and then it signups to Wix. Next thing it does, it's like we saw, it formed the account created in Wix. It publishes a new Wix website. Now, all these websites lead to the same page, the attack page that we saw earlier. Now, what it does, it takes the newly created website, the URL of the website that was created and send it using Facebook messages to all the victim's friends on Facebook. This is how the malware is distributed. Lastly, these guys were rude enough to grab the victim's Google authorization token and submit a review in the Google Chrome extension web store of five stars. So they have really good reputation for their malicious extension. Cool. Now, my next question is why would this attacker even need Wix on the way? Why wouldn't he just inject the code to Facebook and then use Facebook Messenger to distribute the URL of his attack page? I mean, he has already an attack page. Why would he need Wix on the way? So the answer here is that Wix was used to distribute a bot. Wix was actually here as supplier of disposable URLs. Every victim that is infected creates a new website, a new attack URL that leads to Wix. And then it was much harder to Facebook to detect this attack because all the URLs were different. There wasn't a common malicious URL that was sent in these requests. So the attacker basically used Wix's reputation in order to distribute his malware. And what we have discussed so far is only the infection phase of this attack. Obviously, these bots are then used for a lot of things that they all lead to the same result money for the bot masters. So after they infect all these bots using Wix or other platforms, they can use them later. These bots, they have a command and control for these bots we'll see in a second. They can send, they can run DDoS attacks and spam and run other attacks. They can also put these bots for rent and then gain money for these attacks as a service. We just saw a campaign of bot infection using com extensions. Let's see another one. So it took us some time but we stopped this attack. And two months later there were news about a new attack and this is how it looked like. It says Facebook common tagging malware spreading via Google Chrome. If you receive a Facebook notification regarding a friend tagging you, be very cautious about it. Now this attack was called, was named Tag Me If You Can by Kasper Skilep's researcher in Donau. And when I read his report, his very detailed report, I knew that it were the same attackers that attacked Wix two months before. How did I know? Let's see how this attack worked. So first, a victim gets a notification on Facebook saying that some friend of his of him tagged him in a comment. When the victim clicks this notification, after a small warning of Facebook saying that you are going out of Facebook, a JSE file is immediately downloaded to the victim's browser. Now JSE files act like executable on all Windows machines. So after if the victim clicks on this JSE file, a malware is running causing Google Chrome to crash. Then it copies the Google Chrome process file, the exe file, and create a new Chrome exe file with a Chrome extension installed on it. This is a malicious extension, similar to what we saw before on Wix. After the Chrome is reopened, the extension is uploading a new instance of the JSE file to the victim's Google Drive. Then it takes the URL of the newly uploaded file and send this URL using Facebook API, a create notifications with tagging of all the friends of the victim. One of the victim's friends sees the notification and the whole thing runs again, and we've got exponential growth infection process. Now how did these guys manage to create a notification on Facebook that lead to a download of a JSE file? That's a good question, I'm sure you're all asking yourself that. But it's too long for this lecture, so you can find more details in this talk's white paper or in Dona Orr's report about the tag me if you can attack. Now this, I knew that these were the same attackers because there is a very strong pattern here in this both attacks, and this is the pattern. It always starts with the user clicking on Facebook on something. Next thing that happens is that somehow an extension is installed on his browser. In the Wix attack, it was from the Google Web Store. Sorry, in the Facebook attack, it was using an executable JSE file. After the extension is installed, somehow a new payload of the new instance of the malicious payload is created. It can be a Wix website leading to the attack page or just a JSE file that was uploaded to the Google Drive. Unless the extension takes the URL of the newly created instance and send it somehow in messages or comments, notifications to all the Facebook friends, one of the friends clicking it and then we got the whole thing running again. Now these two attacks had more common and more mutual effects. For example, there were a lot of code snippets that were similar and also the attackers used the same domains. So it clearly was the same attacker. Now I want to say that the companies that were abused in these two campaigns are not minor companies, right? This magical bot somehow comes and defeats Facebook, Google and Wix.com bot protection services. All the services that we were talking about, Facebook messaging, Google Drive, Upload and everything has bot protection mechanisms in place. So why common bots fail to bypass these mechanisms and our bot succeeds? So let's ask ourselves for a second, what makes a good bot? So the goal of a good bot is actually to look like human, right? The bot wants the website that is visiting to think that he is a human that is sitting on a computer and surfing the Internet using a web browser, right? So the first thing that this bot has to cope with is JavaScript challenges. Now this is a non-practice in detecting bots. You give them the right JavaScript calculation and they cannot cope with it. In our case, our bot is actually running inside Chrome. So you can challenge it with any JavaScript that you want and he will cope with it successfully. Great. All right, so the second thing here is what I call human context. Human context is to look like a human when you come to do some action. For example, you don't sign up to Wix or any other service before you pass through the sign-up form, right? I mean, a bot that sends a request to sign up because straight to the server is not a good bot. Now in here, we have the ability in our bot to enter inside the context of the user because Chrome extensions has the ability to inject JavaScript code into active user tabs. So if I'm surfing Facebook, the extension can inject JavaScript code into Facebook that will send the Facebook messages from within the Facebook window. And this way, it has a lot of powers in mimicking the regular, the human behavior. This makes browser extensions the perfect bot. It can run in the context of a user and it can cope with any JavaScript. To understand the full capabilities of such extension, let's have a look at the manifest file of the extension, the malicious extensions we just saw at Wix. So this is the manifest file of this extension. You can see in the red frame that the name of the extension, Viad 30, it's a name of extension that already exists in the web store. I guess that the attackers understood that this way they can easily bypass the Google screening process to Google Web Store. Now what we see here under the permission section is this is the most important permission of this extension. It allows the extension to run a cross-origin request to any destination it wants. It also gives that extension the ability to inject JavaScript code into all the tabs. What else? So we can also snatch the user the victim's cookies. This, by the way, includes HTTP-only cookies. And what else do we see here? There's a background script. Now, the background script runs all the time in the background. It doesn't matter what tab you walk on. And let's have a look at the background script of this extension. This is actually the command and control system of this extension. Why? Let's see what it does. First, it adds a listener to any tab that is updated. Any tab that is updated runs this code. It goes to the attacker's server, download a file called data.js. This file includes the commands for the bot. Then it takes data.js and executes it using tab's execute script on the tab that was updated. Now, this is very important because it allows the attacker full flexibility with his bots. His bot does not have static logic. I mean, it's not doing the same all the time. Every time the attacker wants to change the behavior of the bot, he is able to do it. For example, in the Wix Attack, after we have noticed that the websites that are published only 10 seconds after the sign-up event, we started unpublishing websites that had this behavior. And it stopped the attack for about half an hour. And after half an hour, the attacker, using that, changed the logic of the bot. And from this point, bots use randomized timeout between the sign-up event and the site publish. Also, I can create a script, which is tailored for each active tab. So if I'm on Facebook, I can send commands that send Facebook messages. If I'm on Google Drive, I can send commands that upload for us to Google Drive. So we now know that both extensions are very powerful tools for bot masters. But these campaigns that we just saw are very complicated. And I want to ask you guys, how can we make it easier? Because smuggling an extension to Google Web Store and convincing victims to install this extension or running JSE files on victims' devices is very hard and demands cause a lot of effort. I want to think for a second how can we make it easier. So the thing here is that in order to get the abilities of an extension, we only have to have the ability to execute JavaScript in the context of the extension. And for this, we can go to the same old vulnerability we all know or love, XSS. Now, accessing extensions is not a new thing. Guys have shown it in Black Hat in 2012. But I want to show you today that there are still extensions that are vulnerable. Secondly, to show you the idea of using these vulnerabilities in order to form a botnet. The first example is the Adobe Acrobat extension XSS. It allows users to convert any web page to a PDF file. Now, in January 2016, while it had 30 million installations, this is a crazy number, six days, what they did is they automatically installed their extensions on all devices that had Adobe Acrobat installed of them. And only six days after this, a Google Project Zero researcher, Tavis Omendi, found an access vulnerability in this extension. This is his report. And inside the report, you can see a POC of the exploitation code. And what we see here is basically that there is a page called frame.html that if we send to eat a payload in a parameter, he will execute it. And this is how it looks from the frame side. It's pretty straightforward. Here's our payload in request.message. It goes to STR status and then from there as HTML to the title of the page. The problem here is it's too easy. It's that easy that actually CSP content security policy blocks it because it's an inline script. Now, what about CSP? In 2014, Google enforced CSP default content security policy on all extensions. This was a very important move because it saved us from a horror scenario of accessing extensions. And what it does, it prevents common JavaScript injections like inline scripts, eval functions, and you can only load scripts for whitelisted sources. So the problem here is that CSP is a generic policy and developers that tend to be very creative in the way they create XSS in their software. And let's see another example. So I want to show you the AVG web tune up extension. It aims to protect users when surfing the Internet when in fact it has XSS and actually allow hacking this user and this extension is patched and I'm going to talk today about the vulnerable version of it. The same guy, Tavis Omendi from Google Project Zero found XSS in it and in this case CSP fails and I want to show you how. I want to show you why. I'll show a demo in which there's an attack page. Now there's a victim that comes to this attack page and open it and this victim runs the AVG extension on his browser and this is why you see the extension there listening on the attack page. The extension injects JavaScript into the attack page, into any page including our attack page that adds a listener to a window messages. Now our attack page, which we will see in a second, uses a window post message to send the message to the extension in the same page. The extension in turn transfers our payload, sorry, yeah, this is the payload, the post message and the content script in the attack page forward our payload using Chrome runtime send message to its background script. The background script of the extension has access to Chrome API and particularly to the Chrome tabs API and using the update function we can update any tab with any URL that we choose in the original message that we send from the attack page. In our case, we will use beef in order to hook just any tab of the user. For example, the Facebook tab, yes, with the hook. So, just one second, let's show a little demo. One second. I'll show it here. Okay, I'll try to do it this way. It will be hard, but that's right. Okay, what we see here is the attack page. I'm going to turn on this is beef command, command system. You can see that there's nothing here. There are no bots right now. I'm going to turn on the AVG extension. I do it with much caution because it's vulnerable. It's the vulnerable version of this extension. And here's a black hat. What we're going to see is an attack on black hat page. I'm going to refresh it to show you that there's nothing here. Now, I'm going to run the attack page, my exploitation page. And you can see that the black hat page has an alert. And you can see that we have a new hook on this tab. And you can see here that the beef.js file is downloaded from the attacker server. If I click OK, I can see here that the beef agent start to communicate with the CNC machine in here. And here we got the beef bot on black hat.com. So, to sum up, we saw how we can hack extensions and run in the context of these extensions. And as I said before, my final goal is to use this accessibility in order to create bot nets. And this is how we can do it. Once we have the first victim that installed our bot, using beef, for example, we can create an attack page, the attack page URL of the attack page, and send this URL using Facebook messages or other social means to all the friends on Facebook of the victims. If they have the extension installed, a vulnerable extension, we will hack them in the same way using our attack page and install beef on them. If they don't have the friends of the victim do not have the extension, we can always refer them to Google Web Store to download this great, great antivirus tool and then hack it in the same way using our attack page accesses. Summing up, this is what we saw. So, browser extensions make great bots, we saw why. We also saw that, as we speak, there are attackers that use comic extensions in order to create and control their bot nets. We also saw that extensions still got accesses and CSP is not enough in our case because there are many ways to create accesses. And the same infection campaigns that we saw earlier in the weeks in Facebook attack can be achieved using, by exploiting Chrome extensions, accesses vulnerabilities. If you have any questions about this talk, please approach me or you can catch me in this email. Thank you so much.