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 email@example.com\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.
3 years ago
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?
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
The following GUIDs need to be blocked: firstname.lastname@example.org (listed version) email@example.com (unlisted version)
On top of that the extra files are downloaded insecurely.
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
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.
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
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 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.
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.
(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.
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 :)
Sorry, also could it track browsing history etc? Last bit should read "noobs like me" xD
(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.
Due to the amount of off-topic comments I'm restricting the ability to comment on this bug.
Restrict Comments: true
A new copy of the add-on surfaced on AMO and is now blocked: https://addons.mozilla.org/en-US/firefox/blocked/i1212
this new version is also distributed as unlisted addon with the ID "firstname.lastname@example.org", which should be blocklisted as well.
I've also received reports of email@example.com 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?
Thanks, I added it to the blocklist: https://addons.mozilla.org/firefox/blocked/i1213
There was another semi-clone uploaded, now blocked too: guid: firstname.lastname@example.org https://addons.mozilla.org/en-US/firefox/blocked/i1228
A 1:1 clone of v3 has been uploaded as v4. GUID: email@example.com
Switched to a regexp block to avoid having to repeat ourselves too much. https://addons.mozilla.org/en-US/firefox/blocked/i1229
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.
The following IDs need to be blocked because of the same issue (using the same code): addon@gemaoff firstname.lastname@example.org email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org email@example.com
Updated i1229 to cover those cases.
Updated i1229 to remove firstname.lastname@example.org and blocked old versions of email@example.com in https://addons.mozilla.org/en-US/firefox/blocked/i1263 - allowing versions>=1.1.2 to be unblocked.
Updated i1229 to remove firstname.lastname@example.org and blocked old versions of email@example.com 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.