DoubleAgent attack leverages Microsoft's Application Verifier The Microsoft Application Verifier is a tool that allows developers to verify code for errors at runtime. The tool ships with all Windows versions and works by loading a DLL inside the application developers want to check.
Cybellum researchers discovered that developers could load their own “verifier DLL” instead of the one provided by the official Microsoft Application Verifier.
Simply by creating a Windows Registry key, an attacker could name the application he wants to hijack and then provide his own rogue DLL he’d like injected into a legitimate process.
Several antivirus makers affected
Cybellum researchers say that most of today’s security products are susceptible to DoubleAgent attacks. The list of affected products includes:
Trend Micro (CVE-2017-5565)
“We have reported [DoubleAgent to] all the vendors more than 90 days ago, and worked with [a] few of them since,” Michael Engstler, Cybellum CTO, told Bleeping Computer in an email.
At the time of writing, “the only vendors that released a patch are Malwarebytes (version number: 3.0.6 Component Update 3), AVG (version number: 16.151.8007) and Trend-Micro (should release it soon),” Engstler added.
New Attack Uses Microsoft's Application Verifier to Hijack Antivirus Software
Will COMODO be able to stop DoubleAgent dead in it’s tracks before DoubleAgent attacks it?
Will Comodo allow an unknown app to create a registry key?
Already reported here
Its funny how they claim that Comodo is vulnerable but I bet they didn’t even try or if they did, it was sandboxed and their tool reported a “success” without actually checking to see if it really did succeed.
No we are not vulnerable to this AppVerifier injection. Michael [from Cybellum] contacted us on this issue at our security response email, and we had a long discussion on the topic.
The claim was: Malware can use this registry key to inject arbitrary code into COMODO processes and hence disable the protection. DLL injection through AppVerifier registry keys has been around since Windows XP i.e. the last 10 years, and CIS [Comodo Internet Security], by default, protects these keys against malicious modifications already. Check the attachment CIS_protected.png. In order for the attack to be successful, malware has to write to this registry key, and CIS already protects against this by default. There are actually hundreds of similar ways of injecting into other processes, and I am not sure other AVs are even aware of them.
Most of the disagreement comes from not understanding how CIS layered defense works and assuming CIS is like the classical antivirus products mentioned in the original article. Nevermind protecting itself against such attacks, CIS protects EVERY other application against such attacks too.
For this attack to be successful, the malware author should be able to bypass CIS protection. CIS, by default, allows only whitelisted applications to modify such critical keys. Non-whitelisted applications will be either blocked or sandboxed, rendering the attack ineffective.
To his credit however, during our discussions with Michael[from Cybellum], another attack vector was disclosed to us. This can cause problems with default configuration so we will be addressing it with an update in April. We will be giving more details on it with the release.
Edit: Fixed grammatical errors
Thanks for the update :-TU. Is CCAV protected against this threat? If not, is CIS protected under the default configuration? (isn’t HIPS disabled by default?) Please advise as I just want to use the best security (inc. configuration) that Comodo has to offer.
Great to know some news about upcoming releases of CIS :-TU
By the way, default configuration is not advisable, it comes with too many flaws…
I’d suggest any CIS/CFW/CAV user to switch to Proactive Security configuration and then fine-tune it
CCAV will run all unknowns in the sandbox so again it shouldn’t be affected. As for CIS you should switch to the proactive configuration as pointed out by Jon79.
One addition: CIS will also sandbox unknowns by default. Even wihtout proactive config, it will still sandbox.
Thanks egemen for the response and clarifications on this matter. :-TU
Sure Np. I appreciate our deep tehcnical responses. Very impressive.
HAve you noticed new rule in CIS 10? It is has a new rule saying sandbox any unknown introduced less than 3 days ago.
That’s at default configuration, on Proactive there’s no time limit
For a great setup of CIS, please check this Comodo Firewall 10 Setup - YouTube
Sure. Thats why Vault 7 is afraid of you guys
Thanks for the confirmation futuretech.
It’s Michael from Cybellum here.
First of all I would like to give a lot of credit to Comodo as it was one of the most challenging antiviruses to attack with DoubleAgent.
Comodo implemented a very interesting feature called CIS Protected Registry Keys which in fact was supposed to block DoubleAgent-like attacks.
We struggled at the beginning and indeed Comodo managed to block most attempts to attack it via DoubleAgent.
It was tricky, but eventually we succeeded, and Comodo is vulnerable to DoubleAgent just like all the other antiviruses.
I took the time and effort to upload a POC video showing DoubleAgent successfully attacking Comodo DoubleAgent Zero-Day Attacking Comodo Antivirus - YouTube
This video was done a few minutes ago, so it obviously affects the latest version of Comodo.
The Comodo attack is the only one that doesn’t use our publicly available POC code, but rather a different private code.
We decided not to share the private code in order to protect Comodo users, but Egemen (from Comodo) have received it and is aware of it.
Egemen has done a great work communicating with us, and hopefully a new patch would be released soon to close Comodo’s vulnerability to DoubleAgent.
Co-Founder & CTO, Cybellum
That’s great. Welcome to the forums, Michael. I’m looking forward to your bug reports.
It is a bit unclear to me how the issue relates to Sandbox component. By the way, I agree that DLL shouldn’t be loaded in such a way. So… what about browsers? Are these vulnerable from that perspective? (as you probably know there is module blacklisting/whitelisting)
Indeed. Quite annoying. Why? (although I have some ideas in mind)
Correct. The PoC we have is a new COMODO specific issue which can allow attacker to do a few things with default configuration. Default config needs to be slightly changed. See below for configuration changes to cover this PoC as well.