Ask Questions Here - ReHIPS Features & Unexpected Behaviors

Started by HJLBX, April 11, 2016, 01:56:50 AM

Previous topic - Next topic

HJLBX



Here is one of those strange command lines:

taskhostw.exe $(Arg0)

This is the command line for starting a program via Task Manager.

Even though the command line is whitelisted in ReHIPS, executing a program via Task Manager will always generate a Sub-Program alert for this command line.

Any ideas ?

fixer

This is a bug. Should be fixed in the upcoming release.

HJLBX

I have been trying to open ReHIPS.xml.

I have tried opening as Admin, but ReHIPS.xml will always open as a blank page in Internet Explorer.

I have also tried as Admin using WPS xml editor - which also uses Internet Explorer - so same result.

* * * * *

I can open using WPS text editor and keep most of the xml formatting, copy & paste to notepad - so I found a workaround.

* * * * *

I don't want to open xmls as text file because it is just a jumbled mess in plain text editors.

* * * * *

Am I missing something when trying to use browser to open ReHIPS xml ?

aDVll

Quote from: HJLBX on April 27, 2016, 12:42:03 AM
I have been trying to open ReHIPS.xml.

I have tried opening as Admin, but ReHIPS.xml will always open as a blank page in Internet Explorer.

I have also tried as Admin using WPS xml editor - which also uses Internet Explorer - so same result.

* * * * *

I can open using WPS text editor and keep most of the xml formatting, copy & paste to notepad - so I found a workaround.

* * * * *

I don't want to open xmls as text file because it is just a jumbled mess in plain text editors.

* * * * *

Am I missing something when trying to use browser to open ReHIPS xml ?
No clue about wps but if you want to keep formating use Notepad++ (start as admin), it works excellent. It even has a portable version
https://notepad-plus-plus.org/download/v6.9.1.html

HJLBX

Quote from: aDVll on April 27, 2016, 09:40:20 AM
Quote from: HJLBX on April 27, 2016, 12:42:03 AM
I have been trying to open ReHIPS.xml.

I have tried opening as Admin, but ReHIPS.xml will always open as a blank page in Internet Explorer.

I have also tried as Admin using WPS xml editor - which also uses Internet Explorer - so same result.

* * * * *

I can open using WPS text editor and keep most of the xml formatting, copy & paste to notepad - so I found a workaround.

* * * * *

I don't want to open xmls as text file because it is just a jumbled mess in plain text editors.

* * * * *

Am I missing something when trying to use browser to open ReHIPS xml ?
No clue about wps but if you want to keep formating use Notepad++ (start as admin), it works excellent. It even has a portable version
https://notepad-plus-plus.org/download/v6.9.1.html

Thanks.  Notepad is useless as an editor.

aDVll

Yeah it's good for nothing. Notepad++ on the other hand is very useful for me. Keeps formatting and all.

HJLBX

This is just a preliminary observation; I have to confirm.

I tested malware by downloading a malware pack to C:\ReHIPS on 14/4/2016.

I selected the various malware icons and chose right-click "Run isolated in ReHIPS."

At least three of them were ransomware and I am unsure of the classification of the others - since it was a quick test of the Isolated Environment.

On 28/4/2016 I noticed some essentially inert folders\files had been installed to data directories (e.g. ProgramData and AppData).

For example, there was a randomly named folder in C:\ProgramData and a Hitman Pro scan detected a generic trojan.  Some other partial or empty files were also found.

* * * * *

Has anyone performed any malware testing of right-click "Run isolated in ReHIPS" ?

Could it be that right-click "Run isolated in ReHIPS" allows some very fast drops to the real user directory ?

[NOTE:  I have seen this type of behavior with other security softs.]

* * * * *

I am just looking for any infos that might help before I proceed to further malware testing.


Umbra

i guess it is time to recreate my Virtual Machine ^^

fixer

Running with right-click "Run isolated in ReHIPS" should be no different from Alert and Allow in isolated environment. And neither of them allows fast drops as process is restarted in isolated environment and is isolated from the very beginning of execution.

fixer

Quote from: HJLBX on April 27, 2016, 12:42:03 AM
I have been trying to open ReHIPS.xml.

I have tried opening as Admin, but ReHIPS.xml will always open as a blank page in Internet Explorer.

I have also tried as Admin using WPS xml editor - which also uses Internet Explorer - so same result.
I think this is because xml has several root elements and not just one as regular xmls do. I'll see what I can do.

HJLBX

I just want to confirm my understanding of ReHIPS isolated environment file access restrictions.

Most virtualization allows inter-process communications and all the programs run inside such a sandbox have full read access essentially to the entire real user file system and registry.

This is true even when running an application using Windows' very own LUA\SUA.

One of the primary advantages to using ReHIPS is that reads are re-directed and limited to ReHIPSUser. 

Even if a user selects "Copy User Data" for an isolated environment there is relatively little risk since real user data access has to be done specifically - and is not done generically across the entire file system.

