Some Installers Bypass Antiexecutable\Default-Deny Set&Rules(SB or HIPS) [M1507]

Some Installers\Apps Can Bypass Anti-Executable\System Default-Deny Settings and Rules + Might Not Show In Local Host File Rating Database

This is a potentially CRITICAL vulnerability.

Can you reproduce the problem & if so how reliably?:

Yes. Reproducible with at least 10 - 25 % of standard and portable application installers.

This by-pass can be easily confirmed by anyone.

If you can, exact steps to reproduce. If not, exactly what you did & what happened:

1: Configure CIS for anti-executable\default-deny using the following settings:

A. Security Settings > File Rating > File Rating Settings > De-select “Trust applications signed by Trusted Vendors.”
B. Security Settings > File Rating > File Rating Settings > De-select “Trust files installed by Trusted installers.”
C. Security Settings > Defense+ > Auto-sandbox > Create rule as follows: Block - All Applications - Unrecognized

  • OR -

1.1

A. Security Settings > File Rating > File Rating Settings > De-select “Trust applications signed by Trusted Vendors.”
B. Security Settings > File Rating > File Rating Settings > De-select “Trust files installed by Trusted installers.”
C. Security Setting > Defense+ > HIPS > HIPS Settings > Select “Do NOT Show Pop-Ups: Block Requests.”

2:

Download installer\app (For sake of easy demonstration, e.g. Q-Dir from Softpedia or some of the SysInternals utilities). You may have to hunt-down portable apps that can bypass CIS default-deny, but they’re out there.

NOTE: Samples and links to installer downloads are provided.

3: Extract installer (for portable apps only).
4: Execute installer - either from desktop or from within browser.
5: Installer will bypass CIS anti-executable\default-deny sandbox and\or HIPS configurations; it will execute and install application or run (cmd.exe - in the case of SysInternals utilties).
6: Security Settings > File Rating > File Rating List > Search for installed application; it might not be present in File Rating list.

NOTE: It is safe to assume that if an installer, like some of the SysInternals utility\apps, can execute the Windows Command Line Interpreter (cmd.exe) and bypass both both sandbox and HIPS anti-executable\default-deny configurations, then it would be true for all other interpreters: wscript.exe, cscript.exe, java.exe, javaw.exe, javaws.exe, powershell.exe, powershell_ISE.exe, etc. That is an extensive, critical vulnerability.

Default-Deny configuration should block all Unrecognized scripts not white-listed on system of types: .bat, .cmd, .csh, .inx, .isu, .js, .jse, .ps, .ps1, .rgs, .sct, .vb, .vbe, .vbs, .vbscript, .ws, .wsf

The portable application installer file extension also needs to be blocked using Default-Deny configuration: .paf

Self-extracting archive installers can by-pass default-deny configuration: 7z SFX and most others.

Theoretically these are easy fixes for the developers; just add the file extension types to the File Group list (e.g. *.jse, *.vbscript, *.paf, .sfx).

For maximum security the default-deny configurations (both sandbox and HIPS) outlined above should block any executable application (.) rated as “Unrecognized” or, better yet, “Any” - regardless of source - archived or un-archived, packed or unpacked, stand-alone, off-line, run from browser, run from AppData\Temp directories, run from all “User Space” directories, etc. In other words, only files in the File Rating database that are rated as “Trusted” should be allowed to run using the above AE\DD configuration; if a file is not in the local CIS database the above configuration should block it.

One or two sentences explaining what actually happened:

Installer\app was able to bypass both CIS’ sandbox and HIPS anti-executable\default-deny configurations. Despite settings and rules installer executed and installed the application or executed cmd.exe or other interpreter. There are a wide variety of installers that are able to by-pass CIS antiexecutable\default-deny configurations outlined above.

In other words, some installers are treated as Installers\Trusted - despite CIS settings that should block them.

One or two sentences explaining what you expected to happen:

I expected CIS to block any (.) installer\app with either a sandbox or HIPS anti-executable\default-deny configuration.

If a software compatibility problem have you tried the advice to make programs work with CIS?:

Not Applicable.

Any software except CIS/OS involved? If so - name, & exact version:

None.

Any other information, eg your guess at the cause, how you tried to fix it etc:

None.

B. YOUR SETUP
Exact CIS version & configuration:

8.0.2.4591 - Proactive Security

Modules enabled & level. D+/HIPS, Autosandbox/BBlocker, Firewall, & AV:

ALL

Have you made any other changes to the default config? (egs here.):

Yes. Configuration file attached.

Have you updated (without uninstall) from CIS 5, 6 or 7?:

No.
if so, have you tried a a a clean reinstall - if not please do?:

 Not Applicable.

Have you imported a config from a previous version of CIS:

No.

Clean install Windows OS < 1 week; no “bloat\crapware.” Clean install CIS.

 [b]if so, have you tried a standard config - if not please do[/b]:

 I have tried different configurations; it does not fix the issue.

 ISSUE IS NOT SYSTEM DEPENDENT:  Tested on Intel\AMD, i3, i5, A8, A10, desktop, laptop.

OS version, SP, 32/64 bit, UAC setting, account type, V.Machine used:

Windows 8.1 x86-64 (OEM) Toshiba\AMD\Intel, “Always Notify,” Administrator, No VM used.

Other security/s’box software a) currently installed b) installed since OS, including initial trial security software included with system:

a= None. b= None.

