Guideline violation of add-on "YouTube Unblocker"

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: narsil_bz, Assigned: jorgev)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

3 years ago
Posted file response.json
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160210153822

Steps to reproduce:

I installed the add-on "YouTube Unblocker" version 0.6.20 from AMO. Immediately after installing my antivirus software (Avast) warned me of a blocked download from a third-party website associated with neither Mozilla nor the add-on. The download was another add-on which Avast categorized as malware.

Looking at the code of the add-on "YouTube Unblocker", I found the responsible code in the file youtubeunblocker@unblocker.yt\resources\unblocker-api\lib\utils.js following line 138. The function updateConfigFile() downloads files from a web server and places them onto the hard drive of the user. It checks for a "whitelist", so that - seemingly - no other files can be overwritten. The actual file list to update comes as response from the server api.unblocker.yt and is therefor not part of the add-on. The configuration I got from the server is in the attachement response.json (captured with Wireshark).

As you can see in the attachement, the server owner (the add-on programmer?) uses relative pathnames to overcome the "whitelist". This works because the regular expression in utils.js doesn't check for the end of the string. And so the add-on can place files where it should never be able to.

In the case of the attached response.json it is a user.js and a malicious add-on. Both are a clear violation of the add-on guidelines.

Beware: Sometimes the server answers with a different configuration. I couldn't find out, what the pattern is, for the server delivering malware or a clean configuration. But if you google for the URL in the response.json and Avast you find more people getting this malware via Youtube Unblocker.


Actual results:

The add-on created a new user.js (trying to deactivate code signing for add-ons), downloaded a malicious add-on from a third-party website and tried to install it.


Expected results:

The add-on should never overwrite the user.js and try to install malware.
Component: Add-ons → Administration
Product: Tech Evangelism → addons.mozilla.org
Thank you for your report, the add-on has been disabled.

The userscript that is being downloaded flips the signing pref so the unsigned add-on that is being downloaded can be installed. That add-on contains highly obfuscated code. What I could find is that it hides itself from the add-ons manager  and immediately re-enables itself should it get disabled.

Jorge, given the impact and the number of affected users, should we consider blocking the affected version?
Flags: needinfo?(jorge)
See Also: → 1251940
(Assignee)

Comment 2

3 years ago
We'll need to block this one as well, but we'll have to figure out if any external messaging is in order first.
Assignee: nobody → awilliamson
Status: UNCONFIRMED → NEW
Component: Administration → Blocklisting
Ever confirmed: true
Flags: needinfo?(jorge)
The following GUIDs need to be blocked:

youtubeunblocker@unblocker.yt (listed version)
youtubeunblocker__web@unblocker.yt (unlisted version)
On top of that the extra files are downloaded insecurely.
(Assignee)

Comment 5

3 years ago
Blocked:
https://addons.mozilla.org/en-US/firefox/blocked/i1128
https://addons.mozilla.org/en-US/firefox/blocked/i1129
Assignee: awilliamson → jorge
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED

Comment 6

3 years ago
This add-on is completely safe, and has been fraudulently added to the block list. The OP was no doubt some Big Corp giant intending to circumvent the features of this plug-in by filing a bad-faith security report.

I thank you in advance for unblocking this plug-in, and/or telling me how to have my Firefox locally ignore the block list and enable it on my end anyway.
Comment hidden (advocacy)
Comment hidden (off-topic)
(Assignee)

Comment 10

3 years ago
The add-on was confirmed to be unsafe, and has been reported and confirmed as unsafe in the past (bug 1172198).

There are plenty of alternatives available in the add-ons site which you may want to try instead of disabling the blocklist and putting yourself at risk: https://addons.mozilla.org/firefox/search/?q=unblock%20youtube

Comment 11

3 years ago
I know this bug is already resolved, but it reminded me of a similar experience with Youtube Unblocker and shows that this is not a one-time accident, but the authors of this addon are notoriously trying to bundle it with adware. The following documentation is from backup that I made in May 2014, so almost 3 years old.

After installation of Youtube Unblocker (or when the addon was disabled and reenabled) it initiated a connection to api.unblocker.yt and downloaded 2 JSON files (see Wireshark screenshot quidam1.png), which instructed the addon to inject the script https://a.xfreeservice.com/partner/e1NnelDg/?cid=1 into popular search engine websites (script from 2014 is attached as xfreeservice.txt). (To disguise its behaviour, the server only sent the script when the referer was actually from a search engine, otherwise a blank file was delivered.)

