Any information of what was stolen how and why?

[makedir]

This comes like a total shock to me, just read by luck on Reddit today that the addon had malware... I used it for years on all my devices!

Any information on what happened what was stolen ect?

[tballas]

greatsuspender#1304 has a bunch of info, specifically,
greatsuspender#1304 (comment)

[csis0247]

Not really. The best information was still the added tracker/analytic from months ago, replacing Google Analytics: greatsuspender#1263

This recent comment summarized the problem: greatsuspender#1263 (comment)

While on the surface the new owner merely switched to another analytics provider, it allows arbitrary code execution from the external analytics provider. No one knows what code is being fetched from the external server, which may or may not be malicious.

[NotWearingPants]

No, and we will probably never have.

The problem was including code from a remote untrusted host (cdn.owebanalytics.com).
This means that the owner of this site can serve a malicious JS file only to specific people (by IP), and you won't be able to know.
There is no evidence of this happening, but that doesn't mean it didn't/couldn't. We can't know what or even if anything was stolen, we would need to find a person that is served malicious code from that site, but everyone reports getting the harmless OpenWebAnalysis script.

The reasons for suspicions are the new owner reportedly acting shady, and this owebanalytics.com not being affiliated with the real OpenWebAnalytics which it pretends to be (Open-Web-Analytics/Open-Web-Analytics#703 (comment)), so it looks like it was meant to appear harmless (like google-analytics and others) to a person investigating it. It also pretends to be the CentOS website when accessed directly. Plus, the addition of this new tracking script was published without uploading the code to the github repo, which makes it look like the owner tried to hide the change.

We will probably never know if and what was done, all we can do is try to question the new owner about this domain, and try to figure out who is behind this domain. Note that the new extension owner might have just come across this analytics site and wanted to use it, he might be separate from the actors behind it and not necessarily the malicious one in this case (the analytics site might also be non-malicious, but it seems very suspicious).

[NotWearingPants]

Btw while we can't know what happened, we can look at the possibilities, by looking at the permissions the extension is granted:
"permissions": [ "tabs", "storage", "history", "unlimitedStorage", "webRequest", "webRequestBlocking", "http://*/*", "https://*/*", "file://*/*", "chrome://favicon/*", "https://greatsuspender.github.io/", "contextMenus", "cookies" ]

So it could:

• know your entire browsing history
• get all the cookies which means it can log on to all your accounts which you have "remember me" turned on (until you logout and log back in, which invalidates these cookies)
• make requests on your behalf (for example post/like on facebook what it wants, delete all your github repos)
• replace any file you try to download with a malicious version, for example if you downloaded any program at all it can add a malicious snippet of code to it which will take over your entire computer once you run the innocent program you downloaded, not only the browser - yikes

While it may be stressful to imagine the possibilities, erring on the past too much won't help. What I do is assume I wasn't targeted (we may all have been, this wasn't necessarily targeted towards specific people), and if I was - so be it. I guess we'll deal with whatever comes.
I think the conclusion should be to be very-very careful and picky as to what extension permissions we are granting from now on, and to who, and also to show the companies we the customers will not use their product if they don't invest in security measures (although Google is one of the best companies at this IMO).

This shows recent work Chrome did to help prevent these cases, and this and this shows they still have a lot to do.

If you also use Visual Studio Code for example, you should support microsoft/vscode#52116, it will help preventing things like this from happening there too.

[cowbert]

Btw while we can't know what happened, we can look at the possibilities, by looking at the permissions the extension is granted:
"permissions": [ "tabs", "storage", "history", "unlimitedStorage", "webRequest", "webRequestBlocking", "http://*/*", "https://*/*", "file://*/*", "chrome://favicon/*", "https://greatsuspender.github.io/", "contextMenus", "cookies" ]

So it could:

• know your entire browsing history

The extension always required this permission, even prior to the buyout. In fact, that's the only way you can set idle timers as well as maintain any semblance of state, by timestamping when a tab was last active and comparing it to the current timestamp, as well as restoring the state from history.

[NotWearingPants]

@cowbert this doesn't change what I said. Any available permissions, regardless of which owner added them, could have been taken advantage of by the remote code. The cookies permission was also present before.
FWIW the new owner added the permissions webRequest & webRequestBlocking, since he added the ability to block images of ads and such from appearing in the preview image of a suspended tab, if you enabled previews. These new permissions indeed make the situation worse, but the pre-existing https://*/* already makes it bad.

[Poopooracoocoo]

and people said that the same tracking stuff was found in other malicious extensions.

[makedir]

Btw while we can't know what happened, we can look at the possibilities, by looking at the permissions the extension is granted:
"permissions": [ "tabs", "storage", "history", "unlimitedStorage", "webRequest", "webRequestBlocking", "http://*/*", "https://*/*", "file://*/*", "chrome://favicon/*", "https://greatsuspender.github.io/", "contextMenus", "cookies" ]
So it could:

• know your entire browsing history

The extension always required this permission, even prior to the buyout. In fact, that's the only way you can set idle timers as well as maintain any semblance of state, by timestamping when a tab was last active and comparing it to the current timestamp, as well as restoring the state from history.

That was always the case? Why doesnt Chrome warn a user, when an extension updates and wants new permissions with an update? I dont think great suspender ever wanted permissions to cookies and everything else.

[cowbert]

some of the permissions overlap with warnings, so adding a new permission doesn't retrigger the warning. If you add tabs after <all_urls> it won't retrigger the warning because you already accepted the <all_urls> one. See: https://developer.chrome.com/docs/extensions/mv2/permission_warnings/

[NotWearingPants]

I dont think great suspender ever wanted permissions to cookies

It did. Before v6.31 it used cookies to save some state of suspended tabs. Now it uses that permission to delete old cookies left by the previous version. smh.

And like @Poopooracoocoo said, chrome does alert. The new permission is webRequest, but even without adding this new permission things would be bad already.

[Poopooracoocoo]

Chrome does alert users when an extension declares new permissions in an update. At least for certain permissions. The scary thing that happened with TGS is that remote code was being executed! Chrome didn't alert users when that was added. It didn't alert me that the extension was found to have malware and that it was disabled.