Jump to content

Banking and payment protection discussion


Recommended Posts

12 hours ago, Mr_Frog said:

sometimes I even find users recklessly installing  there are so many extensions to browsers and it is even more surprising that a user like this is active daily to access internet banking via a browser because he is from the financial division.

Glad you brought this up.

Eset in ver. 16 by default enabled the Secure all browsers option which is the source for all these green border complaints.

However to allow supported browsers to be usable, Eset by default also allows all browser extensions to be functional. It goes without saying that the primary source of browser malware are extensions/add-ons. Also by doing this, Eset actually weakened prior B&PP capability which didn't allow any extensions/add-ons to load.

I for one want nothing to do with the Secure all browsers feature. If Eset decides in a future release to make the feature mandatory, it's "bye-bye" to Eset usage for me.

Edited by itman
Link to comment
Share on other sites

27 minutes ago, itman said:

I for one want nothing to do with the Secure all browsers feature. If Eset decides in a future release to make the feature mandatory, it's "bye-bye" to Eset usage for me.

This is precisely what I've said since this new feature landed: Don't. Meddle. With. The. Browsers. SSL scanning is intrusive enough and even that can, sometimes, break stuff.

Having Secure All Browsers as a default is not a good choice. Perhaps make it an option during install, like PUP protection, where the user has the choice of enabling it or not, and inform the user of what that entails.

As it is, this just became something I have to instantly disable on every install of EIS.

Link to comment
Share on other sites

Some additional comments in regards to Eset's B&PP.

Eset should be first and foremost directing its attention to correcting existing deficiencies in B&PP such as screen scraping protection.

Next is I am all for increased browser security protection. Enhanced memory and keylogger protections are great but should be provided regardless of if B&PP mode is enabled. In fact, Eset should be protecting all processes against global keyloggers.

B&PP's primary protection is locking down the browser from external code injection. Ideally, that also should be standard browser protection. However, I can understand that the browser needs to be loaded in a protected environment (B&PP mode) to accomplish this. On the other hand, all browser's Eset protects do address this issue in some form. That is if malicious code is injected into the browser, it can't infect non-browser processes.

Link to comment
Share on other sites

Case in point about browser extensions:

Quote

During a routine investigation, Cyble Research and Intelligence Labs (CRIL) discovered multiple Chrome extensions that compromised over two million users with Browser Hijackers. A browser hijacker is an unwanted program that modifies browser settings without user permission and redirects them to specific web pages that they do not intend to visit. After installation, a browser hijacker might open doors for future attacks by redirecting users to malicious websites.

All the extensions that we found were present on the Chrome web store. After installation, we observed that the browsers hijackers were also changing the browser’s default search engine without the users’ knowledge. We noticed that extensions wouldn’t work if a user tried to revert to the default browser settings.

These extensions send the user queries to different servers with multiple redirects, and at the end, the search results are shown from search engines such as Yahoo or Bing rather than default ones. Such search query redirects can collect user information and show advertisements to further serve the developer’s financial motives.

https://blog.cyble.com/2022/11/22/over-2-million-users-affected-with-browser-hijackers/

Link to comment
Share on other sites

Additional comments of the subject of allowing browser add-on's/extensions in secured browser mode.

To date, Eset's detection capability in regards to malicious/PUA add-on's/extensions has been next to nil. Ditto on removal/cleaning capability of those add-on's/extensions. Eset needs to show documented proof of this capability prior to allowing browser add-on's/extensions in secured browser mode.

Link to comment
Share on other sites

So what is the solution here? Pretty simple as I see since the problem is primarily a design issue.

First and foremost B&PP behavior will revert to that of ver. 15. Primarily, no browser extensions are allowed. B&PP mode will again be initiated via access to a financial or manually created URL, via desktop icon, or with Eset GUI.

Next, refer to the below screen:

1. B&PP settings highlighted in green will be removed since they didn't exist in ver. 15.

