Bouncer (previously Tuersteher Light)

New stable builds of Bouncer, both Demo and Paid, will be released shortly (likely within 1-2 days). Florian is going to remove Bouncer from Beta Camp page to avoid any confusion since it has reached a solid level of stability. I'll let you guys/gals know once Florian has uploaded the updated builds to his server.

I haven't had a chance yet to talk too much with Florian about any changes with regard to licencing but I have asked Florian to provide me with some more details, particularly regarding "early adopters" here at Wilder's who have purchased licences already prior to any changes. I will update here as soon as I find out more.

 

Thanks for the update! Bouncer just keeps getting better. That being said, I honestly don't know whether i'm using the latest beta, or latest stable build right now. There needs to be an about section on the Bouncer tray tool to show the user what build they have installed. I have the option for Install Mode in the Bouncer Tray Tool. Is that the latest beta? Being a paid user I asked Florian for a beta version without the .ini data limit, and I think this is the beta build he send me. Is the beta currently the only one to offer install mode?

 

I tried using Bouncer with UAC (Max Settings), and UAC silently blocks writing to/editing the Bouncer .ini file. I'm editing the Bouncer .ini file with notepad, and when I try to save the changes Windows says "access denied". I'm logged in as Admin. I don't receive any prompt from UAC so I don't have any option to allow editing of Bouncer.ini. I have seen this behavior with UAC silently blocking many things in the past so that is why I have rarely used UAC. Shouldn't UAC always prompt the user before blocking something? Is there something I can do in order to use Bouncer with UAC?

Edited 5/24 @ 8:27

 

I don't use Bouncer, but from my experiences with INI files... they don't trigger an UAC response. Some "might", but so far, 3rd party INI files have not. If you edit Sandboxie.ini directly by double-clicking on it, UAC doesn't pop up, even though it is in Windows directory. The same applies for SoftwarePolicy.ini, which sits in a subdirectory of Windows. However, if you go through their respective programs, UAC pops up.

So far, the only workaround I have come up with (or even tried) is running an elevated Notepad and opening up the ini file, modifying and then saving.

Assumptions:
1) Bouncer.ini is located in either Windows, Program Files, or Program Files x86
2) If you use AppGuard, you have made necessary adjustments to allow Notepad to save

Anyone else, please correct me if I am off base...

 

No, you seem to understand the problem well. I will try running notepad elevated next time to see if it will allow me to edit the Bouncer.ini file. It is in the Window directory. It seems Microsoft has some work to do on UAC, it seems flawed when it comes to usability. Thank you for your suggestion!

 

I took the easy way out with elevated Notepad and made a link on Desktop, set it to Run as Admin... then dragged it onto Quick Launch bar... comes in handy!

 

notepad has to be elevated to edit the .ini-file, that's normal.

If you want to edit the sandboxie.ini from within Sandboxie:
Sandboxie Control - Configure - Edit Configuration = it simply calls an elevated notepad.exe and then you see an UAC-prompt.
But in general you have to elevate notepad "yourself", if you want to edit files in the Windows-Directory.

 

Florian has compiled and signed the latest stable Bouncer binaries last night. As well, the Bouncer installer is signed with both SHA-1/SHA256 to follow recent Windows requirements. He is hoping to upload the installers today (both demo and paid). This release will include the latest goods, including Install Mode as well as the entirely new BouncerTray app.

Yes, at least until the newest stable release comes out later today, that Install Mode feature was only available in the latest Beta Camp release. It is possible that Florian compiled a build just for you that may be equivalent to the upcoming stable release. But otherwise, as far as public availability at that time within the last few days, Install Mode was only available in the beta release.

Yes, in theory, whenever the user is requesting something that requires elevated privileges, UAC should prompt the user unless someone has modified UAC settings, though I don't intend to suggest that in your case. In general, if a user needs to modify a file within a protected area such as C:\Windows, it would require elevation. For example, if you wanted to manually edit with Notepad or Notepad++, you would need to right-click on the shortcut for those programs and choose Run as Administrator.

