Using fake reviews to find dangerous extensions
krebsonsecurity.com
krebsonsecurity.com
As a maintainer of a relatively popular extension (hoverzoom+, ~360K users) I get business offers all the time [1]. A few of them are pretty good, actually. I'm not surprised that some developers eventually give up and take one of those offers. But I am surprised that there aren't more of these "under new management" extensions, or maybe we just don't know about them.
Many temptations of an open-source Chrome extension developer - https://news.ycombinator.com/item?id=27327892
> This is an open source version of the original HoverZoom extension which is now overrun by malware and deleted from store. In this version all spyware has been removed, many bugs were fixed and new features were added.
Were you involved with the project when that all went down?
1: https://chrome.google.com/webstore/detail/hover-zoom%20/pccc...
1. What rules are being violated by these offers? It is what happens after the sale might break the rules but I can't report someone for having bad intentions.
2. I do not believe Google would be interested in spending even a minute of their precious human time to do any real investigation. If they can't automate the solution then they ignore the problem.
They might be people who were already banned for modifying other extensions into malware, back at it again on a new account. The hint that they're trying the same tactic might be enough to link their previous and new accounts, and then ban them again.
Especially for other extension devs to see who may share similar experiences and helping exposing a pattern of waste-of-time proposals (which I think at that point over values any assumed privacy it was a cold email after all).
Half of those were probably scammers anyway.
That could be very enticing for a lot of developers.
Thanks for sharing this.
An extension developer ought to know the exact purpose of every network request their extension makes, so inspecting network logs is indeed a good plan.
Just remember there are ways to detect if the developer tools panel is open...
Right, but it could be set up to only do that starting six months after installation or something.
Does the Chrome store not require that the dev account associated with these extensions be on the official corporate domains? That would seem like an easy way to prevent spoofing of Fortune 100 companies.
See: https://news.ycombinator.com/item?id=27192997 (no one could actually tell which where legit and which were not)
It's possible that things have changed since I created my account nearly a decade ago, or that somehow I got a pass because google manages my domain's email. But they definitely do not force @gmail.com addresses for all devs.
EDIT: See this Microsoft extension [1] for example. It shows @microsoft.com, which is undoubtedly not managed by google like my little old startup's email is!
1: https://chrome.google.com/webstore/detail/microsoft-editor-s...
You need to go to any google signin page, click "Create account" > "For myself" > "Use my current email instead".
You can then use that to make chrome extensions.
All the counter-examples I could find in the linked thread are Google Mail (for Business), which is functionally the same as requiring a gmail account in that it requires Google to be your mail-provider.
A lot of people in corporations set things up without necessarily understanding what they're setting up. This includes apps. If you're thinking, "Wouldn't Microsoft know how to set things up correctly?" the answer is "Not necessarily". It's not "Microsoft" setting up some app account, it's a random guy on a random team somewhere in Microsoft, who might not have ever published an app before, much less gotten any training or done much investigation into it.
But this is how misinformation spreads. Many people only read it and believe it without looking closer.
We just trust that other people know what they are talking about. :)
... Also I could be wrong, I'm trusting the counter examples in that thread. :D
Simple domain validated publishing similar to Let's Encrypt would be way better for devs and users, but that would require Google and Apple to give up control and that doesn't happen in monopoly markets.
Edit: And Microsoft. Between them those 3 companies are the gatekeepers of almost all (signed) app distribution.
You're putting them in the same bucket, but TFA calls out Google (and not Apple) for good reason.
> Between them those 3 companies are the gatekeepers of almost all (signed) app distribution.
And? I'm assuming you're not saying "software should not be signed", in which case I'm missing your point.
You're right. I'm not saying "software should not be signed". What I'm saying is the current trust industry is providing almost no value.
When I run an application on Windows that passes SmartScreen, all I know is that some company somewhere paid for an EV code signing certificate. In most cases, I don't know who the company is and don't have a way of finding out. That doesn't benefit me at all and most normal users misunderstand it to mean the company is trustworthy when that's not the case.
I've seen enough malware and adware signed with EV certificates that I personally place their value at zero. That's also influenced by my own experience in getting code signing certificates where the process used by CAs for identity verification are not anything official, but seem to be a rigid checklist of items that needs to be followed by someone with no cultural or local knowledge of my jurisdiction. IE: Easy to game once you know the process.
So, for me, the way code is currently signed tells me that someone had $2k USD to start a company and buy an EV certificate. That's it.
When I say that simple, domain validated code signing would be more useful for devs and users, I mean that I'd prefer to have the (ex:) UAC prompt tell me "This application is distributed by example.com" rather than "This application is distributed by Example XYZ LLC". I have a much better chance of determining the trustworthiness of the signer by knowing their domain than I do by knowing their registered business name.
And when I say Google and Apple are worse, I mean they've created systems that are completely opaque. It's "trust us" and they've both demonstrated repeatedly that they aren't worthy of being trusted.
As a specific example for Apple, there was a fake Fall Guys app on their store when it was at peak popularity. The fake app used the IP of the real one to trick users. Starting with the assumption that Apple's capable of ensuring that doesn't happen, you assume it's a legit app. If you expect to see what "website" (aka domain) is distributing the app it gets much easier.
Distributed by fallguys.com vs distributed by fallguysapp.com is the worst IP squatting you'd see and I could visit both sites if I wasn't satisfied enough assuming the more valuable domain is the real app creator.
In addition to that, IP squatting via a domain has a well established set of rules for trademark disputes, so a publisher can take action immediately to protect their trademarks rather than begging Apple or Google to take down a fake app.
The problem with a "good" system is that Apple, Google, and Microsoft have to give up control in order to let publishers self police their IP / trademarks and none of them will do that.
IMHO, anyone doing curation should be liable for IP theft and trademark violations. I have that opinion about _all_ online providers. As soon as they start curating or moderating they should be liable as if they're a publisher / distributor.
Example:
Beth Anderson <beth@monetize-extensions.com> Mon 10:58 AM To: Mostly Spam <dev@x-ing.space>
Hello
I am Beth and I am offering monetization for browser extensions, with everything that is going on our team was extremely focused and productive in creating a way to earn revenue on extensions.
We offer to change default search to Bing or Yahoo on your extension which can earn up to $800 a month per 5000 users. This is a premium product by invitation only and can easily be added to your chrome extensions.
You are might curious to know if it is allowed? And I must say that this is completely allowed! Please reply to this email to discuss this further!
Looking forward hearing from you!
Beth Anderson
Business Development Manager
I feel like this would make a great corporate logo for a discount legal firm on It's Always Sunny In Philadelphia that Charlie would start when high on Elmer's glue.
I get downvoted a lot every time I post this here.
Also Mozilla's own extensions - 'Firefox Multi-Account Containers' and 'Facebook Container'.
I emailed the dev (his email was on the about section of the extension). He told me that the code was no longer public because he was selling it to someone else that wanted to take it over. I had all kinds of red flags from this, so I uninstalled it right away.
Anyway, since you said "Google Play Music" it's no longer relevant is it.
Open source works on the idea that "given enough eyeballs, all bugs are shallow." The thing people forget is the "enough eyeballs" part. As if people are sitting around auditing every sub-dependency of a sub-dependency of React.
In addition, I don't know of any package repository that requires the authoritative source[1] from github to match the compiled/minified/etc. package that is uploaded and published. And I suspect most repos are vulnerable to this.
There are many popular but unloved packages out there.
[1] I'd also point out how incredibly stupidly dangerous it is that the open source community has basically given Microsoft the keys to be the authoritative source for all of open source. No one has learned a damn thing. And, somewhat ironically, Microsoft buying out an entire user base for their own nefarious purposes really fits the topic at hand.
1) Package managers are a huge security risk.
2) Recursive dependencies massively increase that risk.
3) You should check all your dependencies into your repo, or at least some kind of manifest with secured signatures of those dependencies, and never automatically update dependencies.
I see a few things that can improve this situation by quite a lot:
1) Languages should provide an extensive and expressive standard library of some sort, either one bundled with the language, or a tightly vetted and controlled set of first-party dependencies.
2) Package managers should not automatically resolve recursive dependencies, but should force users to manually add all dependencies of any dependency that is added. This additional friction would force you to acknowledge all the risk you are taking on by adding dependencies, and it would force the ecosystem as a whole to reduce the number of dependencies.
Apps provided on any platform by major, trusted vendors are much more likely to be safe. Apple/Microsoft/Adobe might find themselves compelled to add a government backdoor, but they're probably not going to chuck in code to send your credit card number to the darkweb.
As for install random programs from unknown vendors on the Google Play Store, yeah, I'm a bit nervous about that. It would be nice if we could manage trust on such platforms in some way, but all we can do is hope to be on guard at all times. Google clearly doesn't care if you get hacked by a third party, as long as they don't do it directly.
If most of your secure information is handled via web browsers, as is usually the case today, extensions are drastically more risky than arbitrary software, because of the privileged place in the stack they operate.
There are two things that I think would be beneficial: allowing users to easily disable the extension from automatically updating, and allow users to be able to see the source code of the extension directly in the chrome web store. I hope they already have some kind of internal monitoring system for their reviews to set off an internal alert if someone says 'malware' etc and to investigate further.
What?!? This work was done by an independent researcher. Why is google providing account recovery emails to the general public (and therefore attackers)?!?
Edit: fixed typo; replaced “recovery passwords” with “recovery emails”
It doesn't refer to passwords but email addresses.
And Google doesn't have to provide them even the actual address for them to determine that they are identical, they just need to provide something that maps 1:1 with the email, without the mapping.
Developer emails for extensions are public normally, so those being revealed aren't an issue.
On the other hand, someone who is very savvy knows that the permissions required by many/most browser extensions create an opportunity for massive privacy intrusions and security risks.
It's hard to create a business aimed at people who are savvy enough to know what extensions are but not savvy enough to realize what a huge risk they represent.
note: it's also possible to sell to super-unsavvy users, who do not know what extensions are but are willing to install them anyway.
Granted, such a service wouldn't have the resources to review all extensions, but it could probably handle vetting the most popular and updates to those popular extensions. I can even imagine some kind of market that would let a group of people get this service to begin vetting a new extension.
All seemed good and it appeared that people from all sorts of places had been their customers, until I saw one particular review. It was in Latin.
These companies are very bad at being proactive in enforcing their published policies.
edit: I guess the signal "I tried this extension but replaced it with that other one which I like better" would be very informative though
And yes, I think it's much better than reviews that ask for an absolute scale with no context.
Maybe a boolean "would you buy this product again" is the basic question for a review. It's still open to being gamed, but only in one way.
In all seriousness, this is a really interesting technique. Maybe there are analogues for other fake/bot behavior in other contexts.
The data source basically contained account IDs, billing addresses, credit card hashes and whether an account was identified as fraudulent or not.
Using that data, I built a quick GraphDB prototype that showed clusters of fake/fraud accounts. It was simple stuff, but back then said execs were pretty impressed.
I don’t know what came of that because I left shortly after, but it was an interesting little experiment. I had fun building it!
It is possible that we just did a really good job on the justifications, but I have never had a store submission come back with no required changes or clarifications outside of Google.