Bouncer (previously Tuersteher Light)

I believe it makes more sense to make the HMPA test tool a protected process. HMPA test tool in this case would represent your web browser, Flash Player, PDF Reader, etc.. Imagine an exploit has executed in one of these web applications, MemProtect would then stop the exploit from injecting into other processes. The only difference is that HMPA Test tool is representing your vulnerable web applications.

Did Florian already release a beta build of MemProtect that only protects the processes the user defines in their policy? I thought MemProtect still covers all processes.

 

Yes I agree, but "stop the exploit from injecting into other processes" is something else than "stop the execution of the payload" which in this case is calc.exe, so in other words, it's still not clear to be how MemProtect exactly works.

 

It works in this case by preventing an exploited process from injecting into any other processes. The exploit is confined to the process it has exploited. I tried to find more info on the new memory protection mechanisms used by Windows 10 that Windows_Security listed, but I did not find what he was talking about. Maybe he could provide me with a link if he has time. I read about some new memory protection Windows 10 uses, but i'm not sure it was what Windows_Security was explaining. I was reading about it somewhere on this page. Sorry, don't remember exactly where on the page, it's been a week ago. https://technet.microsoft.com/en-us/library/mt601297(v=vs.85).aspx

 

Yes but like I said, blocking the execution of a child process that is spawned by the attacked process, is not the same as blocking code injection into another process. Normally if the browser gets exploited it will download and execute malware that runs as child process. This malware will then try to inject code into system processes, or into the browser. This is what MemProtect should stop.

But of course, you don't want malware to run at all, because you want to block the attack in an earlier fase. Here is where Bouncer and other AE tools comes into play, they will simply block execution of malware. But apparently MemProtect can also block process execution, but when I ask for info, Windows_Security and 4Shizzle keep mentioning the "protected process" feature, which has absolutely nothing to do with blocking process execution.

 

I don't really get your argument with my statement. You basically just restated what I said. I will try to be more specific. Blocking the executions of child process, and blocking injection into a process already running is not necessarily the same. The child process would be a binary payload downloaded through the exploited process, or through another process that was injected into. The exploit may inject into another process already running in order to gain access to a System resource needed to manipulate the System in order to download the payload using a different process, or to become persistent. If you have processes A-E running and A is exploited it may inject into process E, and use that process to download the binary payload. It's not always the first exploited process that attempts to execute the child process. It's easy to stop this by not allowing vulnerable applications to read/write to the memory of other applications.

Edited 4/11 @ 1:18

 

There is no argument, I'm just trying to explain that the easiest way to block the exploits, is to block malware from executing. I don't believe that MemProtect is meant for that, you need tools like Bouncer and other AE for that. MemProtect is meant to protect the system in case AE or AV has failed, it will then try to block memory modification of certain processes. So in other words, I doubt that the HMPA Exploit Test Tool is a good way to test MemProtect's capabilities, since it simulates process execution (after memory corruption), not code injection.

 

And now MemProtect comes into play. The (exploited) browser can download but it can't execute malware (even if the exploited browser has SYSTEM-Rights).
MemProtect is preventing the execution, too!

Yes, MemProtect is not meant for that. Other programs are needed.
But if the Browser is protected with MemProtect it is definitely blocking the execution of child-processes.

BUT...

It all depends, how MemProtect is configured.
Example:
C:\Program Files\Mozilla Firefox\*>C:\Program Files\Mozilla Firefox\*
It means, all executables in the Firefox-directory can execute (and injecting to) other files in the Firefox-directory.
a) If Firefox downloads "malware.exe" to the user-directory and executes it = Blocked.
b) If Firefox downloads "malware.exe" to the Firefox-Directory and executes it = NOT blocked (but only if it has enough rights to write malware.exe to this directory)
An AE should have blocked both, right?
But the hole in (b) can be filled with Pumpernickel, where the write-access from Firefox can be restricted to specific directories (=files can't be written to the firefox-directory)

C:\Program Files\Mozilla Firefox\firefox.exe>C:\Program Files\Mozilla Firefox\firefox.exe
It means, firefox.exe can only execute (and inject to) firefox.exe.
a) If Firefox downloads "malware.exe" to the user-directory and executes it = Blocked.
b) If Firefox downloads "malware.exe" to the Firefox-Directory and executes it = Blocked (even if it has enough roughts to write malware.exe)
Now both are blocked.

