Add "Physical Drives" group to HIPS Protected Files[M2326]

1. What actually happened or you saw:
The history goes back a number of versions of Comodo Internet Security where certain applications were able to bypass the existing HIPS protection and gain access directly to the physical drive itself. This meant they could bypass any file system and read/write binary data at arbitrary locations anywhere on the disk, including inter-partition space and the boot sector. >:( I had a notable case long time while ago where (despite having HIPS enabled) one such program was able to write data right into my boot sector (first 63 LBA of the disk). Having been running a dual-boot system at the time and running a hashing script on those sectors from a Linux OS, this of course triggered an alert each time the data was changed. I’ve repeatedly had to restore the original data from a backup before I finally traced the culprit to a ■■■■■■ DRM implementation. Fortunately there wasn’t anything majorly serious, but it could have easily been some boot sector residing malware.

2. What you wanted to happen or see:
I was running Comodo Internet Security with HIPS enabled. It should have detected this “intrusion” into outside-filesystem space on my disk. This could be a serious security issue, if applications are allowed to access and modify critical data at arbitrary locations on the disk. Perhaps CIS should finally add an option to show HIPS alerts whenever a program attempts such access because everyday applications generally do not need low-level disk access. The only legitimate programs I can currently think of are disk partitioning tools and maybe some hex editors.

3. Why you think it is desirable:
I am proposing an enhancement to the security of HIPS. :-La New CIS versions should include a new group of Protected Objects by default. Specifically a new group called “Physical Drives” should be added to Protected Files. I don’t exactly know what entries should be listed in this group, but following two entries seem to have worked for me over the years:

  • \Device\Harddisk*\DR*
  • \Device\HarddiskVolume*

4. Any other information:
Windows has a list of devices, but you can’t easily view them without using some special tools. For this purpose we will use a program called “Winobj” that is part of the Microsoft Sysinternals Suite. Running this program showed a number of interesting devices to block. For local disk drives there were a number of interesting entries that I have listed below (notice that some of them are symlinks). I do not know, if it is sufficient to block only the actual devices or do symlinks also need to be blocked, but as I have stated above, I have reduced these entries into just two effective lines. This also begs the question of what other interesting devices are listed in here that could be added to the protected files list. A few devices I can think of are Microphones and Webcams. I’ll likely have to fill in a new wishlist for those after I do some more research.

/Device/Harddisk0/DR0 /Device/Harddisk0/Partition0 => /Device/DR0 /Device/Harddisk0/Partition1 => /Device/HarddiskVolume1 /Device/Harddisk0/Partition2 => /Device/HarddiskVolume2

/Device/HarddiskVolume1
/Device/HarddiskVolume2

/Device/HarddiskVolumeShadowCopy1
/Device/HarddiskVolumeShadowCopy2
/Device/HarddiskVolumeShadowCopy3
/Device/HarddiskVolumeShadowCopy4
/Device/HarddiskVolumeShadowCopy5
/Device/HarddiskVolumeShadowCopy6
etc.

/Device/HarddiskVolumeShadowCopy{SOME-UUID-HERE}
/Device/HarddiskVolumeShadowCopy{SOME-UUID-HERE}
/Device/HarddiskVolumeShadowCopy{SOME-UUID-HERE}
/Device/HarddiskVolumeShadowCopy{SOME-UUID-HERE}
etc.

Possibly related thread about removable media:
https://forums.comodo.com/install-setup-configuration-help-cis/set-removable-drives-usb-drive-as-write-protected-t30790.0.html

EDIT: Added picture.

HIPS already protects against direct disk access. Remember you will only get a HIPS alert if the application is rated as unrecognized when HIPS is set to safe mode. To always get alerts set HIPS to paranoid mode.

Hi, futuretech.

Please allow me to get back to you on this one.

I have to admit this has been in my COMODO wishlist for a few years, and I haven’t managed to keep up with new developments. I’m going perform some testing again because I could have sworn that it did not work in the past, hence I made this thread. In either case, the worst case scenario is that the user will get 2 HIPS alerts - one for disk access and another for physical (raw) access, which can be useful since the first alert does not exactly specify what the application is trying to access. The second alert can be a potential red flag for malware, so this is still useful. Anyway, I’ll get back to you after I do some testing with CIS10.

Regards!

UPDATE: Okay, I’ve done some testing today and found out the disk access behavior has definitely changed since I last tested it. I swear some earlier versions of CIS (v5+) did not offer this type of HIPS alerts for raw access.

I downloaded Hex Workshop v6.80 from Breakpoint Software. It’s a nice hex editor, and they offer a free 30 day trial download. The main program has an option under “Disk => Open Drive…” menu to open partitions or physical drives for raw access. Fortunately my CIS did not recognize the installed files as Trusted, but listed them as Untrusted so I didn’t have to deal with that shenanigans. Upon trying to open my physical disk, I was presented with a HIPS alert whether I want to allow “Direct disk access” for this program. This alert isn’t new to me, as I’ve seen it several times in the past. Denying it effectively blocked the hex editor from reading the disk contents. Allowing it popped up a second alert that the hex editor wants to access a protected interface of “\Device\Harddisk0\DR0” (Physical Drives group).

Technically speaking it would appear that the existing HIPS disk-access protection is working, but it’s not Hex Workshop that I had problems with in the past. I am still a bit skeptical about this because I’ve seen a number of applications (notably some installers) requesting disk access without actually triggering the second alert. This means the disk access HIPS alert has multiple triggers, and not all of them are for raw disk access. I’ll keep testing this feature in the near future to see, if I can find any anomalies. Perhaps next time I install SolidWorks we’ll see, if the FlexNet service (assuming they still use that garbage) manages to write to my boot area without triggering the proper alert.

I’m withdrawing this wish for now, but if I find any more relevant data in the future I’ll request a reevaluation… unless someone else wants to add anything to the discussion?

Regards!

The direct disk access alert is really an alias for anytime a process wants to open \Device\HardDisk* with any kind of access above read access (GENERIC_ALL, GENERIC_WRITE) just like the direct memory access alert is an alias for the \Device\PhysicalMemory object. So it is redundant to have a file group containing the \Device\HardDisk path added to protected files.

Greetings once again!
I finally managed to install SolidWorks and test things out again. And as it turns out I was right all along. In this report/wishlist I originally performed a simple test by using Hex Workshop that I had initially installed after a clean reinstall of Windows 7. My CIS10/HIPS was in safe mode, and all related files were unrecognized by Comodo File Rating (they were not HIPS-whitelisted). I tested this without adding my “Physical Drives” group into the HIPS Protected Object section.

Here are the results:
When I ran Hex Workshop and tried to open my HDD for raw access, I would get a nice HIPS alert asking me whether I want to allow an application (BPSDA64.exe) that is trying to access the disk directly (see first attached image). I confirmed this (see second image) by observing what is happening in the Process Monitor by Microsoft Sysinternals, although the Comodo HIPS Alert Logs show that the program tried to access a file called “??\PHYSICALDRIVE0” instead.

Next I ran Solidworks which in turn triggered the FlexNet program (FNPLicensingService64.exe) to run and nothing happened - no similar disk access alerts popped up. Upon next reboot my Veracrypt complained that the boot sector has been compromised. I managed to restore my boot sectors (first 2048 LBA) from a backup and repeated the test. Similarly, no alerts popped up, but this time I had Process Monitor running and I managed to capture the culprit (see third image). Once again here are the very same results that I reported years ago in my original thread (the procmon image sadly got removed). The program is somehow able to write data to my LBA 0x3C without triggering any disk access HIPS alerts.

Finally I added my “Physical Drives” group to the HIPS Protected Objects section, restored the bootloader and repeated the tests. Running Hex Workshop now produced two HIPS alerts - the original direct disk access popup and a new protected object popup (mine). Next I executed Solidworks and waited to see what would happen. And what do you know… looky here (last image), there is a new HIPS alert! I wonder what could this be. Could it be that sneaky flexnet trying to write to my boot sectors again? :slight_smile:

So there you have it.
This is the reason why I originally asked for the Physical Drives to be added to Protected Objects by default. Apparently the built-in direct disk access does not offer adequate protection. Even today, this security bypass is still present in CIS today after 3 years of me originally reporting it. IMO it is a serious security bypass and should be fixed ASAP in default installations of CIS. I proposed a trivial fix by simply adding a new group to the protected objects list. The benefit of this approach is that it doesn’t even require the devs to do any programmatic changes to the product.

So Comodo, please…
FIX! FIX! FIX!

It could be doing so by using a kernel mode driver, does this service start at system startup? You can try to enable block all unknown requests when the application is not running under HIPS settings and save the HIPS rule to block loading device driver and direct disk access for the service executable, reboot and check HIPS logs to see any blocked events from the service.

I tried 3 different methods of direct disk access and each time I was presented with a direct disk access alert. They were: call CreateFile with path of \.\PhysicalDrive0, CreateFile call with \.\C: and NtCreateFile using \Device\Harddisk0\DR0 path.

Thanks Angle,
we will check and get back to you.

■■■■ you, futuretech! You made me do research on this thing for a third time. :slight_smile:

I didn’t see any kernel driver popups during testing phase or otherwise, although there were a number of other HIPS popups about this process (i.e. some file access requests in Program Files), I didn’t deem them relevant to this discussion. But by the looks of it it’s using classic WriteFile Windows API to do the job according to the Process Monitor. No, the service does not seem to start at boot - at least the process executable isn’t present in Process Explorer after the PC starts up, but it pops up after SolidWorks is started for the first time. Although there seem to be two of these FlexNet Services present in Sysinternals Autoruns, I’ve checked the Windows Computer Management (right-click “My Computer” and choose “Manage”) and both service entries seem to be set to manual startup.

  • c:\program files (x86)\common files\macrovision shared\flexnet publisher\fnplicensingservice.exe
  • c:\program files\common files\macrovision shared\flexnet publisher\fnplicensingservice64.exe

I’ve done as you’ve asked. I’ve enabled “Block all unknown requests…” and set the HIPS permissions for this process to block Disk access and Device drivers’ installation. After a reboot the logs didn’t show anything blocked or suspicious in “HIPS Events”.

Anyway, we’re probably just jumping left and right here. Perhaps it would be best, if I somehow managed to send over this file (or better yet an installer) so you can perform the tests yourself?

Hi Angle,
Thank you for keeping following up CIS.
Please confirm:

  1. please check rating of FlexNet program (FNPLicensingService64.exe) in File Lists, make sure it is unknown, otherwise CIS does not give hips alert.
  2. please make sure there is no application HIPS rule in Setting which may be saved automatically when you remember a previous choice.

Regards
Haibo

Okay, so here’s the thing.

I believe it would be best, if I managed to somehow hand over this whole ■■■■ thing so you people can perform the analysis yourselves. I tried to look for an installer for this FlexNet thing, but apparently it is built-in into the SolidWorks installer itself. Unfortunately I will not be able to send you the whole installer because:

  • The installer is several gigabytes in size
  • It is copyrighted stuff

I have however done some digging online, and I believe I may have found a viable alternative. Although this approach is still on the edge of shady business, we’re doing this for research purposes, right? Anyway, I found a program online that apparently has the same flexnet installer built-in, but is only 15 MB in size. Is it okay with you people, if I turn this file over to you? I tested it out a bit in my temporary Windows 7 installation and it behaves the same way i.e. no disk access popup.

I already checked prior posting my update. The file is classified as Unrecognized (with a grey question mark icon) in the file list of the File Rating section. I also mentioned that I have seen a number of other HIPS alerts (popups) for this application during my tests. There were just no disk access alerts.

FNPLicensingService64.exe
CRC32: 8700CC37
MD5: D64DC2C0A849063960159D84E4154329
SHA-1: 182DBEA7325408CDC67BA2BC2BF2B1BF54196223
SHA-256: F2A3A1AC3EDD8B2D94E98F5FAE45F7C42CDBD12B1FAC2B1338A6BAF78936D940
SHA-512: 019820619D53A8752F21B3C8EB388CC081440B21902A317B5FFC30BE5B7CBECA24EBBFF10CE2BB571F7D73D3BA075E822ECC633607B70057A2744F64682152F5

I’m not exactly sure what you mean here, but I have deleted the HIPS rule for FNPLicensingService64.exe several times while I was repeating my experiments. I did choose the popup to remember my choices, but those alerts were not for the disk access (there was never a disk access popup). Even now the rule has a custom ruleset for FNPLicensingService64.exe, and the “Disk” entry is set to “Ask”. While running, I only get the popup for my own Physical Drives entry (see last image in my previous analysis post).

Cheers!

I have however done some digging online, and I believe I may have found a viable alternative. Although this approach is still on the edge of shady business, we're doing this for research purposes, right? Anyway, I found a program online that apparently has the same flexnet installer built-in, but is only 15 MB in size. Is it okay with you people, if I turn this file over to you? I tested it out a bit in my temporary Windows 7 installation and it behaves the same way i.e. no disk access popup.
Yes you can send me a PM and I will take a look and pass it on as well to comodo.

PM Sent…

Hi Angle,
Can you pls send the 15M installer to haiboz@comodo.com, pls zip with password and send.
Regards
Haibo

I CC’d your e-mail address that is listed in the tracker but I will send you the file to the comodo.com address. One thing I noticed was when application is running in containment you will see in HIPS logs the blocked event for direct disk access, but outside containment it doesn’t alert for direct disk access and you will only notice direct disk modification if you add \Device\Harddisk* to protected objects > protected files under HIPS settings. Due note that FNPLicensingService64.exe is trusted due to being signed by Flexera Software LLC which is in trusted vendors list, so remove vendor prior to testing and disable cloud lookup or set HIPS to paranoid mode.

Simple way to test is to use option ‘Purge All Activations’ button of application found in archive.

Yeah, maybe I forgot to mention that I purged all my trusted vendors list prior testing. The only vendors I left in the list were Microsoft, Comodo and some driver vendors i.e. Intel, AMD/ATI, etc. Cloud lookup was also disabled, and HIPS was in safe mode. Although I am unsure how much all of this matters, but FNPLicensingService64.exe was listed as unrecognized file in my list, but I take it you could also manually set it to unrecognized, but I haven’t tried that.

herbzhang: Do you still need the file?

I have successfully reproduced, by installing an adobe ps cs3 build with flexnet protection。
I remove all trust vendor ,stop internet ,move FNPLicensingService to untrust file. and set HIPS to paranoid mode.
Looks especially strange.
FNPLicensingService write disk call stack to atapi.sys

ChildEBP RetAddr Args to Child

00 b1f2cae8 f8dd85a3 8240cd98 81bd98c8 8240cd98 atapihook!fake_handle+0x45 (FPO: [Non-Fpo]) (CONV: stdcall) [c:\users\jacklee\desktop\mbr\79953504atapirw-specsectors\atapi_bandiskwrite\atapi\atapihook.c @ 72]
01 b1f2cafc 804ef119 8240cd98 81bd98c8 81bd9a88 atapihook!fake_scsi_dispatch+0x13 (FPO: [Non-Fpo]) (CONV: stdcall) [c:\users\jacklee\desktop\mbr\79953504atapirw-specsectors\atapi_bandiskwrite\atapi\atapihook.c @ 124]
02 b1f2cba4 805cf3a0 00000000 81bde0d8 b1f2cbf4 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
03 b1f2cbb4 805cf092 81bde0d8 81be0008 81be00e4 nt!RawReadWriteDeviceControl+0x60 (FPO: [Non-Fpo])
04 b1f2cbf4 804ef119 81bde020 81be0008 81be0008 nt!RawDispatch+0x114 (FPO: [Non-Fpo])
05 b1f2cc70 80575d5e 81be0108 00000000 81be0008 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
06 b1f2cc84 8057384a 81b03c38 81be0008 82414d98 nt!IopSynchronousServiceTail+0x70 (FPO: [Non-Fpo])
07 b1f2cd38 8053e638 000000d8 00000000 00000000 nt!NtWriteFile+0x602 (FPO: [Non-Fpo])
08 b1f2cd38 7c92e4f4 000000d8 00000000 00000000 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ b1f2cd64)
09 00a5fcf0 7c92df6c 7c810e86 000000d8 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
0a 00a5fcf4 7c810e86 000000d8 00000000 00000000 ntdll!NtWriteFile+0xc (FPO: [9,0,0])
0b 00a5fd54 004017b3 000000d8 00870bd0 00000200 kernel32!WriteFile+0xf7 (FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be wrong.
0c 00a5fd7c 00401ed8 00000000 00000000 007550ac FNPLicensingService+0x17b3
0d 00000000 00000000 00000000 00000000 00000000 FNPLicensingService+0x1ed8

------------------------------------FNPLicensingService writefile handle analyzing ----------------------------------------
kd> !handle 0xd8

Failed to get VadRoot
PROCESS 82194488 SessionId: 0 Cid: 0ab4 Peb: 7ffdc000 ParentCid: 0314
DirBase: 0a0c0420 ObjectTable: e105c750 HandleCount: 54.
Image: FNPLicensingService.exe

Handle table at e105c750 with 54 entries in use

00d8: Object: 81bd5868 GrantedAccess: 0012019f Entry: e11ae1b0
Object: 81bd5868 Type: (825ebe70) File
ObjectHeader: 81bd5850 (old version)
HandleCount: 1 PointerCount: 3

kd> !fileobj 81bd5868
Device Object: 0x8226bab8 \Driver\Disk
Vpb: 0x825ea190
Access: Read Write SharedRead SharedWrite

Flags: 0x44000a
Synchronous IO
No Intermediate Buffering
Handle Created
Volume Open

File Object is currently busy and has 0 waiters.

CurrentByteOffset: 4000

kd> !devobj 0x8226bab8
Device object (8226bab8) is for:
DR0 \Driver\Disk DriverObject 824d5938
Current Irp 00000000 RefCount 1 Type 00000007 Flags 00000050
Vpb 825ea190 SecurityDescriptor e10088d8 DevExt 8226bb70 DevObjExt 8226bfd0 Dope 825e5f20
ExtensionFlags (0000000000)
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) 824d6b70 \Driver\PartMgr
AttachedTo (Lower) 8240cd98 \Driver\atapi
Device queue is not busy.

