799266 - Blocklist malicious "Mozilla Safe Browsing" add-on

Status: VERIFIED FIXED

(Toolkit :: Blocklist Policy Requests, defect)

Description

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

I was looking into some SUMO reports and I ran into this add-on. It is called "Mozilla Safe Browsing", by "Mozilla Corp." and it replaces your homepage and probably other settings. We need to block it.

However, I also discovered that his add-on uses a randomly generated ID. I haven't seen it repeat yet, so it is apparently generated every time.

Since extension blocks don't have name matches (or at least the admin form on AMO doesn't support it), we need to block it differently. What came to mind was a patch in the Add-ons Manager that blocks all add-ons that have this name. We could also consider a more general approach, but I'd like to address this case in the long term.

Blair, what do you think?

Comment 1

[Blair McBride [:Unfocused] (UNAVAILABLE)]

*sigh* Yet another reason why we really need to overhaul the blocklist, since the blocklist service itself currently only supports matching add-ons by ID. Blocking by name isn't too difficult to add - but it does require an API change. We could also potentially just hard-code a list of patterns.

However, even that wouldn't be very effective for this one :\

Seems the add-on is installed by the Win32/Medfos family of trojans. There's a writeup on it here:
https://blogs.technet.com/b/mmpc/archive/2012/09/10/msrt-september-12-medfos-hijacking-your-daily-search.aspx

Both the add-on's ID *and* name changes - though the name would be from a list, at least. However, the add-on is downloaded by the trojan, so its likely that the list of possible names can/will change.


I managed to find a copy of the add-on - the code I obtained doesn't mess with the homepage, but it does:
* hijack search pages on Google, Yahoo, Ask, Bing, AOL, and AVG
* mess with the URL displayed in the URL bar and status bar

It hijacks search pages by injecting a remote script into the page, which modifies the URLs of the search results to redirect to whatever it wants (presumably all pay-per-click sites, as it spoofs the HTTP referrer too). There's also a separate script injected on non-search Google pages that works to force-enable Google's Instant Search.

The domain it loads the scripts from also changes. However, since the operation of the add-on is dependent on loading remote scripts, we could request that those domains be added to the SafeBrowsing database so they're blocked. For the version of the add-on I inspected, that would kill hijacking of search pages.

Additionally, I think it would be worthwhile to help antivirus vendors detect variants of this - since we can potentially get additional samples via reports on SUMO.

Comment 2

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

Can you attach the XPI?

Comment 3

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: Trojan:JS/Medfos.A - sample 1

Obvious warning: THIS IS A TROJAN. DO NOT INSTALL THIS ON A PROFILE YOU CARE ABOUT.


I've packed it into a .xpi, but it gets installed unpacked into %LOCALAPPDATA%\<ADDON-ID>

I don't know the details of *how* it gets installed - I only got the source code, not the trojan that installs it. Source:
http://www.reddit.com/r/techsupport/comments/z4a3y/the_firefox_extension_mozilla_safe_browsing_2014/

Comment 4

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 669846 [details]
Trojan:JS/Medfos.A - sample 1

Er, in retrospect, lets make this harder to accidentally install...

Comment 5

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Forgot to mention: That Reddit link says that this sample originally was not detected by Microsoft Security Essentials. On my machine, with updated definitions, it is now detected as Trojan:JS/Medfos.A.

Comment 6

[Kris Maglione [:kmag]]

Just for reference, VirusTotal currently has it detected by Microsoft and ESET-NOD32, whatever that is: https://www.virustotal.com/file/dfa637582ed0e76396efe5e3c59c02b95115d37ca26444798cad45d5962f1d40/analysis/1349839345/

Would be nice to get that number higher.

Comment 7

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

I submitted the file to Norton, McAfee, Kaspersky, AVG and Avast.

Blair, can we look into hardcoding a name block as a short term solution? We can at least prevent them from using such a deceitful name.

Comment 8

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: Patch v1

Things I am not proud of: This patch.

It's awful, but: it's safe, minimal, and does the job. So should be ok to uplift quickly to 17, or maybe even a 16.0.2.

It could have been more minimal, but I added a block ID so we can point to a page about why its blocked - I think messaging in this specific case is even more important than usual. However, since the block ID is hard-coded, we need to get a blocklist page up on AMO for this *before* it lands - so we know what ID to use.


