1161259 - Extension block request: CSS Helper Pro, {7ec49ce9-375a-4cb7-acdb-9fa990b3249d}

Status: RESOLVED WONTFIX

(Toolkit :: Blocklist Policy Requests, defect)

Description

[[:philipp]]

Attachment: {7ec49ce9-375a-4cb7-acdb-9fa990b3249d}.xpi

Extension name: CSS Helper Pro
Extension UUID: {7ec49ce9-375a-4cb7-acdb-9fa990b3249d}
Extension versions to block: all

Reasons: this addon was reported by a user on irc as it had been installing bypassing the opt-in screen in firefox (from an unknown source). looking into the source code it appears to contain code to inject ads and redirect requests to different websites and contains a misleading name.

Comment 1

[Oli]

Attachment: {9c4e89e7-bcc8-4922-a02c-b2c13d8dfb43}.xpi

The second bad add-on I have found in my Firefox. I think they work together.

If you google the "updateURL" this add-on uses you find this page: https://www.herdprotect.com/post-6879-firefox-malware-detected-hides-itself-as-an-extension.aspx

Comment 2

[Oli]

Just some URLs since the entry point of this add-on is really weird. Every case I find online says there are no binaries found only the add-on appearing mysteriously:

French: http://forum.bitdefender.com/index.php?showtopic=58027
German: http://www.trojaner-board.de/166311-bitdefender-meldet-firefox-oeffnen-virtualcloudnow-com-malware.html
German: http://www.trojaner-board.de/166349-bitdefender-meldet-start-firefox-virtualcloudnow-com-malware.html
English: http://www.reddit.com/r/firefox/comments/33f2kz/firefox_37_crashed_on_open_found_an_apparent/

Of course it's not easy (or almost impossible) to exclude a binary injectin the addon as an installation vector but

Comment 3

[Oli]

(Sry, my Internet crashed.)

*Of course it's almost impossible to exclude a binary injecting the add-ons as an installation vector but for me it seems like the add-ons somehow got installed through Firefox's add-on update mechanism. Is that possible?

Comment 4

[Gregg Lind (Fx Strategy and Insights - Shield - Heartbeat )]

Those are nasty little ones.  Tasty bits:

1. Hides display of itself from about:addons
2. Watch all web traffic.

Nasty!

Comment 5

[[:philipp]]

can you check if those are non-random IDs so they are even feasible to be put on a blocklist?

Comment 6

[Oli]

Attachment: 0.9496733455635479.xpi

Comment 7

[Gregg Lind (Fx Strategy and Insights - Shield - Heartbeat )]

(Hello from User Advocacy!)

Bad news:  Those id's are randomized.   

1.  The `{7` one works by injecting ads.  
2.  The `{9` one phones home to a (dead) server.  (virtualcloudnow.com).  That one also hides itself from about:addons (by injecting a style sheet!).  

No way that either of these would survive signing review, at least :)

Comment 8

[Oli]

I've managed to obtain some more infos:

The installation dates:
March 18th 2015 18:03:39 UTC+1 - "{9c4e89e7-bcc8-4922-a02c-b2c13d8dfb43}.xpi" gets installed (version 0.4)
April 22th 2015 02:10:50 UTC+2 - "{7ec49ce9-375a-4cb7-acdb-9fa990b3249d}.xpi" gets installed (version 1.0.6.5)
May 2nd 2015 03:06:08 UTC+2 - the second add-on gets updated (I was not able to get hold of this version unfortunately.)

But: I have found version 0.5 of the first add-on in my Temp folder (I have checked the "extensions.json" file for the "sourceURI" field). That's the third file I've uploaded before: "0.9496733455635479.xpi".

It's quite interesting if you compare the files:
It looks like the author is up-date with current changes. For example he added his add-on to the "browser.addon-watch.ignore" preference which is quite new afaik. Also in v0.5 the author set "multiprocessCompatible" to true in the "install.rdf" file.

You could maybe find some more IDs using VirusTotal: https://www.virustotal.com/de/domain/bw9210.virtualcloudnow.com/information/

