Bug? ekrn.exe can be terminated by users!

Hi all,

I was very surprised when I came across this on the official NOD32 Chinese forum.

OK, here's the deal.
When you load taskmgr in windows, click the "Processes" panel to see all the processes that are running. You'll notice that only egui.exe is shown by default, ekrn.exe is nowhere to be found. But if you click "Show processes from all users", it'll appear (this is Vista).

Normally, if you select ekrn.exe and "End Process", nothing happens - ekrn.exe remains running. Now you open your ESS installation folder (X:\Program Files\ESET\ESET Smart Security where X being your drive label), right click on ekrn.exe and select rename. Give it any name you want as long as it's different from its original name (ekrn.exe). Now try to terminate the ekrn.exe process in taskmgr again and... it works! ekrn.exe is gone!

Now if you bring up the ESS window from your systray again, you'll notice that nothing works. Although the interface is still intact, nothing internal is running. For example, if you click Protection Status -> Personal Firewall, nothing will be listed.

The end result? Well, I was a little comforted when I learned that once ekrn.exe is terminated, internet access is cut off completely so that any malware that phones home wouldn't work. But if it were a virus, the damage would have been done. Oh and of course, you can get back on the internet after a reboot (Log off then back on doesn't work. You have to reboot.)

I'm running Vista Business with ESS 563 and have personally tested the above process myself. If you don't know what I'm talking about, just try it, you'll see what I mean.

So far I don't have a solution to this but I did find a little workaround.
Provided you are running Vista and have not had UAC turned off, set your "X:\Program Files\ESET\ESET Smart Security" folder security as the screenshot. Assign Full Control to SYSTEM and Administrators and leave only the following checked for Authenticated Users and Users:
1. Read & execute
2. List folder contents
3. Read
This way, if any attempt was made from a 3rd party to rename any file inside the folder, UAC will prompt you for confirmation.

http://www.ffximars.com/ESS.Folder.Security.jpg

 

It's getting pretty late today so I'm going to hit bed.

Let me know if you need more screenshots. I'll get on them when I get back home from work tomorrow.

 

