A forum for reverse engineering, OS internals and malware analysis 

All off-topic discussion goes here.
 #31180  by Victor43
 Sun Jan 07, 2018 6:53 am
Two questions to ask. 1. Does WFP have a Registry Callback which allows all registry calls at user and kernel level to be filtered and 2. How to intercept a thread from creating a thread or process ?
 #31181  by Vrtule
 Sun Jan 07, 2018 11:56 am
Hello,
How to intercept a thread from creating a thread or process?
The PsSetCreateProcessNotifyRoutineEx should work for blocking process creation (AFAIR you get also the information about the thread creating the new process since the callback is run in its context). As far as I know there is nothing similar for blocking thread creation. However, if you need to block creation of remote threads, that usually requires obtaining a handle to the target process with write permissions (and that can be observer/blocked via ObRegisterCallbacks).

Registry operations can be monitored and filtered through CmRegisterCallback(Ex). Well, some operations are kinda undocumented, so it is not easy to filter them, howerver, such usually require administrative privileges (saving/loading/replacing/restoring registry trees).
 #31183  by Victor43
 Sun Jan 07, 2018 11:01 pm
@Vrtule thank you. Can you tell me one thing where can these special functions be placed ? Would they require to be placed inside a separate driver file just designed for the sandbox or could they be placed inside a WFP driver file (driver file designed to filter TCP traffic) ? I'm interested in sandboxing the web-browser and POP/SMTP applications.
 #31184  by Vrtule
 Mon Jan 08, 2018 12:27 pm
When I was playing with HIPS/sandboxing, I had a driver implementing the main logic and separate drivers covering individual areas (file system, registry, network, process/thread access...). These drivers were connected to the main one as plugins. The whole thing worked quite nicely. I have the source code somewhere and I will probably release it to the public in the future (well, it is quite old and I seem not to have time to continue with it).

However, AFAIK there is nothing preventing you from monitoring/filtering registry and network in one driver. Although, I expect Microsoft is probably encouraging people to write separate drivers for separate things.

So, you may try the one-driver-rules-them-all approach and it should work.
 #31185  by Victor43
 Mon Jan 08, 2018 11:36 pm
@Vrtule thank you. Since you had an opportunity to work with a sandbox can you tell me if a sandbox is done right what are the chances of exploits passing through the sandbox and able to make unauthorized changes to the system ? Second question what do you know of cloud based sandboxing ?
 #31186  by Vrtule
 Tue Jan 09, 2018 12:00 pm
Second question what do you know of cloud based sandboxing ?
Nothing actually.
Since you had an opportunity to work with a sandbox can you tell me if a sandbox is done right what are the chances of exploits passing through the sandbox and able to make unauthorized changes to the system?
You should really know the interfaces you are using. Although they might look really nicely in the documentation but they implementation might have certain drawbacks. For example, on Windows 7 and older, when filtering certain types of registry operations (e.g. registry value deletion), some data are not copied to kernel buffers by the operating system (e.g. the value name), so the sandoxed application can change tem at any time and there is a high chanse of a TOCTOU vulnerability.

The best way (on my opinion) is to run the sandoxed application with least privileges possible (zero integrity level, under a heavily constrained job object etc.) and hook its userland libraries. Your hooks will communicate with the sandbox which decides what actions can or cannot be permitted. The point is that if the application bypasses your hooks (e.g. by invoking system calls directly) it cannot do much harm.

I think that the kernel registry callbacks are useful when you need to protect several registry keys/values (or areas), or to restrict the sandoxed application from previous paragraph from its privileges even more. But using them as the main way of implementing the sandbox is not a good idea.
 #31189  by Victor43
 Wed Jan 10, 2018 11:54 pm
You should really know the interfaces you are using. Although they might look really nicely in the documentation but they implementation might have certain drawbacks. For example, on Windows 7 and older, when filtering certain types of registry operations (e.g. registry value deletion), some data are not copied to kernel buffers by the operating system (e.g. the value name), so the sandoxed application can change tem at any time and there is a high chanse of a TOCTOU vulnerability.

The best way (on my opinion) is to run the sandoxed application with least privileges possible (zero integrity level, under a heavily constrained job object etc.) and hook its userland libraries. Your hooks will communicate with the sandbox which decides what actions can or cannot be permitted. The point is that if the application bypasses your hooks (e.g. by invoking system calls directly) it cannot do much harm.

I think that the kernel registry callbacks are useful when you need to protect several registry keys/values (or areas), or to restrict the sandoxed application from previous paragraph from its privileges even more. But using them as the main way of implementing the sandbox is not a good idea.
I think I understand what you're saying overall but can you elaborate a little on what you mean "interfaces" ? Also you mentioned hooking userland libraries how can this be done best ? More importantly if the application by-passes the hooks as you mentioned by calling the system functions directly then what is the point of implementing userland hooks ? With respect to adding a registry callback I'm mostly interested in preventing any changes to the registry so only write capabilities however file operations, blocking process creation along with write protecting registry changes altogether shall be used to devise least privileges. Not sure what you meant by "under a heavily constrained job object" ? Could you elaborate a little here.

Thanks again
 #31190  by Vrtule
 Fri Jan 12, 2018 3:36 pm
can you elaborate a little on what you mean "interfaces"
In this context, interface is a set of APIs used for certain purpose (e.g. filtering registry calls).
Also you mentioned hooking userland libraries how can this be done best ?
Well, probably inline hooks will do.
More importantly if the application by-passes the hooks as you mentioned by calling the system functions directly then what is the point of implementing userland hooks ?
The key point here is that the sandboxed application itself has as less privileges as possible when talking about the Windows security model. However, there may be "permissions", you wish to grant the application, that cannot be easily expressed by the terms of the security model. As an examle, let's say you need to grant the sandboxed application access only to a file A (and just image you cannot do that via the standard security means, such as ACLs). From the security model viewpoint, the application does not have access to A, however, your userland hooks may be used to communicate with your more privileged application that can then access A on behalf of the sandboxed one.

So, the userland hooks are used to grant the sandboxed application some extra permissions, not to restrict it. The assumption is that a nice application will not bypass the hooks, so it will get permissions it needs. However, the malicious application that bypasses the hooks gets nothing, since the sandbox restricts it by the security model (low integrity level, restricting SIDs in the access token etc.).
heavily constrained job object
Job objects allow you to place some retrictions on applications run under them. At the time I was researching them, the most interesting was the GUI restriction – e.g. preventing the sandobxed application from sending Windows messages outside the job object. With new versions of Windows, the possible set of restrictions grew quite a bit. I just wanted to point you to job objects as an interesting contept for implementing a sandbox.
 #31221  by Victor43
 Thu Jan 25, 2018 5:34 am
I have another question about Sandbox design. Other than the avenues of interception of untrusted code what else is there involved in the overall design of a sandbox ?