2. Settings highlighted in red will be moved to Web access protection settings. Additionally, the ver. 16 extensions option will be moved also be moved there.

A new section will be created in Web access protection titled "Advanced browser protection" that will contain the above settings.

3. I really don't see the need to inform the need to inform the user that Advanced browser protection is enabled. At most if enhanced memory and/or keyboard protection is enabled, a desktop notification at browser startup stating Advanced browser protection is enabled is sufficient.

Eset_BPP.thumb.png.62d3781dcb6732cb86dc1e62979c3b46.png

Link to comment
Share on other sites

  • Administrators
29 minutes ago, itman said:

Primarily, no browser extensions are allowed.

The problem with this is that many users would complain about not being able to generate PDF, log in to their bank sites with a smart card requiring a browser plug-in, etc. That's why all extensions are allowed by default. Malicious extensions are treated like any other malware and we add detection for them.

Link to comment
Share on other sites

18 minutes ago, Marcos said:

The problem with this is that many users would complain about not being able to generate PDF, log in to their bank sites with a smart card requiring a browser plug-in, etc.

These are special cases as I see it.

As I posted and proposed, the activity you noted would be allowed in Secured browser mode in the context of Advanced web protection settings in Web access protection section.

Edited by itman
Link to comment
Share on other sites

I thought of another solution that would require minimal modification on Eset's part.

The ability to enter protected web sites would remain in place with the Secure all browsers option enabled. When Eset encountered one of these URL,s, it would open another browser instance with all extensions disabled.

The given here is it would be the user's responsibility for maintaining the URL list.

Edited by itman
Link to comment
Share on other sites

My opinion is that the ideal would be to leave the manual option to run the browser in "Secure mode", or without it by default. It's convenient because I know I'm running a more protected mode in the case of sensitive sites - banks and the like. I don't need it for viewing entertainment sites. 
This separation is also good because the "Secure browser" has its own profile, i.e. settings, extensions used (also referred to by itman) etc. 👍

Link to comment
Share on other sites

As far as AV's being able to detect malicious extensions, the research shows otherwise:

Quote

Endpoint Protection and Threat Intelligence Research Alone Do Not Detect Malicious Chrome Extensions

With those security controls in place and companies already investing heavily in endpoint protection, you might think that users would be safe from malicious extensions. However, our research shows this is not the case.

Overall, we discovered 85 malicious Chrome extensions on our customer networks. Some had never appeared in the Google Chrome Web Store, while others had been removed by Google. Nevertheless, they were still found operating on customer networks.

How can users continue to run malicious extensions despite the many security controls? During our research, we identified four approaches attackers use to introduce malicious extensions into user browsers:

  • Browser Configuration and Third-Party Sites: Some extensions enter browsers due to poor browser configuration and downloading CRX (Chrome extension installation file) from malicious sites, i.e., not Google’s official web store. One malicious site we identified that distributes malicious CRXs is http://extore[.]space/inspire. Some of the extensions are real and benign, while others might be fake with malicious code.
  • Malicious Code Injection During Update: In other cases, Google might have approved the extensions, but attackers later injected malicious code in one of the extension’s updates after the extension becomes popular.
  • Extension Rights Acquisition: Other ways are by adversaries purchasing a popular extension’s rights from the developer and then injecting malicious code. Taking over the key (which generates the extension ID) and credentials from the developer might also be a way to get plugged into a popular extension.
  • Independent Code Downloads: We’ve also identified other Malwares/PUPs or malicious extensions that would download and install additional (other) malicious extensions.

 

https://www.catonetworks.com/blog/threat-intelligence-feeds-and-endpoint-protection-systems-fail-to-detect-24-malicious-chrome-extensions/

 

Edited by itman
Link to comment
Share on other sites

  • ESET Staff

Thanks all of you for your interest and valuable opinions. I'll try to reply to some of your points.

On 11/22/2022 at 3:28 PM, itman said:

