Serious Discussion Comodo discussions

[rashmi]

@Andy Ful, Most malware DLLs drop in Temp/AppData, while legitimate DLLs stay in System32/Program Files. Is it correct?

 

[Andy Ful]

@Andy Ful, Most malware DLLs drop in Temp/AppData, while legitimate DLLs stay in System32/Program Files. Is it correct?

Most malware drops temporary payloads in the %LocalAppdata% or installs in UserSpace (user AppData, ProgramData, etc.).
Dropping payloads in the system folders (SystemSpace) requires higher privileges.

Legitimate DLLs can stay anywhere, depending on the software. The software installed for all users (systemwide), mainly keeps executables (including DLLs) in SystemSpace. Applications installed for a particular user mostly use only standard privileges, so the executables are dropped/located mostly in UserSpace.

 

[rashmi]

Would this method be useful against DLL hijacking? (If it functions properly in Comodo)

File Groups and Paths
Trusted DLLs Locations
C:\Windows\System32\*.dll
C:\Program Files*\*.dll
C:\Program Files (x86)\*.dll
Untrusted DLLs Policy
*.dll

Auto-Containment Rules
Ignore > File Group > Trusted DLLs Locations
Run Virtually > File Group > Untrusted DLLs Policy

 

[rashmi]

I attempted to run the portable version of HDSentinel Pro from my PortableApps directory (C:\PortableApps), a program already on my system and in the Comodo whitelist. Comodo contained "detect.dl," a file listed in the Comodo File List as trusted. This method appears functional and could be useful for mitigating DLL hijacking, assuming minimal impact on usability.

 

[Andy Ful]

Would this method be useful against DLL hijacking? (If it functions properly in Comodo)

File Groups and Paths
Trusted DLLs Locations
C:\Windows\System32\*.dll
C:\Program Files*\*.dll
C:\Program Files (x86)\*.dll
Untrusted DLLs Policy
*.dll

Auto-Containment Rules
Ignore > File Group > Trusted DLLs Locations
Run Virtually > File Group > Untrusted DLLs Policy

I am not sure. You may check it by using the method from:

Advice Request - Testing DLL Search Order Hijacking against security features.

The DLL Search Order Hijacking is a well known (but not common) vector of attack. It is often performed via a vulnerable Microsoft EXE file or EXE signed by the well known reputable vendor. A popular way of exploiting this vulnerability is based on loading by the vulnerable EXE, one of the...

malwaretips.com

The problem is that in DLL hijacking, already trusted processes load DLLs. In my previous tests, Comodo with autocontainment did not contain DLLs except when:

• the DLL was flagged as malicious,
• the trusted executable that ran the DLL (like RunDll32) was restricted by Script Analysis settings.

 

[Andy Ful]

I attempted to run the portable version of HDSentinel Pro from my PortableApps directory (C:\PortableApps), a program already on my system and in the Comodo whitelist. Comodo contained "detect.dl," a file listed in the Comodo File List as trusted. This method appears functional and could be useful for mitigating DLL hijacking, assuming minimal impact on usability.

This suggests that it works, although the whitelist looks too simplistic.

 

[Andy Ful]

Can you run PowerShell console with those restrictions?

 

[rashmi]

This suggests that it works, although the whitelist looks too simplistic.

You'll definitely enhance and complete it, I'm sure.

 

[Andy Ful]

You'll definitely enhance and complete it, I'm sure.

Not soon. Currently, I do not use/test Comodo.
The DLL block rule (*.dll) looks very strong (can block Trusted DLLs), and many system DLLs are outside your whitelist. The usability of such restrictions will depend on the Comodo Profile and user whitelist. Depending on the Comodo Profile, different system and non-system locations can be whitelisted by default for DLLs.

You should copy the folder with HDSentinel to some other locations and check if the rules work as intended:

1. C:\ProgramData\
2. C:\Users\*\AppData\Local\
3. C:\Users\*\AppData\Local\Temp\
4. C:\Users\*\AppData\Roaming\

