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.
A number of LastPass users recently received an email like the following, indicating that someone else attempted to log into their account:
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.
What’s the worst possible vulnerability a browser extension could possibly have? If the extension connects to a local application, facilitating Remote Code Execution in that application would be pretty bad. But if it’s only the sandboxed browser extension, then granting attackers access to each and every website is probably as bad as it goes. The only way to top this should be making the access permanent, surviving even a browser restart.
Somehow the fun browser extension “Meow, The Cat Pet” ended up in that exact spot. Despite having merely 200 thousand users, it is promoted prominently in the “Fun” category of the Chrome Web Store. Yet up until recently it had a Cross-Site Scripting vulnerability. This vulnerability would have allowed any website to inject JavaScript code which would have executed in the context of websites visited by the user. A one-time visit to a malicious website would have been sufficient to compromise the browser integrity permanently.
As we’ve seen before, shopping assistants usually aren’t a good choice of browser add-on if you value either your privacy or security. This impression is further reinforced by Keepa, the Amazon Price Tracker. The good news here: the scope of this extension is limited to Amazon properties. But that’s all the good news there are. I’ve already written about excessive data collection practices in this extension. I also reported two security vulnerabilities to the vendor.
Today we’ll look at a persistent Cross-Site Scripting (XSS) vulnerability in the Keepa Box. This one allowed any attackers to track you across Amazon web properties. The second vulnerability exposed Keepa’s scraping functionality to third parties and could result in data leaks.
Browser extensions make attractive attack targets. That’s not necessarily because of the data handled by the extension itself, but too often because of the privileges granted to the extension. Particularly extensions with access to all websites should better be careful and reduce the attack surface as much as possible. Today’s case study is Custom Cursor, a Chrome extension that more than 6 million users granted essentially full access to their browsing session.
The attack surface of Custom Cursor is unnecessarily large: it grants custom-cursor.com website excessive privileges while also disabling default Content Security Policy protection. The result: anybody controlling custom-cursor.com (e.g. via one of the very common cross-site scripting vulnerabilities) could take over the extension completely. As of Custom Cursor 3.0.1 this particular vulnerability has been resolved, the attack surface remains excessive however. I recommend uninstalling the extension, it isn’t worth the risk.
Update (2021-11-24): I’ve now looked into Cute Cursors, a competing extension with close to identical functionality. My conclusion is that Cute Cursors is secure, the attack surface is as minimal as it should be. So I recommend any Custom Cursor users to switch.
As readers of this blog might remember, shopping assistants aren’t exactly known for their respect of your privacy. They will typically use their privileged access to your browser in order to extract data. For them, this ability is a competitive advantage. You pay for a free product with a privacy hazard.
Today we will take a closer look at a browser extension called “Keepa – Amazon Price Tracker” which is used by at least two million users across different browsers. The extension is being brought out by a German company and the privacy policy is refreshingly short and concise, suggesting that no unexpected data collection is going on. The reality however is: not only will this extension extract data from your Amazon sessions, it will even use your bandwidth to load various Amazon pages in the background.
Normally, CSS injection vulnerabilities are fairly boring. With some luck, you can use them to assist a clickjacking attack. That is, unless the vulnerable party is a browser extension, and it lets you inject CSS code into high profile properties such as Google’s. I’ve now had some fun playing with this scenario, courtesy of G App Launcher browser extension.
The vulnerability has been resolved in G App Launcher 23.6.1 on the same day as I reported it. Version 23.6.5 then added more changes to further reduce the attack surface. This was a top notch communication experience, many thanks to Carlos Jeurissen!
The cookie consent screens are really annoying. They attempt to trick you into accepting all cookies, dismissing them without agreeing is made intentionally difficult. A while back I wrote on Twitter than I’m almost at the point of writing a private browser extension to automate the job. And somebody recommended Ninja Cookie extension to me, which from the description seemed perfect for the job.
Now I am generally wary of extensions that necessarily need full access to every website. This is particularly true if these extensions have to interact with the websites in complicated ways. What are the chances that this is implemented securely? So I took a closer look at Ninja Cookie source code, and I wasn’t disappointed. I found several issues in the extension, one even allowing any website to execute JavaScript code in the context of any other website (Universal XSS).
As of Ninja Cookie 0.7.0, the Universal XSS vulnerability has been resolved. The other issues remain however, these are exploitable by anybody with access to the Ninja Cookie download server (ninja-cookie.gitlab.io). This seems to be the reason why Mozilla Add-ons currently only offers the rather dated Ninja Cookie 0.2.7 for download, newer versions have been disabled. Chrome Web Store still offers the problematic extension version however. I didn’t check whether extension versions offered for Edge, Safari and Opera browsers are affected.
I looked into the Print Friendly & PDF browser extension while helping someone figure out an issue they were having. The issue turned out unrelated to the extension, but I already noticed something that looked very odd. A quick investigation later I could confirm a massive vulnerability affecting all of its users (close to 1 million of them). Any website could easily gain complete control of the extension.
This particular issue has been resolved in Print Friendly & PDF 2.7.39 for Chrome. The underlying issues have not been addressed however, and the extension is still riddled with insecure coding practices. Hence my recommendation is still to uninstall it. Also, the Firefox variant of the extension (version 1.3) is still affected. I did not look at the Microsoft Edge variant but it hasn’t been updated recently and might also be vulnerable.
Note: To make the confusion complete, there is a browser extension called Print Friendly & PDF 2.1.0 on the Firefox Add-ons website. This one has no functionality beyond redirecting the user to printfriendly.com and isn’t affected. The problematic Firefox extension is being distributed from the vendor’s website directly.
Mind you, I’m not saying that Amazon is currently doing any of this.
Yes, when I wrote that article I didn’t actually know how Amazon was using the power they’ve given themselves. The mere potential here, what they could do with a minimal and undetectable change on one of their servers, that was scary enough for me. I can see that other people might prefer something more tangible however.
So this article now analyzes what data Amazon actually collects. Not the kind of data that necessarily flows to Amazon servers to make the product work. No, we’ll look at a component dedicated exclusively to “analytics,” collecting data without providing any functionality to the user.
The logic explained here applies to Amazon Assistant browser extension for Mozilla Firefox, Google Chrome and Microsoft Edge. It is also used by Amazon Assistant for Android, to a slightly limited extent however: Amazon Assistant can only access information from the Google Chrome browser here, and it has less information available to it. Since this logic resides on an Amazon web server, I can only show what is happening for me right now. It could change any time in either direction, for all Amazon Assistant users or only a selected few.
