When extension pages are web-accessible

In the article discussing the attack surface of extension pages I said:

Websites, malicious or not, cannot usually access extension pages directly however.

And then I proceeded talking about extension pages as if this security mechanism were always in place. But that isn’t the case of course, and extensions will quite often disable it at least partially.

The impact of extension pages being exposed to the web is severe and warrants a thorough discussion in a separate article. So here it comes.

Note: This article is part of a series on the basics of browser extension security. It’s meant to provide you with some understanding of the field and serve as a reference for my more specific articles. You can browse the extension-security-basics category to see other published articles in this series.

Attack surface of extension pages

In the previous article we discussed extension privileges. And as we know from another article, extension pages are the extension context with full access to these privileges. So if someone were to attack a browser extension, attempting Remote Code Execution (RCE) in an extension page would be the obvious thing to do.

In this article we’ll make some changes to the example extension to make such an attack against it feasible. But don’t be mistaken: rendering our extension vulnerable requires actual work, thanks to the security measures implemented by the browsers.

This doesn’t mean that such attacks are never feasible against real-world extensions. Sometimes even these highly efficient mechanisms fail to prevent a catastrophic vulnerability. And then there are of course extensions explicitly disabling security mechanisms, with similarly catastrophic results. Ironically, both of these examples are supposed security products created by big antivirus vendors.

Note: This article is part of a series on the basics of browser extension security. It’s meant to provide you with some understanding of the field and serve as a reference for my more specific articles. You can browse the extension-security-basics category to see other published articles in this series.

Impact of extension privileges

As we’ve seen in the previous article, a browser extension isn’t very different from a website. It’s all the same HTML pages and JavaScript code. The code executes in the browser’s regular sandbox. So what can websites possibly gain by exploiting vulnerabilities in a browser extension?

Well, access to extension privileges of course. Browser extensions usually have lots of those, typically explicitly defined in the permissions entry of the extension manifest, but some are granted implicitly. Reason enough to take a closer look at some of these permissions and their potential for abuse.

Extension manifest of some Avast Secure Browser built-in extensions, declaring a huge list of permissions

Note: This article is part of a series on the basics of browser extension security. It’s meant to provide you with some understanding of the field and serve as a reference for my more specific articles. You can browse the extension-security-basics category to see other published articles in this series.

Anatomy of a basic extension

I am starting an article series explaining the basics of browser extension security. It’s meant to provide you with some understanding of the field and serve as a reference for my more specific articles. You can browse the extension-security-basics category to see other published articles in this series.

Before we go for a deeper dive, let’s get a better understanding of what a browser extension actually is. We’ll take a look at a simple example extension and the different contexts in which its code runs.

Hijacking webcams with Screencastify

Everyone has received the mails trying to extort money by claiming to have hacked a person’s webcam and recorded a video of them watching porn. These are a bluff of course, but the popular Screencastify browser extension actually provides all the infrastructure necessary for someone to pull this off. A website that a user visited could trick the extension into starting a webcam recording among other things, without any indications other than the webcam’s LED lighting up if present. The website could then steal the video from the user’s Google Drive account that it was uploaded to, along with anything else that account might hold.

Screencastify is a browser extension that aids you in creating a video recording of your entire screen or a single window, optionally along with your webcam stream where you explain what you are doing right now. Chrome Web Store shows “10,000,000+ users” for it which is the highest number it will display – same is shown for extensions with more than 100 million users. The extension is being marketed for educational purposes and gained significant traction in the current pandemic.

As of now, it appears that Screencastify only managed to address the Cross-site Scripting vulnerability which gave arbitrary websites access to the extension’s functionality, as opposed to “merely” Screencastify themselves and a dozen other vendors they work with. As this certainly won’t be their last Cross-site Scripting vulnerability, I sincerely recommend staying clear of this browser extension.

Update (2022-05-25): Version 2.70.0.4517 of the extension released today restricted the attack surface considerably. Now it’s only five subdomains, run by Screencastify and one other vendor. Update (2022-05-31): Screencastify reduced the attack surface further by no longer granting websites access to the user’s Google Drive. And as of version 2.70.1.4520 all five subdomains with privileged access to the extension are run by Screencastify themselves. As far as I can tell, with these changes the issue can no longer be exploited.

Adobe Acrobat hollowing out same-origin policy

It’s unclear whether all the countless people who have the Adobe Acrobat browser extension installed actually use it. The extension being installed automatically along with the Adobe Acrobat application, chances are that they don’t even know about it. But security-wise it doesn’t matter, an extension that’s installed and unused could still be exploited by malicious actors. So a few months ago I decided to take a look.

A PDF file displayed in the browser. The address bar says: Adobe Acrobat. Adobe Acrobat icon is also visible in the browser’s toolbar.

To my surprise, the extension itself did almost nothing despite having a quite considerable code size. It’s in fact little more than a way to present Adobe Document Cloud via an extension, all of the user interface being hosted on Adobe’s servers. To make this work smoother, Adobe Acrobat extension grants documentcloud.adobe.com website access to some of its functionality, in particular a way to circumvent the browser’s same-origin policy (SOP). And that’s where trouble starts, it’s hard to keep these privileges restricted to Adobe properties.

