I met some HIPS’s bad behaviour causing security risk. In particular, I was using Comodo v10.2.0.6526. HIPS in safe mode.
Consider an app that is unrecognized for Comodo, i.e. app’s executable file ‘App.exe’ has ‘Unrecognized’ status in Comodo’s ‘File List’. When such app accesses a protecting resource (in particular, Windows’s global hook) first time, HIPS fires alert. User trusts the app, so he/she creates permanent HIPS rule directly from the alert interface to allow access to that resource, or even to treat that app as ‘Allowed Application’ (one of the predefined HIPS rules). That’s works fine. But now assume that the app is modified by a virus (‘App.exe’ is modified on disk), so becomes a dangerous app with destructive behaviour. What does HIPS do when the modified app accesses the allowed resource? Surprisingly, HIPS does nothing!
The same behaviour has a place when one of the app’s components is modified, e.g. a DLL that the app loads.
Moreover, one can take an arbitrary file and replace ‘App.exe’ with that file - HIPS also will do nothing!
All those things occur due to HIPS does not use checksums of ‘App.exe’ and it components, but relies on file paths while scanning the rules. Of course, paths are very useful while determining file groups and assigning rules to those groups, but are security risks described above a suitable price? I thinks a HIPS system must strongly identify that objects are changed and ask user about that to update/discard existing object’s rules. How can one prevent risks described above with Comodo’s HIPS?
When user does not create rules, but marks ‘Apps.exe’ as ‘Trusted’ in ‘File List’, changing ‘App.exe’ file causes HIPS alert when accessing protecting resource, since ‘App.exe’'s checksum changed and ‘Trusted’ status lost. That’s fine, but HIPS alert does not appear when doing the same with a DLL that ‘App.exe’ uses. Again - it’s huge security risk!
I tried this scenario with Comodo Firewall v11.0.0.6728 - even more wrong result: ‘App.exe’ modification was silently ignored.
Concretely, I was experimented with well-known Sizer app Sizer by Brian Apps. On that page there is ‘sizer334.zip (16KB)’ package. The app requires no installation. The app uses global hooks to change windows sizes. The app is not known for Comodo database (FLS).
At first run HIPS fires alert about hook installation. After allowing that action and creating permanent rule from the alert directly, and then changing ‘sizer.exe’ (adding one byte at the end in a text editor) HIPS fires no alert.
if file’s or executable’s hash changes comodo auto containment doesnt allow to run but ı am a just user of comodo and not a advanced user so more advanced user or comodo stuff can help you sorry for english
Once installed, HIPS monitors and verifies all file system activity on your computer. Every new executable file is first scanned against the virus blacklist (known ‘bad’ files) and the file whitelist (known ‘good’ files). If the file is on neither list it is given an ‘Unrecognized’ file rating. Apart from new executables, any executables that are modified are also given the ‘Unrecognized’ status. This helps safeguard against malware changing the behavior of a previously trusted application.
That’s a key feature. But I don’t see that in scenarios above.
First of all you the user are allowed to do whatever you want to your system, so HIPS does not stop the user, it stops unrecognized applications from modifying the system. Hence in your scenario, HIPS will alert when an unknown application attempts to modify any existing file, such as ‘app.ex’, as long as the file is located within an area protected by the protected files section of HIPS settings.
Secondly, rules are usually used for when an application that the user trusts that is constantly updated, the user doesn’t have to keep changing the file rating to trusted. They can continue to work without being blocked by HIPS.
If you’re paranoid you can always set HIPS to paranoid mode, which means you will always get alerts from all applications regardless of file rating. Hence the name paranoid mode ha.
The key point is that after modification of initially trusted app it must become unrecognized for HIPS. E.g. a virus infects an app - an obvious example. HIPS, however, does not block infected app’s access to protected resources (concretely, installing windows hooks). Maybe, HIPS works normally in case of files or processes as protected resources, I did not try it now.
Secondly, rules are usually used for when an application that the user trusts that is constantly updated...
It's completely inappropriate way. Virus changes an app - is it an update?
Comodo v11.0.0.6728. Have tried with files as protected resources.
When explicit HIPS rule exists allowing access to a protected resource, HIPS does not prevent this resource access from modified app or any app that replaces the initial app keeping the app path.
When there is no explicit rule, but user marked the app as trusted in ‘File List’, then after app’s modification it looses trusted status. So, HIPS works properly in that case, as expected and documented.
I beleive that paranoid mode does not help for p.1 above, since there is explicit rule exists.
And once again in p.2: when an app uses a DLL, HIPS does not react at modified DLL.
Again non-trusted applications can not change existing files on disk, once an application is written to disk it automatically is protected from modification by non-trusted applications. As for rules it would be pointless to block an application from doing something when an application hash is changed and the rule is explicitly set to allow a specific action, that is the whole point of what the rules are meant for. Rules override file rating, that way if an application is changed because it was updated in a trusted and secure manner, it will continue to work without alerting the user especially if the user made a rule to allow the application to perform certain actions.
Same applies to Dll files, they are protected from modification, and a dll that is loaded by an application is limited to the same rules/actions that the application has applied to itself. Also if a dll is modified in a way that it doesn’t work from its original, say a dll that has backdoor coded added to it and it a required dll for an application, the dll will either fail to load or cause the application to crash.
futuretech: thanks for detailed answer. I agree with your points, since ‘Executables’ file group is in protection by default, and only trusted apps might modify executable files. But many real use cases involve situations when files may be changed when HIPS is not active. For example, consider dual-boot system with Windows and Linux. There is common NTFS partition for both systems (a widely spread technique). On that partition there are Windows apps. These apps are trusted to HIPS. When user works in Linux, a Linux’s virus modifies Windows apps, so when user returns back to Windows and launches such apps they become destructive and HIPS does not help. On single system there is also possible when user turns off HIPS for a short time, or HIPS might fail to load for some reason. So, modification may occur when HIPS is not active.
kyl: Please see “Enable Auto-Containment” checkbox and policies below. If hash changes, an app becomes unrecognized, so might run in the container regarding to the settings, I think. Personally me does not use containment feature in Comodo. I use virtual machines to explore unknown apps behaviour.
Then it doesn’t matter, when a protection mechanism is disabled then of course the risk of successful infection is higher. The security software protects the system when it is enabled and active, once it is no longer active then you are not protected, no security software will protect you when it is not active. It is the responsibility of the user in a dual-boot situation to have active security measure in place to protect the non-active partition. If the user intentionally disables a protection mechanism, it is on them if the system gets compromised.
What you are expecting is for rules to be hashed based instead of being based on file path, that is not doable as the user will get frustrated every time an application is legitimately changed. They will be forced to answer the same alert over again, asking for the same permission that they had already previously allowed. Also it would become a headache trying to remove the old rules because the user would have to figure out which rule is the correct one to keep. It is just not usable for rules to be applied to a specific file hash of the application. This also all applies with firewall application rules, anti-virus exclusions, and auto-containment rules.
The discussion is about HIPS so containment doesn’t really matter, especially when auto-containment is turned off in favor of using HIPS to protect the system.
futuretech: For me hash based rules are preferred, indeed. But for average user, probably, current behaviour is more convenient. A very useful feature - using file groups in HIPS rules bases on paths (even with wildcards) by nature. It’s much more hardly to implement file groups based on hashes. Also, it’s less intuitive.
Anyway, thanks all (especially, futuretech) for the discussion. It was pleasant and informative for me.