kd> !devstack 0x8226bab8
!DevObj !DrvObj !DevExt ObjectName
824d6b70 \Driver\PartMgr 824d6c28

8226bab8 \Driver\Disk 8226bb70 DR0
8240cd98 \Driver\atapi 8240ce50 IdeDeviceP0T0L0-3
!DevNode 820c1ee8 :
DeviceInst is “IDE\DiskVMware_Virtual_IDE_Hard_Drive___________00000001\3030303030303030303030303030303030303130”
ServiceName is “disk”


I write a same program using like CreateFileA “\\.\PhysicalDrive0” WriteFile
handle analyzing is same
---------------------------------MyPhysicalDrive0 writefile handle analyzing--------------------------
kd> !handle 50

Failed to get VadRoot
PROCESS 81bd2430 SessionId: 0 Cid: 01fc Peb: 7ffda000 ParentCid: 06a0
DirBase: 0a0c0460 ObjectTable: e2f04468 HandleCount: 21.
Image: PhysicalDrive0WriteDisk.exe

Handle table at e2f04468 with 21 entries in use

0050: Object: 8216bb00 GrantedAccess: 0012019f Entry: e12c50a0
Object: 8216bb00 Type: (825ebe70) File
ObjectHeader: 8216bae8 (old version)
HandleCount: 1 PointerCount: 1