Companies don’t usually like security reports pointing out that something bad could happen. So I went out on a quest to find a Cross-site Scripting (XSS) vulnerability allowing third-party websites to abuse the privileges granted to documentcloud.adobe.com. While I eventually succeeded, this investigation yielded a bunch of dead ends that are interesting on their own. These have been reported to Adobe, and I’ll outline them in this article as well.

TL;DR: Out of six issues reported, only one is resolved. The main issue received a partial fix, two more got fixes that didn’t quite address the issue. Two (admittedly minor) issues haven’t been addressed at all within 90 days from what I can tell.

Party time: Injecting code into Teleparty extension

Teleparty, formerly called Netflix Party, is a wildly popular browser extension with at least 10 million users on Google Chrome (likely much more as with Chrome Web Store anything beyond 10 million is displayed as “10,000,000+”) and 1 million users on Microsoft Edge. It lets people from different location join a video viewing session, watching a movie together and also chatting while at it. A really nifty extension actually, particularly in times of a pandemic.

Screenshot of the extension’s welcome page, asking you to choose the streaming services you have an account with. The available choices include Netflix, Hulu and Disney+.

While this extension’s functionality shouldn’t normally be prone to security vulnerabilities, I realized that websites could inject arbitrary code into its content scripts, largely thanks to using an outdated version of the jQuery library. Luckily, the internal messaging of this extension didn’t allow for much mischief. I found some additional minor security issues in the extension as well.

Skype extension: All functionality broken? Still exploitable!

One of the most popular Chrome extensions is Skype, a browser extension designed as a helper for the Skype application. Back when I reported the issues discussed here it was listed in Chrome Web Store with more than 10 million users, at the time of writing more than 9 million users still remain. What these users apparently didn’t realize: the extension was unmaintained, with the latest release being more than four years old. All of its functionality was broken, it being reduced to a bookmark for Skype for Web.

Yet despite being essentially useless, the Skype extension remained a security and privacy risk. One particularly problematic issue allowed every website to trivially learn your identity if you were logged into your Microsoft account, affecting not merely Skype users but also users of Office 365 for example.

Last week Microsoft, after a lengthy period of communication silence, finally published an update to resolve the issues. In fact, the new release shares no functionality with the old extension and is essentially a completely new product. Hopefully this one will no longer be abandoned.

Screenshot of a browser window with Skype extension icon. The extension pop-up is open displaying two menu items: Share on Skype and Launch Skype

Writing my own build system: Coupling gulp concepts with modern JavaScript

I’ve been using gulp.js as the build system of choice for my browser extensions for a while. Last week I suddenly felt an urge to develop something better, and now I have PfP being built by my very own build system. Did I suddenly succumb to the NIH syndrome?

Well, I believe that I have good reasons to develop something better than gulp. And the time investment is quite moderate given the time already sunk into maintaining build configurations. At least I hope that this won’t go the way of this xkcd comic.

While I still like gulp a lot, its reliance on Node streams turned into a significant downside. It’s a nice concept in theory: something generates a stream of files, and one can add various processors to manipulate the stream and bring it into the shape you want. Yet stream manipulation is just complicated enough to be a hurdle. So you rely on gulp plugins to do it.

And gulp plugins are a very considerable chunk of my dependency hell. Unlike the actual tools I use which are usually popular enough to be well-maintained, the plugins to integrate them with gulp are typically developed by a single person. Even if that person keeps updating their plugin, the updates often enough don’t keep up with the development of the tool and/or introduce subtle breakage. Worse yet, some tools cannot be used because no well-maintained gulp plugins exist for them.

This is the main issue being addressed here. While at it, I realized that some additional improvements can be made. In particular, tasks can easily be made more powerful. And gulp lacks two important helpers that in my opinion need to be integrated properly: removing and renaming files.

How did LastPass master passwords get compromised?

A number of LastPass users recently received an email like the following, indicating that someone else attempted to log into their account:

Email with the LastPass header: Login attempt blocked. Hello, Someone just used your master password to try to log in to your account from a device or location we didn't recognize. LastPass blocked this attempt, but you should take a closer look. Was this you?

The mail is legitimate and has been sent out by the LastPass service. The location however was typically very far away from the user’s actual location, e.g. in a country like Brazil or India. Yet this isn’t merely an attempt to guess the password, as LastPass will only send a mail like this one if the correct master password is provided in the login attempt.

One affected user created a thread on Hacker News and at least a dozen others chimed in with similar experiences. This indicates that a large-scale attack is underway, with the total number of affected users being quite significant.

As online password managers go, a user’s master password is the most critical piece of information. So the important question is: how do the attackers know the master passwords? There are some explanation being discussed: credential stuffing, phishing, malware, LastPass compromise. As I know a thing or two about LastPass, I’ll write down how likely these are and why.

TL;DR: It appears that LastPass infrastructure has been compromised, all other explanations being rather unlikely. And, surprisingly, it isn’t given that the attackers actually know these master passwords.