Software Review Comodo Firewall Bypassing a Bypass

[cruelsister]

I would expect from the Untrusted level to reject the elevation request even if the user accepted the request

I wouldn't. Such an alert should always occur (without respect to the Containment level), with the default action being Block.

This tweak will introduce more weaknesses than is worth.

As it actually prevents UAC from disabling abilities of the Anti-Malware application being relied on, it most certainly is worth it. As to the implied weaknesses of making the reg edit (with UAC ALREADY being set at Never Notify), I'm personally not aware of any, are you?

 

[Andy Ful]

I wouldn't. Such an alert should always occur (without respect to the Containment level), with the default action being Block.


As it actually prevents UAC from disabling abilities of the Anti-Malware application being relied on, it most certainly is worth it. As to the implied weaknesses of making the reg edit (with UAC ALREADY being set at Never Notify), I'm personally not aware of any, are you?

I already mentioned it. When Windows starts it runs Explorer shell with high privileges due to that reg tweak. So, almost all applications/exploits/malware also run with high privileges (except rare processes compiled with restriction to run only with standard or lower rights). Malware and exploits do not need privilege escalation or UAC bypasses to run with high privileges, just by applying that reg tweak.
For example, when you run the web browser it will be allowed by Comodo, and some web browser's processes will run with high privileges due to that reg tweak. If exploited, the exploit will also run with high privileges.

That reg tweak would be OK, if Comodo could detect/block/contain all malware and exploits. But we know that this is not true neither for malware nor for exploits (system exploits or exploits of benign applications).

What Comodo settings are good enough to safely apply that reg tweak? The @cruelsister-like settings are not good enough:

1. The containment can be avoided by DLL hijacking.
2. The containment can be avoided by some signed malware.
3. Comodo can be bypassed by many fileless exploits/malware.
4. Comodo can be silently dismantled by Comodo challenge. Without this tweak, some users can stop the attack due to the UAC alert.

In all those cases, the malware/exploit has much more chances to be executed/undetected because it does not have to use privilege escalation or UAC bypass to obtain high privileges. Without that reg tweak the malware must use additional/special/suspicious code so the AVs have more chances to detect it. In my tests with Comodo challenge, I intentionally did not use UAC bypass, because it would make the attack more detectable.

At home, you will have more examples of malware from points 1-3 because such malware is created without knowing the target. On the contrary, the malware with a special Comodo bypass is virtually nonexistent.

 

[cruelsister]

Comodo can be bypassed by many fileless exploits/malware

A single example would be of value.

 

[Andy Ful]

A single example would be of value.

Two examples were already posted.
1. Comodo challenge.
2. DLL hijacking used in the bypass. It was not contained and allowed to run TDSSKiller. So, DLL hijacking vector is not sufficiently covered by Comodo.

No offence. By writing that many fileless exploits/malware can bypass Comodo (also in your settings), I did mean the attackers who are motivated to target Comodo users. It does not mean that Comodo is routinely bypassed in the wild, but rather that is not so strong to use the reg tweak that disables LUA. This is probably the reason that Comodo does not use this tweak, and it was not recommended by the Comodo staff - even if it could improve the containment.
If I correctly recall, your settings do not use HIPS and you do not tweak the Script Analysis Settings. So, many fileless attacks will not be contained, as in the case of Comodo challenge. After applying HIPS and Script Analysis Settings, Comodo can probably block most of the fileless attacks (like some variants of Comodo challenge), but loses much of its usefulness.

 

[cruelsister]

Two examples were already posted.
1. Comodo challenge.
2. DLL hijacking used in the bypass. It was not contained and allowed to run TDSSKiller. So, DLL hijacking vector is not sufficiently covered by Comodo.

1). I don't have the C Challenge file so can't speak to it.
2). Regarding this bypass- the malware used essentially is 2 components. The POC is the trigger and if allowed to proceed ANY added file, Benign or malicious will also proceed. If the POC is prevented from running, no subsequent payload can proceed.

Comodo ON ITS OWN will prevent the POC. The issue is that when UAC (which interferes with comodo) this PARTICULAR mechanism will be allowed as containment will be messed with. But certainly not a large issue, and certainly it gas nothing to do with dll's

 

[Andy Ful]

2). Regarding this bypass- the malware used essentially is 2 components. The POC is the trigger and if allowed to proceed ANY added file, Benign or malicious will also proceed. If the POC is prevented from running, no subsequent payload can proceed.