kd> !fileobj 8216bb00

Device Object: 0x8226bab8 \Driver\Disk
Vpb: 0x825ea190
Event signalled
Access: Read Write SharedRead SharedWrite

Flags: 0x44000a
Synchronous IO
No Intermediate Buffering
Handle Created
Volume Open

CurrentByteOffset: 600

kd> !devobj 0x8226bab8
Device object (8226bab8) is for:
DR0 \Driver\Disk DriverObject 824d5938
Current Irp 00000000 RefCount 1 Type 00000007 Flags 00000050
Vpb 825ea190 SecurityDescriptor e10088d8 DevExt 8226bb70 DevObjExt 8226bfd0 Dope 825e5f20
ExtensionFlags (0000000000)
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) 824d6b70 \Driver\PartMgr
AttachedTo (Lower) 8240cd98 \Driver\atapi
Device queue is not busy.
kd> !devstack 0x8226bab8
!DevObj !DrvObj !DevExt ObjectName
824d6b70 \Driver\PartMgr 824d6c28

8226bab8 \Driver\Disk 8226bb70 DR0
8240cd98 \Driver\atapi 8240ce50 IdeDeviceP0T0L0-3
!DevNode 820c1ee8 :
DeviceInst is “IDE\DiskVMware_Virtual_IDE_Hard_Drive___________00000001\3030303030303030303030303030303030303130”
ServiceName is “disk”