If the DLLs are blocked in those locations, almost all application installations/updates will fail.
I am not sure about Windows Updates.
I am not sure if the block rule is overridden for signed DLLs by whitelisting the vendor.

 

[rashmi]

Can you run PowerShell console with those restrictions?

Yes, Windows PowerShell.

Not soon. Currently, I do not use/test Comodo.
The DLL block rule (*.dll) looks very strong (can block Trusted DLLs), and many system DLLs are outside your whitelist. The usability of such restrictions will depend on the Comodo Profile and user whitelist. Depending on the Comodo Profile, different system and non-system locations can be whitelisted for DLLs.

You should copy the folder with HDSentinel to some other locations and check if the rules work as intended:

1. C:\ProgramData\
2. C:\Users\*\AppData\Local\
3. C:\Users\*\AppData\Local\Temp\
4. C:\Users\*\AppData\Roaming\

If the DLLs are blocked in those locations, almost all application installations/updates will fail.
I am not sure about Windows Updates.
I am not sure if the block rule is overridden for signed DLLs by whitelisting the vendor.

The "untrusted policy" prevents/virtualizes DLL execution from non-whitelisted locations. We can either expand the whitelist or use high-risk locations (remove *.dll) for the untrusted policy.

I'm also not sure about Windows updates, but checking for them works.
I only tried the stated containment rules to see if they work.

 

[Andy Ful]

Yes, Windows PowerShell.


The "untrusted policy" prevents/virtualizes DLL execution from non-whitelisted locations. We can either expand the whitelist or use high-risk locations (remove *.dll) for the untrusted policy.

I'm also not sure about Windows updates, but checking for them works.
I only tried the stated containment rules to see if they work.

The crucial thing is the ability to override the general block DLL rule by the Trusted Vendors List. Otherwise, the general block DLL rule will be hard to manage in practice.

 

[rashmi]

The crucial thing is the ability to override the general block DLL rule by the Trusted Vendors List. Otherwise, the general block DLL rule will be hard to manage in practice.

How about these locations for the whitelist?
C:\ProgramData\*
C:\Users\rashmi\AppData\Local\*
C:\Users\rashmi\AppData\Roaming\*
C:\Windows\Installer\*
C:\Windows\Temp\*

 

[Andy Ful]

How about these locations for the whitelist?
C:\ProgramData\*
C:\Users\rashmi\AppData\Local\*
C:\Users\rashmi\AppData\Roaming\*
C:\Windows\Installer\*
C:\Windows\Temp\*

It should be OK (I use similar whitelisted locations in the WHHLight WDAC and Hard_Configurator).
I hope that Comodo by default whitelists the necessary system locations.

 

[rashmi]

It should be OK (I use similar whitelisted locations in the WHHLight WDAC and Hard_Configurator).

Oh yes, I can use your WHHLight whitelist for security and usability, right?

 

[Andy Ful]

I am not sure how those rules can impact the Comodo Script Analysis settings (script, scriplet restrictions). But, there are high chances that the scripts and scriptlets will still be blocked. In WHHLight, the problem is solved by using different security layers for PE files and others.

 

[Andy Ful]

Oh yes, I can use your WHHLight whitelist for security and usability, right?

Yes, this can be a good starting point.

 

[rashmi]

I am not sure how those rules can impact the Comodo Script Analysis settings (script, scriplet restrictions). But, there are high chances that the scripts and scriptlets will still be blocked. In WHHLight, the problem is solved by using different security layers for PE files and others.

I won't just copy the WHHLight whitelist, but it's an excellent place to start.

 

[piquiteco]

Oh yes, I can use your WHHLight whitelist for security and usability, right?

Spoiler: Windows Hybrid Hardening Light

 

[Andy Ful]

@rashmi,

You must solve the problem of properly whitelisting SystemSpace, which is allowed by default (no whitelisting required) in WHHLight for PE files via WDAC.
Otherwise, some Windows updates can fail.

 

[Andy Ful]

@rashmi,
If I correctly recall, Comodo uses many rules to properly whitelist the system processes. It would be necessary to check if your general DLL block rule does not break them.