Analysis and Exploitation of an ESET Vulnerability

http://googleprojectzero.blogspot.com/2015/06/analysis-and-exploitation-of-eset.html

EDIT: fix was released: http://www.virusradar.com/en/update/info/11824

 

Here is a link to an interesting story on the above topic in Forbes magazine. The article contains some good discussion of governments and hackers trying to reverse engineer or break into the code of various security products. It talks about the specific ESET issue and also contains some good quotes from representatives of other vendors talking about the general problems they face protecting their products. There is especially interesting commentary from Vincent Steckler, CEO of Avast, about the idea of reverse engineering client software when much of the real brains of modern security software happens on the backend or in the "cloud."

http://www.forbes.com/sites/thomasbrewster/2015/06/24/google-eset-antivirus-hack-easy/

 

With "security" software on so many PCs, it makes perfect sense to attack them.

Yeah that's all well and good until their internal network/servers is compromised. If you think that's unlikely, it was just a few weeks ago we heard of it happening to Kaspersky.

 

fixed the following day
www.eset.com/int/about/press/eset-blog/article/eset-vulnerability-fixed/

 

Yes, I think the big products as listed in the article below are probably fairly well exploited by various governments.

https://firstlook.org/theintercept/2015/06/22/nsa-gchq-targeted-kaspersky/

ESET does deserve credit for fixing the problem quickly. They are an honorable company and always my default product.

 

Hum ........... By default, runtime packers are not checked by real-time scanning?

 

Yes that's correct. But FYI I checked in V9, and both Runtime packers, and Advanced Heuristics is enabled by default for real-time scanning. (AH under realtime scanning is disabled in V8 as well).

I don't enable AH in V8 for RT scanning as it could affect the performance, and I actually assumed it was disabled by default in V9 as well (hadn't checked before now ), but it was enabled, and I can't say that I notice any difference in performance, so I will leave both enabled for RT.

 

A lot of confusion on AH it appears. First, a def. what it is:

Using Advanced heuristics/DNA/Smart signatures creates a virtual computer within the scanning engine that allows the scanner to observe what the object being scanned might do if it were allowed to run on the actual machine. Thus, it is more resource intensive, but offers the benefit of being able to identify malicious activities that would otherwise go undetected.

ref: https://docs.labtechsoftware.com/La...olicyManagement/CreatingDefaultESETPolicy.htm

In other words, it is Eset's version of sandboxing.

The default settings for ThreatSense parameters for real-time scanning is AH is set to "off."

And this applies for the AH setting in the advanced options setting of real-time scanning:

Therefore, advanced heuristics is only used for newly created and modified files. Files whitelisted by ESET will not be scanned again if you have Smart optimization and LiveGrid enabled.​

By default, advanced heuristics are not used when files are executed but can be enabled by selecting the Advanced heuristics on file execution option. Enabling this option may slow the execution of some applications due to increased system requirements.
​

My opinion is as far as AH real-time scanning settings go, they are correct. If the file was scanned once when created or modified, it does not need to be scanned when executed. Also I believe the scan on file execution option applies to all files which is definitely over-kill.

Ditto for the runtime packers settings, they only need to be scanned when created or modified; not every time they are executed.

However on a PC infected prior to the Eset installation, the above settings would not catch resident unknown malware. I believe that is why Eset does turn on AH in the ThreatSense parameters for the start up and on demand scans.

-EDIT- Additional under the ThreatSense settings for Web Access Protection, both AH and runtime packers are enabled. So that will cover all your Internet based apps.

 

@itman

I am very sorry, what I said is not correct.
I am not used to this new GUI yet, I looked at the wrong section ;P

AH and Runtime packers is NOT enabled by default under real-time scanning. (they are disabled)

But they are both enabled for Newly created and modified files, and AH is also enabled/used on file execution.

So I believe these settings are the same in the V9 Beta as they are in V8, IIRC

 

According to Eset's write ups, files scanned OK by AH are whitelisted; won't be scanned again till modified. So I guess, scanning on execution wouldn't be that much overhead. However, as time went by, the white list would get quite large and that could impact performance.

I do know that the on-demand scan does have AH enabled. However, some malware disguises itself on download. If it is zero-day stuff, it won't be active till run. So I guess the scan on file execution is one of those "I'll be damned if I don't" scenarios.

 

Since Eset hasn't replied to my posting in their Smart Security forum, I will post this issue here.

Based on my testing using the Surfright x64 exploit test tool, Eset has zip protection against x64 exploits. It failed every Surfright x64 exploit test when using my x64 IE10 browser . So if your using a x64 browser, you better install additional exploit protection.

As far as x86 exploits, Eset's exploit protection caught everyone of the Surfright's test exploits using IE10 x86 and Adobe Reader.

 

I don't understand how ESET can detect exploits of Surfright's tool in IE and Adobe Reader? IIRC the exploits are occuring in the tool itself?

 

@itman
Do you think that this can be caused by ESET using 32 bit ekrn.exe?

 

Latest ver. of the tool allows you to select app you want to test. You can still run the tool stand-alone. However, that would be useless with Eset since its exploit blocker only works against Internet facing apps; browser, pdf, and MS office apps.

The x64 ver. of the tool will only allow me to test IE X64. If I try to search for anything else, the tool hangs. The x86 version of the tool has no issues with selecting any x86 app for testing.

 

Good question. Really don't know. Not sure it's ekrn.exe that is doing the exploit checking. Have a hunch it's the EpfwNDISLightWeight Filter it install on your network device. That bugger is doing all the protocol filtering. BTW - I am using a wireless adapter.