I confirm this on Windows XP SP2. It's possible to rename ekrn.exe and then stop the process. All protection is gone then, and while HTTP and POP3/SMTP protocols don't work then, my torrent client was able to download and upload data to previously acquired peers (it couldn't make connection to the trackers.) The tray icon doesn't go red and even opening the application doesn't give a hint that something's wrong, unless you try to run a scan or change settings. It says that maximum protection is ensured.

I've seen other security products which deny access to their processes and they can't be terminated, isn't there a way to do that with ESS/NOD32? And in no way should it be possible to rename the ekrn.exe file, while Windows is running.

 

This is one of the worse security risk I have ever found on Eset!! It is absolutely ridiculous that you can terminate the service of ESS. If you take into consideration that when you put your trust into a Security Suite usually this is your first line of defense this is outrageous!!!
I was able to replicate this on my XP and I can say that unless there is a clear answer from Eset nobody should run this product.

 

Here's a proof of concept - takes just two simple commands in a .bat file to disable completely ESS:

Code:

ren %SYSTEMDRIVE%\PROGRA~1\ESET\ESETSM~1\ekrn.exe ekrn.bak
%systemroot%\system32\taskkill /IM ekrn.exe /f

To undo, run the following commands:

Code:

ren %SYSTEMDRIVE%\PROGRA~1\ESET\ESETSM~1\ekrn.bak ekrn.exe
net start ekrn

You realize that the .bat file could be programmed to then download a real viral payload off some server and run it without any problem.

 

This is shocking.

Also works for ESET Antivirus (as expected).
Hopefully ESET can comment on this, and fix it as soon as possible!

I may have to look elsewhere if not.

 

I think you'll find that if you're running as Administrator you can do anything you want; as it should be. Prime reason Administrator user should be highly restricted; even solo online.

 

That is an entirely different subject, and you're right. But the fact is that other security solutions with a solid self-protection can't be disabled so easily even with administrative privileges.

 

True.

But the thing is, I'm not. I'm running Vista under a Users account.

 

rahx, have you made a support ticket about this problem (via the "Contact Customer Care" section of the program)?

I am also able to confirm that this problem does also exist with ESET NOD32 Antivirus running on Vista x64.

Although, I'm greeted with a UAC prompt when I try to rename ekrn.exe, I am able to do it by saying "Yes" to UAC, then terminate the service after renaming it.

I can then download the EICAR test file without any interruption from anything.

Hopefully this can be sorted out!

 

Hi _Rupert_,

I haven't submitted a ticket yet, but guess I should. Will do that shortly.

As for the UAC prompt, as long as it prompts you when you try to rename it, you should be fine. Because if any 3rd party program tries to rename it with UAC enabled, they will only get an error #903 - Elevated Permission Required.

 

I don't think a support ticket is necessary, this is not a bug. It's just a design flaw which should be addressed as soon as possible.

 

Be nice to have some input from ESET staff on such an important issue. This is after all their support forum.

 

Wow Not good and Eset needs to respond to this Asap.My confidence with eset lets say just fell off the pedestal.

 

Don't let anything bad in and you won't have a problem.

 

This is not a bug but as GaryRW wrote , this is the Administrator's power . Administrator can do anything with the machine no matter the self defences . I am Administrator and I can first stop self defence , then perform the desired task . Since I can stop the self-defence , anything (everything) in my account (in my admin account in XP) will have the same privilages so that everything can stop the self defence , so self defence is pointless.

Self Defence is more marketing than real feauture

 

Problem is that what it takes to shut ESS and EAV down is now shown to be something fairly simple.

Under XP you have no UAC to save the day but let's be honest, how long will it be before someone beats UAC in Vista ?

Seems to me (I'm no expert) that what is needed is some self monitoring where the running ekrn monitors and forbids renaming/deleting of itself (ekern.exe). If you really need to delete it then you can start in safe mode and do so when the application is not running.

 

As I said, Administrative privileges are not a must in this case.

On either XP or Vista, as long as EAV/ESS is installed on drives other than C: and does not have the proper folder security settings (C: usually does), even Users can terminate ekrn.exe.

And if you tried to stop some other security software on the market (eg. Outpost), you'll find that it is not possible to do so even if you are logged in as a member in the Administrators group.

 

You realize that if ESS can be disabled without getting infected with anything, you can't prevent anything bad from getting in afterwards?

Like rahx said, it's impossible to terminate the self-defence of other security products except by using the GUI. Another one I recently tried is BitDefender 2008, its process can't be terminated even if you're the Administrator, and there is no way to disable the self-defence from the program settings. What's the point in denying there is a problem with ESS?

 

I've just logged onto my sons "user" account, gone to task manager found ekm.exe and stopped it dead. systray icon disappeared as well. TBH ESS is going to disappear for good of my PC and many others for that matter.

 

Exactly.

Many of these other products, in which the protection can only be terminated from within the GUI also ensure that the mouse clicks are "real" within the GUI.
And so, for example, you wouldn't be able to terminate the protection of the program via remote access, even when you're using the GUI.

This is disappointing. The fact that ekern can be renamed whilst it's running boggles the mind. I won't feel as secure as I felt before realising about this until it's been fixed.

 

I totaly agree with bluesprite. I am a loyal nod user so not to defend other security apps but If it can be disabled as said the virus protection to me seems like a big security Hole.admin or not we should not be able to disable It only from the Gui. It should have self protection against.If this issue and it is I will no longer be a loyal subscriber.just my 2 cents for whats is worth.ps thanks rahx for the Heads up sad to here but great job.

 

I cannot confirm that. I created a limited user account and another power user account for the purpose of testing (Windows XP). Ekrn.exe can't be renamed or terminated from those types of accounts. But that's not comforting, as majority of users run Admin accounts. And in Vista, there's no need for a hacker to bypass the UAC, users who do a lot of admin tasks will disable it themselves after a while. It can get on one's nerves pretty quickly.

edit: correction, you can rename the ekrn.exe file as a power user.

And yes, you can kill the egui.exe process but that doesn't affect the protection.

 

A nightmare scenoiro for ESET.

Now I was fiddling last night and installed another AVS in error, ie not removeing ESS. The only way to save the day was to shut down evm.exe and TBH I didn't bat an eyelid, even though I couldn't do the same to the other AVS. So I found the issue 24hrs ago. It was first reported here at 7.50 GMT and at 2240 GMT it still is not fixed.

I can't beleive this wasn't spotted by the Beta testers either. Sorry but if it isn't fixed soon I'm out of here.

Edit: you can also kill the egui.exe file.

 

It's not a secret that you can kill ekrn.exe, but it's an NT service and it's set to restart automatically, so no loss of protection, although I'd rather have it un-killable. Real problem starts when you first rename the file, then it obviously can't be restarted anymore...