Here is the original attack flow:
Run POC -> POC can create services outside containment through magic -> Use service(to run curl.exe) to download the payloads ->
-> Use service to run a file trusted by Comodo and do dll hijacking(the bad dll released escaped.txt) -> Run tdsskiller -> Comodo dead

As we can see Comodo did not detect or contain DLL hijacking with bad DLL. It is also common for other AVs, so DLL hijacking popularity is growing.

The modified attack flow:
Exploit (system or benign application) -----> Buffer overflow -----> run shell code -----> create service ----> use service to download the payloads ----> DLL hijacking (ransomware, info stealer, etc.)

In the modified attack, the malicious code is in the DLL (no other file is used to avoid detection/containment).
Such attack can bypass Comodo without triggering containment, especially when HIPS is disabled or in Safe Mode. The attack is much easier with disabled LUA, because the shell code runs with high privileges. Without this tweak, the exploit needs also another exploit (privilege escalation) to create the service. Exploits without privilege escalation are common. Exploits with privilege escalation are rare and quickly patched.

You are an active member on the Comodo forum, so it would be interesting to ask the Comodo staff why they do not disable LUA to improve the containment in Limited, Restricted, and Untrusted settings.

 

[ErzCrz]

I wonder what affect, if any, changing the CF exes' to Compatibility - Run as Administrator would have. Probably none, just thinking out loud and I'd probably just set Do not show elevated privilege alerts to Block.

 

[cruelsister]

The POC is the loader and can do various things. The way to stop it is by disabling UAC in the registry. Then Cmodo can operate as it should and will block the loader from doing anything.

It really is a simple as that- no run as admin needed, no dll hijacking, no service created, no nothing else. Allow UAC to screw with Comodo and whatever the POC is coded to do can be accomplished.
Prevent UAC from screwing with Comodo, the POC is blocked and all is Good.

 

[EASTER]

The POC is the loader and can do various things. The way to stop it is by disabling UAC in the registry. Then Cmodo can operate as it should and will block the loader from doing anything.

It really is a simple as that- no run as admin needed, no dll hijacking, no service created, no nothing else. Allow UAC to screw with Comodo and whatever the POC is coded to do can be accomplished.
Prevent UAC from screwing with Comodo, the POC is blocked and all is Good.

Okay i am officially confused now. I would think another REAL TEST of YET A SIMILAR POC might be of benefit. @Andy Ful stated and made points on the basis of the LUA registry change that he seemingly insists will render Comodo FW INERT, well at least when HIPS is off and another setting NOT tweaked.

@cruelsister SHOWS the point that with Windows UAC disabled from interfering with Comodo's capability, The POC is effectively Contained and as such unable to release it's fun prizes of DLL hijacks Service creation etc. Which seems pretty cut and dried. If POV cannot activate, it is simple, it IS prevented courtesy CFW with Cruel Settings.

I just today download the NEW COMODO with the fixed Certificate issue it was plagued with and would like to soon install it with Full Confidence

I see 2 differing points of reasonable contentions. Please specify more. This is a good discussion. BTW I NEVER USE SILENT MODE myself.

With UAC active it interacts with Comodo Containment by forcing certain items into running at the Partially Limited level, and not at a more restrictive level. For almost all files (fair or foul) this is not an issue- but for this particular mechanism it is. So although the recent videos utilize TDSSKiller as the payload, one can easily switch to a Data Stealer or Ransomware instead (although the biggest use so far has been against SEP).

 

[Andy Ful]

Okay i am officially confused now. I would think another REAL TEST of YET A SIMILAR POC might be of benefit. @Andy Ful stated and made points on the basis of the LUA registry change that he seemingly insists will render Comodo FW INERT, well at least when HIPS is off and another setting NOT tweaked.

Currently, the POC proves that Comodo cannot fully cover DLL hijacking. The author of the bypass prepared an exploit that successfully ran DLL hijacking outside the sandbox. Disabling LUA is one of a few methods to prevent that particular exploit, but this will work only when the attack is partially contained. If the exploit is not contained, then Disabling LUA only makes the attacks easier and more dangerous.

From my experience, there can be more possible exploits (some known and some unknown yet) that will not be contained at all, and can also run DLL hijacking. Such attacks will not be blocked even if LUA is disabled and are very dangerous because the malicious code will run with high privileges without UAC bypasses.
In such cases: Disabling LUA = UAC bypass without any suspicious code

One interesting question was asked here:

Comodo Internet Security 2025 was obliterated by an exploit! | Page 4 | MalwareTips

actualy its already poping out as "paid services" at some "other" places... so its a matter of time (little if i may) untill we have fileless malwares and...

malwaretips.com

 

