Ask Questions Here - ReHIPS Features & Unexpected Behaviors

[Noverco]

Thank you, fixer that's absolutely smashing news.  I am certainly impressed on how quickly this issue has been resolved. 

How does one get this fix - is it via a new updated version of a ReHIPs?

[aDVll]

Thank you, fixer that's absolutely smashing news.  I am certainly impressed on how quickly this issue has been resolved. 

How does one get this fix - is it via a new updated version of a ReHIPs?

yes. You will be able to test the fix on the next rehips version. Rehips it's a completely offline solution it doesn't do updates on it's own. 

[Noverco]

Thank you, aDVll for the confirmation that the new fix will be delivered via a new version of ReHIPs. Will look forward to test new version.

[HJLBX]

I am trying to solve a few problems.

General Problem:

Some programs installed in real user directory (C:\Program Files and C:\Users\User\AppData - as examples) do not function correctly to various degrees when executed isolated.

Question:

Is there a way to install those problematic programs directly inside the ReHIPSUser profile - instead of the real user profile - to see if that will resolve the problematic behavior(s) ?

If yes, then what is the proper procedure ?

[fixer]

Is there a way to install those problematic programs directly inside the ReHIPSUser profile - instead of the real user profile - to see if that will resolve the problematic behavior(s) ?

DeployHelper was meant for this. Right-click on your program setup/installer file->Run in ReHIPS DeployHelper. If installer requires admin privileges, then Run in ReHIPS DeployHelper as Administrator can be chosen. Then this program standard setup window will be shown, install it. After installation finishes, DeployHelper window will be shown with possible list of executable files. Take a look at this list and make some changes if needed. These files will be added to the ReHIPS database to be started in isolation in the same isolated environment your program was installed into.

[HJLBX]

Is there a way to install those problematic programs directly inside the ReHIPSUser profile - instead of the real user profile - to see if that will resolve the problematic behavior(s) ?

DeployHelper was meant for this. Right-click on your program setup/installer file->Run in ReHIPS DeployHelper. If installer requires admin privileges, then Run in ReHIPS DeployHelper as Administrator can be chosen. Then this program standard setup window will be shown, install it. After installation finishes, DeployHelper window will be shown with possible list of executable files. Take a look at this list and make some changes if needed. These files will be added to the ReHIPS database to be started in isolation in the same isolated environment your program was installed into.

Is there any security disadvantage - to programs installed to ReHIPSUser with DeployHelper ?

By that, I mean, isn't a program installed to ReHIPSUser at least a bit more vulnerable to tampering or other mis-deeds - as opposed to it being installed in the real user profile (C:\Programs) ?

I don't honestly know if there is any significant risk to malc0de having access to a program's executables and libraries within ReHIPSUser.  Malc0ders don't typically try to modify program *.exes and *.dlls since the typical installation directories are protected against modification by Windows.

However, if the executables and libraries are installed to ReHIPSUSer, does ReHIPS protect them from modification - the same as Windows' file system protection mechanisms ?

[fixer]

Is there any security disadvantage - to programs installed to ReHIPSUser with DeployHelper ?

By that, I mean, isn't a program installed to ReHIPSUser at least a bit more vulnerable to tampering or other mis-deeds - as opposed to it being installed in the real user profile (C:\Programs) ?

DeployHelper installation itself doesn't provide security, i.e. it you start some malicious installer by DeployHelper, it may do something bad during installation. But after installation it doesn't matter if you use this program after Allowing in isolation or after DeployHelper installation, both are equally secure.

I don't honestly know if there is any significant risk to malc0de having access to a program's executables and libraries within ReHIPSUser.  Malc0ders don't typically try to modify program *.exes and *.dlls since the typical installation directories are protected against modification by Windows.

However, if the executables and libraries are installed to ReHIPSUSer, does ReHIPS protect them from modification - the same as Windows' file system protection mechanisms ?

At first I'd like to say, that even DeployHelper-installed software may reside in Program Files folder. It'll require admin during installation, but it's possible.
You're right, Program Files folder is write-protected, isolated programs won't be able to write into in/change files in it, and ReHIPS user home profile folder is isolated-program writable. But does it pose security risk? I don't think so. When it comes to overwriting executables, it means isolated environment is already compromised, and some malicious code is already executing in it. This executable files changing right won't allow it to elevate, something like let it persist in already compromised isolated environment. But such environment should be recreated anyway. Besides ReHIPS control hashes of executable files. Plus malware can persist without executable files modification, but controlling program data (some exploit, for example).

[HJLBX]

How are you "white-listing" programs ?

1.  By file-path only
2.  By digital signature (Trusted Publisher & valid certificate)
3.  By hash

