Analysis and Exploitation of an ESET Vulnerability

Read my post #41. There I quote the reply I received from Eset tech support after they had contacted development on this issue. Again as you pointed out, it is hard to get a straight answer out of Eset for any technical details.

So let me summarize what I have posted in this thread. My opinion is the HIPS in factory default auto setting provides no application protection. All it is doing is protecting Eset from being tampered with. The "smart" mode of the HIPS when it works right is only slightly better protection-wise. I believe all that mode is doing is preventing critical system and registry areas from being tampered with.

The HIPS is extremely buggy. Probably the main reason Eset doesn't want the user fooling around with it. Also the reason you really can never get a straight answer from Eset on HIPS issues.

As far as Eset exploit protection goes, most of it is done by using advanced heuristics/DNA/etc. at the network level using the Eset network adapter filter. However, I believe there has to be a component of exploit protection that protects at the HIPS level. Eset would not have added the exploit option as part of the HIPS settings if this was not the case. As I stated previously, I don't know how you can have truly effective exploit behavior blocking capability without setting a .dll hook into processes being monitored. I believe there is a bug in the later versions of Eset where the hook is not being generated properly in auto and smart modes. I have not yet run the HIPS in interactive mode but I strongly believe that doing so will cause the hook to be properly injected. All I have done is to simulate interactive HIPS mode processing by adding "ask" rules to the automatic HIPS mode processing.

Finally as far as what eplghooks.dll does, it's not much. It activates windows global hooking and unhooking. That's about it as far as I can determine examining the string data for it in Process Explorer.

-EDIT- Also once hooking has been established, it is not just browsers and related processes that are hooked. I have seen eplghooks.dll injected into taskeng.exe that was running under a svchost.exe process. Note that again I have no specific HIPS rule for taskeng.exe. To me this is more than enough proof that this hook is part of Eset's exploit/advanced memory protection.

 

I read the response you quoted from Eset, and I don't know anymore now than before reading their response. If eplghooks.dll is not responsible for the exploit protection then what is? We may never know. I tried using Eset HIPS before in interactive mode after running my computer in training mode for 2 hours, and it did not help at all. It prompted me to death. It made my computer absolutely unusable. I ran every one of my applications while in training mode, and I was still overwhelmed with prompts. If they don't want to spend development time on their HIPS I would suggest they add a behavior blocker like Emsisoft has instead.

 

FYI - you need to run training mode for more than a couple of hours. More like a couple of days so it monitors all OS boot and scheduled tasks. Even that won't cover all scheduled tasks since many run on extended intervals; time updates and defrag once a week, WIN maintenance tasks, etc.. You can also just go into task scheduler and force run those tasks while in the training period.

Emsisoft's BB hooks everything for the most part. That is what makes it different from a conventional HIPS. On the other hand, Emisisoft sucks at exploit protection if you follow the exploit tests done by the AV labs. Mainly because its BB doesn't monitor memory modification.

This is one reason why I have EMET 5.2 installed. I use it as backup to Eset's network level HIPS protection. However EMET has limited protection against memory heap spraying, etc. due to its fixed memory address protection. But its popular software configuration covers many more apps than Eset's exploit protection does such as Thunderbird, standalone Adobe Reader, MS Office apps, etc.. As best as I can determine, Eset's exploit protection just covers the browser plus its plug-ins and stubs to Adobe Reader and MS Office apps.

Personally, I am thinking of going with HitmanPro Alert paid when my current EAM subscription expires. It covers everything exploit wise plus has Cryptolocker protection. It is probably better complimentary software to Eset Smart Security. I can also get rid of EMET.

 

That was not the issue at all. It happened immediately after the training period. It had nothing to do with the scheduled task. I immediately began to receive prompts, and they never stopped. That should not have occurred. I rebooted in training mode 3 times during the two hour training period to learn applications that load early. I also ran all my applications while in training mode. I also always disable everything in task scheduler that I don't need, or want to run.

Most classical HIPS do not monitor memory modification either. Most HIPS historically have only monitored physical memory access. Online Armor HIPS actually injects into all processes. You rarely find a process that Online Armor does not inject into. I used Online Armor from 2005-2015, and I checked for process injection with all my processes when using Online Armor. I actually prefer a HIPS with good whitelisting over a BB any day. I have not been happy at all with Eset's HIPS so I think maybe they would do a much better job at developing a BB.

The last time I checked Emsisoft BB did not inject into all processes. I think they reduced the number of applications their BB injects into recently even more. I can't say that with certainty though since I did not check for injection myself, i'm just going by Emsisoft's description of their product. Behavior blockers are not meant to block exploits, but should block some of their payloads. Most of the exploit test that have been conducted in the past 2 years did not give credit unless the exploit itself was blocked, or the webpage was blocked by blacklisting it. They didn't test to see if the binary payload was blocked. They only tested to see if the exploits were prevented from running. Many traditional AV's received a pass by blacklisting the website, and not allowing the website to load therefore the exploit had no chance to run. It didn't reflect their ability to block the exploits themselves. I'm sure the results would not have been nearly as good for products that rely on blacklisting websites, or domains.

 

