Bouncer (previously Tuersteher Light)

I understand but this is one of the most important things, even for experienced users IMO. For example, EXE Radar could have also easily introduced problems, if it wasn't for the standard rules that the developer has baked into the app. Same with System Safety Monitor, the developers made sure that you couldn't make Windows unbootable.

About exploits, the reason why I mentioned this, was because I was thinking that in theory you could block lots of payloads if they can not execute from certain folders. Actually, this is nothing new, because tools like AppGuard, VoodooShield and EXE Radar are already doing this, although in a slightly different way.

 

Actually after thinking about this a bit, I do agree with you 100%. I remember previous builds of his used to have Windows, Program Files and ProgramData already in the bouncer.ini rules. I think the complication with that previous method is that the device paths aren't necessarily the same from machine to machine. However, thanks to your suggestion, it made me think that this could certainly be done within the installer (when he releases it) to automatically detect device paths for critical Windows directories and automatically add to bouncer.ini prior to first use. That's certainly possible and I am glad you brought it up. Technically, it could be possible to code into driver to detect just the same and enforce it so user doesn't mess up. And of course user can still define individual Deny rules within those Allowed paths as well. I will bring up the importance of this with the developer.

In that regard, yes, Bouncer would block everything that you throw at it within the blocked folders as defined by the users rule sets. With the exception of fileless/memory only malware, I would assume. I apologize, I had misunderstood you at first. When you mentioned exploits I thought you were referring to trusted executables (in allowed folders like program files) being exploited. But if you are just talking about a pile of executables fully loaded with malware and exploits, trying to execute those in a user folder blocked by Bouncer, those executables would be denied execution and payloads not delivered. Same goes for RLO and other spoofing if that were added into the scenario. Certainly not as full fledged when compared to AppGuard and EXE Radar, but that is not the developers goal to be anything like the others.

 

hi I want to give this program a try where can I get the latest install?

 

From here: http://excubits.com/content/en/products_bouncer.html
Agree to Terms on bottom of page to provide current download link.
If you need some basics, check my previous post: https://www.wilderssecurity.com/thre...y-tuersteher-light.359127/page-3#post-2441578
Feel free to ask any questions, I'm happy to help.

 

Update regarding Bouncer's executable signing from the developer:

Spoiler

Regarding your question: Yes, I plan to sign the win32 executables. I need
to obtain another code singing certificate for win32 executables,
unfortunately you cannot use the kernel driver signing certificate. This is
why I did not sign the executables yet, but it is definitely on my to-do
list, because it is important to have a full chain of trusted executables.
I think for the initial demo it was and is still okay, although it is not
perfect. Since the tools are new and were not on my initial time plans and
frames this was set on hold. But I think I will get one during January 2015
- so no long time to wait

 

it is necessary to save bouncer.ini in C:\Windows ? if yes it is better to save config and load config button always load from C:\Windows

 

Yes, you are correct. I was actually thinking about that myself yesterday as well. For example, upon starting up Admin Tool that it could by default load the rules from C:\Windows\bouncer.ini to display anytime you start up Admin Tool to make it a bit quicker for changing rules and so on. That would also make it quicker/easier to toggle between LETHAL modes (enabling/disabling blocking) as well. But I wanted to think about a bit more before I bring it up with the developer. My other thoughts along with that were that maybe some Admin's could be setting up multiple bouncer.ini rules and therefore could be loading/saving from other directories and such. For example, I often like to a backup of my bouncer.ini rules in my user directory where I often modify it there first, and then copy it over the bouncer.ini in the Windows folder later. However, I think it is a great idea and could be implemented in a way that works well for whatever the scenario may be. Thank you for bringing it up. I was thinking about it the other day and it has given me time to think about it some more now as well. I will talk to the developer about it and discuss the best way to implement it.

 

Yes correct, for that kind of stuff you need specialized anti-exploit tools, but anti-executable tools can probably stop most exploits. I've used System Safety Monitor for years on Win XP, and I never got hit with an exploit.

 

great news

 

Update from developer on your suggestion regarding bouncer.ini loading with Admin Tool:

Thanks again for the great idea. I really like the way in which it will be implemented.

 

thank you this save time a lot when creating rule

 

Some development updates based on user suggestions:

• The developer has an internal version of Admin Tool now that is being tested which includes auto-loading of the bouncer.ini configurations to making saving, loading and even toggling between LETHAL/Logging modes easier, as suggested here by Wilders users. In testing it seems to be working great and will likely be released this week (or next at the latest). See my post #85 above for more details.

• The developer is still working on getting an installer put together to make it easier to get started with Bouncer, although there are some issues to work out between different versions of Windows. Anyways, he has successfully added an option to the installer which, during installation, determines the users device paths correctly for directories that are critical for the proper functioning of Windows and gives the user and option to have thos automatically added to their bouncer.ini configuration to avoid potentially having a Windows system that does not boot. This was suggested here at Wilders as well. This part of the installer is working now so it is just a matter of working a few other bugs out now until the installer will be released. At a later time this type of checking may be done within the driver itself but that will be a later release.