C. ATTACH REQUIRED FILES

  1. Configuration file.
  2. Samples.

[attachment deleted by admin]

Shadow Defender 7z SFX installer can by-pass default-deny configuration.

Attached installer to original post and updated comments regarding self-extracting archive installers and packers by-passing CIS default-deny configuration.

Best Regards,

HJLBX

Located standard installer that can by-pass CIS antiexecutable\default-deny configuration if run from browser: Baidu PC Faster

Link: http://baidu-pc-faster.en.softonic.com/

Best Regards,

HJLBX

Located another standard installer that by-passes CIS antiexecutable\default-deny configuration: MiniTool Partition Wizard free

Link: http://dw.cbsi.com/redir?ttag=download_now_button_click&lop=link&ptid=3000&pagetype=product_detail&astid=2&edid=3&siteid=4&destUrl=http%3A%2F%2Fdownload.cnet.com%2FMiniTool-Partition-Wizard-Free%2F3001-2094_4-10962200.html%3FhasJs%3Dn%26hlndr%3D1&onid=2094&oid=3000-2094_4-10962200&rsid=cbsidownloadcomsite&sl=en&sc=us&topicguid=utilities%2Fsys&topicbrcrm=&pid=14019572&mfgid=6285158&merid=6285158&ctype=dm&cval=NONE&ltype=dl_dlnow&spi=aa75c43d6e86143202f9868a33aeec4f&devicetype=desktop&pguid=16d6cf76a8c6690a20e54224&viewguid=U@Dpq19RnVabHV-B7ojBsUp7RSgE5-uCUX48

Best Regards,

HJLBX

Located another standard installer that can by-pass CIS antiexecutable\default-deny configuration: JAM Software Ultra Search

No need to run within browser for by-pass.

Link: https://www.jam-software.de/customers/downloadTrial.php?article_no=670&language=DE&

I can keep adding installers but I think I have sufficiently demonstrated that there is a serious security flaw with the antiexecutable\default-deny configuration I outlined in my original Bug Report.

Best Regards,

HJLBX

No reply from devs or mods?

The configuration for anti-executable\default-deny requires two other options/settings to be disabled and that is to uncheck Enable Cloud Lookup under File rating settings and Detect programs which require elevated privileges e.g. Installers or Updaters under Sandbox settings. Then CIS is properly configured for Anti-executable/Default-deny. Then try to execute applications that are not already in the local file list.

Ah-ha! Thank you.

I was having the same problem with “Install with tracing with SoftOrganizer” on a malware executable making Comodo oblivious to the malware being run where Comodo would catch it if I just ran it normally.

I submit that the options can be better worded to reflect what they do–disabling the “Trust files installed by trusted installers” option seemed to be the thing to do to keep my malware file from being trusted when run from a trusted installer but it wasn’t. I couldn’t see how disabling “Detect programs which require elevated privileges e.g. installers or updaters” was–which seemed like an option one would want to keep, lest installers go running unchecked. This was almost a deal-breaker for me.

Hello @qmarius

This issue has not been fixed in v. 4591.

  1. Re-tested with all originally supplied samples to verify issue still persists.
  2. Made minor changes to improve clarity in original report.
  3. Added new link to installer download page - which had been changed by vendor.
  4. Added HIPS default-deny configuration to original report.
  5. Changed version from 4508 to 4591.

Best Regards,

HJLBX

Also the latest version fails comodo leak test! gone back to last version and all is fine

Thank you very much for your report in standard format, with all information supplied. The care you have taken is much appreciated by Comodo, and will increase the likelihood that this bug can be fixed.

Developers may or may not communicate with you in the forum or by PM/IM, depending on time availability and need. Because you have supplied complete information they may be able to replicate and fix the bug without doing so.

I can confirm this problem on my Windows 7 Home Premium SP1 64bit system.
Same CIS version. Inform to you devs

Think about this one carefully…

Comodo defers to Windows UAC to block\alert for some installers.

What about the case of a malicious installer that disables Windows UAC - which I have seen more than a few times testing malwares.

In that case, Comodo doesn’t block malicious installer, Windows UAC is disabled and cannot block malicious installer… and

guess what ?

Goose cooked…

HJLBX

Disabling cloud lookup in addition to un-checking trust applications signed by trusted vendors forces all new files introduced to the system to be rated as unknown or unrecognized and with an auto-sandbox rule to block all applications rated as unrecognized, will block execution of those newly introduced applications.

Unfortunately, following your suggested settings does not fix the issue on my - as well as others’ - specific systems; even with the above settings the installers still by-pass CIS.

One of the primary problems is with installers that trigger Windows UAC.

HJLBX

Would you be able to provide a specific example installer that does this?

The bug report along with sample installers has been in Verified Bug Reports for some time now.

Best Regards,

HJLBX

Ok I just tried executing the installers and before a UAC prompt appeared CIS asked if I wanted to allow execution of the installer. CIS always intercepts execution of applications before anything else include a UAC elevation prompt. Unless the hips rule for windows explorer ‘run an executable’ access right is modified to allow all applications under exclusion, I don’t see how a UAC prompt can be invoked.

All the steps to recreate the by-pass are detailed in the bug report and the bug is confirmed by multiple users on different systems.

HJLBX

Unless you are running W8\8.1 you will not likely recreate the by-pass.

The bug report is for W8.1 - not all Windows OS versions.