Automatic allow for application running under Authority-NT/System account

Hello,

I’m not filling a bug report for 3 reasons :

  • first, I use an old version of comodo (3.5.54375.427), because I’m afraid to recreate all rules…
  • second, if it is a bug it might have been corrected in new versions (I would like a link to a versions changelog between all versions so that I could see what has been corrected :slight_smile: )
  • third, it might not be a bug but a feature (apps running as Authority-NT/System might be given some rights automatically since they can’t be started under this account unless the system is already compromised)

My config :

Windows XP SP3
Comodo 3.5 in Paranoïd mode

What happens :

If I run an application under the Authority-NT/System account, this app can do “direct disk access” and “protected com-privileges access” without warning of CIS

However this app will trigger an alert when “modifying protected file”, “modifying protected registry key”, “starting a driver”

But the same programs will normally trigger the alerts for “direct disk access” and “protected com-privileges access” if run under the admin account…

I couldn’t test other CIS alerts since I don’t have programs that trigger them

How to test that yourself :

If someone want to test (most probably under a current version of CIS) :

you can use Diskview from sysinternals/microsoft : http://download.sysinternals.com/Files/DiskView.zip that does “direct disk access” when refreshing its view
and process explorer from sysinternals/microsoft : http://download.sysinternals.com/Files/ProcessExplorer.zip that does “modify protected file”, “modify protected registry key”, “start a driver” and “protected com-privileges access”

Since these 2 apps are from sysinternals/microsoft and are signed, you should not “trust app digitally signed” from sysinternals/microsoft or you will get no alert at all !

You’ll also need to start these applications under the Authority-NT/System account :
Personnally I use NtWrapperLite from duodata : duodata.de
If you run Vista/7 you may need to read this page :duodata.de to have the app started by NtWrapperLite be interactive (with a GUI)
A more simple alternative may be to start these applications through the task scheduler, see here : http://security.fnal.gov/cookbook/LocalSystem.html

Thanks for any response.

Not interesting enough subject?
I know it’s week-end… 88)

But if it is an already corrected bug, or a well-known ‘feature’, I would like a link for some explanation

I did search the CIS forum for ‘authority’ and ‘localsystem’ but with 0 relevant result (except my own post)

:-La Don’t mistake an application runnning under the Authority-NT/System account (or LocalSystem account, this is the same thing I think), and the (pseudo-)process called System

PS : found the link to the release notes Comodo Internet Security Release Notes with Version Updates
Read all of it, but apparently no bug fix concerning this problem since my version (3.5.54375.427) up to the last 5.0.163652.1142…

bump

I think this question should be answered to, or someone to test that it does not occur any more on current CIS versions.

The test i made under xp sp3, cis 3.13 and procexp started from the command line under authorityNT won’t be conclusive, i suppose:
everything is customized in my cis 3.13 installation, and procexp has e.g. allowed COM interfaces privileges (LocalSecurityAuthority debug, backup and shutdown).

I can run the same test under cis 5, but it shall most certainly have the same results: when launching procexp from the command line, defense+ asks for cmd.exe to run procexp, exactly like it does when the credentials are not authorityNT, and thus in these conditions authorityNT cannot run it in my back, but i suppose that this customized behavior won’t help you much.

Thanks for your test Brucine

and thus in these conditions authorityNT cannot run it in my back
to be clear authorityNT/System is not a program but an account under which a programs runs (the account a program is currently using can be seen with the TaskManager or with ProcExp in the UserName column)

It would be easier with DiskView that just does ‘Direct Disk Access’
http://download.sysinternals.com/Files/DiskView.zip
(!) this file is signed by Microsoft/SysInternals so it could be allowed automatically
(you may have to temporarily not trust Microsoft/SysInternals publisher to perform a valid test)

Starting the program to test from the command line (cmd.exe) is not enough to have it be run under the authorityNT/System account, unless cmd.exe is already running under this account (But maybe you anderstood that, and did it the right way…)

as a reminder you can find here a method with the TaskScheduler to start any app under the authorityNT/System account : http://security.fnal.gov/cookbook/LocalSystem.html
(on my computer XP-SP3 the ‘Task Scheduler’ service is named ‘Schedule’)

As a last point, the question is not a missing alert for a program start, but for a program (DiskView.exe for example) getting a special right (‘Direct Disk Access’ in this case).

I suppose i expressed myself in a wrong manner: i actually tested like you said, running e.g. Diskview from the command line after having shifted to the NT Authority/System account.

Diskview fails to alert for Disk access under both accounts, as does procexp, and by extension probably whatever Microsoft (and by extension Sysinternals) software, altough Cloud, Sandbox, and Trusted Vendors are all disabled.

It reminds me of experimenting replacing Microsoft’s genuine shutdown.exe by a third-party executable, same name and location: CIS warns for running the third-party one, but not the genuine one, leading to think (and as also showed by CIS event logs reporting some running applications as “trusted” altough nothing is) that CIS is somehow hardcoded to trust some softwares even if no setting says so.

This leaded me to test further with a Non-Microsoft software.
Altough a lot of applications require disk access (e.g. both Partition Magic and Easeus Partition Manager do), they are “heavy” executables requiring full installation.
I thus decided to use HP USB Format Tool.
You can get it from the web googling “sp27213” or “sp27608”, but providing a not installable, but extractable exe with the 2 relevant applications, HPUSBF.EXE (Dos emulation mode) and HPUSBFW.EXE (Windows GUI mode), and of course need for testing purposes Hewlett-Packard to be disabled as a trusted vendor if it is.
In order to avoid you the said extraction, i append the 2 said files, and of course HPUSBF.EXE is more handy for what we are concerned with, as it only requires explorer.exe permission and asks for direct disks access as soon as launched.

