Protomartyr

Level 6
Verified
As some of you might have noticed, Nano Adblocker is now months behind upstream. It became clear that I simply do not have enough time to properly maintain the Nano projects.

At the beginning, there was no backlogs. As the projects grow, I added a backlog system to better manage open issues. That was unfortunately not enough, so I added another level of backlog -- the triage queue. Then a third level. And then a fourth one. Now the fourth level of backlog, the notification queue, has 178 issues waiting for my attention. No matter how well I organize incoming issues, if I do not have enough time to look into them, I will simply fall further and further behind. With thousands of issues backlogged, it is only a matter of time that the Nano projects collapse.

But there is good news. A team of Turkish developers is in the process of acquiring Nano Adblocker and Nano Defender. With more people and resources, hopefully they will be able to put an end on this backlog madness, and finally give Nano Adblocker some real development time instead of constantly trying to catch up to upstream. The transition is still taking place, so I would like to ask for your patience. I will have more details on this in the upcoming days or weeks.

I know some of you might be concerned about cybersecurity. So far, the new developers kept all of their promises and rarely made any excuses. On top of this, Google is making the WebStore review process stricter and stricter. So strict, in fact, that I had problems publishing updates in the past. While annoying to developers, this strict review process is exactly what shielding users from cybersecurity incidents. So I do not believe there is a reason to be concerned at this moment.


Full announcement and discussion here:
 

Gandalf_The_Grey

Level 38
Verified
Trusted
Content Creator
Can this thread be pinned and show a warning?

Remove Nano Adblocker and Nano Defender now!

If I read the replies here nothing good is coming out of this:
Now in the hands of two unknown developers who have already removed the privacy policy:

gorhill commented 5 days ago

I can't find any information about them.
So this is what is actually happening, I consider all else to be fluff:
"Two developers"[1] with no track record of ever contributing to the current project, or any related projects at least showing any sort of interest in content blocking or privacy or even loosely related topics, and with no visible internet presence to this day, paid an undisclosed amount in exchange of the user base and control of the GitHub repositories.
As of now, the user base has already been transferred (as per Chrome store listings), and in all likelihood a majority of those users will have no idea their installed extensions is no longer maintained by the person they originally trusted, at least implicitly, when they installed those extensions. Links to the privacy policy have been removed from the Chrome store listings (here, and here).
It goes without saying that the goal of these "two developers" is to monetize the two extensions. Those "two developers" will likely continue to import all the work from upstream, i.e. uBO, which is the result of long time volunteers investing their own free time and efforts days after days spanning years, which also contributed to make Nano AdBlocker to become what it is.
[1] Using quotes because nobody knows that there are really two actual developers given that nothing can be verified so far.
 

Jan Willy

Level 4
What should we do with these items on FilterLists | Subscriptions for uBlock Origin, Adblock Plus, AdGuard, ...

Schermafbeelding 2020-10-11 190144.jpg
 

Gandalf_The_Grey

Level 38
Verified
Trusted
Content Creator
Since the original developer is not working on them anymore, I would remove them.
They could still be fine, but at the moment nothing is clear about Nano.
A quote from that GitHub thread:

Techman commented 2 days ago

Looks like I will be removing everything related to Nano Core/Defender from my uBlock Origin preferences. I've seen how this goes with content-blocking extensions. They have usually turned around and monetized in some fashion. We don't need any more rubbish like that in the ecosystem.
@jspenguin2017, I honestly think it would have been better off that you shut down the projects and redirect users back to uBlock Origin instead of "sell" them down the river. As @gorhill has mentioned, it is entirely likely that existing extension users have no idea that ownership has changed hands. This is a significant privacy and security issue as extensions can auto-update.
In all honesty, I'm for uBlock Origin marking Nano lists as bad unless these situations can be addressed.
Transferring the project over to unknown and unproven maintainers makes no sense.
 
Last edited:

Gandalf_The_Grey

Level 38
Verified
Trusted
Content Creator
From that discussion:

gorhill commented 15 hours ago
edited​

