Bouncer (previously Tuersteher Light)

The MemProtect application is one of my main interest other than Bouncer. I have found MemProtect to be extremely powerful. It passed all of Surfright's memory simulated exploits from their test tool on my Windows 7X64 machine. MemProtect was not compatible with Eset Smart Security 9 though on my Windows 7X64 machine with it's default policy. I have not tried tweaking Mem Protect's policy file yet. I can't remember if I tried it with Eset Smart Security 8 which is what i'm currently using. The problem I ran into with Eset Smart Security 9 was if I attempting accessing Eset's setting's it would cause my computer to stop responding, and I would have to do a hard shut down. Maybe it would fix the problem if I exclude Eset's AppData, or ProgramData Folder. I can't remember what was covered by MemProtect default policy.

 

Thanks for the feedback, I forgot to reply. But it does sound interesting.

 

I have been intending on sharing some more rules for Bouncer, particularly after becoming more familiar with the parent checking feature.

Spoiler: Mozilla Firefox

Code:

[#LETHAL]
[LOGGING]
[#SHA256]
[PARENTCHECK]
[WHITELIST]
C:\Windows\Temp\???????.tmp\*.dll
C:\Users\*\AppData\Local\Temp\???????.tmp\*.dll
C:\Users\*\AppData\Local\Mozilla\updates\*
C:\Users\*\AppData\Local\Temp\MozUpdater\bgupdate\updater.exe
C:\Users\*\AppData\Local\Mozilla\updates\????????????????\updates\0\*
[BLACKLIST]
[PARENTWHITELIST]
[PARENTBLACKLIST]
[EOF]

Spoiler: Mozilla Thunderbird

Code:

[#LETHAL]
[LOGGING]
[#SHA256]
[PARENTCHECK]
[WHITELIST]
C:\Windows\Temp\???????.tmp\*.dll
C:\Users\*\AppData\Local\Temp\???????.tmp\*.dll
*\extensions\{e2fda1a4-762b-4020-b5ad-a41df1933103}\components\calbasecomps.dll
C:\Users\*\AppData\Local\Thunderbird\updates\*
C:\Users\*\AppData\Local\Temp\MozUpdater\bgupdate\updater.exe
C:\Users\*\AppData\Local\Thunderbird\updates\????????????????\updates\0\*
[BLACKLIST]
[PARENTWHITELIST]
C:\Program Files (x86)\Mozilla Thunderbird\thunderbird.exe>*\extensions\{e2fda1a4-762b-4020-b5ad-a41df1933103}\components\calbasecomps.dll
[PARENTBLACKLIST]
[EOF]

Spoiler: Google Chrome

Code:

[#LETHAL]
[LOGGING]
[#SHA256]
[PARENTCHECK]
[WHITELIST]
C:\Windows\Temp\??_?????.tmp\setup.exe
C:\Users\*\AppData\Local\Temp\??_?????.tmp\setup.exe
C:\Users\*\AppData\Local\Google\Chrome\User Data\PepperFlash\??.?.?.???\pepflashplayer.dll
[BLACKLIST]
[PARENTWHITELIST]
C:\Users\*\AppData\Local\Temp\??_?????.tmp\setup.exe>C:\Windows\*
C:\Users\*\AppData\Local\Google\Chrome\User Data\SwReporter\?.??.?\software_reporter_tool.exe>C:\Windows\*
[PARENTBLACKLIST]
[EOF]

Spoiler: Office 2010 - Click-To-Run

Code:

[#LETHAL]
[LOGGING]
[#SHA256]
[PARENTCHECK]
[WHITELIST]
Q:\140066.enu\*
C:\PROGRA~2\COMMON~1\MICROS~1\VIRTUA~1\*
[BLACKLIST]
[PARENTWHITELIST]
Q:\140066.enu\*>*
C:\PROGRA~2\COMMON~1\MICROS~1\VIRTUA~1\CVH.EXE>*
[PARENTBLACKLIST]
[EOF]

Spoiler: Process Explorer

Code:

[#LETHAL]
[LOGGING]
[#SHA256]
[PARENTCHECK]
[WHITELIST]
C:\Users\*\AppData\Local\Temp\procexp64.exe
[BLACKLIST]
[PARENTWHITELIST]
C:\Users\*\AppData\Local\Temp\procexp64.exe>*
[PARENTBLACKLIST]
[EOF]

Spoiler: Adguard For Windows

Code:

[#LETHAL]
[LOGGING]
[#SHA256]
[PARENTCHECK]
[WHITELIST]
C:\ProgramData\Adguard\Temp\*
C:\ProgramData\Package Cache\{????????-????-????-????-????????????}\setup.exe
[BLACKLIST]
[PARENTWHITELIST]
C:\ProgramData\Adguard\Temp\*>*
C:\Program Files (x86)\Adguard\AdguardSvc.exe>C:\ProgramData\Adguard\Temp\*
C:\ProgramData\Package Cache\{????????-????-????-????-????????????}\setup.exe>*
[PARENTBLACKLIST]
[EOF]

Spoiler: DISM

Code:

[#LETHAL]
[LOGGING]
[#SHA256]
[PARENTCHECK]
[WHITELIST]
C:\Users\*\AppData\Local\Temp\????????-????-????-????-????????????\*
C:\Windows\Temp\????????-????-????-????-????????????\*
C:\Windows\Temp\{????????-????-????-????-????????????}\*
[BLACKLIST]
[PARENTWHITELIST]
C:\Users\*\AppData\Local\Temp\????????-????-????-????-????????????\*>*
[PARENTBLACKLIST]
[EOF]

I am hoping to be able to edit these later, refine some rules that may need to be refined further, etc. And I would like to add more programs later, including some built-in Windows 8.x/10 functionality and more.

 

I keep getting the blocked event below in my Bouncer Log. I made an allow rule for it under [PARENTWHITELIST], but I still continue to receive the blocked event. Could some kind users check the rule I created to allow it in my policy file to make sure I don't have any spaces in the rule anywhere? The last time I had this happen Fabbian informed me I had a space in my rule. I never could find the space so I guess my eyes are not so great. My policy file can be found at the following link. https://www.dropbox.com/s/q56e3i9l9eoji0p/Bouncer.rar?dl=0

Thank you so much in Advance!

C:\Windows\System32\sppsvc.exe > C:\Users\achilles\AppData\Local\Mozilla\Firefox\Profiles\2kofkxxe.default\safebrowsing\goog-malware-shavar.sbstore > 9e49533d44787d2228de71cff6747758602025bb9780b74063251a8eb4034b86

 

@Cutting_Edgetech Your rules look fantastic. I don't actually see anything that would be conflicting here, although I find it odd that those .sbstore files are showing up in the chain of execution. However, I do have an idea. As odd as it may seem, try adding the following to your rules. Restart driver and see if it continues to show up in your logs. Particularly, I am most curious about seeing if the first whitelist rule will fix the problem more so than the parent whitelist rule.

Code:

[WHITELIST]
*\safebrowsing\goog-malware-shavar.sbstore
[PARENTWHITELIST]
C:\Windows\System32\sppsvc.exe>*\safebrowsing\goog-malware-shavar.sbstore

One correction from your config but unrelated to the problem:

Code:

[PARENTWHITELIST]
C:\Program Files (x86)\Process Explorer\procexp.exe>C:\Users\achilles\AppData\Local\Temp

Missing backslash asterisk \*
Should be:

Code:

[PARENTWHITELIST]
C:\Program Files (x86)\Process Explorer\procexp.exe>C:\Users\achilles\AppData\Local\Temp\*

 

@Cutting_Edgetech: You need to add

Code:

C:\Users\achilles\AppData\Local\Mozilla\Firefox\Profiles\2kofkxxe.default\safebrowsing\goog-malware-shavar.sbstore
C:\Users\achilles\AppData\Local\Mozilla\Firefox\Profiles\2kofkxxe.default\safebrowsing\goog-unwanted-shavar.cache

to the [WHITELIST] part. This should solve problem. In your current config you only whitelisted the parent but not the final "executable" that will be executed.

By the way: I am using Bouncer on all my machines (1x Windows 7x64, Firefox, Office, Logic Audio, Magix Video Maker, some EASports Games, 1x Windows 8.1 32-bit, Chrome, Office, 1x Windows 8.1 64-bit, Chrome). On all machines it works really decent and so far I had no issues. The driver is really stable and it looks like it works

 

Thank you guys so much!! I will make all the changes you have pointed out right now. It's always great to have knowledgeable users proofread my policy! I will let you know how that turns out.

 

Your rule above is redundant to the following rule below in green that 4shizzle recommended right? Your rule is more lenient since it will allow anything to access "malware-shavar.sbstore" right?

C:\Users\achilles\AppData\Local\Mozilla\Firefox\Profiles\2kofkxxe.default\safebrowsing\goog-malware-shavar.sbstore

[PARENTWHITELIST]

C:\Windows\System32\sppsvc.exe>* is not pointing to the full path. Can a rule like this be used? I thought you had to list the complete path to the target.

Edited 12/1 12:07 am

 

Might be worthwhile copying procexp64.exe out of temp and storing it in a system directory?

 

Have you done that? I thought the path for procexp64.exe was hardcoded in Process Explorer. Where can I change the path in Process Explorer settings?

 

You don't change any paths. Just open process explorer, leave it opened, then copy procexp64.exe from temp into the desired folder and from there on you just launch procexp64.exe from there.

 

I did not know you could do that. Just to be clear, are you saying it will run from the path I copy it to from then on, or will I have to copy it to the System Space every time I lunch Process Explorer? Thank you for your help!

 

Once copied, it will run from the new path.

 

Bingo just like FTV said, it'll run from the new location, as if you installed it there from the beginning.

 

The developer should have made it run from there all along. I have Process Explorer running from Program Files (x86). I think it should have run from System Space, or Program Files by default. Maybe we should send the developer an email explaining why it would be better for him to make it run from System Space, or Program Files by default lol Thank you for your help!

 

I actually was not having any problems running procexp64.exe from the user-space using the rules I had. I moved it to C:\Windows, and now Bouncer blocked a few actions from Process Explorer. I will have to make a couple rules to see if it fixes the problem. Well, I will do that tomorrow. It's 6:19 am in the morning here, and I have not had any sleep. I got to grab a few hours of sleep. I will visit back later today. Thanks!

 

I just realized that coping procexp64.exe to C:\Windows did not work. It still copies itself back to C:\Users\username\AppData\Local\Temp. I think we may have had a misunderstanding. I thought you was referring to the temp file (procexp64.exe) that Process Explorer spawns in the Temp Folder in AppData since that is what most of my rules are allowing in my policy. I already have Process Explorer running from Program Files (x86) Folder. I already knew I could run the app from just about anywhere since it is a portable app. It's the temp file that it spawns in the AppData folder that causes the problems if the user does not create the needed rules in Bouncer. Well, Process Explorer is working ok on my machine. I really am going to go to sleep now.

 

Yes, you are correct. My rule is redundant and would achieve the same as 4shizzle's, but mine is more lenient as you mentioned while 4shizzle's is more strict.

The beauty of the parent check feature rules is that you can fully use wildcards (* and ?) just the same as you would in the regular whitelist section. So you can use wildcards before and/or after the > symbol, so referring to either the parent process or child processes. You can go absolutely crazy with the wildcards if you want.

For example, I will show you some of the rules from my parent whitelist section:

Code:

[PARENTWHITELIST]
C:\Windows\SysWOW64\Macromed\Flash\FlashUtil*_??_?_?_???*.exe>C:\Users\*\AppData\Local\Temp\{????????-????-????-????-????????????}\fpb.tmp
C:\Users\*\AppData\Local\Google\Chrome\User Data\SwReporter\?.??.?\software_reporter_tool.exe>C:\Windows\*
C:\Program Files (x86)\Mozilla Thunderbird\thunderbird.exe>*\extensions\{e2fda1a4-762b-4020-b5ad-a41df1933103}\components\calbasecomps.dll
C:\Users\*\AppData\Local\Temp\????????-????-????-????-????????????\DismHost.exe>C:\Windows\*.dll
C:\Users\*\AppData\Local\Temp\????????-????-????-????-????????????\DismHost.exe>C:\Users\*\AppData\Local\Temp\????????-????-????-????-????????????\*.dll
C:\PROGRA~2\COMMON~1\MICROS~1\VIRTUA~1\CVH.EXE>*

 

A strange problem:

Bouncer sometimes blocks files in "C:\PROGRA~2\MICROS~1\", which refers to "C:\Program Files (x86)\Microsoft Office\". The problems are:

1. C:\Program Files (x86)\* is allowed by default. Why Bouncer still could block things in it?
   
2. Why the path "C:\PROGRA~2\MICROS~1\" has such a strange form?

To avoid such block, I have to whitelist "C:\PROGRA~?\MICROS~1\*". Allowing "C:\Program Files (x86)\Microsoft Office\*" has no help, though it refers to the same folder.

By the way, does anyone know that, why Excubits remove the purchase page from their website? I do not mean I have decided to purchase a license. I am just curious about this.

EDIT：

After looking up this on the Internet, I found that such kind of path is incurred by the limitation of the DOS system.

Yes, DOS...

In DOS, every file name can contain at most 8 digits. So, since "Program Files (x86)" contains 19 digits, it is shortened to this strange form:
"PROGRA~2"
As you can see, it contains actually 8 digits.

But...why? Why such a DOS path will appear in the log of Bouncer? Why we have to whitelist C:\PROGRA~?\MICROS~1\* when we have already whitelisted C:\Program Files (x86)\Microsoft Office\* ?

 

Some Bouncer News:

From: https://excubits.com/content/en/news.html
Upcoming priority Rules for Bouncer and some other news
2015/12/06 by Florian

This is what Microsoft itself is passing off through the kernel for several versions of it's Office suite for only certain functionalities. For whatever reason, Microsoft's programming is utilizing the old 8.3 filename/directory convention. I'm not entirely sure if it comes down to some legacy Office code that Microsoft is dragging along with each version or what. But anyway, this is just what's being passed through the kernel and not specific to Bouncer. However, it's quite possible for the Bouncer developer to make some changes so that it automatically converts full path rules into 8.3 filename paths as well. The problem with that, though, is that the use of these 8.3 filename convention is very rarely used in software programming these that it would be a waste of development time which would be better used toward other features. As a matter of fact, out of the 2 or 3 times that I have ever seen this 8.3 convention issue come up, it was only specific to certain components of Microsoft Office. I have not seen it show up elsewhere. So it's much easier at the moment to just create a rule or two for these in 8.3 convention which I believe you have already done.

 

Thank you very much for your information and your explanation of the 8.3 filename issue, @WildByDesign .

The new features are very exciting. I hope that:

1. The priority symbol "!" not only can be used in the normal whitelist, but also can be used in the parentwhitelist.

2. I hope that Pumpernickel could be integrated into Bouncer. But the function of blocking writing should be implemented independently of the current function, i.e., blocking execution. Otherwise, this new feature may not be usable. To see this, suppose that I have added a folder to the blacklist of execution. In such case, allow processes to write into that folder will not cause security issues. In fact, that folder may be a temp folder used by the browsers for storing data, so we cannot prevent processes from writing to that folder.
On the other hand, for the folders in the whitelist of execution, I hope to control the processes that can write to those folders, in case that malwares are dropped to those folders to bypass Bouncer.
To sum up, for some folders in the blacklist of execution, we will need to add them to the whitelist of writing; for some folders in the whitelist of execution, we will need to add them to the blacklist of writing. That is why I think the white/black lists of writing should be separated from the white/black list of execution.​

 

Wow, this Bouncer app really packs a punch, now with the ! rule...

I was pretty content with cruising on a primary (AppGuard, NVT-ERP, SBIE) & secondary (SRP, Secure Folders, Group Policy) combination for a while to come. Also been teasing myself to jump over to Linux for a while. I wanted to get used to not having to update signatures or repositories each and every day, along with hard-coded updates that I have no control over.

Now that the, ummm... novelty has worn off, I will have to knock back some beers to decide if I want to try out Bouncer or head over to Qubes + Whonix.

 

Florian has updated his security research blog as well with some interesting information but also includes some updated blacklist rule suggestions.

Just some bits and pieces from the blog:

From: http://bitnuts.de/
Limits of Application Whitelisting
2015/12/07 by Flo

Code:

[BLACKLIST]
*InstallUtil*
*Regsvcs*
*RegAsm*
*wusa*
?:\$Recycle*
*reg.exe
*vssadmin.exe
*aspnet_compiler.exe
*csc.exe
*jsc.exe
*vbc.exe
*ilasm.exe
*MSBuild.exe
*script.exe
*journal.exe
*msiexec.exe
*bitsadmin*
*iexpress.exe
*mshta.exe
*systemreset.exe
*bcdedit.exe
*mstsc.exe
*powershell.exe
*powershell_ise.exe
*hh.exe
*set.exe
*setx.exe
*InstallUtil.exe
*IEExec.exe
*DFsvc.exe
*dfshim.dll
*PresentationHost.exe
C:\Windows\ADFS\*
C:\Windows\Fonts\*
C:\Windows\Minidump\*
C:\Windows\Offline Web Pages\*
C:\Windows\tracing\*
C:\Windows\Tasks\*

Those blacklist rules could also be converted easily to utilize parent checking feature as well, I assume.

He is also suggesting to restrict access to the following directories:

Code:

C:\Windows\ADFS\*
C:\Windows\Fonts\*
C:\Windows\Minidump\*
C:\Windows\Offline Web Pages\*
C:\Windows\tracing\*
C:\Windows\Temp\*
C:\Windows\Tasks\*
C:\ProgramData\*

 

Thank you @WildByDesign for sharing this information.

I have a problem here: Chrome frequently requires to execute files in C:\Windows\Fonts .

I hope to whitelist it, but this is difficult before we have the new symbol "!".

In my opinion, I think adjusting the priorities of current lists might be a better design than adding a new symbol "!". Particularly, in the current version, the priority sequence is:

WHITELIST = PARENTWHITELIST < BLACKLIST = PARENTBLACKLIST

In my opinion, it might be better if the developer could change the priority sequence to:

WHITELIST < BLACKLIST < PARENTWHITELIST < PARENTBLACKLIST

With such a priority sequence, if A.exe invokes B.exe, and *\A.exe>*\B.exe is in the PARENTWHITELIST, then B.exe is allowed to run, regardless whether B.exe is in the WHITELIST or BLACKLIST. I think such an architecture at least can make it easier to allow chrome to execute the fonts files.

 

@Online_Sword

The developer earns his money primarily in the Business to Business market. My guess is that it would only confuse system admins, which would only make selling to them harder.

In general blacklist overrule whitelists, so it would be confusing to apply a set which uses different application priority. For a "priority" whitelist to be effective, it should overrule a blacklist.

There are a few system managers on this forum, so you might ask them (I am just guessing).

Regards Kees