Your training mode issues are not unique if your check the Eset forum postings. Many postings about the HIPS just flaking off and not working properly especially when user rules are added to it; either automatically by training or manually. You might try what Eset has recommended on the forums which is a new install and immediately setting the HIPS to training mode. The bottom line is the HIPS is buggy.

True that a classical HIPS does not monitor memory per se. However, in Eset HIPS Target Application tab, the provided coverage per Eset documentation for the "Modify state of another application" protection is detection of writing to applications memory. It is questionable how effective that is since it certainly does not detect heap spraying by the Surfright exploit test tool. The memory protection referenced probably just detects .dll injection and the like.

Again, I have never seen any anti-exploit software that does not hook the processes it is monitoring. EMET, MBAE, and HMPA all do. This leads me to believe that Eset advanced heuristics, etc. at the network level is just sandboxing the browser content and looking for obvious malware behavior and traces. And unless SSL protocol scanning is enabled, it is debatable how effective that is for encrypted data. Eset is then deferring to the HIPS and additional "mystery" exploit and memory protection to do the rest. I can't see how it can do the later w/o hooking the process.

Join me in suggesting that Eset purchase the licensing rights to Online Armor from Emsisoft since they no longer want to support it. Then use it as the HIPS in Eset. Now that would be a "killer" security suite.

 

First, I am now working with Eset tech support on this eplghooks.dll issue.

Today I did some more extensive testing. The result is there is a definite conflict between Eset's exploit/memory protection and EMET 5.2. What I discovered is that disabling EMET's browser protection still causes it's hooks to load into the browser. Even disabling EMET's service and rebooting still causes its hooks to load into the browser. None of this is a surprise to me since I had previously observed that EMET imbeds deeply into the OS. As long as EMET is loaded into the browser, it will override all Eset HIPS based exploit/memory protection. So I uninstalled EMET, rebooted, and checked to ensure that eplghooks.dll was being injected into the browser. Then I retested using the SurfRight exploit x64 test tool. Eset passed every test including all the heapspray tests! Note that this is far superior to EMET's protection using the same tests. So as long as eplghooks.dll hook is injected, I feel that Eset's browser exploit protection is top notch. The key is to get eplghooks.dll to load every time ........... Also noteworthy is Eset's exploit/memory protection stops the test payload from executing. Undetermined is if it actually blocked the browser memory injection. It did not terminate the browser. I believe these observations parallel those of Kaffine's when he tested Eset's exploit protection a while back using live exploits.

I really wanted to use EMET for its non-browser apps protection but now realize that is not possible if Eset's exploit and memory protection is enabled. However, Eset still has it's advanced heuristics/DNA protecting all web filtered connections so you still have that for exploit protection for Internet interfacing non-browser apps.

Note: I had previously excluded all EMET's processes from Eset's realtime scanner and HIPS prior to all this recent testing.

-EDIT- Above testing done on WIN 7 x64 and IE10 x64 w/EPM enabled.

-UPDATE- Today after first cold boot and resultant full registry refresh, I observed that eplghooks.dll was inserted into explorer.exe and related processes; browser, etc. It was not inserted into taskhost.exe, tasking.exe, etc. This is exactly the behavior I would expect given that Eset's HIPS based exploit protection only protects the browser. This is also for me further proof the Eset's exploit protection was detecting EMET's hook injections as a threat in those processes resulting in it also injecting it's hook to monitor EMET's activity. Proof that setting EMET process exceptions in Eset's HIPS had no effect on it's behavior.

Also of interest is I also use Emsisoft Anti-Malware and the above testing was done with EAM installed. To date, there appears to be no conflict with it's behavior blocking and resultant hooking with Eset's HIPS. I have also set exceptions for both however.

 

I will if I can find the thread you are referring to. I have not actually looked for the thread yet though. I don't think Eset would purchase Online Armor though for it's HIPS even though I wish they would. They would probably be worried about how much time would be involved in extracting the HIPS code from the other code, and making it ASLR, and DEP compatible. I will join the discussion when I have time, but I think it would be best to send the suggestion by using the feedback box in the Eset application.

 

I already use MBAE so I wonder if it would be compatible with Eset's exploit protection. It may cause a conflict.

 

It's called 'Future Suggestions." https://forum.eset.com/topic/51-future-changes-to-eset-smart-security/

 

I believe MBAE would be more compatible with Eset than EMET. However, all these anti-exploits insert hooks. And in my testing, the third party hooks will take precedence over Eset's HIPS processing. Setting exclusions for the third party anti-exploits in Eset's HIPS appears to have no effect in this regard. Ideally, your want those products to work complimentary to Eset's HIPS. If the other software fails to catch the exploit, then Eset's HIPS protection will catch it. In my testing to date that unfortunately is not the case. Almost always, the third party software hook will override Eset's HIPS as far as memory and exploit protection that is HIPS based.