Also no injection of eplghooks.dll is occurring for explorer, browser, etc. on my PC. Not sure if that is used by the exploit blocker or not. Probably not since exploit blocker for x86 Internet facing apps works OK.

 

Thank you. I was completely oblivious to this possibility until now.

 

Hm, I have protocol filtering disabled (driver unloaded) but still can enable exploit protection. All features depending on protocol filtering are disabled and can't be enabled but exploit protection not. I was sure that HIPS component provided exploit protection.

 

Yes, Eset says that exploit protection is part of the HIPS. If so, I believe that "hooking" is really required for any type of effective protection. For example, MBAE free will insert it's .dlls into the browser to implement its protection.

The interesting part is I looked at Eset's settings in my WIN 7 x64 registry. Whatever .dlls it uses are stored in profiles there. Zip reference to eplghooks.dll there. One thing I am wondering is if it loaded via AppInit_DLLs mechanism? I have loading of .dlls via that method turned off in the registry for security reasons. So I recently did multiple uninstalls of Eset SS 8 at least three of which was with their safe mode uninstaller. I also allowed loading of AppInit_DLLs via registry. Still a no go as far as injecting of eplghooks.dll. As far as I am aware off, all Eset's .dlls are dynamically loaded anyway.

And it gets weirder. For a short time, I actually did see injecting of eplghooks.dll occurring. But only after a system crash that resulted in WIN recovery actually stating that spldr.sys driver was corrupted and had to be restored from backup copy. Like that? That driver by the way is a WIN 7 security driver.

In none of the Eset installations was one problem encountered except for all my network drivers being hosed after using the safe mode uninstaller.

Finally I did do extensive HIPS testing using custom rules and encountered no issues or concerns.

Bottom line is I don't at this point trust anything in regards to Eset's exploit and memory protection. The only tests I have seen on those features were done by AV labs with little details given as to the type of exploits tested; x86 or x64.

 

I also don't think that Eset's exploit protection can be compared to MBAE, EMET or HMPA. I don't think that they are loading their own DLL into other apps (at least I didn't find any reference to it, would appreciate any info about it, though). I always thought that they are using their HIPS to monitor some of process activities and by this try to identify possible exploits. I don't think that ESET is offering exploit mitigations, rather exploit detection. But I might be wrong...

 

I think we are getting close here.

Eplghooks.dll resides in Eset x86 folder. In other words, it's a 32 bit .dll. Now this excerpt:

SetWindowsHookEx function can be used to inject a DLL into another process if the following conditions are met:

• A 32-bit DLL can be injected only into a 32-bit process, and a 64-bit DLL can be injected only into a 64-bit process. It is not possible to inject a 32-bit DLL into a 64-bit process or vice versa.
• The 32-bit and 64-bit DLLs must have different names.

ref: https://msdn.microsoft.com/en-us/library/windows/desktop/aa384274(v=vs.85).aspx

So on x64 OS and processes, Eplghooks.dll will never be used. On a 32 bit OS, I am sure it will inject just fine. Fooling around on a 64 bit OS will crash your system as I learned the hard way.

As you commented, there is no full exploit mitigation when Eset is installed on a 64 bit OS. There is detection when running a 32 bit process and what appears to be blocking but that is it based on my tests. No alerts or logs entry, etc.. When running a 64 bit process, Eset's exploit protection is a "hit or miss" scenario from what I have determined.

You need a separate exploit blocker that does work unconditionally on 64 bit processes if running Eset on a 64 bit OS.

 

Thanks itman for testing and sharing

 

One more thing.

I actually created a HIPS rule to block global hooking and state modification for IE10 x64. And the SurfRight exploit tool whizzed right past that rule. That rule did stop MBAE dead in its tracks though.

 

Eset not alone though in lack of 64 bit protection. Kapersky also has issues as noted in this discussion on MalwareTips: http://malwaretips.com/threads/kaspersky-x64-bit-protection.45594/ .

This is one reason I run Emsisoft Anti-Malware with Eset Smart Security. EAM's behavior blocker has no issues hooking 64 bit processes. Appears they are one of the few that have figured out a way around PatchGuard. Unfortunately though, EAM has zip exploit protection .

 

Eureka!!! I found the x64 exploit protection bug

And finally all the erratic behavior I observed in the past with this feature now makes sense; sometimes Eset would pass all the test tool x64 tests, other times it wouldn't after reinstalling. etc.. Also since Eset never responds to my postings in their forum, I am not going to inform them about the bug. Let them keep getting lower scores in any future AV lab exploit testing. If they do become aware of this, they owe me a lifetime license.

My initial hunch was right in that it has to do with the network adapter filter since that is where protocol scanning is done. And people like Minimalist most likely aren't affected since they have disabled all protocol filtering.

Note the screenshot below. By default, there are no excluded applications. Ready for this one? You have to exclude at least ekrn.exe and also eguie.exe for good measure from protocol filtering as I have circled in the screen shot. Once that is done, Eset passes every test tool x64 exploit test. I believe this excluded app list is built dynamically as apps are added to your PC. Eset forgot to auto exclude their own apps. Or in my opinion, Eset never thoroughly tested x64 exploit protection using the default configuration.

I also believe there is another Eset install bug but I have yet to find any impact from it. I suspect though it may be impacting some desktop displays from Eset. The bug is ekrn.exe installs as an interactive service. However in WIN 7/8, the default startup setting for the Win Interactive service is manual. Appears Eset is not properly starting this service since it remains at manual setting after boot time.