Zero-Day Exploit

[zero_day 1]

First US-CERT issuing a warning to ESET. Now this. Yes ESET is vulnerable.
https://cybellum.com/doubleagent-taking-full-control-antivirus/

Why the hell isn't ESET things that are recommended by Microsoft?

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

[Marcos 5,451]

1, In order to inject a fake verifier dll, one would have to modify values for ekrn.exe and egui.exe under IFEO but these have been protected by self-defense since v4.2.

2, We are aware that some non-crucial processes are not currently protected by self-defense, however, in order to modify the registry an attacker would have to gain admin rights. Even if that happened, it wouldn't make much sense to spend time injecting a malicious dll into an unprotected less important process just to disable protection for instance, as this could be done directly via gui once an attacker gains admin rigths. Needless to say, that in such case he or she can do much more damage to the system or data then just disabling the AV.

3, They claim: "Microsoft has provided a new design concept for antivirus vendors called Protected Processes. The new concept is specially designed for antivirus services. Antivirus processes can be created as “Protected Processes” and the protected process infrastructure only allows trusted, signed code to load and has built-in defense against code injection attacks. This means that even if an attacker found a new Zero-Day technique for injecting code, it could not be used against the antivirus as its code is not signed. Currently no antivirus (except Windows Defender) has implemented this design. Even though Microsoft made this design available more than 3 years ago."

Really?

 

On systems with ekrn running as a protected service, unprotected processes have no access to it.

[zero_day 1]

Then someone should inform them.

[itman 1,801]

Eset should demand a retraction from the author.

Vulnerable Antiviruses

The list of vendors that have been tested and found to be vulnerable to DoubleAgent.
The tests were done on the latest version of the vendor on Windows 10 x64 using our POC code.

Avast (CVE-2017-5567)
AVG (CVE-2017-5566)
Avira (CVE-2017-6417)
Bitdefender (CVE-2017-6186)
Trend Micro (CVE-2017-5565)
Comodo
ESET
F-Secure
Kaspersky
Malwarebytes
McAfee
Panda
Quick Heal
 Norton

BTW - Eset ver. 10 does run as a Level 0 protected process, the same level as System as shown in the below screen shot.

Appears CERT is rapidly descending into "toilet bowel space" these days. Or more likely, Microsoft recently made a sizable contribution to Carnegie Mellow.

Edited March 22, 2017 by itman

[zero_day 1]

Well that's fine and dandy that it runs as PsProtectedSignerAntimalware-Lig but has it been tested?
https://github.com/Cybellum/DoubleAgent

[itman 1,801]

3 minutes ago, zero_day said:

Well that's fine and dandy that it runs as PsProtectedSignerAntimalware-Lig but has it been tested?
https://github.com/Cybellum/DoubleAgent

Please do and post back your results.

[zero_day 1]

4 minutes ago, itman said:

Please do and post back your results.

Nice try.

[Peter Randziak 1,181]

AS Marcos stated, you need to have admin rights to write required registry entries to perform this type of attack. 

The registry entries for ESET service (ekrn.exe) and ESET GUI (egui.exe) are protected by the Self-defense as mentioned.

I tried myself the "rename" workaround, they mentioned in the technical analysis on Win7x64 (so without Protected service available) and it was blocked by Self-defense successfully.

[MichaelEngstler 0]

Hi Guys,

It's Michael from Cybellum.

ESET has done a great job in designing its AV and its self-protection, but we found a few issues that needed to be fixed in order improve the way ESET protects itself. That's why we decided to contact ESET at November 2016 and work with them together. We believe our mutual work has improved ESET's security, and even received as gratitude an official acknowledgement from ESET for our discovery (attached).

What were these issues?

1. Non Protected Processes.

We found a list of processes that are not Protected Processes (including egui.exe, attached) and therefore could suffer from code injection vulnerabilities like DoubleAgent.

More over, most of these processes registry keys where not protected by ESET Registry Protection and could be modified by an attacker.

We knew from the beginning that ekrn.exe was a Protected Processes and have never stated that it's vulnerable, our focus was rather on exploiting the non Protected Processes.

2. ESET Registry Protection Bypass.

Although most of the time ESET did manage to protect its most crucial keys (ekrn.exe and egui.exe) on some occasions it failed to protect them leaving an open door for attackers to directly attack ekrn.exe and egui.exe.

We are not sure why this is happening, but I'v created a POC video demonstrating an ESET Registry Protection Bypass using DoubleAgent.

This video was done a few minutes ago, so it obviously affects the latest version of ESET.

 