while ring3 SCSI-PASS-THROUGH is like that
------------------------------SCSI-PASS-THROUGH packet send to atapi |handle is different--------------------------
kd> !fileobj 824545f8

Device Object: 0x8240cd98 \Driver\atapi
Vpb is NULL
Event signalled

Flags: 0x40002
Synchronous IO
Handle Created

CurrentByteOffset: 0

kd> !devobj 0x8240cd98
Device object (8240cd98) is for:
IdeDeviceP0T0L0-3 \Driver\atapi DriverObject 82427a58
Current Irp 00000000 RefCount 1 Type 00000007 Flags 00005050
SecurityDescriptor e10088d8 DevExt 8240ce50 DevObjExt 8240cfd0 Dope 825e5e50 DevNode 820c1ee8
ExtensionFlags (0000000000)
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) 8226bab8 \Driver\Disk
Device queue is not busy.
kd> !devstack 0x8240cd98
!DevObj !DrvObj !DevExt ObjectName
824d6b70 \Driver\PartMgr 824d6c28
8226bab8 \Driver\Disk 8226bb70 DR0

8240cd98 \Driver\atapi 8240ce50 IdeDeviceP0T0L0-3
!DevNode 820c1ee8 :
DeviceInst is “IDE\DiskVMware_Virtual_IDE_Hard_Drive___________00000001\3030303030303030303030303030303030303130”
ServiceName is “disk”


Also need to further confirm the analysis of the behavior of FNPLicensingService.exe in ring3 , how send parameter to open target device ,when the writefile handle borned.

Best Regards

Issue is caused by HIPS ignoring/allowing certain actions when an application is running at the System level account.

Hi Guys,
We allow application running at system level to make these operations.
Considering an unknown application can not install application that will have access at system level, this hypothesis is not valid for malware.

So you can’t write a malware to achieve it.

Thanks
-umesh

But you can by using the CreateService function and setting the lpServiceStartName parameter to NULL which tells createservice to use the local system account. Which is what happened with flexnet being installed as a windows service to run in the context of the SYSTEM account. HIPS should be as strong if not more effective as the sandbox, so HIPS should monitor all actions of a process regardless of what account it is running under as.