I just wanted to confirm a few things though. You mentioned that the build that you are using includes Install Mode. Does the build that Florian gave you also include the latest BouncerTray app? That should be easy to determine because the new BouncerTray app includes sub-menus for Bouncer and Install Mode. See the following post, click on Spoiler to see screenshots of latest tray menu: https://www.wilderssecurity.com/thre...-tuersteher-light.359127/page-48#post-2583211

Let's assume that you have the latest BouncerTray app. The way that Florian has designed it is if you click on "Open Config File" it should have a UAC elevation request first and then open Notepad with the config file as Admin to make the process easier. If you have a moment, can you confirm if you have this latest version of BouncerTray?

 

Good news for Bouncer early adopters:

Florian just told me that everyone who bought a Bouncer licence before 24.05.2016 will get liftetime updates! As WildByDesign already said, the next stable release should be available very soon (maybe today).

 

I've got some confirmation back from Florian with regard to lifetime licence purchases. Florian and his small team are going to honour lifetime licences purchased prior to 24.05.2016 (May 24th, 2016). A number of users here were early adopters to Bouncer and wanted to help support Florian's development because we believed in what he was trying to achieve. So for those of us who have purchased lifetime licences prior to 24.05.2016, they are going to honour those early adopters with a lifetime of unlimited use and any future updates/features specifically for Bouncer.

So my understanding is that Bouncer purchases after 24.05.2016 and going forward, those users are entitled to lifetime/unlimited use of Bouncer as well, but that there will be some sort of yearly fee if/when those users need any of the new features that will be added to Bouncer. I mentioned to Florian how I have quite often purchased software over the years from Stardock (desktop customization software) and that from major version to major version, they would offer their a nice discount. Anyway, more to elaborate on this later but I've got to go at the moment.

 

Official Launch: New version of Bouncer
2016/05/24 by F. Rienhardt
Link: https://excubits.com/content/en/news.html

Demo version: https://excubits.com/content/files/bouncer_demo.exe

Full version, for those who have previously purchased, is available at the unique URL's that each user had generated after purchase. There's generally a unique URL and also a unique password to initiate the download.

Both versions are digitally signed May 24th, 2016 with SHA1 and SHA256 signatures.

As always, ensure that you keep a backup copy (or copies) of your bouncer.ini config files.

 

thank you very much for info and updates

 

I forgot to mention that Florian has also updated the user manual recently with details on priority rules, command line scanning and more. I think that he's done a good job with documentation lately which is great.

Link: https://excubits.com/content/files/bouncer_manual.pdf

I agree 100%. I believe that Florian realizes and appreciates the fact that many users from Wilders have helped a lot with feedback and suggestions to help shape the future of Bouncer.

You're welcome, my pleasure.

 

Yes, I have the same BouncerTray App as shown in the spoiler image. Thank you!

I have run into another problem i'm investigating at the moment. I have not really been able to do much with Bouncer until now since I never had the paid version before so I was not able to try much with it, or do much testing. I'm seeing either a bug, or a usability problem in the Parent Check functionality, i'm not seeing what I think should be expected behavior. I decided to not allow web browsers, pdf readers, flash, office applications, compression software (WinRAR) to spawn any .exe, or .tmp files except for the .exe processes that are required for the applications to function properly; I used priority rules for that. I did some testing, and all the applications I added to the PARENTBLACKLIST are still able to spawn any .exe child process in the Program Files Directory, but I don't know about the .tmp yet. If this is because of the PARENTWHITELIST policy listed below then I think we have a big usability problem, and if it's not then maybe I found a bug. I thought that if you added an application to the PARENTBLACKLIST then it ignored if they were located in a directory that was part of the PARENTWHTELIST. If that's not the case then I think that should be expected behavior, or the PARENTCHECK feature will not be very practical, or effective. If it only cover processes spawned in the the user-space then that would make no sense because all processes should already be blocked in the User-Space if they are not on the WHITELIST. I'm going to keep doing more testing, and see if I continue to see the same behavior.

[PARENTWHITELIST]
C:\Program Files (x86)\*>*
C:\Program Files\*>*

 