Note: Back then Youtube Unblocker had an option where you could agree that search engine results should be modified. But this option was a) enabled by default and b) the unique ID, Firefox profile path, local username and other identifying information was always uploaded, regardless if this option was switched on or off.

Next, Youtube Unblocker connected to the anonymously registered domain googloapis.com (no typo here) to download a second addon (see quidam2.png). This addon had no name and was modified in a way that it did not show up under about:addons, so it stayed invisible to the user. The addon file was called watcher.xpi (attached), was saved in the Firefox profile folder and got enabled without user feedback. As far as I could tell the addon did nothing useful, except repeatedly transmitting information to another anonymously registered domain watcher.aws.sparpilot.com (eg the names of all sites that the user opened, see quidam3.png).
There was no option to disable this behaviour and the privacy statement of Youtube Unblocker made no mention of this second addon. Even after uninstalling Youtube Unblocker, watcher.xpi stayed installed and active. I therefor recommend that everyone who ever installed this addon to check the Firefox extension folder for unknown addons!

Exactly as the bug opener, it was not possible to consistently reproduce this behaviour. When starting from scratch and installing Youtube Unblocker a second time, it received different JSON files and behaved completely normal.

Comment 12

3 years ago
Posted image quidam1.png

Comment 13

3 years ago
Posted image quidam2.png

Comment 14

3 years ago
Posted image quidam3.png

Comment 15

3 years ago
Posted file xfreeservice.txt

Comment 16

3 years ago
Posted file watcher.xpi
Comment on attachment 8726405 [details]
watcher.xpi

Changing the mime type on the .xpi so it won't accidentally try to install for people. Also going to hide it so we're not giving bad ideas to lazy people. Anyone motivated could duplicate what this add-on does, but it would take work if you don't already know how.
Thanks for the additional background information as well as providing that file, that is very helpful to us.

Comment 19

3 years ago
Can you please clarify the kind of vulnerability which has been used to download the malicious add-on? Is it because of the directory traversal inside the config-file? If yes, is there anything Mozilla can do to fix this on their side? (Aka provide a bugfix for Firefox. And treat is a real vulnerability.) Also maybe check/scan if there are more add-ons with this kind of behaviour?

In general terms: Is it really possible (and intentional) that an installed (and maybe also signed) add-on is able to download another add-on (with or without user interaction)? I mean, at all. Is this something which other add-ons also do? I always thought it's impossible and trusted Mozilla to secure its update-mechanism (and let it be the add-on update mechanism).

Btw, just for completeness reasons: This bug 1161259 is actually about the same malware. And it's quite detailed.
(Assignee)

Comment 20