• Also suggested at Wilders was having the win32 executables (Admin Tool and BouncerTray) digitally signed as well. The developer has requested a signing certificate for win32 executables. That will hopefully be received within a few weeks and at that time, the executables packaged with Bouncer will be signed and available for download.

 

Is it possible to write more complex rules like limiting the rights web applications have? AppGuard limits the rights of web applications by not allowing them to write to the system space, and Program Files Folders. AppGuard also has memory protection that uses similar rules. It would be pretty cool if I could make more complex rules with Bouncer.

 

Hey CET. Short answer: No. There are no ways to write complex rules with Bouncer to limit rights of applications or memory protections. AppGuard is certainly more sophisticated when it comes to that and is kind of in a league of it's own. While Bouncer is intended to be a simple application whitelisting KMD for typical anti-executable purposes.

Long answer: Limiting rights and memory protection between apps is just not in the scope of Bouncer. I'm just speaking from my own knowledge and understanding, not on behalf of Bouncer devs. In my opinion, it is quite similar to SRP, but stronger and more efficient. I know that in the future the devs plan on releasing a paid version (lifetime licence) that will add file hashing capabilities which will be great. But still nothing comparable to AppGuard. Personally, I use Bouncer for anti-exe along with EMET for anti-exploit and use a Standard user account. Although similar could be done with SRP and EMET, or SRP and MBAE, VA and EMET, and so on. I know that the bouncer devs want to keep things simple and within the kernel, not having to rely on userspace apps to interact with the kernel driver which is quite often what would have to happen when adding more capabilities.

 

Apparently Bouncer can be used to mitigate against the recent Windows 8.1 Elevation of Privilege in ahcache.sys/NtApphelpCacheControl that was published by Google. You can simply blacklist 'ahcache.sys' temporarily until Microsoft releases a patch. Alternatively, users with UAC sliders set to Maximum (Always notify) are also protected.

From: http://excubits.com/content/en/news.html

 

Hi
still waiting for the next release

 

I'll post here when the updated binaries are released and let you know. The feature that you quoted from is working perfectly in testing, so release shouldn't be too far off. There is another feature that the developer still had a bug to deal with but that was something completely different. I will talk to the developer and see how things are going. Are you interested in the English executables or German?

Win32 executable signing has been achieved now as well.

 

German executables

 

German executables are updated now: http://excubits.com/content/de/produkte_tuersteher.html

 

Updated Bouncer release it out now with the following features:

• Executables are digitally signed now
• Admin Tool automatically loads rule set now (when started from BouncerTray)
• Admin Tool can automatically add rules for critical Windows directories (when started from BouncerTray with no existing rules)

Download updated bouncer.7z package: http://excubits.com/content/en/products_bouncer.html

Despite the added usability features (thanks to Wilders users' suggestions) in the executables, Bouncer remains 100% kernel mode since these executables don't use any hooks or communicate with the Bouncer kernel driver directly. That seems to remain as the developers' main goal for Bouncer.

 

@WildByDesign thank you very much it is now much better and faster on creating rule and save and load rule
just some other Thought,idea
when stat/stop driver with BouncerTray it show some Message like driver stoped
it is better that show this Message from (popup) notification area appear
and BouncerTray use about 7.43mb RAM,since it is do some simple job i think it is CONSUME very much ram
so it is need improved

 

You're welcome, my pleasure. Although all that I did was merely pass your suggestion along to the developer. So thank you for the great suggestion because it will be more beneficial for the users of Bouncer, myself included. I like the way that it works now much better thanks to your suggestion as well as some suggestions from other users here at Wilders as well.

The one line that you said "it is better that show this Message from (popup) notification area appear", I apologize but I don't understand exactly what you mean. The pop up messages in Bouncer are designed to use the default notifications of whichever version of Windows the user is running it on. For mine, running Windows 10, the Bouncer messages show up using the default Toasts notifications which look quite nice and also using the default OS notification method show up in the new notification center of Windows 10. So if you are running Windows 8.x or Windows 7, it would be using the default within the operating system. That way it can also write to the Event Logs as well. By your suggestion, do you mean that Bouncer (or BouncerTray in particular) should have it's own built-in notification pop ups?

Mine is using 6.1mb RAM on 64-bit Windows 10. Yours is using 7.43mb RAM. I have to be quite honest, I personally don't have any worries about that myself. To me, the most important thing is the efficiency and security of the kernel mode driver. I am not affiliated with the development of Bouncer, just merely a good acquaintance of the developer whom I've had many good security-related conversations with and have suggested some ideas for Bouncer along the way including great suggestions from Wilders' users here too. But I have to be quite honest, there are many more exciting things coming down the pipe for Bouncer and I personally don't think that this is much of a worry or priority at the moment. If you want to suggest it to the developer, you can always do that and he is very open to feedback. I'm pretty sure that it would likely mean rewriting the BouncerTray program from scratch, but that is just my guess.

 

I am currently testing an upcoming Plus version of the Bouncer driver which utilizes SHA-256 file hashing at the moment. This is getting interesting.

 

Good to know they employed SHA-256 which is considered secure enough so far than broken hash like MD5.

 

Indeed, and yet still lightning fast with SHA-256 hash filtering of executables (including .dll, .sys, etc.) I believe the developer is going with SHA-384 come release time.