@Cutting_Edgetech could you provide us your [PARENTBLACKLIST] rules? Thanks.

I am using the official (brand new) version of Tuersteher (I think Bouncer should be same). It works great for Chrome. I only allow Chrome to run needed dlls and processes by Chrome. I did another test after reading your post with dedicated software and it also work like I expected. Maybe there is just a tiny typo or something in your [PARENTBLACKLIST] that causes the issue.

 

Does anyone know of a portable application that creates a child process in it's folder without just launching another executable that is already in the folder. Basically, I need an application like Process Explorer except it creates the child process in it's own folder instead of in the AppData Folder. I need this for testing Bouncer PARENTCHECK feature. I have plenty of applications that spawn child processes, but the Apps I have are spawning executables that are already located in the portable app folder.

 

Bouncer cannot avoid that an application creates a file in its folder. You can only block that a process is launched (created), not written to disk. I do not understand what you want to achieve.

It is very simple: Specify in [PARENTWHITELIST] first (left from >) the parent allowd to run child (right from >). Example:

[PARENTWHITELIST]
C:\Program Files\*>C:\Windows\*
C:\Program Files\*>C:\Program Files\*
[PARENTBLACKLIST]
*chrome.exe>C:\Windows\*cmd.exe
*chrome.exe>C:\Windows\*notepad.exe

So chrome is not able to run cmd.exe or notepad.exe. It is just example, you can do more.

 

I've been trouble shooting this problem with Florian, and Florian had a typo in the example rule he gave me a few weeks ago so initially my policy contained the same typo as his. I changed that yesterday after pointing out to Florian that the rule did not look right to me, and it was not working. I changed the rules exactly how he said they should be, and they still are not working. He informed me that the following 4 rules should work to deny any .exe from being spawn: *firefox*>*exe, *firefox*>*.exe, *firefox.exe*>*exe, *firefox.exe*>*.exe He informed me you did not have to put a dot before the extension like .exe, and .tmp. That did not make any sense to me, but I did not write the driver either. I wrote them the way that made the most sense to me as you can see below. Below is part of my PARENTBLACKLIST. Do you see any errors? I tried writing them all the ways listed above.

Code:

[PARENTBLACKLIST]
*firefox.exe*>*.exe
*firefox.exe*>*.tmp
*firefox.exe*>*.bat
*plugin-container.exe*>*.exe
*plugin-container.exe*>*.tmp
*notepad.exe*>*.exe
*notepad.exe*>*.tmp
*wordpad.exe*>*.exe
*wordpad.exe*>*.tmp
*FlashPlayerApp.exe*>*exe
*FlashPlayerApp.exe*>*.tmp
*FlashPlayerPlugin.exe*>*.exe
*FlashPlayerPlugin.exe*>*.tmp
*FlashUtil32_??_?_?_???_Plugin.exe*>*.exe
*FlashUtil32_??_?_?_???_Plugin.exe*>*.tmp
*FlashUtil64_??_?_?_???_Plugin.exe*>*.exe
*FlashUtil64_??_?_?_???_Plugin.exe*>*.tmp
*FlashPlayerInstaller.exe*>*.exe
*FlashPlayerInstaller.exe*>*.tmp
*FlashPlayerUpdateService.exe*>*.exe
*FlashPlayerUpdateService.exe*>*.tmp
*PDFXCview.exe*>*.exe
*PDFXCview.exe*>*.tmp
*mpc-hc64.exe*>*.exe
*mpc-hc64.exe*>*.tmp
*vlc.exe*>*.exe
*vlc.exe*>*.tmp
*WinRAR.exe*>*exe
*WinRAR.exe*>*.tmp
*Rar.exe*>*.exe
*Rar.exe*>*.tmp
*Ace32Loader.exe*>*.exe
*Ace32Loader.exe*>*.tmp
*.jpg*>*.exe
*.jpg*>*.tmp
*.png*>*.exe
*.png*>*.tmp
*.gif*>*.exe
*.gif*>*.tmp
*.bmp*>*.exe
*.bmp*>*.tmp
*.dib*>*.exe
*.dib*>*.exe
*.dib*>*.tmp

 

