Banking and Payment Protection Not Working

[itman 1,659]

Win 10 build 10240, Eset SS 9 ver.391

 

Just did an upgrade from ver. 8 to ver. 9 from ver. 8. Everything appears for the most part OK except for banking and payment protection. Initially when I opened it manually, it wouldn't open IE11 at all. Now it opens IE11 but the entire web page is blank and the blue circle goes round and round. Then the browser terminates.

 

Also appears B & P doesn't work from a normal IE 11 browser start when entering www.bankofamerica.com.

[itman 1,659]

Appears to be a problem with the command line start up of IE11 by Banking and Payment Protection. Should there not be a blank between "ESET-Home" as noted in the below screen shot? Can I fix this with a registry edit?

 

 

-EDIT-Actually there is no "-Home" command line option according to MS: https://msdn.microsoft.com/en-us/library/hh826025(v=vs.85).aspx . So there is either something wrong with the URL specified or there is an issue the -noframemerging option with IE11 tiling?

Edited August 8, 2016 by itman

[itman 1,659]

I also tried the hxxp://eset.com/BPRedirector/Eset-Home address via execution of iexplore.exe in a run command and received a 404 not found page error. 

 

So what is the status of this?

[Marcos 5,070]

Why did you attempt to open ttp://eset.com/BPRedirector/Eset-Home? It's not expected to open. On my Windows 10 with v9 installed, www.bankofamerica.com opens in a secure browser.

[itman 1,659]

Why did you attempt to open ttp://eset.com/BPRedirector/Eset-Home? It's not expected to open. On my Windows 10 with v9 installed, www.bankofamerica.com opens in a secure browser.

My problem is I can't even open a Banking and Payment Protection session using the standalone desktop icon or with the Eset GUI itself. As I posted in the screen shot, all that happens is a blank IE page is displayed with the blue circle wait symbol rotating. It stays like that for about 10 secs or so and the Banking and Payment Protection shuts itself down.

 

I tried an Eset repair option w/reboot and that didn't help.

 

I am running IE 11 x64 w/EPM enabled both in the security zone and in the advanced option section. I also have the 64 bit tab option enabled.

 

Note: When I tried ver. 9(multiple times!) before on Win 7, there were no problems w/Banking and Payment Protection. So this has something to do w/Win 10 and Eset ver. 9.

[Marcos 5,070]

