Which Elements of Comodo do You Use?
- Thread starter AtlBo
- Start date
- Status
- Apr 1, 2017
- 1,782
But Comodo didn't mention anything about processes or the user itself!make no sense because change is change! does it mean I cant delete the file with third-party tools?I tried smth right now: removed the protected file with Pchunter which can remove everything from your hard drive! again comodo Hips didn't react!
Last edited:
- Apr 1, 2017
- 1,782
I guess there is a big bug which Comodo missed it.shmu can you pls try this? add smth to that protected files/folders and try to remove the file with a third-party tool or by yourself!
- Oct 11, 2014
- 112
It is obvious that you will not be alerted by known programs, insurance or user actions.
Since that would generate a huge amount of alerts that a user (even me) would not support ...
Imagine that you copy 10 images .. 1 alert for each image .. Now imagine 100 ...
Since that would generate a huge amount of alerts that a user (even me) would not support ...
Imagine that you copy 10 images .. 1 alert for each image .. Now imagine 100 ...
- Jul 3, 2015
- 8,153
I read the description of that protection on Comodo help, and according to what I understood, I really think it should have prevented file modification, when you used a third-party tool. Best to bring it up on the Comodo forum and see what they have to say.
But I can't test it myself, as I recently uninstalled Comodo, due to different disappointments that I had.
1 I replaced a valid program file with a cracked one, and Comodo did not block it (proactive config with autocontainment and HIPS enabled).
2 I ran an unsigned reg file that modified the registry, and Comodo did not react.
3 BSOD, I believe it was due to advanced HIPS protection.
4 Comodo sometimes blocks Windows audio driver from loading at system startup.
- Apr 1, 2017
- 1,782
Hi, this is not about known or unknown programs!
comodo saying: Protected Files- Allows you to specify programs, applications, and files that are to be protected from changes.
pls, there is nothing about the user action or anything about known or unknown program idk how you ppl find these stuff
I'm talking about the what comodo said!
This feature doesn't work!how comodo recognize if the process is malware or safe?! what if the process is malware and not detected by Comodo sig?!
What if I want to use the hips+firewall and not the auto sandbox or anything annoying.
As you can see comodo log the action(Comodo won't tell me what was that ? remove or rename? no information) for this file but the problem is it didn't block the action! comodo log it as blocked action but the file is in Recycle Bin
comodo saying: Protected Files- Allows you to specify programs, applications, and files that are to be protected from changes.
pls, there is nothing about the user action or anything about known or unknown program idk how you ppl find these stuff
I'm talking about the what comodo said!This feature doesn't work!how comodo recognize if the process is malware or safe?! what if the process is malware and not detected by Comodo sig?!
What if I want to use the hips+firewall and not the auto sandbox or anything annoying.
As you can see comodo log the action(Comodo won't tell me what was that ? remove or rename? no information) for this file but the problem is it didn't block the action! comodo log it as blocked action but the file is in Recycle Bin
Attachments
Last edited:
- Apr 1, 2017
- 1,782
Found the Same problem with Eset hips! because they don't care about the hash(they only consider the PATH or name)! but Rehips care about the hash!this is the strong point with Rehips
P.S ESET hips won't react at this but the Eset firewall can detect the application modification! so the change can happen but that file cant reach the internet(still better than nothing).
Last edited:
- Dec 29, 2014
- 1,716
I think Comodo only will block a running process that is unknown from making a change with Protected Folders. It's confusing but I haven't gotten much result from using the protected folders designation. Only time I have seen it is when some app that was unknown was trying to make the change.
I tested FileLocker just now to see if it protects from folder rename. It does. That's what I have been using over Comodo, since it also gives you the extra flexibility to say what apps can write to a location. In any event it will block renaming of a location so that's good. BTW, I am sure because I turned it off and was able to rename the location I tested.
Probably because they are the ones who have a chance of bypassing HIPS without paranoid settings
BTW this post isn't me debating with you, I don't agree or disagree with whatever was going on because I didn't read through it and don't plan too lol. I just saw that bit with the corner of my eye and wanted to say the above hahaha
- Dec 29, 2014
- 1,716
@Sunshine-boy...So you changed the name then deleted the folder or just deleted the folder? No matter what its a bug for sure that Comodo didn't block the action. The log shows they intended this with the protection.
Maybe you could report the bug to Comodo. For sure it should be fixed or addressed somehow. Protected Folders/Files is a good idea, but if any app can change a folder/file name then it can do what it wants with the contents or at least in many cases.
- Apr 1, 2017
- 1,782
Even with hips in paranoid mode and costume settings for pc hunter( block access for protected files/folders)! I can force remove protected files! Idk what is it? next generation removal tool or what? it can bypass the hips!
it can bypass the hips!
Last edited:
It probably bypasses API hooks for file removal with a system call to NtDeleteFile, or it uses a kernel-mode device driver to remove files without triggering NtDeleteFile hook on SSDT/FltRegisterFilter callback.
I'm betting on the latter being the reason why it bypasses your HIPS.
- Apr 1, 2017
- 1,782
I changed the name and Comodo didn't react I also removed the file but again comodo dint care! hips in paranoid and settings are set to proactive mode.
comodo don't care if the user removes the files! idk why!
- Apr 1, 2017
- 1,782
Hacker xd I guess you are right because the tool creates a driver!!but I have A block rule for MY file! hips should avoid it! whats the solution for such things opcode? what if there is a malware that can do such thing?and how Hips can handle it?
Pchunter can even remove the system files or the whole windows folder!much much better than iobit unlocker!
Last edited:
@Sunshine-boy If it installed a driver without consent according to your HIPS configuration then it probably used a work-around for that too. There are many ways to work-around HIPS, you just need to know how the monitoring is applied. I mean I've never used the software you're referring to but I know it is genuine security software and appears to be aimed at cleaning rootkits infections, so you'd expect them to have great knowledge on Windows Internals which is more or less the entry point to bypassing features like HIPS.
There are many ways to install a device driver. The first method would be relying on the normal service manager to create and start a Windows Service for a device driver. The second method would be applying registry modifications to setup the device driver installation (basically replicating what the service manager will do for initialisation before the start operation) and then using Native API functions like NtLoadDriver to start the service. The third method would be using an undocumented Native API function called NtSetSystemInformation, which is something that Microsoft used in the past for this same thing (which is how the technique was discovered). Another method could be injecting code into another process and have it load the driver for you. Another method could be patching an existent driver which isn't active but can be accessed on disk for read/write and then have that utilised automatically at boot, etc.
The NtLoadDriver and NtSetSystemInformation techniques are commonly only ever used in malicious software, but their use is not prevalent. Especially not nowadays at-least. Genuine software usually uses the documented service manager APIs, but when it comes down to security software, it would be reasonable to expect a sense of undocumented things going on because sometimes it is the only way to achieve the desired result. This is also why some security software causes crashes on new updates to Windows (e.g. new OS version won't be supported for X amount of time because the vendor needs to start reverse engineering and maintain support for "undocumented" things it may have been previously doing for specific features).
We also would need to look at how the HIPS product you are using actually works. It may be the case of both kernel-mode and user-mode components, and reverse engineering the software would reveal the technique the vendor is using to have implemented the specific feature of discussion - of course I am not going to reverse engineer genuine security software since this is unnecessary and illegal, but you should get the understanding of what I am trying to say. If a security product is injecting code into running processes to control execution flow for when specific APIs are used, but the author of the software decides to make a "custom" wrapper for the targeted controlled function (or in the case of NTAPI invocation, relying on a direct system call), then that would be bypassed. Whereas, if a specific feature is implemented from kernel-mode, then the user-mode program would not be making progress by using undocumented tricks like a system call because it'd still pass through the security software's interception once it reaches kernel-mode level. In a situation like that, it would require a zero-day exploit or a work-around overlooked by the vendor which implemented the feature (e.g. a vendor may block X action but may have forgotten there was another way to do the same action which isn't under the scope of their monitoring yet).
Malware can do these things and it could have done them for years. If we take a step back to the times around 2006 - 2012 there was some really deadly threats from those times surrounding rootkit infections which could do complex and sophisticated things, applying techniques to surpass behavioural prevention. However, without a bypass for PatchGuard (Driver Signature Enforcement feature specifically), you must have a signed device driver on 64-bit systems. Due to this, and due to many people moving to 64-bit over the many years since such a feature was introduced back on Windows Vista, the malware in the wild has significantly changed. It isn't normally about virus infections or rootkits to subvert even security software to hide other malicious software nowadays, but about generating income through ransomware and adware - those are the prevalent threats nowadays as far as I am aware. In fact, even banking malware has plummeted down a lot recently in my opinion - still popular though. It would have been common to find samples for Carberp, Zeus, SpyEye a few years ago, not as common nowadays. You have more chances of finding BadRabbit nowadays or a similar ransomware outbreak.
As for removing system files, you can delete files which are even in use as long as you have the correct privileges. For example, you cannot delete a file in a protected directory without having the rights to access those files with delete requests (e.g. acquire administrator rights); files in use can be deleted via a Native API function called NtDeleteFile. You can do this from user-mode thanks to NTDLL which sends requests up to a kernel routine which eventually leads to the real function within ntoskrnl.exe (kernel-mode image -> the Windows Kernel to be precise). Explorer.exe and most other software relies on the normal Win32 API which will lead down to the Native API calls in NTDLL (-> Kernel), but when you use Native API functions from NTDLL to pass to kernel-mode directly in this way, you bypass the checks performed by the documented and Microsoft supported-for-use functions which are supposed to be used by developers. Alternatively, just use a kernel-mode device driver and then you can invoke kernel-mode only functions (instead of the original Zw routines) to make a wrapper for the Nt* functions using the kernel-mode only functions instead (which they would have originally called anyway), whilst bypassing kernel-mode callbacks registered by other device drivers (e.g. maybe by a security product) or potential kernel-mode patches which may be present (32-bit systems).
The documented APIs will perform checks and put up restrictions for removing files in-use by other processes. The undocumented APIs won't necessarily have those checks, unless they are enforced from kernel-mode level under the original Windows Kernel routine which ends up being executed for the desired functionality which would be the end-result. This explains why you may not be able to delete GenuinePhotoshop.dll which is executing under GenuinePhotoshop.exe from the normal Windows File Explorer, whilst an external security tool like you have referred to will be capable of doing so.
There are many ways to install a device driver. The first method would be relying on the normal service manager to create and start a Windows Service for a device driver. The second method would be applying registry modifications to setup the device driver installation (basically replicating what the service manager will do for initialisation before the start operation) and then using Native API functions like NtLoadDriver to start the service. The third method would be using an undocumented Native API function called NtSetSystemInformation, which is something that Microsoft used in the past for this same thing (which is how the technique was discovered). Another method could be injecting code into another process and have it load the driver for you. Another method could be patching an existent driver which isn't active but can be accessed on disk for read/write and then have that utilised automatically at boot, etc.
The NtLoadDriver and NtSetSystemInformation techniques are commonly only ever used in malicious software, but their use is not prevalent. Especially not nowadays at-least. Genuine software usually uses the documented service manager APIs, but when it comes down to security software, it would be reasonable to expect a sense of undocumented things going on because sometimes it is the only way to achieve the desired result. This is also why some security software causes crashes on new updates to Windows (e.g. new OS version won't be supported for X amount of time because the vendor needs to start reverse engineering and maintain support for "undocumented" things it may have been previously doing for specific features).
We also would need to look at how the HIPS product you are using actually works. It may be the case of both kernel-mode and user-mode components, and reverse engineering the software would reveal the technique the vendor is using to have implemented the specific feature of discussion - of course I am not going to reverse engineer genuine security software since this is unnecessary and illegal, but you should get the understanding of what I am trying to say. If a security product is injecting code into running processes to control execution flow for when specific APIs are used, but the author of the software decides to make a "custom" wrapper for the targeted controlled function (or in the case of NTAPI invocation, relying on a direct system call), then that would be bypassed. Whereas, if a specific feature is implemented from kernel-mode, then the user-mode program would not be making progress by using undocumented tricks like a system call because it'd still pass through the security software's interception once it reaches kernel-mode level. In a situation like that, it would require a zero-day exploit or a work-around overlooked by the vendor which implemented the feature (e.g. a vendor may block X action but may have forgotten there was another way to do the same action which isn't under the scope of their monitoring yet).
Malware can do these things and it could have done them for years. If we take a step back to the times around 2006 - 2012 there was some really deadly threats from those times surrounding rootkit infections which could do complex and sophisticated things, applying techniques to surpass behavioural prevention. However, without a bypass for PatchGuard (Driver Signature Enforcement feature specifically), you must have a signed device driver on 64-bit systems. Due to this, and due to many people moving to 64-bit over the many years since such a feature was introduced back on Windows Vista, the malware in the wild has significantly changed. It isn't normally about virus infections or rootkits to subvert even security software to hide other malicious software nowadays, but about generating income through ransomware and adware - those are the prevalent threats nowadays as far as I am aware. In fact, even banking malware has plummeted down a lot recently in my opinion - still popular though. It would have been common to find samples for Carberp, Zeus, SpyEye a few years ago, not as common nowadays. You have more chances of finding BadRabbit nowadays or a similar ransomware outbreak.
As for removing system files, you can delete files which are even in use as long as you have the correct privileges. For example, you cannot delete a file in a protected directory without having the rights to access those files with delete requests (e.g. acquire administrator rights); files in use can be deleted via a Native API function called NtDeleteFile. You can do this from user-mode thanks to NTDLL which sends requests up to a kernel routine which eventually leads to the real function within ntoskrnl.exe (kernel-mode image -> the Windows Kernel to be precise). Explorer.exe and most other software relies on the normal Win32 API which will lead down to the Native API calls in NTDLL (-> Kernel), but when you use Native API functions from NTDLL to pass to kernel-mode directly in this way, you bypass the checks performed by the documented and Microsoft supported-for-use functions which are supposed to be used by developers. Alternatively, just use a kernel-mode device driver and then you can invoke kernel-mode only functions (instead of the original Zw routines) to make a wrapper for the Nt* functions using the kernel-mode only functions instead (which they would have originally called anyway), whilst bypassing kernel-mode callbacks registered by other device drivers (e.g. maybe by a security product) or potential kernel-mode patches which may be present (32-bit systems).
The documented APIs will perform checks and put up restrictions for removing files in-use by other processes. The undocumented APIs won't necessarily have those checks, unless they are enforced from kernel-mode level under the original Windows Kernel routine which ends up being executed for the desired functionality which would be the end-result. This explains why you may not be able to delete GenuinePhotoshop.dll which is executing under GenuinePhotoshop.exe from the normal Windows File Explorer, whilst an external security tool like you have referred to will be capable of doing so.
Last edited by a moderator:
- Dec 29, 2014
- 1,716
Thanks for such a detailed explanation. Does Windows report an attempt to do this with any sort of pop up notification of the block like an error box or anything? Never seen one before.
So it's harder to get rootkits on a 64 bit system, partly because the driver has to be signed. I can understand that. Should I hope still that this hasn't made security devs feel at ease about monitoring for attempts? If someone finds a way to use a valid signature somehow (maybe unlikely) then maybe this could be a problem still. Also, sounds like 32 bit OS uses are at risk. Should they be concerned?
- Apr 1, 2017
- 1,782
Thank you for your clear and helpful explanation! a great hacker we got there.
Comodo asked me about that driver(.sys) and I allowed it!But it's not important because I asked hips to protect these files -.- IDC because Comodo didn't tell me if you allow this driver then I cant protect your files from change even if you have the block rules:notworthy:.btw thanks.
Comodo asked me about that driver(.sys) and I allowed it!But it's not important because I asked hips to protect these files -.- IDC because Comodo didn't tell me if you allow this driver then I cant protect your files from change even if you have the block rules:notworthy:.btw thanks.
Last edited:
- Apr 1, 2017
- 1,782
What if I DW smth safe from Softpedia but the hackers like opcode already hacked Softpedia and put the infected driver in my software package? -.- I will allow it since I DW it from Softpedia and hips cant save me because it's weak!before you show AI is useless and now its time for hips lol! can bb blocks this!?
@Opcode No one knows( i mean average users because not everyone is malware analyst lol!) an allowed driver can bypass the Hips!thanks, i learned smth new.many thanks
@Opcode No one knows( i mean average users because not everyone is malware analyst lol!) an allowed driver can bypass the Hips!thanks, i learned smth new.many thanks
Last edited:
- Oct 11, 2014
- 112
All security software reviews the certificates of the files .. If this is safe then they let them do their work (thus avoiding false positives) ..
Comodo has a separate list of white, black and unknown applications (for analysis).
In this way you can differentiate when it is a legitimate software or not .. this helps to avoid false positives .. It is a weakness but also difficult to exploit (eg ccleaner) ..
HIP alerted you and you allowed the controlled access ... The HIP of comodo is alert and does not differentiate malware from godware .... . for this you must ask that viruscope work on your pc (outside the sandbox), this way you can monitor your computer
Comodo has a separate list of white, black and unknown applications (for analysis).
In this way you can differentiate when it is a legitimate software or not .. this helps to avoid false positives .. It is a weakness but also difficult to exploit (eg ccleaner) ..
HIP alerted you and you allowed the controlled access ... The HIP of comodo is alert and does not differentiate malware from godware .... . for this you must ask that viruscope work on your pc (outside the sandbox), this way you can monitor your computer
I've seen cases where an unsigned driver has been attempted to be loaded, but has been blocked from doing so followed by an on-screen prompt to the user saying that the activity was prevented due to the certificate issue. However, I've only seen it happen a few times myself whilst on Windows 7 using genuine tools to automatically create and start services for device drivers, therefore I am not entirely sure. I believe it was some sort of "information" alert with only OK as the option, as opposed to a security-warning "stay alert" sort of warning.
It is certainly much more difficult but as far as I am aware there is a decent work-around to PatchGuard for Driver Signature Enforcement which works on Windows 10 - it evolves around exploitation of the genuine VirtualBox device driver.
The theory behind it is that the VirtualBox device driver does a few unusual things which you could have imagined considering it is used for virtualisation software, and because it is a kernel-mode device driver, it also has access to kernel-mode memory. There is a DLL called CI.dll which you should be able to find under your System32 folder ("SYSTEMDRIVE:\Windows\System32\") and you'll also notice it is loaded as a module (import) under ntoskrnl.exe (along with other loaded device drivers being listed there - kernel-mode device drivers become module imports of ntoskrnl.exe the same way that a normal Dynamic Link Library becomes a module import of a normal user-mode process). The file-name "CI" stands for Code Integrity and it is responsible for handling checks regarding the system configuration about PatchGuard - it will check if Test Mode is enabled or not and make changes accordingly for example, and all of this initially happens at boot during the initialisation of the Windows Kernel. The VirtualBox driver exploitation technique will use the VirtualBox driver from user-mode by starting it up and then forcing it to perform operations from kernel-mode for the attacker (directing it from user-mode) to patch the flags within CI.dll (which is under kernel-mode memory and thus without a zero-day vulnerability like this one (e.g. maybe physical memory exploitation) you cannot abuse it) so the system believes that Test Mode/Unsigned device drivers can be loaded. The problem with this technique stems from the unpredictable potential for a BSOD crash depending on the OS version but it does not necessarily happen - the aim is to load the driver as quickly as possible after patching the flags and then re-patch them back to their original values to conceal evidence of tampering having occurred in the first place. The only catch is that the driver must be adapted to become referred under the term "driverless" so it doesn't get identified, and this also automatically makes the driver hidden, thus making it a lot tougher to identify its presence.
Even though there is enhanced mitigations against rogue device drivers, this doesn't necessarily automatically stop all rootkits. With or without an exploit for Driver Signature Enforcement (a feature of PatchGuard), criminals which are serious about their work and are developing Advanced Persistent Threats (APTs) of a higher sophistication to the standard malware you may find in the wild which will commonly target Home users, can definitely go to the trouble (and be successful) with acquiring a code signing certificate, probably through a company taking bribes or bought online by someone else who handles obtaining of the certificates. Thankfully, past an early patch update on Windows 10, you'll actually require an Extended Validation digital signature as opposed to the previous standard one for kernel-mode signing if the driver will be used on Windows 10 systems which have installed the early security patch, which makes things a whole lot tougher because an Extended Validation certificate will be a lot trickier to get hold of for a criminal compared to an original one.
32-bit environments are not as secure as 64-bit environments because they miss out on enhanced security features - PatchGuard is an example of one of those features which are missed out on, and forced Data Execution Prevention is also missed out on (64-bit processes are automatically enabled for DEP as far as I am aware). This doesn't mean that a 32-bit Windows user cannot be protected though, because there are still good security solutions which can be used, and common sense is a good starting ground and the most important key aspect of staying protected against both old and the latest malware attacks. However, on the contrary, a successful rootkit infection can do a lot more on a 32-bit environment compared to a 64-bit environment by default (e.g. easily patch the Windows Kernel to make concealment difficult, attempt to subvert security software trying to identify the concealment having taken place by the rootkit infection, etc.).
User-Mode rootkits exist too, as well. They can be used to do some nasty things but of course not to the same depths as a kernel-mode rootkit. For example, a user-mode rootkit could effortlessly inject code into Task Manager to conceal processes belonging to other malicious software packages which may be installed on the system and active in-memory (e.g. spyware) as long as it had elevated rights to access the address space of that process.
All in all, I don't think there is a need to worry much about it. Not nowadays at-least, despite attacks doubling and getting more and more complex. The reasoning behind this is that a lot of malware authors targeting average users like you and myself are without doubt typically inexperienced and most likely nothing more than basic script kiddies piggy-backing off public source code, and the more sophisticated outbreaks surrounding ransomware infections can be avoided by making good decisions anyway (e.g. ignoring unexpected e-mails and certainly not aimlessly handling the attachments to them, not being click-happy whilst doing online research, being careful with new installations, etc.). Even if we look at the original Petya, the deployment was actually incredibly basic (simple Win32 API calls - you would be able to find better examples online for hijacking the Master Boot Record probably)... The complex thing about it was its boot-loader (encryption of the Master File Table in 16-bit Assembly without requiring Windows).
Ransomware and adware is famously prevalent nowadays. Ransomware will usually provide some sort of awareness notification to the victim so they can potentially get started on making a ransom payment faster, and adware is also focused on money. Home users can still be in the firing line for complex attacks (e.g. as we saw from Petya, NotPetya, WannaCry and BadRabbit), however the main goal for criminals which are serious about their work is likely about targeting wealthy and popular businesses so they can be pressured into making big large payments to keep a breach quiet from the public (we recently heard about this happening with the company Uber, only a few days ago did they announce the truth about the events that took place a long time ago) or to receive decryption of the critical company files (which they may or may not even get back after paying - malware authors cannot be trusted).
We went from viruses, rootkits and bootkits to less advanced threats taking place. Then we went back to bootkits for the time Petya was quite popular and booming on the security head-lines, same for a few other recent outbreaks. I wonder where we will go next...
Last edited by a moderator:
- Status