I did test MBAE free with Eset and no EMET installed a while back. Using the SurfRight exploit test tool, MBAE's browser(IE10) protection was about equal to that of EMET 5.2 results. MBAE failed all the heapspray tests I believe, and a few others. Memory protection is a big deal for me since I still run WIN 7 which is vulnerable to heapspray attacks.

 

Is it correct to say that most posts in this thread haven't got anything to do with the topic title? I'm just checking.

 

Yes, most post are not related to topic, but there are a lot of interesting findings abut ESET's exploit protection written by itman.

 

OK I see, I was reading some posts quickly and I became a bit confused, that's why I asked. But about the original report, this stuff looks kinda scary, I was always a bit skeptical about this, but this guy managed to write a working exploit! The good news is that I haven't used an AV since 2006.

 

Every software has bugs, AVs are no exception. Exploiting them is usually more dangerous since they usually have highest privileges (at least drivers and services).

 

I'm guessing it's probably also harder to write working exploits. That's why AV's are not targeted on a large scale. Same goes for exploiting kernel bugs.

 

Those exploits are probably reserved for targeted attacks. For uneducated or uncareful users they don't need those exploits.

 

The HIPS in ESET software has actually been there for a very long time, even before the version when it got visible in the GUI (in v4 or v5 ? don't remember) and it plays a central role, like a core component in the product, especially now when the Exploit Blocker, Advanced Memory Scanner and Self Defense works as extension from the HIPS. I am no software engineer, but I don't think it's possible to just buy the code and throw it into their own program and expect it to work as is. And I assume it would take a good amount of time making changes to make it work with the rest of the ESET code. It's better if you make some suggestion to ESET on what changes you would like ESET to make to their HIPS in order to let them know what you expect from a HIPS system, how you would want it to work. If you think the HIPS is buggy, point out the bugs and let them fix them. Why spend money buying HIPS code when they can fine tune and improve what they already got. But as you know, nothing happens over night with ESET, so you have to be patient.

 

Oops!

One thing I forgot to do is exclude Emisisoft Anti-malware from the picture when I uninstalled EMET. That never occurred to me since I assumed EAM behavior blocker has little if any exploit blocking capability. So I created an EAM BB rule to allow all browser activity. With that enabled, I retested using the Surfright exploit test tool. Not good results. Eset only blocked the null page and load library test exploits.

So it was EAM's BB that was actually preventing the test exploit payloads from executing. That explains why the browser was not terminated at least. Interesting. Also EMET was interfering with EAM's behavior blocker and possibly not Eset's exploit and memory protection.

As far as Eset goes, I am pretty much back to square one in that the SurfRight exploit test tool cannot effectively test Eset's exploit and memory protection.

Also anyone who is using EAM/EIS and other anti-exploits together should take note. They also might be interfering with EAM/EIS behavior blocker.

 

Pretty much a total rewrite along the lines of Defense+ or Online Armor; hence my purchase suggestion. There should be no hidden default rules; those should all be transparent to the user and able to be supplemented if so desired. There should be capability to exclude signned system processes and the like in a single global command. Wildcard capability should be greatly expanded in the rules. I can go on but I think you can get my drift.

 

Are you sure a total rewrite is needed to make that happen ? I know that some are hidden, but are they not hidden to prevent the average user from fiddling around with them as they are meant to protect critical OS areas etc ?

But send your suggestions to ESET, they may not respond but they surely read what you have to say.

 

Shame @Marcos doesn't seem to get around Wilders much more.

 

In the Emsisoft forum, I have read a couple of posts from the Emsisoft employee that MBAE has issues with Emsisoft's products.

And here's one
http://support.emsisoft.com/topic/17786-scans-do-not-complete/?p=135546
(But since this thread is about ESET, then further discussion regarding this should be done elsewhere)

 

That is definitely safe to say. I did not realize what the name of the thread was. I read the last few post in the thread, and started contributing to the discussion not knowing what the thread tile was.

 

It's been my experience that Eset HIPS does very little without configuring it for yourself. The only problem with that is the HIPS does not work as expected after configuration. That's been my experience anyway. I would love to see Eset acquire Online Armor HIPS if they are capable of integrating it into ESS, but its hard to say how much work would be involved without seeing the code.

 

Also the retail and commercial versions of the HIPS are different. Although the GUI interface for the two products are very similar, the commercial version HIPS has features not supported in the retail ver. such as wildcard file names with having to enter a path name e.g. *.exe,*.scr, ................ etc..

It's obvious that the retail feature is pretty much a HIPS in name only; more akin to anti-executable software than a full featured HIPS.