1251911 - Guideline violation of add-on "YouTube Unblocker"

Status: RESOLVED FIXED

(Toolkit :: Blocklist Policy Requests, defect)

Description

[narsil_bz]

Attachment: 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 [e-mail]\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.

Comment 1

[Andreas Wagner [:TheOne] [use NI]]

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?

Comment 2

[Jorge Villalobos [:jorgev] (he/him)]

We'll need to block this one as well, but we'll have to figure out if any external messaging is in order first.

Comment 3

[Andreas Wagner [:TheOne] [use NI]]

The following GUIDs need to be blocked:

[e-mail] (listed version)
[e-mail] (unlisted version)

Comment 4

[Daniel Veditz [:dveditz]]

On top of that the extra files are downloaded insecurely.

Comment 5

[Jorge Villalobos [:jorgev] (he/him)]

Blocked:
https://addons.mozilla.org/en-US/firefox/blocked/i1128
https://addons.mozilla.org/en-US/firefox/blocked/i1129

Comment 6

[The Ceej]

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 7

[The Ceej]

(In reply to Jorge Villalobos [:jorgev] from comment #5)
> Blocked:
> https://addons.mozilla.org/en-US/firefox/blocked/i1128
> https://addons.mozilla.org/en-US/firefox/blocked/i1129

It wasn't broken. There was nothing to fix. Now you blocked it. Now it's broken. Now there's something to fix. I thank you in advance for unblocking it.

Comment 8

[The Ceej]

(In reply to narsil_bz from comment #0)
> Created attachment 8724515 [details]
> 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
> [e-mail]\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.

You work for Google. You are attempting to sabotage this plug=in because it thwarts your "regional blocks."  You will not win. They will discover that you're lying and unblock this plug-in.

Also, bad faith fraudulent reports like yours will no doubt result in the ability for the end user to override a blocked plug-in and allow it to run anyway.

Comment 10

[Jorge Villalobos [:jorgev] (he/him)]

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

[Yet Ding]

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

[Yet Ding]

Attachment: quidam1.png

Comment 13

[Yet Ding]

Attachment: quidam2.png

Comment 14

[Yet Ding]

Attachment: quidam3.png

Comment 15

[Yet Ding]

Attachment: xfreeservice.txt

Comment 16

[Yet Ding]

Attachment: watcher.xpi

Comment 17

[Daniel Veditz [:dveditz]]

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.

Comment 18

[Andreas Wagner [:TheOne] [use NI]]

Thanks for the additional background information as well as providing that file, that is very helpful to us.

Comment 19

[Oli]

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.

Comment 20

[Jorge Villalobos [:jorgev] (he/him)]

(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 22

[wilf]

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 :)

Comment 23

[wilf]

Sorry, also could it track browsing history etc?

Last bit should read "noobs like me" xD

Comment 24

[Jorge Villalobos [:jorgev] (he/him)]

(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.

Comment 25

[The Ceej]

Somehow, it's considered abuse for me to give step-by-step, easy to understand instructions on how to circumvent the blocking of this add-on, which I had to figure out myself because nobody was responding to my request on how to do that, but to spam my inbox with 18 unsolicited Emails is perfectly polite.

This is why there hasn't been a good build of Firefox since 3.6. Because of this kind of **** right here. "Rapid release" is just a euphemism for "our last release was so bad, we have to put out another one really quick so you forget about it."

How about just roll back to 3.6 and build off that? How about actually LISTEN to the people who use Firefox... The few that are left anyway... Because **** like this is going to push ME away too.

Comment 26

[:glob ✱]

Due to the amount of off-topic comments I'm restricting the ability to comment on this bug.

Comment 30

[Jorge Villalobos [:jorgev] (he/him)]

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

[[:philipp]]

this new version is also distributed as unlisted addon with the ID "[e-mail]", which should be blocklisted as well.

Comment 32

[Philipp Kewisch [:Fallen][📱📆]]

I've also received reports of [e-mail] 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?

Comment 33

[Jorge Villalobos [:jorgev] (he/him)]

Thanks, I added it to the blocklist:
https://addons.mozilla.org/firefox/blocked/i1213

Comment 34

[Andrew Williamson [:eviljeff]]

There was another semi-clone uploaded, now blocked too:
guid: [e-mail]

https://addons.mozilla.org/en-US/firefox/blocked/i1228

Comment 35

[Andreas Wagner [:TheOne] [use NI]]

A 1:1 clone of v3 has been uploaded as v4.

GUID: [e-mail]

Comment 36

[Jorge Villalobos [:jorgev] (he/him)]

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

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

Comment 37

[Andreas Wagner [:TheOne] [use NI]]

The author changed the ID once again: addon@gemaoff

The file is identical to v4.

Comment 38

[Andrew Williamson [:eviljeff]]

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.

Comment 39

[Andreas Wagner [:TheOne] [use NI]]

The following IDs need to be blocked because of the same issue (using the same code):

addon@gemaoff
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]

Comment 40

[Jorge Villalobos [:jorgev] (he/him)]

Updated i1229 to cover those cases.

Comment 41

[Andrew Williamson [:eviljeff]]

Updated i1229 to remove [e-mail] and blocked old versions of [e-mail] in https://addons.mozilla.org/en-US/firefox/blocked/i1263 - allowing versions>=1.1.2 to be unblocked.

Comment 42

[Andrew Williamson [:eviljeff]]

Updated i1229 to remove [e-mail] and blocked old versions of [e-mail] in https://addons.mozilla.org/en-US/firefox/blocked/i1264 - allowing versions>=1.6.8 to be unblocked.