Sure, an AE should have blocked all these files.
But, if Firefox wants to read (or write to) the memory of other processes, an AE can't prevent that.
MemProtect can do this.

 

Yes you already mentioned this, but you wasn't too sure the last time, so I was hoping for someone else to confirm. But I have to say that after reading your post, you seem to be 100% sure that MemProtect is indeed able to not only block code injection (memory modification), but also process execution. So then it makes sense that it will pass the Exploit Test Tool, mystery solved. So this means that this feature overlaps with Bouncer, but I assume this isn't a problem?

 

You just have to make sure, that if there is a rule for Bouncer to allow Firefox to execute Flash in the Windows-directory -- the rule has to be done for MemProtect too.
If not, Bouncer allows it but MemProtect blocks it. Result = Flash is blocked.
Edit: Only if Bouncer is configured to block all childprocesses from Firefox [PARENTBLACKLIST] and MemProtect is configured this way, too.
=> Bouncer: The user adds a rule to let Firefox execute Flash
=> MemProtect: Now the user has to do this for MemProtect too.

 

Florian has just compiled an internal build with the [DEFAULTALLOW] option. Myself and possibly a few others have got to test this for a few days. At the moment it is not digitally signed. As long as initial tests go well, it will be digitally signed and released on Beta Camp page likely on the coming weekend, dependent on Florian's free time and how well the testing goes. I've got my copy but I wont have a chance to test this until late this afternoon, but I will provide some feedback later tonight on how well it goes.

 

Then *>* can be removed from the whitelist if [DEFAULTALLOW] is set.
Oh, the file MemProtect.ini is 2000bytes big if the option is added to the MemProtect.ini. That's very close to the limit

 

@mood and @WildByDesign

I sincerely had hope that the default allow did not needed any ini/config setting. The idea behind asking for a default allow, was to prevent dead locks due to user errors. Having to add the command line [DEFAULT ALLOW] is nearly the same as "*>*", so the potential point of catastrophic user failure still exists.

Regards Kees

 

Yes, it's "the same as before".
First i thought, it's gonna be a new version where the "auto-allow"-mode is a default -- without an option in the MemProtect.ini.
I mean: No rules in the whitelist + blacklist = nothing is blocked (because of auto-allow mode)
...and if the user wants a deny-mode, he can put *>* in the blacklist and configure his programs/directories accordingly.

 

