A cute cover for a dangerous vulnerability.

Dave Bittner: Hello everyone and welcome to the CyberWire's Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities, solving some of the hard problems and protecting ourselves in our rapidly evolving cyberspace. Thanks for joining us. [ Music ]

 

Nati Tal: If you're already there under the hood of Chromium, you find some stuff that looks suspicious or look like vulnerable for exploitation. And one of those things was the use of private APIs. It's like a customization method in Chromium that a developer can use to integrate new capabilities for their web applications.

 

Dave Bittner: That's Nati Tal, head of Guardio Labs. The research we're discussing today is titled "CrossBarking: Exploiting a Zero-Day Opera Vulnerability with a Cross-Browser Extension Store Attack." [ Music ]

 

Nati Tal: So we see this type of customization and we already think that, okay, it's something that needs to be handled extremely with care. And as such, we will probably find some vulnerabilities out there in those areas. So to make sure this is not the case and everything is safe, we started to dig deeper on different Chromium-based browsers. One of those was Opera. And quite quickly, we realized that there are many customizations over there. And this is exactly what happened. We saw those customizations and the use of specific privileges on domains owned by Opera. And we realized that, okay, it works well, but there is a problem there. Because when you do such a customization, you need to be extra careful with protecting your own domains from misuse. One of those kinds of misuse is actually what we found using other extensions, malicious extensions in this case, to abuse or even exploit this type of permissive domains, inject your own code to those domains, and in this method, gain privilege escalation basically on everything that Chromium can offer you.

 

Dave Bittner: Well, before we dig into some of the details here, for folks who might not be familiar with private APIs and what they enable, can you give us a quick explanation of what they are and how they work?

 

Nati Tal: Yeah, let's do this with an example. In this case, there are many types of web applications or custom features that you get with your browser. One of those, as an example, is the Chrome Store. On any Chrome-based browser, even on Google's Chrome, you have a store in which you can see many types of themes or different kinds of new customization for your browser, like extensions. And with the click of a button, get those installed on your browser. So if you think about it, it's not a simple website that everybody can create and develop and offer this button to install an extension. This is something that is more permissive, and this is why embedded inside the Chromium code, there are specific privileges or APIs in this case that allow a click on a website to install an extension. And those are allowed to work only from code that runs on specific domains. In this case, the Chrome Store web app application. Those are basically a web- this is basically a web app API that gives the Chrome Store extra privileges to install an extension on your browser and basically do all other stuff like disable extensions and such. Those APIs are not public. Not everybody can use them. Only those that have the permission to create a web app and deploy it to the domain where Chrome Store is running now. And this is also why they are called private APIs in this case.

 

Dave Bittner: Well, these private APIs are supposed to have certain security functions that go with them. But you and your colleagues started exploring this, and you found some pretty clever ways to get around this. Tell us what you did.

 

Nati Tal: Yeah. Well, as I said before, to execute code using those private APIs, you need to execute this code from the context of a privileged domain like the Chrome Store or any other specific domain that is embedded in the code of your browser. So there are many standard ways to execute your own code from another domain or another context. The most common one that is being abused all around is XSS being able to inject your code or some kind of code into another domain or website. This includes an exploitation of some kind of vulnerability in this code, in this website, which is most of the time hard to find. And there are many state-of-the-art ways to just remove and mitigate this kind of vulnerability from websites today. So we thought about, okay, this is a way that might work. Again, you need to find a vulnerability in any specific web page. But we remember that, again, we are working with extension, and we know extensions very well. And all those kinds of capabilities that are embedded in this concept of extension. And we realized that there is one way to inject your own code using another extension. And after we tested it and tried it out, we realized it's even easier than we thought [laughter]. Basically, all you need to do is use a built-in feature of an extension, which is called content scripting. An extension can actually inject code to any web page you want, as long as you give it the permission to do so. And there are mitigations against using private APIs in this case, because when you execute code in content scripting, it is running on a different content, not the content you want, not the context of the web page. But it has the ability to dynamically change the content of the web page itself. It's like using something that is abusing a feature, basically, that is not there for this specific need. So what we did was to inject the code into the actual page and basically create, dynamically create a script inside the original web page. And they're deploying our own code. So this way, our code, which is a malicious code in this case, is being executed from the context of the permissive domain. And all was done with simple, like, one-liner in our malicious extension.

 

Dave Bittner: Well, Nati, you're not giving yourselves enough credit here, because it wasn't just any extension that you all created here. Tell us about the extension itself.

 

Nati Tal: [Laughs] Yeah. I'll start from the beginning. In this specific research, we thought about, again, there are POCs and we create those. And those basic POCs, they are not so, you know, like, interesting or clever. In this case, we wanted to extend our research not only to the specific vulnerability we found but also on the basic methods used today to exploit it. And to show the people, the researchers, and the community how easy it is also in other matters to deploy a malicious extension, not only for this kind of vulnerability but any other kind of malicious activity. So what we did was actually deploying a malicious extension titled Puppies, I think was the name [laughter]. What it did was something like the benign feature of just creating or rendering cute puppies all over your screen.

 

Dave Bittner: Right.

 

Nati Tal: Something that is, like, cute and it doesn't seem malicious in any way.

 

Dave Bittner: No, sign me up. Sign me up, Nati [laughs].

 

Nati Tal: Yes, exactly.

 

Dave Bittner: Just to be clear, this is an extension that when you install it, when you go to whatever screen in your Opera browser, in addition to the content, you get a picture of a cute puppy. So what could be dangerous about that?

 