Some more (possible) IDs I've found:
- 66740287-d43f-4f7d-9a7e-d71d506065dd & b721b873-aeff-4fae-b7c3-29cd404ef4ba (http://www.trojaner-board.de/166311-bitdefender-meldet-firefox-oeffnen-virtualcloudnow-com-malware.html)
- f46d542f-b810-405e-ad23-53cbb61de32d (http://www.trojaner-board.de/166349-bitdefender-meldet-start-firefox-virtualcloudnow-com-malware.html)
- cd41cd83-65c8-4aec-843f-92a4d85e5644 (https://www.reddit.com/r/firefox/comments/33f2kz/firefox_37_crashed_on_open_found_an_apparent/)
- fe3d83f9-5cde-4191-93de-c10c114673ce & bce2d402-0036-4b50-87ba-a8f64d9f4cc8 & 2d116663-0500-4c0c-8ee6-9865d783959f & 2c8a477c-1b32-40e5-afd1-83f256853c73 (http://www.camp-firefox.de/forum/viewtopic.php?t=106261&p=892556)

Also I have found (same as on the "camp-firefox.de" thread) a "store.json" file at this place: "[my Firefox profile]\jetpack\[add-on ID]\simple-storage\"
I will upload this file too. It's heavily obfuscated. I've tried using "http://codebeautify.org/jsviewer" but did not have much luck. All I can tell is that it only does inject the ads on the following domains: *.google.com, *.google.de, *.google.ch, *.google.at

Also: It looks like there is always one add-on with some random "legit-sounding" name like "CSS Helper Pro", "Shockwave Flash Compiler Light", "PDF Print Manager Plus", etc and another add-on with no name which is hidden from "about:addons".

All in all: This seems like some more advanced adware and I'm really looking forward to the add-on signing.

Comment 9

[Oli]

Attachment: store.json

Comment 10

[Oli]

Attachment: store_beautified.json

Comment 11

[Oli]

Attachment: {cd41cd83-65c8-4aec-843f-92a4d85e5644}.xpi

Source: https://www.reddit.com/r/firefox/comments/33f2kz/firefox_37_crashed_on_open_found_an_apparent/

This is in fact exactly the same as the "9c4e89e7-bcc8-4922-a02c-b2c13d8dfb43" in version 0.4.
The only change is that it has another "campaignId".

Comment 12

[[:philipp]]

in the light of comment 7 i'm closing the block request as wontfix then. maybe the attached samples can help train the signing mechanism in flagging malicious pieces of code though...

Comment 13

[Tyler Downer [He/Him]]

There may be a pattern that we can detect however, that would enable us to blocklist these add-ons.

Comment 14

[Kris Maglione [:kmag]]

We can block most of them by updateURL. Aside from "CSS Helper Pro", they all seem to be:

https://bw9210.virtualcloudnow.com/addon/firefox/update.rdf?guid=%ITEM_ID%&version=%ITEM_VERSION%

"CSS Helper Pro" has no updateURL, so we might have to block it by name, but I can't find either the name or the ID in FHR.

Comment 15

[Kris Maglione [:kmag]]

OK, at the moment it looks like the "CSS Helper Pro" add-on is using a mix of randomized names and IDs, along the lines of:

CSS Helper, css helper, CSS Manager Pro, CSS Helper Free, CSS Helper Light, CSS Manager Pro, CSS Extension Pro, CSS Notifier Pro, CSS Wizard Pro, css player pro, ...

I don't see any add-ons using this naming pattern with more than a single user, so we could probably manage a regexp block. They're probably using other naming patterns too, though, so I'm not sure it would be worth it.

In either case, we should definitely proceed with the block for the updateURL in comment 14 as soon as possible.

Comment 16

[[:philipp]]

will blocklisting of these malicious addons (that can be targeted according to comment 14) go into action?

Comment 17

[FredMcD]

I have another one for your list. Discovered Hidden Add-on On Firefox. How To Check Yours
https://support.mozilla.org/en-US/forums/support-forum-contributors/711335

. . . . and found an add-on labeled; 1a74de22-379e-4487-878c-58c64d169f73 It does not identify what it is or does. And it is hidden from the Add-ons Manager. . . .

After looking around, I discovered a way to have the Add-ons Manager show the hidden add-on; Type chrome://mozapps/content/extensions/extensions.xul?<enter> in the address bar.

Do you want me to upload it to this post?

Comment 18

[Nada Nix]

I've just discovered this on my Mac. The extension name appears to be random, it's the same as its UUID, {63569564-b42d-4798-a3a6-6906fe62c199}. The updateURL is changed, it's now:

"https://ping.mozversioncheck.com/addon/firefox/update.rdf?guid=%ITEM_ID%&version=%ITEM_VERSION%"

...rather than the bw9210.virtualcloudnow.com reported earlier. Version is 0.6.

No idea how it got there, though my extensions.json says it was installed from a file in my temporary download directory, rather than from an internet URL like usual.

I haven't seen any other unusual addons, hidden or not, such as "CSS Helper" or anything like that.

Comment 19

[[:philipp]]

apparently there is now a version 0.7 of the addon as well

not sure if it's related, but a user with this hidden malicious addon reported symptoms that would suggest that a user.js file is created in order to disable updates (maybe to circumvent the addon signing requirement in future versions): http://www.camp-firefox.de/forum/viewtopic.php?f=1&t=113148

Comment 20

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

I've staged a block for this add-on based on updateURL:
https://addons-dev.allizom.org/en-US/firefox/blocked/p736

I need someone to give this a try and make sure these add-ons are being properly blocked, and other add-ons aren't being incorrectly blocked (metadata blocks haven't been tested enough).

I'll also note that this will have a negative effect for users of older versions of Firefox, per bug 1111728.

Finally, it looks like the blocklisting form validates the URL in the updateURL field, so it doesn't accept regular expressions. I hope the exact match is good enough.

Comment 21

[Christian Riechers]

Attachment: install.rdf of {54b32862-53da-4c8c-b959-0aed0dd95478}.xpi

Comment 22

[Christian Riechers]

I found {54b32862-53da-4c8c-b959-0aed0dd95478}.xpi on my installation of Firefox on Win7. No idea how it got there. It wasn't visible in Add-on Manager, but only in Troubleshooting Information.
Not sure if related, but that installation of Firefox failed to update from v38.0.5 to 39.0.

Comment 23

[[:philipp]]

thanks for attaching that file from version 0.8 - it comes with a new update url again, so this probably means you'll have to be fast to block it efficiently...

Comment 24

[[:philipp]]

Attachment: version 0.9 of addon

version 0.9 of the addon with yet another update url is attached. 
please note that there are continuing reports linking this malicious addon to putting a user.js file into a users profile which prohibits further firefox application updates: https://www.soeren-hentzschel.at/mozilla/firefox/2015/07/11/firefox-aktualisiert-sich-nicht-auf-die-neuste-version-moegliche-ursache/

due to the frequency of this issue in user requests for support this may affect many thousands of installations in the wild.

Comment 25

[[:philipp]]

to recapitulate, we've now gone at least through the following changing updateURLs:
0.4: https://bw9210.virtualcloudnow.com/addon/firefox/update.rdf?guid=%ITEM_ID%&version=%ITEM_VERSION%
0.6: https://ping.mozversioncheck.com/addon/firefox/update.rdf?guid=%ITEM_ID%&version=%ITEM_VERSION%
0.8: https://update.sppiservices.com/addon/firefox/update.rdf?guid=%ITEM_ID%&version=%ITEM_VERSION%
0.9: https://static.cluodformation.com/addon/firefox/update.rdf?guid=%ITEM_ID%&version=%ITEM_VERSION%

Comment 26

[Kris Maglione [:kmag]]

There's nothing effective we can do about this. Someone needs to report it to AV vendors, and we should block add-ons with names or descriptions that look like UUIDs, which should at least take care of some existing installations (and catch some other malware too), but we're basically out of options.

Comment 27

[Kris Maglione [:kmag]]

(Incidentally, DrWeb is the only AV suite that currently catches this on VirusTotal)

Comment 28

[[:philipp]]

so we cannot block this based on the updateURL after all? 
is it possible to assess by fhr data, how widespread this particular malware addon (UUID name & version number 0.8/0.9) is? it would be rather bad if we lose a considerable amount of users on old insecure versions because they are cut off of any further updates because of this (maybe a hotifx addon targeted to those users would be warranted in such a case)....

Comment 29

[FredMcD]

Here is an idea. All / most add-ons are now signed by Mozilla. If an add-on is not signed,
it is auto disabled at install. But the user can enable it if they want.

Comment 30

[Kris Maglione [:kmag]]

(In reply to philipp from comment #28)
> so we cannot block this based on the updateURL after all?

We could continue blocking each new updateURL that we find, but they're clearly creating them at random now that we've begun blocking.

Blocking names that look like UUIDs will take care of all of the existing cases, but I have no doubt that they'll quickly adapt to avoid that block.

> is it possible to assess by fhr data, how widespread this particular malware
> addon (UUID name & version number 0.8/0.9) is?

To some degree. I was planning to run some numbers on Monday.

> it would be rather bad if we
> lose a considerable amount of users on old insecure versions because they
> are cut off of any further updates because of this (maybe a hotifx addon
> targeted to those users would be warranted in such a case)....

I'm not entirely sure what old versions have to do with this.

(In reply to FredMcD from comment #29)
> Here is an idea. All / most add-ons are now signed by Mozilla. If an add-on
> is not signed,
> it is auto disabled at install. But the user can enable it if they want.

Add-ons are already auto-disabled on install, regardless of signed status. Unfortunately, system installers are trivially able to subvert those measures.

We are going to begin requiring user confirmation before enabling any unsigned add-ons, and then preventing them from being installed entirely. But we need to give developers of legitimate add-ons time to get them signed (and often to fix issues which prevent them from being signed), so we're at least two releases away from that at the moment.

Comment 31

[FredMcD]

> (In reply to FredMcD from comment #29)
> > Here is an idea. All / most add-ons are now signed by Mozilla. If an add-on
> > is not signed,
> > it is auto disabled at install. But the user can enable it if they want.
> 
> Add-ons are already auto-disabled on install, regardless of signed status.
> Unfortunately, system installers are trivially able to subvert those
> measures.
> 
Not fully true, I am sorry to say. The two hidden add-ons that got in my Firefox
were not authorized by me, but they were enabled anyway.

Comment 32

[Kris Maglione [:kmag]]

(In reply to FredMcD from comment #31)
> Not fully true, I am sorry to say. The two hidden add-ons that got in my
> Firefox
> were not authorized by me, but they were enabled anyway.

See the second part of my comment.

Comment 33

[Gregg Lind (Fx Strategy and Insights - Shield - Heartbeat )]

(++ on trying to solve this further up the stream.  This bug is very representative of a whole class of Third Party Software that Affects Firefox.  Ugh.)

Comment 34

[[:philipp]]

so i'm setting his to wontfix again

Comment 35

[[:philipp]]

so i'm setting this to wontfix again

Comment 36

[[:philipp]]

Attachment: version 0.11 of addon

attaching the current version of the malware - just for documentation's sake

Comment 37

[Jackie]

Attachment: Another version (probably 0.13)

Comment 38

[Oli]

Wow, it looks like FINALLY the culprit of this malware has been found: bug 1251911
(Yes, during the time of this bugreport I actually had YouTube Unblocker installed with version 0.6.12.) 

And I was right with my earlier assumption that this hidden add-on/malware has not gotten on the system via some binary but using another add-on. So it actually _IS_ possible to download another add-on via an installed add-on and bypass the "would-you-like-to-install-this-add-on"-message. This is really scary imo!