App Review The Comodo's challenge.

[Andy Ful]

Could this attack be blocked effectively by adding certain HIPS rules like (user) apps deny access to certain files or system resources. I'm wondering if one or more HIPS rules could defend this attack and if so which rules to add.

Yes. But you would have to know the details of the attack.

 

[ErzCrz]

Yes. But you would have to know the details of the attack.

I wonder what the result of the test would be if you sent Containment to "Do Note Show Elevated Alerts" to Block with that ticked so it blocks any untrusted program rather than running in Containment. Something I used to use in my setup awhile back.

 

[rashmi]

I wonder what the result of the test would be if you sent Containment to "Do Note Show Elevated Alerts" to Block with that ticked so it blocks any untrusted program rather than running in Containment. Something I used to use in my setup awhile back.

Selecting do not show elevation alerts just runs the unrecognized file with the chosen option for the setting. Comodo trusts or allows the attack file because the user is starting it, not an unknown program. Containment settings don't matter because containment doesn't come into effect in this case.

 

[ErzCrz]

Selecting do not show elevation alerts just runs the unrecognized file with the chosen option for the setting. Comodo trusts or allows the attack file because the user is starting it, not an unknown program. Containment settings don't matter because containment doesn't come into effect in this case.

Thanks, that's true and I get that. I was wondering whether the untrusted file would then still be blocked despite the containment service being disabled.

 

[Andy Ful]

I wonder what the result of the test would be if you sent Containment to "Do Note Show Elevated Alerts" to Block with that ticked so it blocks any untrusted program rather than running in Containment. Something I used to use in my setup awhile back.

Nothing will change because the file is not contained.

 

[ErzCrz]

Nothing will change because the file is not contained.

Thanks.

Yes, the file would not be contained because containment isn't being used and I get that this is still a bypass of Containment as the service is disabled but, am I right in thinking that the Document5 would still be blocked if you changed the setting to not show alerts and just block untrusted files?

Most of the time I prefer that a file is just blocked outright rather than run in a sandbox so I was just checking that this part of the containment element still blocks the untrusted file.

 

[Sunshine-boy]

Nothing will change because the file is not contained.

Can you pls test this malware vs 360 and Avast pro sandbox see if they can handle it?

 

[rashmi]

Thanks.

Yes, the file would not be contained because containment isn't being used and I get that this is still a bypass of Containment as the service is disabled but, am I right in thinking that the Document5 would still be blocked if you changed the setting to not show alerts and just block untrusted files?

Most of the time I prefer that a file is just blocked outright rather than run in a sandbox so I was just checking that this part of the containment element still blocks the untrusted file.

