Analysis and Exploitation of an ESET Vulnerability

Discussion in 'other anti-virus software' started by Minimalist, Jun 24, 2015.

  1. hamlet

    hamlet Registered Member

    Joined:
    May 10, 2005
    Posts:
    229
    Hi, itman. Thanks for posting all of the interesting information in this thread. How common are the types of exploits that your tool tests for? I guess my real question is, "should a person who is a safe Internet user be worried about this "feature" of ESET? Or, is this the kind of exploit that only shows up under rare circumstances? I am running a 64 bit system with ESET loaded at the moment. I may be the world's most boring and safe computer user, however. I don't want to be open to an easy exploit but I also don't want to go changing security software every time I read a new post at Wilders. :)

    Thanks again!
     
  2. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    Thanks itman for sharing.
    Who would know - protocol filtering interfering with exploit protection...
     
  3. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I have somewhat come to the conclusion that what is blocking the test tool exploits is not Eset's "exploit protection" but the advanced heuristics feature of the ThreatSense real-time engine scanning. By default AH is enabled for protocol scanning. And AH only works properly if Eset apps. are excluded from protocol scanning.

    Most of the Surfright tests are memory based exploits. The test tool is obviously doing nothing malicious to your system. So I doubt any Eset HIPS protection would be activated. In other words what is being caught is "bad behavior" from the browser and it is AH that is doing the mitigation; in this case stopping the calc.exe payload from executing. It is debatable if the browser memory injection is being detected and prevented. To do that, Eset would need a hooked .dll installed in the browser.

    So I guess Eset's "exploit" protection will not come into play unless some malware actually tries to modify something on your PC. Sounds to me they just "beefed up" the sensitivity level of the HIPS.

    Overall, I am not coming away with a "warm and fuzzy feeling" that Eset's exploit protection is adequate on x64 OS systems.
     
  4. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    That last post explains a lot. I've tried Surfright tests and all went trough. I thought that I either run the test tool wrong or my custom ESET's settings somehow broken it's protection. I never bothered to find the reason for failure, though.
    I'm really not disappointed by your results as I've never put much hope on that feature.
     
  5. SweX

    SweX Registered Member

    Joined:
    Apr 21, 2007
    Posts:
    6,429
    Yeah I know, and I have actually pointed out the lack of responses several times before to the officials, but there hasn't really been any improvement worth mentioning, so no need to do it again. But for everyone interest, I will post a quote in your thread on the forum and maybe Marek will stop by Wilders if he finds this interesting enough.

    They say they want us to post on their official forum, but if they don't respond then what's the point.
     
  6. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I will wrap this discussion up by correcting a previous statement. That is, eplghooks.dll is indeed a 64 bit .dll.

    I will use MalwareBytes Anti-Exploit as example here. Mbae_svc.exe is a 32 bit process. When mbae_svc.exe starts up however, it will spawn a 64 bit process called mbae64.exe. It is mbae64.exe that injects the 64 bit .dll called mbae64.dll into the 64 bit process being monitored. I believe the "bug" in Eset SS 8 is that ekrn.exe, a 32 bit process, is not spawning eh64.exe, Eset 64 bit helper driver, which in turn will load eplghooks.dll into the process being monitored. I see no evidence using Process Explorer of eh64.exe ever being started.

    Like I said previously, I did see the eplghooks.dll injection occur at least once many installs ago and at next boot time ended up with a corrupted Win 7 security driver and resultant OS recovery.

    Hopefully, Eset will fix this problem when ver. 9 is released.
     
  7. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I need to say something that is important.

    If you plan on using another anti-exploit, make sure it exceeds the current protection given with Eset's advanced heuristics with protocol scanning turned on. My testing of MBAE free yielded a IE 10 x64 failure rate of 50% using the Surfright exploit x64 test tool on my WIN 7 x64 platform. Also, my experience using both EMET and MBAE is that the other anti-exploit software will override any Eset processing. That is if the other anti-exploit doesn't catch the test malware sample, Eset will not either.
     
  8. RezaNugraha

    RezaNugraha Registered Member

    Joined:
    Jul 11, 2015
    Posts:
    1
    can someone help me how to install ESS
    I can't find Eset support here
    I got this message
    service 'ESET service'(ekrn) failed to start verify that you have sufficient privileges to start system service while installing
    and i already did manual uninstall via safe mode but still can't install it
     
  9. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    This sounds like a permissions issue on your PC. Since it is an installation issue and Eset offers free tech support, I would try to contact them first.

    You can also try Eset's support forum here: https://forum.eset.com/ . I have not found the forum to be very responsive; that is why I suggested contacting tech support directly.
     
  10. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    The answer to your question is a bit complicated.

    The way Eset's advanced heuristics with ports protected by protocol scanning, i.e. 80, 443, and 3128 by default, works is as follows according to the little info Eset has provided. Once exploit behavior is detected by the AH scanner, a connection via LiveGrid is established to further analyze if the behavior detected is malicious. Since my testing involved simulation software that I suspect Eset is aware of, I am assuming at this point they ignored it; i.e. deemed it safe. As such, neither the "threat" (the test tool) or the running process (IE10 x64) were terminated. However, AH did block the test exploit payload (calc.exe) from executing for every test which is the minimum mitigation you would want an anti-exploit to perform.

    -EDIT- I guess I should state what I didn't like from the testing. Eset blocked all desktop interaction with the suspected infected process (IE10 x64) but left the process running. As such, it is up to speculation if Eset upon receiving LiveGrid results would then terminate the infected process. Additionally, many malwares will attempt to interfere with network communication. This could lead to the LiveGrid inquiry/result not being sent/received and the infected process running for sometime unknown to the user.

    The only way to completely verify Eset's exploit protection would be to use something like Metasploit test tool: http://www.metasploit.com/ . This is the tool used by many security pros. And this tool only tests against know exploits. Maybe Kaffeine, a well know "in the wild" exploit expert will test Eset one day. Or, Eset will hire him to do penetration testing against their software.
     
    Last edited: Jul 11, 2015
  11. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Just found a recent exploit test done NSS Labs for Smart Security 8: https://www.nsslabs.com/reports/con...tion-test-report-eset-smart-security-exploits .

    I consider NSS Labs one of the best AV test lab out there. The result of the test were impressive indeed. The following sums up the report:

    ESET Smart Security 8 had 100% protection for 57 days of the 58-day test. The lowest protection score during the test time frame for ESET Smart Security 8 was 98.7%.

    Test Methodology here: https://www.nsslabs.com/reports/security-stack-test-methodology-v15. My only comment is the methodology is a bit dated i.e. developed in 2012.

    Note: The Eset test was done by NSS labs ad hoc. Eset did not pay for the test.

    -EDIT- Oops just noticed the test was for 32 bit OS. So 64 bit protection via AV lab testing has yet to be verified.
     
    Last edited: Jul 11, 2015
  12. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Well, I finally got eplghooks.dll to inject into explorer.exe and the browser.

    I became suspicious of the default HIPS rule where Eset drivers are specified along with all the other drivers. Why would Eset care about its own drivers? So I made a HIPS rule to allow all Eset processes. Rebooted and whalla, eplghooks.dll was injected. Like that?

    I suspect the culprit is eh64.exe but I am tired of trying to get this software to work properly. Tomorrow's cold boot will be the acid test to ensure loading of the hook does trash my OS again.

    -EDIT- Analyzed eplghooks.dll a bit more using Process Explorer. Opening it up in string mode yielded the fact that actually what is loaded is eplgOE.dll. This is only used for e-mail clients that Eset supports; Outlook Express, Window Live Mail, etc.. I use Thunderbird which Eset does not support anymore. So on my PC, no browser hooking will be performed.

    Bottom line - all Eset's exploit protection is heuristic based with analyzes done at the network level. Whether that is adequate for x64 based exploits remains to be determined. Personally, I trust Emsisoft's behavior blocker more for malware protection since it does hook the browser.
     
    Last edited: Jul 13, 2015
  13. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    One last test forgot about.

    I disabled exploit and advanced memory scanning and ran the Surfright x64 test tool exploit again. Guess what? Results were the same as when they were enabled. This proves that whatever Eset uses is not working for 64 bit exploits; at least test ones. Although advanced heuristics alone appear to at least stop most of the test exploits.

    Will probably reinstall EMET 5.2 based on this testing. Might just enable it for x64 IE 10 which is the only x64 Internet facing process I use. At least it's protection was better than MBAE free for the Surfright tests.
     
  14. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I decided to run one more test with the SurfRight Exploit Test Tool. This test was with Eset's exploit blocker and advanced memory scanner turned off. Disturbingly, the results were identical to that with those two features enabled for both the 32 and 64 bit exploits tests. How can that be? A few possibilities.

    1. Eset's exploit and memory protection just don't work on my PC. This is a distinct possibility since I see no injection of eplghooks.dll into any of the apps Eset's exploit protection is supposed to protect. As I explained previously, I am not sure that .dll is used by Eset's exploit protection. I have e-mailed Eset about particulars on what that .dll is used for. I do know that every other exploit blocker app currently injects its protection .dll/s into the processes it is monitoring.

    2. Eset's exploit protection ignores all the Surfright test exploits. I find this a bit hard to believe since every other anti-exploit app I have installed detects the test tool exploits.

    In any case, I have reinstalled EMET 5.2 since I know that does work against most exploits. It additionally protects apps that Eset's exploit blocker does not e.g. Thunderbird, etc.

    -EDIT-

    I just had an epiphany. Also, feel a bit foolish in that I mentioned initially that Eset's exploit blocking protection is done via advanced heuristics/DNA/Smart signatures using the web protocol filtering feature. The web access protection is provided by a filter Eset installs on your network adapter connection. Given that, exploit tests like the one Surfright provides are non-applicable to exploit protection equal to or similar to Eset's.

    The Surfright exploit test tool is directly interfacing with the browser to conduct its tests. In other words, it is bypassing the IP network adapter level where the Eset web filter resides. As such, all web access protection is being bypassed. The only Eset protection in effect is the ThreatSense realtime protection which is designed to check files; not web page content and access.

    The only way to effectively test Eset's exploit protection would be directly from the Internet. You can do so here: http://malware.wicar.org/ ; just make sure you read the disclaimer first.
     
    Last edited: Jul 20, 2015
  15. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I also came across an interesting comparative done in spring of 2014 by AV-Test on WIN XP for Qihoo's behalf:
    https://www.av-test.org/fileadmin/pdf/reports/AV-TEST_XP_Exploit_Test_April_2014.pdf

    This is the only comparative test I know of that separated the static versus dynamic components of exploits. Eset's performance was respectable if not stellar for the static exploit tests. It was sorely lacking on the dynamic tests. This leads me to believe that Eset's "advanced memory protection" is more of the "smoke and mirrors" protection variety.

    Product Name / Blocked Attacks (out of 54) / In %

    Avast Internet Security 2014 / 33 / 61,11%
    AVG Internet Security 2014 / 37 / 68,52%
    Avira Internet Security Suite 2014 / 37 / 68,52%
    Bitdefender Internet Security 2014 / 42 / 77,78%
    Eset Smart Security 7 / 31 / 57,41%
    Kaspersky Internet Security 2014 / 51 / 94,44%
    Kingsoft Antivirus 2013 / 48 / 88,89%
    Norton Internet Security 2014 / 54 / 100%
    Qihoo 360 Internet Security 9 Beta / 54 / 100%
    Tencent PC Manager / 10 / 18,52%


    When looking at the data a bit differently, an interesting observation can be made. The following table shows the results of 33 exploits where no obfuscation or evasion has been applied.

    Product Name / Blocked Attacks (out of 33) / In %

    Eset Smart Security 7 / 24 / 72,73%

    The results indicate that several products may have static detection for certain exploits or certain MetaSploit components (such as the payloads) only and are vulnerable to even basic obfuscation and evasion techniques. This assumption can be verified when looking at the results of the 21 samples that used obfuscation or evasion techniques.

    Product Name / Blocked Attacks (out of 21) / In %

    Eset Smart Security 7 / 7 / 33,33%
     
    Last edited: Jul 20, 2015
  16. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I finally received a reply from Eset tech support on what exactly is the purpose of eplghooks.dll process injection. The request had to go to the developers for a response. The below reply is a bit convoluted and I have given my observations and comments to each response.

    Thank you for contacting ESET Customer Care.

    eplghooks.dll serves when notifications about new processes does not work (Anti-Spam module functionality). It is tasked to report to ekrn when a new process is created with a new name.

    First, this .dll has nothing to do with anti-spam processing. It is part of the behavior blocking protection.

    The implication here is that the .dll is dynamically injected into every process on demand. I have not observed that behavior. When the .dll injection occurs, it always does so at boot time for a selected number of processes. Explained further below.

    "Is eplghooks.dll supposed to be injected into explorer.exe?"
    Not really. eplghooks.dll could be hooked on explorer.exe and also on other processes either (If so, then it is because the above information), but it is not a rule that it should be hooked.


    I have always observed that when injection occurs at boot time, it is explorer.exe that is injected along with most sub processes that run under it including your browser. The hooking occurs at explorer.exe sub process startup so I guess this is the on demand feature Eset was referring to. Additionally taskhost.exe is injected at boot time. That is it as far as process injection goes that I have seen.

    "On rare occasion, I have seen eplghooks.dll injected?"
    Yes, this is correct. Hook depends on, whether in case when notifications about new processes does not work.


    The injection is dependent on how you code your Eset HIPS rules. Last night, I changed my allow rules for EMET and Emsisoft to allow only with no selection for "all" for Files, Target, or Registry permissions. Low and behold upon first boot today, I saw eplghooks.dll injection. If I select "all" for the above permissions, no .dll injection occurs.

    The conclusion here is if eplghooks.dll injection is occurring, it a good way for determining if you have your other security software Eset HIPS exclusions properly configured. If properly configured and eplghooks.dll injection is still occurring after boot, I would start taking a close look at what is running on your PC.
     
    Last edited: Jul 23, 2015
  17. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    An update on eplghooks.dll activity.

    Over the weekend I was fooling around with Heaplocker; trying to get it to run to no avail for IE10. Performing that activity, I observed more that one instance of eplghooks.dll injected into explorer.exe and other related processes at reboot time. Appears that eplghooks.dll will be injected when Eset detects suspicious .dll loading at boot time. Definitely applies to my activity since I was attempting to load Heaplocker via AppInit_Dlls loading using the LoadDLLViaAppInit.dll from Heaplocker author.

    Good to know that Eset has backup protection to that given in the installed network filter. I would prefer that eplghooks.dll always be loaded at boot time. Appears to be no way to do that since most of Eset's .dlls are stubs and can't be registered.
     
  18. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I finally found a way to force loading of eplghooks.dll upon every boot. Also it gave me a lot of insight into how the Eset HIPS works. Creating one or more "ask" rules where monitoring of a source application is specified will cause the hook to load and be injected into non-system apps. An "allow" rule will not cause the hook to load. I also strongly suspect neither will a "block" rule.

    Also a bit odd is that monitoring of target areas; files, apps, and/or registry against all applications i.e. no source application is specified, will not cause the hook to load. This implies that Eset HIPS does do global monitoring of all apps in non-Interactive mode but only on a specific rule basis and only against specified targets. The HIPS will not monitor individual app behavior unless a source application rule is created at which time a hook will be generated by Eset and injected into non-system apps to do so. For example, I created a HIPS rule to monitor PowerShell activity. Eset inserts a hook into non-system apps to do so. If iexplorer.exe or taskhost.exe for example attempts to run PowerShell, I will receive an alert of this activity.

    The above implies that there is no global monitoring by the HIPS of new apps installed. They will only be detected if they perform malware activity against objects monitored by a HIPS predefined or user specified rule -or- if the HIPS is running in Interactive mode.

    Also the above ignores the impact of LiveGrid processing with it's interaction with real-time protection advanced heuristics (sandboxing) since that is separate processing.
     
    Last edited: Aug 1, 2015
  19. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Well, this hooking business starting acting up again .......... Since I have been able to duplicate this situation multiple times, I am pretty sure I have it nailed this time.

    There is a bug in the HIPS. I discovered it after deleting some rules, rebooting, and noticing the rules were still in effect. And yes, I made sure I did the confirmation and that the rules were actually deleted. It appears that when you add/delete and I suspect change rules, it screws up the hooking in Eset. In effect, there is no injection of eplghooks.dll into anything afterwards. I discovered that setting the HIPS back to default which is automatic mode will cause hooking to become effective once more. Resetting to default also keeps all your existing rules in place so there is no harm in doing so. Note that the reset needs to be performed after any change to existing HIPS rules.

    Also setting the HIPS to smart mode will disable all hooking. So in my opinion, you don't want to run the HIPS in smart mode until Eset fixes this.

    Again I believe hooking is required to support Eset's exploit protection at the HIPS level. The hook is inserted into explorer.exe at boot time and will be also injected in to your browser and other related processes upon execution.
     
  20. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    I have been using Eset for a long time, and I have never seen anything injected into Firefox since I have been using it. I don't recall checking explorer.exe before. I switched the HIPS to Smart Mode about a year ago. I will switch the HIPS back to automatic mode with rules, and reboot to see if that changes anything.
     
  21. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    Switching back to Automatic Mode with rules did not change anything. Eset Smart Security 8 does not inject into explorer.exe, or firefox.exe. I will try reverting my HIPS settings to default, and see if that works.
     
  22. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    Settings the HIPS settings back to default did not help either. Still nothing being injected into explorer.exe, or firefox.exe.

    If I get a response in this thread, and I don't answer back then you will know my internet is out. It has been going out all day. It goes out here everytime it rains nearby. I have to have the worst ISP in the country. It has been doing this for years, and their too incompetent to fix it.
     
  23. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I believe you need at least one ask rule to enable the hook. I know allow rules don't activate the hook and I suspect block rules won't work either. Below are my HIPS rules which are self-explanatory. You will note that I have no rule for explorer.exe, yet hooking is occurring.

    Eset-HIPS-Rules.png

    Eset-Eplghooks.png

    eplghooks-all.png
     
    Last edited: Aug 4, 2015
  24. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    Ok, I see. I was about to ask you about that after reading back a few post more into the thread, but my internet went back out again. It just now came back on. I will try that, and see if that works. If that's the case then I have to ask myself if that's poor design on Eset's part. The user should not have to make special changes to the configuration in order for the exploit module to work if it's enabled. Several users have asked how their exploit module works, but they were all given very vague answers. All the responses I have read were very vague anyways. If they ever gave a clear explanation of how their exploit blocker works then I would love to read it. If it's not injecting into processes then AFAIK it can only be blocking payloads that are binary, and not be blocking the exploit itself.
     
  25. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    I forgot to mention this in my previous post, but it makes it difficult to report bugs for the exploit module. Has Eset ever said if it is suppose to inject into firefox, IE, Chrome, Adobe Flash, Adobe Reader, etc. with default settings? Has Eset ever said if the exploit module is suppose to block binary payloads from the exploit, or the exploit itself?
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.