Eset in ver. 16 by default enabled the Secure all browsers option which is the source for all these green border complaints.

We're working on update, that we believe may help to mitigate these complaints.

On 11/22/2022 at 3:28 PM, itman said:

However to allow supported browsers to be usable, Eset by default also allows all browser extensions to be functional. It goes without saying that the primary source of browser malware are extensions/add-ons. Also by doing this, Eset actually weakened prior B&PP capability which didn't allow any extensions/add-ons to load.

Depends on point of view. None of us voluntarily install keylogger, or banking malware. These spy/trojan malware families are there since forever. Our engine detect everything known (or even unknown), but they're still there as families specially targeting banking websites, installed by 0-day, trojan or just bad mail attachment with clear goal to install silently without any evidence and with attempt to survive the reboot.

On the other hand, there are extensions, that cannot be installed without user consent. During install you see, what permission they're requesting (like background-changing extension, that require broad host permissions to all visited websites). When BPP came to EIS, extension installation from any 3rd party website was matter of course. Nowadays it's difficult/impossible to install malicious extension out of official store (especially at Chrome). You have to load them as unpacked extension at Developer mode. But this way was possible also in Secured browser. It's like deliberate damage to the settings.

Much more frequent scenario than conscious installation of adware/spying extension is to click to coffee discout at newsletter and in a minutes entering credit card number to payment gateway for fresh package of Arabica. At unsecured browser.

I don't say that there're not bad extensions, definitely they're there, signed by particular store, even after Chrome/Edge/FF review process. You gives some good examples too. Currently we're working on a solution targeting bad extensions.

So even if you're partially right in matter of solely banking actions, an increased number of scenarios like shopping (and pay by credit card or by payment gateway, that forwards you to your bank website and cannot be redirected to Secured browser) gives strong reason to protect your default browser. Even with extensions enabled.

On 11/22/2022 at 6:53 PM, itman said:

B&PP's primary protection is locking down the browser from external code injection. Ideally, that also should be standard browser protection. However, I can understand that the browser needs to be loaded in a protected environment (B&PP mode) to accomplish this. On the other hand, all browser's Eset protects do address this issue in some form. That is if malicious code is injected into the browser, it can't infect non-browser processes.

Browser vendors protect especially injection to renderer processes (to prevent escape from emulator to OS), but not parent process (where you should look for your credentials).

On 11/22/2022 at 6:53 PM, itman said:

Eset should be first and foremost directing its attention to correcting existing deficiencies in B&PP such as screen scraping protection.

Even thought it's questionable, how many credentials this will protect, you're right. The less time we spend on supporting redirector (that doesn't protect, just navigate you to secured browser), the more time we can spend to security improvements.

On 11/23/2022 at 7:49 PM, czesetfan said:

My opinion is that the ideal would be to leave the manual option to run the browser in "Secure mode", ...
This separation is also good because the "Secure browser" has its own profile, i.e. settings, extensions used (also referred to by itman) etc. 👍

Yes, this is planned.

Link to comment
Share on other sites

Given Eset's recent comments on this issue which is expected Eset behavior, it is obvious that further comments are in essence an exercise in futility.. This stated, I will end by discussion with a reference to the approach taken by another AV vendor, Avast, in regards to secure browser design and banking protection provided within.

Avast has developed its own in-house secure browser based on Chromium. By default, no extensions are allowed in the secure browser. The browser does provide for extensions to be added but only those that are vetted by Avast as to security worthiness and added from their internal extension store.

Given this browser was developed internally by Avast, it would deem it alone was secure enough for Internet financial transactions. It does not. Rather Avast has include a separate banking mode with a separate secure browser instance opening  in a virtualized container; i.e. VM mode, with further extension restrictions.

References:

https://www.techradar.com/reviews/avast-secure-browser

https://support.avast.com/en-us/article/use-bank-mode/#pc

Edited by itman
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...