So here is what I am seeing in the new Nano Defender 15.0.0.206:
Code was added to detect that the dev console of the extension is being opened. If you open the dev console of Nano Defender 15.0.0.206, a notification named report is sent to Coming Soon 4, or in simple words the extension remotely checks whether you are using the extension dev tools -- which is what you would do if you wanted to find out what the extension is doing.
Now this is from reading the code, and I could probably understand better if I could investigate the extension using dev tools -- but given the above, in all likelihood the extension will modify its behavior once you open the dev tools. So here is what else I can see:
At launch, the extension fetch something from Coming Soon 4, called listOfObject. Minor correction: At launch the extension listen to Coming Soon 4 for messages to populate listOfObject.
The content of listOfObject is further used apparently, as far as I can understand the code, to test fields from the details object passed to webRequest.onBeforeSendHeaders(). If all looked up fields succeed, the whole content of the details object is sent to Coming Soon 4 under the name handleObject.
Note that the webRequest.onBeforeSendHeaders() listener is registered for all network requests:
chrome.webRequest.onBeforeSendHeaders.addListener(blockingHandler, {
urls: ["<all_urls>"]
}, ['requestHeaders', 'blocking', 'extraHeaders']);

So which info ends up being sent is configured externally through the listOfObject, and I strongly suspect this would all stop if I were to open the dev tools.
There is a bit of silly attempt at obfuscation in part of the webRequest.onBeforeSendHeaders() handler:
var m = [45,122,122,122]
var s = m.map( x => String.fromCharCode(x) )
var x = s.join("");
var replacerConcat = stringyFy.split(x).join("");

Which is equivalent to:
var replacerConcat = stringyFy.split("-zzz").join("");

Purpose is not clear, it's meant to remove instances of -zzz from request headers, before they are being sent out.

So trying to figure an example of what the new code can do. Let's say it wants to get sensitive information about network requests to a specific bank, then the content of the listOfObject object could be:
{ url: 'bank\.example\.com\/' }

Then the webRequest.onBeforeSendHeaders() handler would check whether details.url matches the regex bank\.example\.com\/. If so, then the whole content of the details object is sent to Coming Soon 4 as a handleObject packet.
The listOfObject can contain any number of conditions, I just gave an example with a single one above.
The extension is now designed to lookup specific information from your outgoing network requests according to an externally configurable heuristics and send it to Coming Soon 4.

A note regarding what the extension is doing above. Though the extension requests the webRequestBlocking permission, that permission is not required to perform the collection of data, including sensitive ones. The permission is only necessary to remove instances of -zzz from the request headers, and I don't know the purpose of this -- maybe someone else knows.

Here the diff for the code change you won't find in their GitHub repo:

gorhill commented 15 hours ago
edited​

Forgot to mention the obvious: uninstall now -- with those capabilities, it should be considered malware.
 

Gandalf_The_Grey

Level 38
Verified
Trusted
Content Creator
From that discussion:

gorhill commented 16 hours ago•​

edited​

So here is what I am seeing in the new Nano Defender 15.0.0.206:
Code was added to detect that the dev console of the extension is being opened. If you open the dev console of Nano Defender 15.0.0.206, a notification named report is sent to Coming Soon 4, or in simple words the extension remotely checks whether you are using the extension dev tools -- which is what you would do if you wanted to find out what the extension is doing.
Now this is from reading the code, and I could probably understand better if I could investigate the extension using dev tools -- but given the above, in all likelihood the extension will modify its behavior once you open the dev tools. So here is what else I can see:
At launch, the extension fetch something from Coming Soon 4, called listOfObject. Minor correction: At launch the extension listen to Coming Soon 4 for messages to populate listOfObject.
The content of listOfObject is further used apparently, as far as I can understand the code, to test fields from the details object passed to webRequest.onBeforeSendHeaders(). If all looked up fields succeed, the whole content of the details object is sent to Coming Soon 4 under the name handleObject.
Note that the webRequest.onBeforeSendHeaders() listener is registered for all network requests:
chrome.webRequest.onBeforeSendHeaders.addListener(blockingHandler, {
urls: ["<all_urls>"]
}, ['requestHeaders', 'blocking', 'extraHeaders']);

So which info ends up being sent is configured externally through the listOfObject, and I strongly suspect this would all stop if I were to open the dev tools.
There is a bit of silly attempt at obfuscation in part of the webRequest.onBeforeSendHeaders() handler:
var m = [45,122,122,122]
var s = m.map( x => String.fromCharCode(x) )
var x = s.join("");
var replacerConcat = stringyFy.split(x).join("");