The rules look fine so far. What is not working exactly. What do you expect to be blocked? For example how do you test that for the rule

*notepad.exe*>*.exe

that notepad.exe is (not) executing a executable. What exploit tool do you use that forcing notepad to load executable. To check and confirm what you are saying we need more information. Saying it do not work is not enough. Need more info on what you are trying to force load (start) of executable from a blacklisted process. Note: If you set something to [PARENTBLACKLIST] only disallows that a parent is not allowed to start an child process, it does not block the parent itself. So if you have *notepad.exe*>*.exe in [PARENTBLACKLIST] you can still start notepad, you only block notepad to start other executable.

 

Well, in my first post I said that all applications that I had added to the PARENTBLACKLIST were being allowed to spawn any child process despite my policy/rules. To answer your question about how I was testing, I was adding application to the PARENTBLACKLIST that spawn child processes to see if Bouncer Logged them as being blocked. I definitely understand that the PARENTCHECK Feature should not block the PARENT. The PARENTCHECK Feature would be useless if it blocked the PARENT.

I rolled my machine back, and PARENTCHECK is working now. I'm not sure what went wrong. I did discover that the PARENTCHECK Feature required a reboot before it would work on my machine. Simply stopping, and starting the driver again did not work. That could account for some of the times I tested. PARENTCHECK always worked for me in the past until now. I'm going to chalk it up to bad luck for now. Thank you for your help anyways!

 

For this info:"C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE > C:\Windows\splwow64.exe"

I created the rule below in parent whitelist:"C:\Program Files (x86)\*>C:\Windows\*"

But I still got the info, could you please show me how to create effective rule for it? I'm using the latest demo version of Bouncer, so please keep the rule as short as you can.

And do you have any good idea to create a rule for this:"CMDCHECK > C:\Windows\System32\svchost.exe > C:\Windows\System32\rundll32.exe C:\Windows\System32\shell32.dll,SHCreateLocalServerRunDll {9aa46009-3ce0-458a-a354-715610a075e6} -Embedding". I created a rule:"!C:\Windows\*\*.exe > C:\Windows\*\*.exe", is it right?

Thanks.

 

Do you know how to create a rule for this info in whitelistCMD?
*** excubits.com demo ***: 2016/05/31_19:22 > CMDCHECK > C:\Windows\System32\svchost.exe > C:\Windows\System32\rundll32.exe C:\Windows\System32\shell32.dll,SHCreateLocalServerRunDll {9aa46009-3ce0-458a-a354-715610a075e6} -Embedding

I've tried to create a rule like:!svchost.exe>*rundll32.exe*C:\Windows\System32\*.dll

Did I make a mistake?

 

I will copy the two example rules that you asked about from both of your posts into code box below and go over them both then will also provide some more examples for ideas.

Code:

[CMDWHITELIST]
!svchost.exe>*rundll32.exe*C:\Windows\System32\*.dll
!C:\Windows\*\*.exe > C:\Windows\*\*.exe

Ok so the first one I will correct below:

Code:

[CMDWHITELIST]
*svchost.exe>*rundll32.exe*C:\Windows\System32\*.dll*

Your example above was very close and you've got a great idea for how the rules can work, but there were two minor mistakes and I will example. You needed an asterisk * before svchost.exe to account for the directory structure preceding it. The whole middle section of the rule is fantastic and you made great use of wildcards. You needed an asterisk * after *.dll to account for the remainder of the command line string ,SHCreateLocalServerRunDll {9aa46009-3ce0-458a-a354-715610a075e6} -Embedding, therefore the * at the end would account for that. Also, the priority rule symbol ! is only really needed if, for example, you have some blacklist rules that may clash with that rule, therefore the priority rule will override in those cases where it may be necessary.

Your other example rule I will correct below and explain. The reason why I want to correct and explain and will also share some further example rules is because your rules are very close and therefore your understanding is quite good and I want to teach you how far you can go with wildcards as well.