[EASTER]

Currently, the POC proves that Comodo cannot fully cover DLL hijacking. The author of the bypass prepared an exploit that successfully ran DLL hijacking outside the sandbox. Disabling LUA is one of a few methods to prevent that particular exploit, but this will work only when the attack is partially contained. If the exploit is not contained, then Disabling LUA only makes the attacks easier and more dangerous.

From my experience, there can be more possible exploits (some known and some unknown yet) that will not be contained at all, and can also run DLL hijacking. Such attacks will not be blocked even if LUA is disabled and are very dangerous because the malicious code will run with high privileges without UAC bypasses.
In such cases: Disabling LUA = UAC bypass without any suspicious code

One interesting question was asked here:

Comodo Internet Security 2025 was obliterated by an exploit! | Page 4 | MalwareTips

actualy its already poping out as "paid services" at some "other" places... so its a matter of time (little if i may) untill we have fileless malwares and...

malwaretips.com

Of those FACTS @Andy Ful, more specifically regarding DLL hijacking PERIOD. That only raises my interest in favoring a layered approach, and a Third Party Security Program capable of meeting that particular exploit. It begs to question WHY haven't we seen even an open source project strictly able to protect against it instead of relying on AV's which have their hands full enough with the malwares they are busy enough monitoring for.

 

[cruelsister]

And still would love a single example of a dll-hijacking malware file getting by CF (in the Wild SHA256 old or new would be adequate).

 

[EASTER]

Nothing should be able to escape strict rules in Comodo FW. Nothing at all with the right settings in place

 

[Andy Ful]

Yes, we have a beautiful idea of Comodo Sandbox spoiled by ugly Windows OS. There were more such beautiful ideas.
I am afraid that Microsoft does not bother about Comodo, so the Comodo staff must do something better, if necessary.

Edit.
I do not think that Comodo is going to improve the sandbox. It is stronger than most solutions and Comodo never claimed that it can fully contain any attack. That is why it implemented a few important security layers like HIPS, Script Analysis, etc.

 

[Andy Ful]

And still would love a single example of a dll-hijacking malware file getting by CF (in the Wild SHA256 old or new would be adequate).

I wish you a very long life, otherwise you might be disappointed.

Edit.
Things could change if Comodo would open a Bug Bounty program.

 

[cruelsister]

I am afraid that Microsoft does not bother about Comodo

Ageed! Also seems they don't care about SEP.

 

[ebocious]

@Andy Ful @cruelsister Does Silent Mode with the firewall set to block popup requests obviate the need to disable UAC?

Second, if it does not, would disabling UAC after setting to always notify stop this exploit? I understand it would cripple run-as and apparently mess with auto containment.

Third, I saw a brief mention of standard user accounts. What impact does it have to run Cruel CF in silent mode and block popup requests within a standard account, with or without UAC disabled?

 

[simmerskool]

It is stronger than most solutions and Comodo never claimed that it can fully contain any attack.

but xcitium sorta does...

 

[rashmi]

It doesn't. A Red popup warning of attempted Elevation will result (in Silent Mode it will just block the request without any popup).

Silent Mode does not prevent elevation requests, but it activates the default action (run in containment).

I'm just changing the below setting to checked and Block.

View attachment 285985

Alternatively, you can choose to set the auto-containment rule for unrecognized applications to "block" and prevent both unrecognized files and elevation requests.

I wouldn't. Such an alert should always occur (without respect to the Containment level), with the default action being Block.

The default behavior is to Run In Containment, not Block. (If you meant for the default action to be Block, please disregard this comment.)

@Andy Ful @cruelsister Does Silent Mode with the firewall set to block popup requests obviate the need to disable UAC?

No. Silent Mode disables firewall alerts and triggers the default containment (run in containment) action. Instead of turning off UAC, it's advisable to configure the firewall and containment to the "block" setting.

 

[cruelsister]

Does Silent Mode with the firewall set to block popup requests obviate the need to disable UAC?

No- please note that UAC (enabled) will prevent CF from reacting (as it normally would) to this attack, so any Comodo setting change after that file is run would be of no consequence. The real question here is if the use of UAC can be justified by anyone, especially as some cutesy cmd line arguments can be added to bring down other AM applications.

With UAC enabled and a person blocking everything that resulted in a UAC popup may make one "Feel Good" but won't add very much to overall security especially as UAC can be easily bypassed (I'm sure I made a couple of videos on this in the past). And even setting the UAC slider to Never Notify will still allow UAC to be enabled, opening up a system to potential issues.

But as always, your system, your choice.