In other words, SYSTEM and USER (ReHIPSUser) profiles are running simultaneously but ReHIPSUser activity is well isolated from SYSTEM.  In the case that a child program is run outside the isolated environment, it will inherit ReHIPSUser access rights and integrity level.

* * * * *

fixer - is all of this correct ?  I think my understanding is not correct.

* * * * *

Let's use a hypothetical example.

A browser is exploited.  The exploit enables fileless malware that searches the system for what softs are installed - e.g. browsers, host processes, etc.

The malware can create processes outside the isolated environment, so I am assume it is able to read the file system.

There is a fine distinction that I think I am missing.

Please point out my errors...

fixer

Lets take a look at possible cases and access rights.
Elevated admin. Maximum access rights, can read+write from everywhere across file system and registry.
Non-elevated admin=LUA. Slightly restricted read rights (some files may be SYSTEM read-only, but elevated admin can take the ownership and grant any access rights to itself and LUA can't do it, but there are few system locations like this+other users' profile folders and registry hives are also inaccessible) and restricted write rights (restricted for the same reason as reading is restricted, but there are significantly more locations, like Program Files, Windows, System32, etc and HKLM registry hive). But this user is vulnerable to LUA elevation and may become elevated admin.
Non-admin user=SUA. The same as LUA, but without elevation vulnerability for the cost of usability.
ReHIPS User. The same as SUA with further restrictions. If you take a closer look, you'll see that by default write access to most files and folders is granted to Authenticated users. And every logged-in user including LUA, SUA and ReHIPS User are Authenticated. ReHIPS turns this group in isolated programs token into deny-only. So no write access will be granted to them by that access control entry. And on top of that, several more filters are layered: network storages, removable media, CD/DVD/BD disks, unsecured filesystems (that don't support access rights like FAT). Besides SUA provides some kind of isolation to protect OS, but if you run all programs in SUA and keep all documents there, one exploited/rogue application will endanger all of them. And ReHIPS keeps different isolated environments isolated not just from OS and real user, but also from each other meaning for example browser gone haywire won't affect office documents in any way.
In other words, ReHIPS User has read access as SUA. And write access is limited to its profile folder and several folders that are explicitly allowed to write to by Windows (we're currently working on blocking write access there too).
If Copy User Data is checked, read access to the real user profile folder will be granted, it's recommended to use for compatibility purposes only during first start and then disable it.

If any isolated program is exploited, it can look for installed software as it's usually installed in Program Files and read access to it is granted. And even if you allow process creation without any isolation or allow parenting without any child inspection, every child process is subject to inheritance. In terms of security pretty much everything is inherited: token, access rights to any objects, including file system and registry, privileges, integrity level, etc. It means that any child process won't be able to escape isolation if parent process was isolated. And it's not just process creation, any action won't allow isolation escape, including task scheduling, some .NET modules registration, unusual host processes usage or some other stuff that is now popular to bypass other security software. Otherwise it's Windows vulnerability and will be patched by MS.

Umbra

#87
@fixer Nice explanation, thanks.

i made some researches but wasn't satisfied enough from the result; maybe you can answer:

Does LUA + UAC at max tweaked to ask passsword would grant the same level of protection as SUA? (i know SUA use file/registry virtualization, im not sure for LUA)

fixer

Quote from: umbrapolaris on May 03, 2016, 03:35:53 PM
Does LUA + UAC at max tweaked to ask passsword would grant the same level of protection as SUA? (i know SUA use file/registry virtualization, im not sure for LUA)
It offers the same level of usability, including virtualization (as it's actually more usability than security feature). But it won't offer the same level of security. I'll quote from here https://technet.microsoft.com/en-us/magazine/2007.09.securitywatch.aspx
QuoteWith Windows Vista, the idea is that users will run as standard user instead, and suddenly local privilege escalation issues become very interesting. Unfortunately, this is also where we run into some of the limitations of UAC. Remember, there is no effective isolation; there is no security boundary that isolates processes on the same desktop. The OS does include some protective measures to keep the obvious and unnecessary avenues of communication blocked, but it would be impossible and undesirable to block them all. Therefore, Microsoft does not consider breaches of that nonexistent security boundary to be security breaches. Mark Russinovich pointed out as much in a blog post at blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx.
Mark is totally correct. Microsoft is well aware of the fact that there is no security boundary between a low process and an elevated one on the same desktop. As there was never intended to be any isolation between processes on the same desktop, it really can't be called a security vulnerability when it is discovered that there is no isolation between processes on the same desktop. Obviously, that diminishes the value of UAC as a first-order mechanism for fighting malware, but it was not designed to be that anyway, despite what you might read in various places, including some from Microsoft.
In other words, UAC and LUA is not for security. And even if you max-out UAC, it won't be for security. Yes, they tried to block some bypassing ways, but if some other ways arise, they can freely refuse to patch it. So I wouldn't rely on UAC and LUA in terms of security.

Umbra