I doubt setting to not show alerts-block would block the untrusted file because, after all, it's a containment/virtualization setting and would require the virtualization service enabled for any action. And from memory: (1) I think that setting applies to only unrecognized files with elevated prompts, and Document5 doesn't require elevated rights. (2) I think to block unrecognized files that don't require elevated rights, you need to set Auto-Containment - Run Virtually (rule) - Action:Block. But I think it won't block Document5 (like it didn't contain Document5 in the tests) with the virtualization service disabled.

 

[rashmi]

Most of the time I prefer that a file is just blocked outright rather than run in a sandbox

I just checked this-
-if you want to "block" unrecognized files rather than contain, set Auto-Containment - Run Virtually (rule) - Action:Block. This setting also blocks unrecognized files with elevated rights, i.e., you don't need to change the containment settings.
-containment setting "do not show elevated prompts-block" will only block unrecognized files with elevated rights.

 

[ErzCrz]

I just checked this-
-if you want to "block" unrecognized files rather than contain, set Auto-Containment - Run Virtually (rule) - Action:Block. This setting also blocks unrecognized files with elevated rights, i.e., you don't need to change the containment settings.
-containment setting "do not show elevated prompts-block" will only block unrecognized files with elevated rights.

Nice one, thanks for the clarification. I'll have to look at implementing this block on next install.

It still doesn't solve the bypass but if at least the Document5 is blocked from running even though containment service is disabled, that's at least useful.

 

[Andy Ful]

It still doesn't solve the bypass but if at least the Document5 is blocked from running even though containment service is disabled, that's at least useful.

Document5 will run without a problem (as I already explained).

 

[ErzCrz]

Document5 will run without a problem (as I already explained).

Interesting. Thanks for the info. Comodo is that configurable, I was trying to look at it from a different angle. The problem with LOLbins is even if you'd created a File Group in File Ratiing settings for all the system32 LOLBins and set as untrusted or unknown you run into all sorts of issues.

Anyway, well done for bringing this to light and hopefully it's something that can be improved on in CIS / CF to protect itself from such attacks.

 

[rashmi]

Interesting. Thanks for the info. Comodo is that configurable, I was trying to look at it from a different angle. The problem with LOLbins is even if you'd created a File Group in File Ratiing settings for all the system32 LOLBins and set as untrusted or unknown you run into all sorts of issues.

Anyway, well done for bringing this to light and hopefully it's something that can be improved on in CIS / CF to protect itself from such attacks.

In Script Analysis, you can add the missing ones.

 

[ErzCrz]

In Script Analysis, you can add the missing ones.

That's true. I'll experiment with adding all the LOLBins and then enable Embedded Code detection in batches to test out the impact.

 

[Andy Ful]

That's true. I'll experiment with adding all the LOLBins and then enable Embedded Code detection in batches to test out the impact.

Do you know how many LOLBins are in the system?
Do you know how many programs trusted by Comodo can be used instead of LOLBins?

 

[ErzCrz]

Do you know how many LOLBins are in the system?
Do you know how many programs trusted by Comodo can be used instead of LOLBins?

Over 500 and just because a file is trusted doesn't mean it's allowed access everywhere. Just look at explorer.exe that gets a HIPS block when you import a configuration with hips enabled. What there needs to be is a rule or built in protection for Comodo files and processes but I can only see that being capable with HIPS or a separate containment rule. I'm testing Beta 3 now so will just see what options there are but at the end of the day I can always just harden the system with one of your programs and I'm covered

EDIT: I like to try and find solutions to things and so far not finding one within CIS but I'm not a programmer or expert, just enjoy what programs like this can do. I like my current MD/DefenderUI/CyberLock/WFC configuration but when some new bypass is identified, I like to see if I can find some sort of a solution with in the program itself as a temporary fix until Comodo comes up with a solution. Anyway, got to get on with work.

 

[Vitali Ortzi]

Could this attack be blocked effectively by adding certain HIPS rules like (user) apps deny access to certain files or system resources. I'm wondering if one or more HIPS rules could defend this attack and if so which rules to add.

Hopefully he decides to share the attack details onces it's patched by a few vendors but seems he is afraid it would be used in malicious ways
(Personally I love project zero 90 day policy as it forces devs to fix the issues)

btw the excuse of because a human executed the file and it gained privileges (this case by the user and not an exploit)
Is ridiculous windows is very prone to escalations and memory based attacks (overflows)

 

[Practical Response]

Hopefully he decides to share the attack details onces it's patched by a few vendors but seems he is afraid it would be used in malicious ways.

Only sharing with the product devs is the responsible thing to do with such an item.

 

[cruelsister]

Best Practice for a person (or cat) that writes a new malware file is to never ever share it routinely and not even distribute it to a VT or similar as doing so could potentially lead to unforeseen consequences.

Even sending the exact file to a developer is not necessary as long as some explanation and video evidence of the attack is shared. That would normally be enough for those with the eyes to see (and for those still blind sending the actual file may still be of little value).

In the case of Comodo, weaving the malware with the UAC and Admin override along with the payload and trigger into a single file to be run without detection may be a bit more problematic (just sayin').

 

[Andy Ful]

I agree with @cruelsister. It is not a problem to bypass the Comodo protection in the cruelsister settings and without the UAC bypass.
If I would try also to apply the UAC bypass, the attack could be contained by Comodo. I think that such an attack would also require lateral movement or exploiting a legal application.
In my opinion, the attack can be dangerous in targeted multistaged attacks on organizations. The idea is kinda similar to the attacks that abuse Microsoft Defender's exclusions.