I tested it both under cis 3.13 and cis 5.0, from my usual administrative account in the GUI way and from the command line, and under NT Authority/System launched either from the command line, either from NT Wrapper.
I supopose that you know that, in this regard, “scheduling” cmd.exe launches 2 windows, the initial one and the one launched when you reach the time specified by “AT”: this last one starts as a child of SCVHOST.EXE, and fails the tests whereas the first one succeeds under administrative account.

The same behavior occurs whatever the way of running the executable is under the NT Authority/System account, but observing in every instance that HPUSBF.EXE is launched as a child of the launching application (CMD.EXE, NT Wrapper, SVCHOST.EXE) themselves children of system applications always running under NT Authority/System (Winlogon, Explorer,…).

I don’t think it possible to deny or ask in CIS disk access for Winlogon (you would never boot) or practical to do it for EXPLORER.EXE, doing so with every other involved system application fails.

The next question is whether this is a CIS bug or “feature”, i.e. under what conditions a malware could control your system through the very high privileges of NT Authority/System: sasser, of course, or Network Shares, are then other CIS defense lines supposed to intercept them, clearly speaking, is remote execution of malware/hacking possible using NT Authority/System without oneself having installed some malware in this regard on the local side, or must we think that legit applications using this account could also use it for malware behavior?

[attachment deleted by admin]

Diskview fails to alert for Disk access under both accounts
Strange, under CIS 3.5, I get the normal alert for DiskView (v2.3) under my Admin account (and no alert under AuthorityNT account), so I had to create a rule for it (Disk Access : Allow). If I don't give Disk Access to DiskView under Admin account it will fail with this message : "Could not open volume".

In my trusted vendors list I don’t have Microsoft or SysInternals, in defense+ settings I have unchecked ‘trust digitally signed softwares’, and I’m in paranoïd mode.

I tried HPUSBFW.EXE, same result as DiskView (alert for Disk Access under Admin account, no alert under AuthorityNT account), more details :

  • under Admin account : HPUSBFW.EXE does NOT work if I deny Disk Access (it displays empty and disabled fields for Device/File System/Volume Label/etc…, and the Start button does nothing), if I allow Disk Access it works normally (fields are filled with infos regarding my 2 USB devices and the start button initiate a formating).
  • under AuthorityNT account : no alert, and HPUSBFW.EXE works normally.
this last one starts as a child of SCVHOST.EXE, and fails the tests whereas the first one succeeds under administrative account.
I understand you get the same result as me with HPUSBFW.EXE (even with CIS v5) : * alert for disk access under Admin account * NO alert for disk access under NTAuthority/System account If so, it's really an account issue.
is remote execution of malware/hacking possible using NT Authority/System without oneself having installed some malware in this regard on the local side, or must we think that legit applications using this account could also use it for malware behavior?
If a malware is already running under Admin account (this is bad), it should not be very difficult for it to restart itself under the NTAuthority/System account, thus bypassing Disk Access And Protected COM-privileges Access (which is worse...) To achieve that it just needs to infect a usually unprotected non-microsoft service, like Lavasoft AdAwareService, or ToshibaTappsrv for Toshibas, that both run under the NTAuthority/System account

This a long post. (I hope it is clear enough)
If the issue is confirmed (by you) under CIS v5, I think it would be good by now to get an answer from a moderator/CIS specialist
I can’t really fill a bug report in the bug forum (or should I ?) since I use an old version of CIS : v3.5 (I’m looking for a link to the CIS v4_1_150349_920 installer to upgrade - I don’t want to go to v5 yet)

I globally have the same settings in cis 3.13 and cis 5.0, and agree to everything excepting the Microsoft/Sysinternals software, where i definitely have no disk access alert under administrative account (i even deleted my cis 3 procexp defense+ entries in order to make sure it was not due to inappropriate access rights).

I am not sure that it is a good idea to upgrade cis 3 to cis 4, often very deceptive, and that it is not better to install 4 from scratch. (I am not even sure that, in fully customized configuration, it is a good idea to run cis 4 or cis 5 at all, and i am only running cis 5 on one of my 2 disks for translation purposes, but it is another question).

If it helps, i have a (never used) cis 4.1 installer (32 bits 4.1.19277.920) in my backup disk, and i can upload it if you want.

Fill a bug if you want, i could do it myself for actual cis 5 version, but i won’t ever do that anymore: you shall spend a lot of time making it under proper format, to hear afterwards either that your issue is not popular enough and is of no interest, either that is is “submitted to developpers”, coming back to the first situation: you won’t ever hear of it again.

Thanks for the time spent for testing

Well, I just supposed that some critical bugs may have been corrected between 3.14 to 4.1, but maybe not.
I won’t use sandbox/cloud check/AV, so 3.14 might be the best (I already have the installer on my computer)

However, if I changed my mind, I would like an upload of v.4.1.150349.920 - 32bits (which has an installer version 4.1.19277.920), or just a link to it since FileHippo does not host this file anymore (they redirect to v5)
If you can’t (it’s big, about 55MB) it does not matter.

I may fill a bug report If have the time (I will just say that the issue seems to occur also with v5, and link to this thread)

However, if I changed my mind, I would like an upload of v.4.1.150349.920 - 32bits (which has an installer version 4.1.19277.920)

Here you are:
http://brucine.hostoi.com/cis41.zip

Downloaded it
Thanks :-TU