It's important to note that except from these issues, ESET has done a very good job protecting itself and managed to block everything we threw at it.

ESET has also done a great job communicating with us, and hopefully a new patch would be released soon to close the issues that were left open.

 

Michael Engstler,

Co-Founder & CTO, Cybellum

Edited March 23, 2017 by MichaelEngstler

[Marcos 5,451]

Hi Michael,
We appreciate your response here. My understanding is that injecting a malicious dll into ekrn.exe (the core process running under the local system account) is not possible due to self-defense. This protection was implemented in v4.2 several years ago.

What was possible (until yesterday and on systems where ekrn is not running as a protected service) was injecting a possibly malicious code into an unprotected process that communicates with ekrn, e.g. in order to disable protection or change settings. However, this cannot be done without administrator privileges. In my opinion, once an attacker gains administrator rights he or she can do virtually whatever they want; including disabling an AV or uninstalling it. Injecting a dll into a non-protected process seems to me like a redundant intermediate step requiring additional effort.

[itman 1,801]

I will say this. I did point out that equi.exe was not running as a protected process a few months back in the forum

Launching a child process as protected

The new security model also allows the anti-malware protected services to launch child processes as protected. These child processes will run at the same protection level as the parent service and their binaries must be signed with the same certificate that has been registered via ELAM resource section.

In order to allow anti-malware protected service to launch child process as protected, a new extended attribute key, PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL, has been exposed and must be used with the UpdateProcThreadAttribute API. A pointer to the attribute value of PROTECTION_LEVEL_SAME must be passed into the UpdateProcThreadAttribute API.

Notes:

• In order to use this new attribute, the service must also specify CREATE_PROTECTED_PROCESS in the process creation flags parameter of the CreateProcess call.
• You need to have your service binaries signed using the /ac switch to include the cross-certificate to chain it up to a known CA. Self-signed cert without proper chaining to a known root CA will not work.

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

Edited March 23, 2017 by itman

[Peter Randziak 1,181]

Hello itman,

thank you for sharing this interesting piece of info.

We are aware of this possibility and we have it in plan to look into it, but it probably won't be easy so no promises.

I still remember the issues we had after enabling Protected service for the ESET service ekrn.exe,... 

Regards, P.R.

[itman 1,801]

57 minutes ago, Marcos said:

What was possible (until yesterday and on systems where ekrn is not running as a protected service) was injecting a possibly malicious code into an unprotected process that communicates with ekrn, e.g. in order to disable protection or change settings.

Dang! I forgot to create a HIPS rule previously to prevent this. Glad Eset now created default rules for same.

[itman 1,801]

2 hours ago, Marcos said:

However, this cannot be done without administrator privileges. In my opinion, once an attacker gains administrator rights he or she can do virtually whatever they want; including disabling an AV or uninstalling it.

Problem is that due to how "insecure Windows really is" malware is increasingly hijacking system utility processes that perform hidden privilege escalation. Most of this can be stopped by setting UAC to maximum level but most users don't even know what UAC is let alone how to reset it. And if they did know how to set it to maximum level, they would reset to default because they were annoyed by the increase in alerts.

[cyberhash 201]

It's a vulnerability that's been in windows for over 15 years. The reason why its making a headline is that it uses an AV product as the middleman now.

Guess everyone has a part to play ........

Microsoft trusts AV vendors
People trust their AV Product that has Admin rights to system (as it stops the bad stuff)
 

[Peter Randziak 1,181]

Hello guys,

we published a customer advisory covering this topic:

 

Regards, P.R.

[itman 1,801]

9 hours ago, Peter Randziak said:

Hello guys,

we published a customer advisory covering this topic:

 

Regards, P.R.

Just ran my own tests including the registry File Execution Options rename "balony" bypass. Looking good

[zero_day 1]

I wonder if Atom Bombing would succeed on ESET ESS?

Edited March 25, 2017 by zero_day

[itman 1,801]

12 minutes ago, zero_day said:

I wonder if Atom Bombing would succeed on ESET ESS?

Not the Dridex ver. 4 malware that use it since Eset blocks it by sig. detection.

Now in regards to the next malware that employs it, we'll have to wait and see. Suspect Eset and most other security vendors have updated their exploit protection to detect the API's used by this latest atombombing malware variant.

[zero_day 1]

2 minutes ago, itman said:

Not the Dridex ver. 4 malware that use it since Eset blocks it by sig. detection.

Now in regards to the next malware that employs it, we'll have to wait and see. Suspect Eset and most other security vendors have updated their exploit protection to detect the API's used by this latest atombombing malware variant.

One would expect they would monitor these API's in the first place.