Which is equivalent to:
var replacerConcat = stringyFy.split("-zzz").join("");

Purpose is not clear, it's meant to remove instances of -zzz from request headers, before they are being sent out.

So trying to figure an example of what the new code can do. Let's say it wants to get sensitive information about network requests to a specific bank, then the content of the listOfObject object could be:
{ url: 'bank\.example\.com\/' }

Then the webRequest.onBeforeSendHeaders() handler would check whether details.url matches the regex bank\.example\.com\/. If so, then the whole content of the details object is sent to Coming Soon 4 as a handleObject packet.
The listOfObject can contain any number of conditions, I just gave an example with a single one above.
The extension is now designed to lookup specific information from your outgoing network requests according to an externally configurable heuristics and send it to Coming Soon 4.

A note regarding what the extension is doing above. Though the extension requests the webRequestBlocking permission, that permission is not required to perform the collection of data, including sensitive ones. The permission is only necessary to remove instances of -zzz from the request headers, and I don't know the purpose of this -- maybe someone else knows.

Here the diff for the code change you won't find in their GitHub repo:

gorhill commented 15 hours ago•​

edited​

Forgot to mention the obvious: uninstall now -- with those capabilities, it should be considered malware.
 

valvaris

Level 4
Verified

Freki123

Level 8
Verified
Maybe I missed it in the walls of text, but for me this quote would be enough to change :D

The extension is now designed to lookup specific information from your outgoing network requests according to an externally configurable heuristics and send it to Coming Soon 4.

 

Gandalf_The_Grey

Level 38
Verified
Trusted
Content Creator
Good that Google disabled those extensions, because now some suspicious/malware activity seems to have taken place:

Checklist for everyone affected​

  • Check your Instagram for random likes, even if you didn't visit it for a long time, you might be still affected
  • Check other websites you visited in the past 10 days for a suspicious activity
  • Check your accounts for suspicious login attempts
  • If suspicious activity found, report below

Countermeasures​

  • Your passwords are probably fine so far, unless you visited a website with poor security practices (which store passwords in cookies, for example). This is actually confirmed by the reports of failed logins by some, as some websites are smart enough not to allow suspicious usage of stolen cookies, which is good.
  • DO NOT simply delete cookies from your browser. Cookies on the server-side need to be refreshed, which cannot be done by deleting cookies on the client-side
  • You need to logout ALL sessions of websites taht you visited in the past 10 days.
  • Find the option in settings to "Terminate all sessions", which will invalidate all previously issued cookies at all locations. Login again to refresh session cookies
    If there is no such option, you can contact support for assistance in terminating all of your sessions due to possible cookie theft.
  • As a last resort, changing password should (although it might not) invalidate all previous cookies. (#5 (comment))
The extensions users should be concerned about are:

User-Agent Switcher​

  • Originally released by eSolutions Nordic AB, and sold to an anonymous third party
  • Users during infected period: up to ~100k
  • ID: clddifkhlkcojbojppdojfeeikdkgiae
  • Infected versions: 2.0.0.9, 2.0.1.0
  • Infected timeframe: August 28th, 2020 - October 15th, 2020

Nano Adblocker​

  • Originally released by Hugo Xu, and sold to an anonymous third party
  • Users during infected period: up to ~182k
  • ID: gabbbocakeomblphkmmnoamkioajlkfo
  • Infected version: 1.0.0.154
  • Infected timeframe: October 15th, 2020 - October 16th, 2020

Nano Defender​

  • Originally released by Hugo Xu, and sold to an anonymous third party
  • Users during infected period: up to ~260k
  • ID: ggolfgbegefeeoocgjbmkembbncoadlb
  • Infected version: 15.0.0.206
  • Infected timeframe: October 15th, 2020 - October 16th, 2020
From Ars Technica:
The incident is the latest example of someone acquiring an established browser extension or Android app and using it to infect the large user base that already has it installed. It’s hard to provide actionable advice for preventing this kind of abuse. The Nano extensions weren’t some fly-by-night operation. Users had every reason to believe they were safe until, of course, that was no longer the case. The best advice is to routinely review the extensions that are installed. Any that are no longer of use should be removed.
 
Last edited:
Top