3 years ago
(In reply to Oli from comment #19)
> Can you please clarify the kind of vulnerability which has been used to
> download the malicious add-on?

YouTube Downloader auto-updates some configuration files, downloading them from its webpage. The add-on initially had the capability of updating any files. This was initially overlooked during review, but after bug 1172198 the developer was required to include a whitelist in the add-on so only a set of allowed files would be updated. Unfortunately, thiat new version had a vulnerability that was only detected recently, which is being exploited by the website to download the second add-on.

> If yes, is there anything Mozilla can do to fix this
> on their side? (Aka provide a bugfix for Firefox. And treat is a real
> vulnerability.) Also maybe check/scan if there are more add-ons with this
> kind of behaviour?

No. The actions performed by this add-on are fairly generic (getting a resource via XHR, save a file).

> In general terms: Is it really possible (and intentional) that an installed
> (and maybe also signed) add-on is able to download another add-on (with or
> without user interaction)? I mean, at all.

Yes, add-ons can do that and much more. The WebExtensions API (https://wiki.mozilla.org/WebExtensions) is meant to have stronger checks and boundaries that should prevent most if not all situations like this one.

> Is this something which other
> add-ons also do? I always thought it's impossible and trusted Mozilla to
> secure its update-mechanism (and let it be the add-on update mechanism).

The current add-ons framework gives add-ons a lot of power, which can lead to problems like this. This is why we have code reviews for all add-ons submitted to AMO. In this particular case, the review process failed to catch the bad code. Given all the history and reports that are popping up around this add-on, including what you just posted about bug 1161259 makes it clearer that the developer was intentionally circumventing us with malicious intent.
Comment hidden (spam)

Comment 22

3 years ago
Can I just ask, what exactly did the malicious code do? For instance is it plausible it could get user details such as passwords (from text entry and/or keyring) and bank details?

Also, I followed this on one machine: http://www.ghacks.net/2016/03/03/beware-firefox-add-on-youtube-unblocker-put-on-blocklist/ , which prompts me to ask:
  - Should this be enough to avoid any issues?
  - And why the hell should `xpinstall.signatures.required` (and important stuff like blocklists) be modifiable by a extension without user intervention!?

Sorry, just its possible that a few machines I know about may be affected (mostly from testing it out previously, often finding it didn't work and disabling it...) which is VERY annoying.

Finally, thank you for spotting stuff like this so noobs don't have to :)
Flags: needinfo?(jorge)

Comment 23

3 years ago
Sorry, also could it track browsing history etc?

Last bit should read "noobs like me" xD
(Assignee)

Comment 24

3 years ago
(In reply to wilf from comment #22)
> Can I just ask, what exactly did the malicious code do? For instance is it
> plausible it could get user details such as passwords (from text entry
> and/or keyring) and bank details?

> Sorry, also could it track browsing history etc?

The add-ons we blocked don't do any of those things, but they also have the ability to install other add-ons that could.

> Also, I followed this on one machine:
> http://www.ghacks.net/2016/03/03/beware-firefox-add-on-youtube-unblocker-put-
> on-blocklist/ , which prompts me to ask:
>   - Should this be enough to avoid any issues?

Those instructions look very thorough and should fix the problems, yes.

>   - And why the hell should `xpinstall.signatures.required` (and important
> stuff like blocklists) be modifiable by a extension without user
> intervention!?

That has to do with the way the current add-on model works. Which is why future versions of Firefox won't have a modifiable `xpinstall.signatures.required` preference, and a new, safer add-ons API is being developed.
Flags: needinfo?(jorge)
Product: addons.mozilla.org → Toolkit
Comment hidden (abuse-reviewed)
Due to the amount of off-topic comments I'm restricting the ability to comment on this bug.
Restrict Comments: true
Restrict Comments: false
Comment hidden (spam)
Restrict Comments: true
Duplicate of this bug: 1261912
Duplicate of this bug: 1261913
(Assignee)

Comment 30

3 years ago
A new copy of the add-on surfaced on AMO and is now blocked:
https://addons.mozilla.org/en-US/firefox/blocked/i1212

Comment 31

3 years ago
this new version is also distributed as unlisted addon with the ID "unblocker20__web@unblocker.yt", which should be blocklisted as well.
I've also received reports of unblocker20__web@unblocker.yt and can confirm this is the ID of the add-on currently available on http://www.unblocker.yt/

The code now uses !local.match(new RegExp("^/data/(" + allowedFiles.join("$|") + "$)")) as comparison for the whitelist, which is different than the last version I could find on AMO. I don't have a copy of the last blocked version for comparison though. 

Jorge, can you take a look?
Flags: needinfo?(jorge)
(Assignee)

Comment 33

3 years ago
Thanks, I added it to the blocklist:
https://addons.mozilla.org/firefox/blocked/i1213
Flags: needinfo?(jorge)
A 1:1 clone of v3 has been uploaded as v4.

GUID: unblocker40__web@unblocker.yt
Flags: needinfo?(awilliamson)
(Assignee)

Comment 36

3 years ago
Switched to a regexp block to avoid having to repeat ourselves too much.

https://addons.mozilla.org/en-US/firefox/blocked/i1229
(Assignee)

Updated

3 years ago
Flags: needinfo?(awilliamson)
The author changed the ID once again: addon@gemaoff

The file is identical to v4.
Now there is seemingly an intent to use unconnected guids we should consider if blocking addon@gemaoff is a worthwhile step - the developer can upload versions with a new random guid quicker than we can discover the fork, respond and block it.
(Assignee)

Comment 40

3 years ago
Updated i1229 to cover those cases.
Updated i1229 to remove axtara__web@axtara.com and blocked old versions of axtara__web@axtara.com in https://addons.mozilla.org/en-US/firefox/blocked/i1263 - allowing versions>=1.1.2 to be unblocked.
Updated i1229 to remove suchpony@suchpony.de and blocked old versions of suchpony@suchpony.de in https://addons.mozilla.org/en-US/firefox/blocked/i1264 - allowing versions>=1.6.8 to be unblocked.
You need to log in before you can comment on or make changes to this bug.