Given that the blocklist rewrite likely won't happen for quite some time, the medium term solution to this is bug 800262.

Comment 9

[Dave Townsend [:mossop]]

Comment on attachment 670277 [details] [diff] [review]
Patch v1

Review of attachment 670277 [details] [diff] [review]:
-----------------------------------------------------------------

It's not the worst patch I've ever reviewed

::: toolkit/mozapps/extensions/XPIProvider.jsm
@@ +112,5 @@
>  
> +// Note: When adding/changing/removing items here, remember to change the
> +// DB schema version to ensure changes are picked up ASAP.
> +const STATIC_BLOCKLIST_PATTERNS = [
> +  { name: "Mozilla Safe Browsing",

Do we have a list of actual names in use in the wild? I came across "Translate This!" in my searching.

@@ +114,5 @@
> +// DB schema version to ensure changes are picked up ASAP.
> +const STATIC_BLOCKLIST_PATTERNS = [
> +  { name: "Mozilla Safe Browsing",
> +    level: Ci.nsIBlocklistService.STATE_BLOCKED,
> +    blockID: "i141" }

Does this ID actually match something in the DB?

Comment 10

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

I just added the placeholder block i162 for this.

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

Comment 11

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to Dave Townsend (:Mossop) from comment #9)
> Do we have a list of actual names in use in the wild? I came across
> "Translate This!" in my searching.

Oops, forgot to mention this - Translate This! is also a legit add-on with almost 55 thousand users: https://addons.mozilla.org/en-US/firefox/addon/translate-this/

We could block that by a combination of name and author, but I haven't been able to find enough details on that variant.

So the question is: do we want to land this as-is and do followups, or try to find enough details on other variants and block them at the same time?


> Does this ID actually match something in the DB?

Nope! I was waiting for comment 10 :)

Comment 12

[Kris Maglione [:kmag]]

If we block "Translate This!", I think it would be better to block the name if it doesn't have the ID the legitimate add-on has, possibly also if doesn't have a reasonable update URL.

Comment 13

[Dave Townsend [:mossop]]

(In reply to Blair McBride (:Unfocused) from comment #11)
> (In reply to Dave Townsend (:Mossop) from comment #9)
> > Do we have a list of actual names in use in the wild? I came across
> > "Translate This!" in my searching.
> 
> Oops, forgot to mention this - Translate This! is also a legit add-on with
> almost 55 thousand users:
> https://addons.mozilla.org/en-US/firefox/addon/translate-this/
> 
> We could block that by a combination of name and author, but I haven't been
> able to find enough details on that variant.
> 
> So the question is: do we want to land this as-is and do followups, or try
> to find enough details on other variants and block them at the same time?

Unless we are doing a chemspill here (seems unlikely) we have at least 6 weeks till this can make release. Seems like it might be ok to spend a few days trying to get a fuller list.

Comment 14

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

(In reply to Kris Maglione [:kmag] from comment #12)
> If we block "Translate This!", I think it would be better to block the name
> if it doesn't have the ID the legitimate add-on has, possibly also if
> doesn't have a reasonable update URL.

There might be other add-ons with the same name, though. Checking for "Mozilla Corp." as the author should be effective enough for this, if that's the case for "Translate This!".

Comment 15

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: Patch v1.1

Did more research, and couldn't find a lot more useful info. But I did find evidence confirming that the "Translate This!" variant uses "Mozilla Corp." as the author too.

So based on what was discussed in the meeting earlier today, updated the patch to block based solely on the author. I double checked that no add-on on AMO uses that string as the author (checked via addons mxr).

The blocklist entry on AMO should be updated to reflect that this will block add-ons with names other than "Mozilla Safe Browsing". I'd suggest having the title be something more generic (maybe mentioning Medfos), and the description mention both known names ("Mozilla Safe Browsing" and "Translate This!") and also explicitly state that these add-ons are not from Mozilla.


Carrying over code review, but would like confirmation from Jorge before landing this on mozilla-central (and then aurora/beta).

Comment 16

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

Comment on attachment 674501 [details] [diff] [review]
Patch v1.1

Looks good to me. I also updated the block to reflect there is more than one add-on involved.

Comment 17

[Blair McBride [:Unfocused] (UNAVAILABLE)]

https://hg.mozilla.org/integration/fx-team/rev/53ae9eb476e9

Comment 18

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 674501 [details] [diff] [review]
Patch v1.1

Nominating this for, uh, basically everything under the sun. It's on fx-team now, would like this to bake for at least 2 days - but generally want this everywhere ASAP.

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: Blocking malware add-ons that we can't block via normal blocklist methods.
User impact if declined: Continued infection, or potential new infection by malware add-ons - which hijacks search results on Google, Yahoo, Ask, Bing, AOL, and AVG. See comment 1 for details.
Fix Landed on Version: 19, but want it on 17
Risk to taking this patch (and alternatives if risky): Tried to keep this code change minimal and low-risk, but its higher risk than the usual blocklist entry - both from a code standpoint and breadth of the block. It will block all add-ons using the exact string "Mozilla Corp." as the author - tere shouldn't be any legit add-ons that use this (but it's not outside the realm of possibility). Code change is a little pedantic in trying to play it safe, and is a bit ugly just so the changes could be kept as minimal and non-invasive as possible.
String or UUID changes made by this patch: None

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Comment 19

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/mozilla-central/rev/53ae9eb476e9

Comment 20

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 674501 [details] [diff] [review]
Patch v1.1

Pre-approving, based on Blair's acknowledgment that this will be baked on m-c for a couple of days.

We've already gone to build on 16.0.2 and there will most likely not be any more releases off mozilla-release for this cycle so minusing there, also minusing for esr17 as that hasn't been forked yet and well get this for free since the forking happens off of 17 once it's gone to mozilla-release.  Otherwise, please go ahead with uplifts once the trunk bake time is sufficient.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/437fff267f2f
https://hg.mozilla.org/releases/mozilla-beta/rev/d0176e58f0ef

This doesn't apply to esr10 at all. Looks like you'll need a branch-specific patch.

Comment 22

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Just unrelated context line changes, thankfully:
https://hg.mozilla.org/releases/mozilla-esr10/rev/4ee3e7040c2a

Comment 23

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Aaaand backed out from esr10 due to bustage. Patch uses for-of loops, which weren't introduced until (I think) 13.
https://hg.mozilla.org/releases/mozilla-esr10/rev/25b9a6ed020d

Comment 24

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Old-school for loops feel so barbaric these days.

https://hg.mozilla.org/releases/mozilla-esr10/rev/3c9ae6ed62f6

Comment 25

[Paul Silaghi, QA [:pauly]]

Trying to install the add-on attached in comment 3 on FF 17b6, 18.0a2 (2012-11-15), 19.0a1 (2012-11-15), 10.0.11 ESR -> "Mozilla Safe Browsing could not be installed because it has a high risk of causing stability or security problems"

Install the add-on on FF 16.0.2. Then run FF 17b6, 18.0a2 (2012-11-15), 19.0a1 (2012-11-15), 10.0.11 ESR -> in Add-ons Manager: "Mozilla Safe Browsing has been disabled due to security or stability issues"

Verified on Win 7, Ubuntu 12.04 and Mac OS X 10.8.2

Comment 26

[Georgi]

Not it's called - Mozilla Framework Assistant


<?xml version="1.0" encoding="utf-8"?>
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:em="http://www.mozilla.org/2004/em-rdf#">

<Description about="urn:mozilla:install-manifest">
<em:name>Mozilla Framework Assistant</em:name>
<em:version>3.0.1</em:version>
<em:type>2</em:type>
<em:id>{275d417e-7035-4846-803c-17119088b011}</em:id>
<em:creator>Mozilla.org</em:creator>
<em:description>Embedded browser engine.</em:description>
<em:hidden>true</em:hidden>

<em:targetApplication>
<Description>
<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
<em:minVersion>3.0</em:minVersion>
<em:maxVersion>28.*.*.*</em:maxVersion>
</Description>
</em:targetApplication>

</Description>
</RDF>


Here we go:

Some dlls + xpi

http://file.bg/f208854XVsdp


Regards,
G.

Comment 27

[originaldrm]

After getting hit with Mozilla Framework Assistant variant the other day I submitted it to Avira Antivirus.

It's been added to their detection.

"The file 'chrome/content/browser.xul' has been determined to be 'MALWARE'. Our analysts named the threat JS/Redirector.SY. The term "JS/" denotes a Java scriptvirus. Detection will be added to our virus definition file (VDF) with one of the next updates."