Combination of all (3) above ?

* * * * *

Here is worst case scenario:

A.  RulesPack contains rules for Program_XYZ.exe installed at C:\Program Files, C:\Program Files (x86) or C:\Users\User\Local\AppData.
B.  Program_XYZ.exe uses digital certificate from Trusted Publisher that is stolen\counterfeited.
C.  No white-listing via hash. (I don't know how you could stay on top of installer hashes)

Not likely, but possible...

[fixer]

By "white-listing" I guess you mean initial rules installation by RulesPack?
It uses only (1). ReHIPS relies on assumption that computer is clean in the moment ReHIPS is installed. Otherwise malware may persist with some drivers and no security software can effectively with 100% guarantee fight it. And as far as I remember, there was a note in some manual that it's recommended to manually check the rules installed by RulesPack. Besides (2) and (3) may change very quickly. For example, chromium is built every day (in not several times a day) and it's not signed. And RulesPack was designed to provide relatively easy way to install rules for any program version. With the though in mind that this interface may be made public one day so users could make their own set of initial rules.

[HJLBX]

Hello Guys,

Can a *.sys file in User Space that is registered on the system to Windows services run amok ?

For example, a malicious *.sys located at c:\users\user\*.

Are there any internal Windows mechanisms that would check a malicious driver or executable registered as a service in User Space ?

[fixer]

Administrator privileges are required to register a new service.
But if some service is already registered, it's possible to replace its executable file with some malicious file. So all service executable files should be stored in secured locations (like System32 or Program Files). And I haven't seen any software yet that installs service executables in insecure locations. Neither I recall any software that checks for this.

[HJLBX]

Administrator privileges are required to register a new service.
But if some service is already registered, it's possible to replace its executable file with some malicious file. So all service executable files should be stored in secured locations (like System32 or Program Files). And I haven't seen any software yet that installs service executables in insecure locations. Neither I recall any software that checks for this.

It has the appearance of being a wide-open door... because all the security softs I have seen don't check for *.sys files in User Space.

It is not difficult to register a driver or service in Use Space, type kernel, start at boot.

I have seen a few malware register executables, but not *.sys files, as services from User Space.

That all being said, of course it is no issue for ReHIPS because of the way isolated environment is designed\works.

Thanks fixer.

[Umbra]

Administrator privileges are required to register a new service.
But if some service is already registered, it's possible to replace its executable file with some malicious file. So all service executable files should be stored in secured locations (like System32 or Program Files). And I haven't seen any software yet that installs service executables in insecure locations. Neither I recall any software that checks for this.

It has the appearance of being a wide-open door... because all the security softs I have seen don't check for *.sys files in User Space.

It is not difficult to register a driver or service in Use Space, type kernel, start at boot.

I have seen a few malware register executables, but not *.sys files, as services from User Space.

That all being said, of course it is no issue for ReHIPS because of the way isolated environment is designed\works.

Thanks fixer.

Remember that you have Secureboot and Early-launch anti-malware feature on Win8/10, that block malicious drivers during boot.

[HJLBX]

Administrator privileges are required to register a new service.
But if some service is already registered, it's possible to replace its executable file with some malicious file. So all service executable files should be stored in secured locations (like System32 or Program Files). And I haven't seen any software yet that installs service executables in insecure locations. Neither I recall any software that checks for this.

It has the appearance of being a wide-open door... because all the security softs I have seen don't check for *.sys files in User Space.

It is not difficult to register a driver or service in Use Space, type kernel, start at boot.

I have seen a few malware register executables, but not *.sys files, as services from User Space.

That all being said, of course it is no issue for ReHIPS because of the way isolated environment is designed\works.

Thanks fixer.

Remember that you have Secureboot and Early-launch anti-malware feature on Win8/10, that block malicious drivers during boot.

I wonder if registering a *.sys file as a service somehow circumvents SecureBoot and ELAM on W8/10 ?

Just wondering... sort of interesting.  I am not sure if there is a distinction between a *.sys driver and a *.sys service on Windows.

Think about it.  When testing malware, some will register services - using an *.exe, but I wonder if it can be successfully done with a *.sys.

[fixer]

Services can be .sys and .exe files.
.sys files are drivers. Drivers operate in kernel-mode and most of them are loaded after ELAM (thus enabling ELAM to inspect loading drivers).
.exe files are user-mode services and are loaded after initialization of some user-mode subsystems which is usually after drivers.
ELAM was mostly designed to inspect drivers, so registering a .sys service won't circumvent it. But keep in mind, it's just some signature scanning, so don't expect some magic detecting unknown samples.