Nati Tal: Yeah, you can even drag it and put it on different places and such [laughter]. [ Music ]

 

Dave Bittner: We'll be right back. [ Music ]

 

Nati Tal: What we wanted to demonstrate in this case was that even a benign extension like this, the cute puppy and every other thing you see out there, like color pickers or stuff like that, utilities, basically they all share the same permissions and power of extensions of this entire ecosystem. And those can be abused or even exploited in this case for other users like exploiting a vulnerability in Opera. And not only that, the case with Opera was a bit different because Opera, they have their own store for extensions, and extensions on their store are being reviewed quite deeply and quite professionally because they're actually reviewing the source code of every extension they allow on their store. But this is also the reason why their store is smaller, much smaller than the one with Google's home. And when you search for something, for example, if you want a cute puppy on every website you browse to and you search for that on the Opera store, you can find it. But it suggests to you, okay, if you can't find it here, go to the Chrome store. We allow you to download and install extensions from there. So, okay, we can't add this kind of malicious extension to the Opera store because they will see our abuse right there in the code because they are more aware of their domains and the kind of APIs they are using. But what if we just add it to the Chrome store? They have no idea what kind of domains are more permissive for Opera or something like that. And, again, those are cute puppies. Why not allow those to be uploaded to the store? So then we realize that it's exactly what we see out in the wild on a daily basis here at Guardio. Different extensions, utilities, and ad blockers even that look all the same with different variance in, you know, in description, in the icon, and stuff like that. But underneath, they are all malicious extensions that do creepy stuff like search hijacking and taking your cookies and hijacking your accounts. And they all have this narrative of utility you need or want. So we realize that if those extensions go there, we really need to understand how easy it is or why it is so easy to use this kind of method in deploying malicious extensions. So we tried it ourselves. And we just created a simple landing page for this Puppies extension with privacy notice and terms of use and everything that is needed to create this kind of extension and get it approved in the Chrome store. It took us around, I think, 20 minutes overall using AI to create the description and images and icons and everything, even part of the code, just to make it more reliable as a puppy extension. And after we uploaded it, like 24 hours later on, we got it approved and it was online on Chrome store. So not only that we discovered a vulnerability and an exploitation method that we, of course, disclosed to Opera and got it fixed before we published it, of course, but also managed to display or to alert all the community about how easy it is to deploy those kinds of malicious extensions and create, you know, the entire flow, the entire chain of exploitation from creating this code, getting it uploaded to a reputable place like the Chrome store. And from there, quite quickly abusing it in the wild, you can use many kinds of modernizing techniques to just propagate this kind of extension, get it on pop-ups and stuff like that and by users and eventually have full control on all Opera browsers in this case.

 

Dave Bittner: Well, you mentioned that you did reach out to the Opera team and they were quite responsive to your research.

 

Nati Tal: Yeah, yeah. Actually, it's not our first time disclosing an issue to Opera. So we are already quite familiar with their engineering team and we have close relationship and we talk like on a daily basis doing this type of research and our analysis and stuff like that. Our initial disclosure to them was something that we called My Flow. It's quite similar because in this case they had their own feature where you can just drag and drop files from your Opera browser on your Android device to your computer, to your desktop and so forth. And one of the APIs there was to download the file and execute it on your system. And using XSS in this case, we managed to just with zero click get your browser to download the file executable and execute it out of the Chrome- out of the browser context entirely on your OS. And of course, again, all those kinds of disclosures are full disclosures. We talk to them and get the POC sent to them. So we also discussed with the Opera engineering about how they are going to mitigate this kind of vulnerability. And one thing that we suggested was just to remove the capability of executing extensions or content scripting on those kinds of permissive domains, which is basically what we saw that Google and Chrome are doing on the Chrome store itself. So first thing to do is just disable content scripting on those domains. And this is exactly what they did. It took them like a few days to code this kind of fix, get it deployed and tested. And it was deployed to all users in a matter of two weeks, even less. And of course we gave time for the propagation so all users will be safe. And only then we published our research.

 

Dave Bittner: Well, it's definitely interesting research but also fun. I have to say, if you're into puppy puns, you will enjoy reading through the research. It's a good read.

 

Nati Tal: I just had to. Like, it was all over there. I just had to.

 

Dave Bittner: Yeah. Why not? Why not [laughter]? Research doesn't have to be dry. It's good to make it fun and good to read. [ Music ] Our thanks to Nati Tal, head of Guardio Labs, for joining us. The research is titled "CrossBarking: Exploiting a Zero-Day Opera Vulnerability with a Cross-Browser Extension Store Attack." We'll have a link in the show notes. And that's Research Saturday brought to you by N2K CyberWire. We'd love to know what you think of this podcast. Your feedback ensures we deliver the insights that keep you a step ahead in the rapidly changing world of cybersecurity. If you like our show, please share a rating and review in your favorite podcast app. Please also fill out the survey in the show notes or send an email to cyberwire@n2k.com. We're privileged that N2K CyberWire is part of the daily routine of the most influential leaders and operators in the public and private sector. From the Fortune 500 to many of the world's preeminent intelligence and law enforcement agencies. This episode was produced by Liz Stokes. We're mixed by Elliot Peltzman and Trey Hester. Our executive producer is Jennifer Eiben. Our executive editor is Brandon Karpf. Simone Petrella is our president. Peter Kilpe is our publisher. And I'm Dave Bittner. Thanks for listening. We'll see you back here next time. [ Music ]