From what I can tell so far in my early testing, the [DEFAULTALLOW] option is done as a switch, very much like the other drivers. So you can use [#DEFAULTALLOW] to retain the typical default deny and that could potentially be the default option. So with this, we will actually be able to choose between default deny and default allow, depending on user preference. So we've got the best of both worlds here. I agree that the config file size restriction of 2KB should be loosened a bit more, for sure. I've got preliminary builds of upcoming Bouncer (with Install Mode) and MemProtect (with Default Allow switch) now to start testing tonight and over the next few days. I'm going to test these as thoroughly as I can. If all goes well, Florian will likely release both of these builds to the Beta Camp page this weekend. Drivers are digitally signed as well.

 

I've decided that I would like (or in reality "need") some assistance from any of you with regard to MemProtect configuration. First, I just wanted to mention that the drivers and builds for memprotect_beta.exe (with Default Allow switch) and bouncer_beta.exe (with Install Mode) are compiled, digitally signed, and essentially ready to be put up on the Beta Camp page likely this weekend. I have been running and testing both drivers/builds for a little over 24 hours now and these builds have been rock solid, efficient, and stable. So as long as there is nothing major to prevent these from releasing to Beta Camp shortly, then these will be available to everyone to test hopefully within days.

However, the only area that I am stuck on with my testing is the new [DEFAULTALLOW] switch and configuration. I personally find it a bit more difficult to create rules for default allow. In this case, everything is allowed except for what we would specify within the blacklist section, I assume. So any process and/or directory that we specify within the blacklist would essentially become sandboxed dependent upon our configuration, of course. With the previous default deny, I would always utilize the detailed logging to my advantage for creating rules. But I am really uncertain with regard to default allow rules. Whoever is able to help with some example rules to test with MemProtect default allow configuration, I Thank You and appreciate your time and assistance greatly.

EDIT: OK, so at the moment I have the following default allow config for MemProtect:

Spoiler: MemProtect.ini Default Allow Testing

Code:

[#LETHAL]
[LOGGING]
[DEFAULTALLOW]
[WHITELIST]
!C:\Windows\*>*
!?:\Program Files\*>*
!C:\Program Files (x86)\*>*
!C:\ProgramData\Adguard\Temp\?.?.???.???*\setup-?.?.???.???*.exe>*
!C:\ProgramData\Package Cache\{????????-????-????-????-????????????}\setup.exe>C:\ProgramData\Package Cache\{????????-????-????-????-????????????}\setup.exe
!C:\ProgramData\Package Cache\{????????-????-????-????-????????????}\setup.exe>C:\ProgramData\Adguard\Temp\?.?.???.???*\setup-?.?.???.???*.exe
!*\cache-exiftool-?*.??\*>C:\Windows\SysWOW64\cmd.exe
!D:\Tools\*>*
!*procexp64.exe>C:\Windows\*
!*procexp64.exe>?:\Program Files*
!*procexp64.exe>*procexp64.exe
!*ProcessHacker.exe>C:\Windows\*
!*ProcessHacker.exe>?:\Program Files*
!*ProcessHacker.exe>*ProcessHacker.exe
[BLACKLIST]
*>*
[EOF]

So that is my starting point for my own default allow testing. The reason for the *>* in the blacklist was because I wanted to be able to trigger some logging to get an idea of what activity may need blocking. And the ! priority rules for some of my previous rules that I wanted to still use to override the blacklist *>* rule. From here, I would need to be specific in the blacklist rules (and potentially ! priority rule some of the key blacklist rules) as to which processes cannot access the memory of other specific processes or locations. But this is where I am stuck at the moment. But I figured I would share where I am at and see if I can reach out to some of your for help.

 

@WildByDesign

Have a look at post #981, this is how it would work the example Chrome is completely isolated (both ways)

Code:

[LETHAL]
[DEFAULTALLOW]
[#LOGGING]
[WHITELIST]
!C:\Windows\explorer.exe>*chrome.exe
!C:\Windows\System32\audiodg.exe>*chrome.exe
!C:\Windows\System32\csrss.exe>*chrome.exe
!C:\Windows\System32\lsass.exe>*chrome.exe
!C:\Windows\System32\svchost.exe>*chrome.exe
!C:\Program Files\Security\ProcessExplorer\procexp.exe>*chrome.exe
!C:\Program Files\Google\Chrome\Application\chrome.exe>*chrome.exe
!C:\Program Files\Google\Chrome\Application\chrome.exe>C:\Windows\splwow64.exe
[BLACKLIST]
*chrome.exe>*
*>*chrome.exe
[EOF]

Now run an experimental isolation for Word (or any other program), just use logging and run it for a day, extend it to all office aps

Code:

[#LETHAL]
[DEFAULTALLOW]
[LOGGING]
[WHITELIST]
!C:\Windows\explorer.exe>*winword.exe
!C:\Program Files\*.exe>C:\Windows\splwow64.exe
[BLACKLIST]
*winword.exe>*
*>*winword.exe
[EOF]

You could tidy up the priority rules by using
!C:\Program Files\Office\*

Regards Kees

 

Only after you blacklist something, you need allow rules. The Allow-Mode should be much easier to handle.
I don't have this build, but i'm looking forward to use it.

 

@Windows_Security Thank you for your time, Kees. I always appreciate and respect your opinions and the knowledge that you are always happy to share with others. I will try these various rules right away and put them to the test over the course of the next 6-8 hours and will report my findings here later and also to Florian tonight as well. Hopefully this will give the go ahead to release to Beta Camp on Saturday or Sunday. The binaries are already compiled and signed. It's just a matter of any last minute showstoppers right now.

@mood Thank you. You've always shared a deep knowledge of the inner workings of these various Excubits drivers and I am very thankful for that. I'm hoping that you and others will be able to get their hands on these updated Bouncer and MemProtect builds this weekend as long as there is no significant issues.

 

New drivers in beta camp as @WildByDesign informed us https://excubits.com/content/en/news.html

My MemProtect rules
1. Mitigate impact of Office being exploited (contain Office apps C:\Program Files\Office\*>*), so only protect the system against Office. Office TrustCenter has also options to harden and secure Office. So one way protection will do.

2. Isolate chrome both ways, so chrome can't touch other processes and other processes can't change Chrome. (*>*chrome.exe and *chrome.exe>*) This is nice when you use Chrome for online banking/shopping.

Code:

[LETHAL]
[LOGGING]
[DEFAULTALLOW]
[WHITELIST]
!C:\Program Files\Office\*>C:\Program Files\Office\*
!C:\Program Files\Office\*>C:\Windows\splwow64.exe

!C:\Windows\explorer.exe>*chrome.exe
!C:\Windows\System32\audiodg.exe>*chrome.exe
!C:\Windows\System32\csrss.exe>*chrome.exe
!C:\Windows\System32\lsass.exe>*chrome.exe
!C:\Windows\System32\svchost.exe>*chrome.exe

!C:\Program Files\Security\*>*chrome.exe

!*chrome.exe>*chrome.exe
!*chrome.exe>*software_reporter_tool.exe
!C:\Program Files\Google\Chrome\Application\chrome.exe>C:\Windows\splwow64.exe
!C:\Program Files\Google\Chrome\Application\chrome.exe>C:\Program Files\Google\Update\GoogleUpdate.exe

[BLACKLIST]
C:\Program Files\Office\*>*

*>chrome.exe
*chrome.exe>*
*software_reporter_tool.exe>*
[EOF]

splwow64 is needed to print from Chrome and Office. It is used by all programs printing something and runs as Medium IL so it is a potential process to be attacked by malware, Because it is owned by Trusted Installer, it can'not be used to survive reboot (hence not protected).

I have all my security software in C:\Program Files\Security\etc. So change security to the install directories of your security software. It is a good idea to allow security software since it might inject a DLL to monitor behaviour

I also contain software_reporter_tool.exe (blacklist *software_reporter_tool.exe>*) since it is a new tool intended to combat malicious redirection Malware in Chrome you want to Chrome to run it.

Google update is allowed to be started by Chrome, because GoogleUpdate.exe runs as high, I have not contained or protected it.

 

@Windows_Security Thanks for the heads up, Kees.

As Kees mentioned, there are new Beta Camp builds for MemProtect (with Default Allow option) and also Bouncer (with Install Mode). I've checked the binaries over and they are the same as I have been testing which are digitally signed April 12, 2016.

If anyone is looking for the English version of Bouncer, download tuersteher_beta.exe and either run the self-extracting executable or use 7-Zip to extract. There is a sub directory called bouncer_beta which contains the English version of the driver. In the Bouncer.ini config file, you can safely add (to the very top) [#INSTALLMODE] which is Install Mode disabled. If you want to install some Windows Update or install programs, remove the # to enable Install Mode. Florian is working on a new tray app that includes the ability to enable/disable Install Mode.

Sometime in the future, Pumpernickel may just have what some users have been asking for. The ability to set rules to block read access to files and/or directories and to essentially hide files and folders.

 

@Windows_Security I've just had a chance now to review and test your MemProtect Default Allow config that you posted today in post #1172 and it works great. Tidy, short, sweet and to the point. Very nice config to protect Chrome and Office programs.

I am personally not a Firefox user. But since Firefox does not have a fully developed sandbox yet, I think that Firefox users could benefit greatly from MemProtect, provided that they have a solid configuration to start with. Kees, do you know if Firefox would follow a similar configuration with MemProtect, such as needing access to those same system processes from your config? I would like to try to figure out and test something that can be shared with Firefox users as well to help fortify Firefox. I will try some Firefox testing later today and see how it goes and, if I get any good results, I will share here later as well.

 

@WildByDesign No, sorry I would simply use logging to determine what to allow, ask some Firefox users about most obvious use cases, e.g.
- install/update firefox
- add/update/remove extensions/skins (also think about the extension data e.g. the blocklists of uBlockOrigin)
- add/delete bookmarks

?

 

I see with MZWriteScanner that Chrome downloads this tool:
2016/04/14_15:51 > W:C:\Users\<...>\AppData\Local\Google\Chrome\Application\chrome.exe > C:\Users\<...>\AppData\Local\Temp\3624_19010\software_reporter_tool.exe
But i I have set the directory "SwReporter" (where the Tool should be copied to) to Read/Execute. So Chrome can't copy and execute it.

In a few weeks/months? Is there an ETA?
With the possibility to hide folders, vulnerable apps can be more restricted.

 

I am not a Firefox user, but I've decided to put together a MemProtect Default Allow example to sandbox Firefox since it lacks a fully developed sandbox at the moment. This is just a preliminary example for Firefox general usage. It does not contain rules yet for Firefox updates, whether automatic or manual updates. I'll have to wait until next Firefox update and utilize MemProtect's logging to acquire what I need to write those update rules. This is assuming a 64-bit Windows system.

Code:

[LETHAL]
[LOGGING]
[DEFAULTALLOW]
[WHITELIST]
!*\Mozilla Firefox\*>*\Mozilla Firefox\*
!C:\Windows\System32\csrss.exe>*firefox.exe
!C:\Windows\System32\lsass.exe>*firefox.exe
!C:\Windows\System32\svchost.exe>*firefox.exe
!C:\Windows\System32\sihost.exe>*firefox.exe
!C:\Windows\System32\audiodg.exe>*firefox.exe
!C:\Windows\System32\spoolsv.exe>*firefox.exe
!*firefox.exe>C:\Windows\splwow64.exe
!C:\Windows\splwow64.exe>*firefox.exe
!*firefox.exe>C:\Windows\SysWOW64\Macromed\Flash\FlashPlayerPlugin_??_?_?_???.exe
!C:\Windows\explorer.exe>*firefox.exe
#!*firefox.exe>C:\Windows\explorer.exe
!C:\Program Files (x86)\Adguard\AdguardSvc.exe>*firefox.exe
!C:\Windows\Temp\DPTF\esif_assist_64.exe>*firefox.exe
[BLACKLIST]
*firefox.exe>*
*>*firefox.exe
[EOF]

This is similar to Kees' rules for protecting Chrome and Office with MemProtect Default Allow from post # 1172 (https://www.wilderssecurity.com/thre...-tuersteher-light.359127/page-47#post-2581606).

For printing from Firefox, the rules for spoolsv.exe and splwow64.exe are required. For audio, the rule for audiodg.exe is required.

The rule for "\DPTF\esif_assist_64.exe" is just for some Intel driver on my system, so most users will not need these. Same goes for the rule for AdguardSvc.exe, only Adguard users would need that.

The rule that contains FlashPlayerPlugin_??_?_?_.exe is only utilized when the user clears the history, cache, etc. and has the option checked to delete plugin data as well. If you don't use Flash with Firefox, then this rule likely is not needed.

Regarding Explorer. The rule for "!C:\Windows\explorer.exe>*firefox.exe" is needed because most likely Firefox would crash otherwise. However, you will notice that I have commented out the line for Firefox accessing Explorer "#!*firefox.exe>C:\Windows\explorer.exe". This is something that shows up in the logs, but I've realized that blocking that from occurring does not seem to cause any problems. I think that allowing Firefox to access/modify Explorer process could be dangerous potentially. Anyway, I will update this Firefox config as I figure it out and test some more, particularly Firefox updates.

 

With AppGuard I have also witnessed Firefox trying to write to the memory of explorer.exe.