Please collect logs with ESET Log Collector (hxxp://support.eset.com/kb3466/) and send me the output via a pm. Maybe the logs will yield something suspicious (possibly conflicting application, dll or whatever).

[itman 1,659]

Please collect logs with ESET Log Collector (hxxp://support.eset.com/kb3466/) and send me the output via a pm. Maybe the logs will yield something suspicious (possibly conflicting application, dll or whatever).

Log file exceeds 2MB. What do you want me to eliminate on a rerun to get within the 2MB limitation?

[Marcos 5,070]

You can upload it to OneDrive, Dropbox, Google Drive, etc. and pm me a download link.

[itman 1,659]

You can upload it to OneDrive, Dropbox, Google Drive, etc. and pm me a download link.

I don't use and don't want to use any of those. Again, what can I exclude to get within the 2MB restriction.

[itman 1,659]

You can upload it to OneDrive, Dropbox, Google Drive, etc. and pm me a download link.

Sent you the log file with the last 5 days of activity.

[itman 1,659]

Personally, I believe the issue is EPM. The spawned IE instance is running in AppContainer as noted in the below quote and which I verified using Process Explorer. I also verified that Emsisoft's hook is not set in the sandboxed IE instance. So if SS is trying to inject its keyscambler hook into it, it will fail.:

 

AppContainer is a sandbox environment introduced in Windows 8, which limits process operations more strictly than does the Integrity Level (in Protected Mode). In a widely known case, the Windows Store applications runs in an AppContainer environment, and an Enhanced Protected Mode designated IE also runs in an AppContainer environment.

Edited August 10, 2016 by itman

[itman 1,659]

I don't know if this is related to this issue or not. But I will post just for further info.

 

I noticed that after boot time and prior to any direct attempts to use Banking and Payment Protection, eOPPFrame.exe is not running under ekrn.exe. Starting up BP&P via desktop,etc. triggers eOPPFrame.exe. Once IE11 doesn't initialize properly, eOPPFrame.exe remains running. Don't know if that can cause further Eset issues.

[itman 1,659]

Confirmed! It is IE11 x64 EPM that is preventing Eset's Banking and Payment Protection stand-alone from starting up. When I disabled EPM in IE11 advanced options, BP&P started up w/o issue. Why Eset was not aware of this is totally beyond me.  Also disabling EPM is not a viable option since a system restart is required to do so.

 

A fix for this would be to create an exception for eOPPrame.exe in AppContainer. That is not possible w/Win 10 Home versions since AppContainer is not assessable.

 

If IE 11 is started in private mode i.e using the -private option, the 32 bit version of IE 11 is started up; at least this was the case for Win 7. Actually, Eset should be using this option in BP&P since it disables all add-ons. Or, Eset needs to modify BP&P, to start up the 32 bit ver. of IE 11. -EDIT- No, IE11 in Win 10 runs the 64 bit ver. in private mode.

 

So the only option available for Win 10 is modify to BP&P to detect if EPM is enabled and then to start the 32 bit ver. of IE11. Or, to always start the 32 bit ver. of IE11.

Edited August 12, 2016 by itman

[Marcos 5,070]

Weird. BPP works alright in IE x64 with EPM enabled on my Windows 10.

[itman 1,659]

Weird. BPP works alright in IE x64 with EPM enabled on my Windows 10.

One possibility is the Eset in place upgrade from ver. 8 to ver. 9 didn't set permissions in AppContainer for eOPPrame.exe. I looked in the registry associated area and didn't see anything Eset related. Also appears, an Eset repair doesn't fix this.

 

I am trying to avoid a reinstall of SS 9 since it is a pain since I use other security software. BTW - I did disable those in testing to ensure those weren't the issue.

 

I believe the AppContainer permission issue can be fixed using Powershell. Ask Eset development for a script I could run to register eOPPrame.exe, etc. properly in AppContainer.

[itman 1,659]

Weird. BPP works alright in IE x64 with EPM enabled on my Windows 10.

I just fired up Process Monitor which I should have done in the first place.

 

Monitoring IE11, tons of access denied for eOPPBrowser.dll. What is most interesting is prior to any eOPPBrowser.dll denials, there is one access denied attempt for C:\Users\XXX\Desktop. So I believe that also is an issue; maybe the primary one?

Edited August 13, 2016 by itman

[itman 1,659]

Here's a screen shot of the access denied messages from Process Monitor in chronological order:

 

 

 

 

 

[AHarMan 0]

Thanks itman I have an old relative who uses windows 10 and was using eset 9 up until the nov update last year when payment protection broke. At the time i was told it was because 64 bit browsers were no longer supported with payment protection and we would have to wait until eset 10 for full compatability. I recently rebuilt the old mans rig and have been putting off installing eset 9 again (despite having a valid license) as he relied on banking and payment protection, but theres no point me reinstalling 9.0.381 if its not compatible with either the nov update or the anniversary update.

 

Are you saying it is now working again in version 9 ? (64 bit browser with or without epm in ie 11) or do you have to hack it / bodge it to make it work ? regarding the entry re the user desktop denied, this could be because one method of using banking and payment protection is to launch the separate BPP browser window from the icon on the desktop.

 

Thanks

[AHarMan 0]

Weird. BPP works alright in IE x64 with EPM enabled on my Windows 10.

 

Which version of windows 10 ? you are right it use to work fine for most of us, but the November update and subsequent updates (inc the recent Anniversary update) meant this never worked again for me and I'm holding off until eset 10 where I've been told it will work correctly again. I suspect as per itmans post, eset have not been communicating with Microsoft about the issue or dropped the ball and no one tested 64 bit browsers with / without epm. Made me laugh when an eset rep told me to use a 32 bit browser (which BPP still wouldn't work after the November update) I mean why would I use a 32 bit browser on a 64 bit OS ? really hope eset 10 is much better and refined for windows 10 compatibility.

[Marcos 5,070]

Currently I have Windows 10 build 10586 and it seems to work fine:

 

[itman 1,659]

Upgraded to ver. .402 and BPP still doesn't work.

[itman 1,659]

Sometimes you never test for the obvious ....................

 

Marcos, I can run BPP from the desktop as admin. I checked my BPP security permissions for myself, i.e. limited admin, and BPP has me set with special permissions. I checked those and all that is shown is special permissions for the basic and delete in the advanced setting. That doesn't look right to me.

 

I did check my current IE 11 permissions and as admin - limited user, I have full control? Don't know if that is the issue or not. Never fooled with those permissions but remember I did upgrade from Win 7 to Win 10.

 

So what is the best way here to proceed? Change BPP permissions for me to full control?

 

-EDIT- I remember reading something that Win 10 has quirks in the area of a process starting another process with higher privileges? 

 

-EDIT2- Believe I am close with the above statement. I have UAC set to highest level. Possible BPP is hanging because it can't handle the UAC prompt request that IE11 might be generating when started by BPP? Not UAC, set that back to recommended level and IE11 still hangs on startup.

 

-EDIT3- Looking at the security accounts that are set up, appears Eset just set up a full admin and user account for me but no limited admin account? I run as a limited admin. Need instructions on how to inherit permissions for C:\Users\Public\Desktop\. That one has me stumped.
 

Edited August 17, 2016 by itman

[itman 1,659]

I think I have pretty much nailed down what the issue is.

 

When Eset configured BBP security permissions, it set up my user level account to inherit the permissions from C:\Users\Public\Desktop\. This I believe is the problem.

 

For reference, I checked IE11's security permissions in its folder and its permissions for my user level account are correct; read and execute only. However, I have pinned IE11 to the desktop taskbar for easy access. Same would occur if I created a desktop icon instead. This results in IE11 being assigned my limited admin security privileges.

 

Appears from the special permissions that BBP is assigning to my user level account, it is trying to run with user account privileges which makes sense since those have restricted access. However since the inherited C:\Users\Public\Desktop\ security privileges are for a limited admin, IE11 when it starts up sees a conflict in security privilege assignment and hangs.

 

In other words, Eset wants ecmd.exe to run at the user's sign on security privilege level(?) but start the browser always at the "user" security privilege level and it is not working.

 

Confusing as hell is it not?

 

-EDIT-

 

Below is a screen shot of my user permission settings for BPP. They are obviously screwed up since the only permission Eset set was delete. Again Eset, how can this be fixed?

 

 

 

 

 

Edited August 18, 2016 by itman

[itman 1,659]

Did more research on this issue. I am now at the point that I have pretty much had it with ver. 9. SSL protocol scanning of my Thunderbird e-mail is again not working and I will address that in the other thread I opened on the subject.

 

I believe the issue with BP&P is noted in this web posting: hxxp://ttps://blogs.msdn.microsoft.com/ieinternals/2012/06/19/enhanced-protected-mode-and-local-files/ . Note the text I highlighted in red.

 

 

Ordinarily, Internet Explorer loads local HTML files in the Local Machine Zone. Locally-loaded HTML files are subject to the Local Machine Lockdown feature which prevents pages from running active content like JavaScript or ActiveX controls, showing the following notification:

 

In order to avoid this lockdown, many local HTML pages will contain a Mark-of-the-Web (MOTW) which instructs Internet Explorer to load the content using the security permissions of a different zone, typically, the Internet Zone. There are several ways to assign a MOTW:

1. A comment inside HTML markup
2. Using an NTFS Alternate Data Stream named Zone.Identifier
3. A Low Integrity Label in the permissions on the file
4. Loading the file from the Temporary Internet Files folder

Internet Explorer itself uses each of these methods in different circumstances, but most developers who are designing HTML to load from local locations will use the HTML comment format, by adding one line to their markup:

 

<!doctype html> 

<!– saved from url=(0014)about:internet –>

<html><head>…

 

When Internet Explorer encounters this comment, it maps the current document into the Internet Zone, and it runs with the permissions of an Internet-based document so JavaScript and ActiveX controls may run with appropriate limits (if permitted by your Internet Zone settings).

 

However, putting local content into the Internet Zone has one very important consequence in Windows 8. The Internet Zone runs in Enhanced Protected Mode (EPM) in Metro-style IE and optionally in Desktop IE. One of the key strengths of the AppContainer isolation mechanism upon which EPM relies is that AppContainers do not permit “Read up” access. That means that content running in AppContainer doesn’t have direct read access to most areas on your hard drive; attempting to open a file in an AppContainer will result in an Access Denied error. (In contrast, the IE7-IE9 Protected Mode feature allowed “Read up” access, only writes were forbidden.)

 

When Internet Explorer is instructed to load the local HTML page above, it first assumes that the content will be in the Local Machine Zone and begins reading the content in a process which is running at Medium Integrity outside of AppContainer. When it encounters the MOTW, it realizes that the content should be loaded in EPM, so it launches an EPM process to take over the loading of the content. The EPM process is now “stuck”—it doesn’t have access to the local file, because the AppContainer forbids reading of the file. The solution to this conundrum is pretty simple—when Internet Explorer’s EPM encounters an Access Denied error on a local file, it asks IE’s broker process (running at Medium) to see whether that local file has a MOTW. If so, the broker process provides read access to the file, enabling the restricted process to read it. If no MOTW is found, then the read is denied and the browser will not render the content.

 

Edited August 23, 2016 by itman

[itman 1,659]

Posting deleted.

Edited August 25, 2016 by itman