Code:

[CMDWHITELIST]
!C:\Windows\*\*.exe > C:\Windows\*\*.exe

Code:

[CMDWHITELIST]
*C:\Windows\*\*.exe*>*C:\Windows\*\*.exe*
or
*C:\Windows\*\*.exe>C:\Windows\*\*.exe*

With this one, it was a similar correction by adding the asterisk * at the beginning and at the end as well to account for any preceding or any trailing text within the command line string. Also, in this example, it was important to ensure that there are no spaces before or after the > symbol. In this example, it was fine to simply remove the spaces. But when working with command line strings, I quite often add an asterisk before and after the > symbol because many command line strings have other information preceding or trailing the command line string.

Now I will provide some other examples all based from the same command line string that you shared. All of the rules below would work equally as well. I will start with a more complex and more stringent/tight rule, then work my way down getting less and less strict with the rules. Regardless, they all should work. So it depends on how tight you want the rules to be. Even the more loose rules will still provide great security as well but also some flexibility.

Code:

[CMDWHITELIST]
C:\Windows\System32\svchost.exe>*C:\Windows\System32\rundll32.exe*C:\Windows\System32\shell32.dll,SHCreateLocalServerRunDll*-Embedding*
*\System32\svchost.exe>*C:\Windows\System32\rundll32.exe*C:\Windows\System32\shell32.dll*
*C:\Windows\System32\*>*C:\Windows\System32\*
*C:\Windows\SysWOW64\*>*C:\Windows\SysWOW64\*
*C:\Windows\Sys?????\*>*C:\Windows\Sys?????\*
*C:\Windows\*>*C:\Windows\*

Now I just noticed the other part of your comment regarding "C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE > C:\Windows\splwow64.exe" for parent whitelist.

Your example rule:

Code:

[PARENTWHITELIST]
C:\Program Files (x86)\*>C:\Windows\*

Your example rule is correct and will work without any issues. No problems there. I will just share some other alternatives for the same scenario that would work equally as well, just to show you some more methods for using wildcards. You can get as crafty and as thorough as you want with wildcards, or you can make rules more efficient and condensed, that is the beauty of Bouncer, the ball is in your court so to speak.

Code:

[PARENTWHITELIST]
*\root\Office1?\*.exe>C:\Windows\*
C:\Program Files (x86)\*>*splwow64.exe

The first example rule just shows Office executables getting access to Windows directory. I made use of the ? wildcard which covers one character, this would account for various versions of Microsoft Office. I believe the \root\ portion pertains just to C2R (click to run) versions of Office, but you could just as well remove the \root\ part and the rule would work with non-C2R Office versions as well. The second rule simply just shows Program Files (x86) sub directories getting access to printing functionality. But as you can see, the sky is the limit with wildcards and rule sets. It really comes down to your own individual preferences, imagination, etc.

Anyway, I hope that is beneficial. Feel free to ask any questions, anytime.

 

Hello, I’m using the latest Demo version of Bouncer. Since the configuration file’s limitation, I’m trying to short the rules. I’m confused with some rules in parent whitelist like below:


Hello, I’m using the latest Demo version of Bouncer. Since the configuration file’s limitation, I’m trying to short the rules. I’m confused with some rules in parent whitelist like below:

1.

[PARENTWHITELIST]

C:\Windows\*>*

C:\Windows\*\*>*

C:\Windows\*\*\*>*

Can I combine the rules into “C:\Windows\*>*” or something like that?

2.

As you can see, I have whistled “C:\Windows\*\*>*” in parent whitelist, but I still got this notice in log file: C:\Windows\System32\dllhost.exe > C:\Windows\System32\WindowsPowerShell\v1.0\pwrshsip.dll,What should I do?

 

If I want to block this behavior, could you please show me how to create effective rule to prevent the dll file executing?





That’s my rule:

C:\Windows\*\*.exe>C:\Users\*\AppData\Local\Temp\*\*.dll

C:\Windows\*.exe>C:\Users\*\AppData\Local\Temp\*\*.dll