Bouncer (previously Tuersteher Light)

This hasn't got anything to do with promises, it has to do with trying to explain things clearly.

 

Let's agree to disagree

 

As suggested here at Wilders, Florian has implemented an Install Mode into Bouncer now within internal builds that I'm testing right now. Install Mode can be enabled and disabled through the BouncerTray tool which, within the config file, changes between [INSTALLMODE] and [#INSTALLMODE]. The tray icon has a new shade of yellow during Install Mode. I believe that there is a reminder after 30 minutes so that the user is aware and doesn't forget. So far my brief testing of this new Install Mode is working great. I have followed up with Florian to ask for more technical details behind Install Mode to clarify and I will share those details when I hear back from him.

 

Looking forward to it in stable release.

 

The tool switches between [INSTALLMODE] and [#INSTALLMODE]
Manually editing the .ini has the same effect (without using the Tray tool) ?

Is the service restarted after switching to [INSTALLMODE] / [#INSTALLMODE] (to read the new .ini) ?
Or is the service reading the .ini in "realtime" (without restarting)?

 

Yes, you can change this manually as well.

When selecting the install mode in tray app, it automatically performs a restart of the kernel driver. Bouncer does not read changes to the config in real time, therefore if you manually made the config change, you'd have to restart the driver in an elevated cmd prompt.

 

The problem is, I'm not sure with what you're disagreeing. But based on your latest comments, it's perhaps indeed better not to respond to avoid even more confusion. But it would be cool if someone could confirm that member Mood was right, the only reason why I'm asking is because he wasn't completely sure.

 

@Windows_Security Kees, I was wondering if I could get your opinion on something. Recently, I have been having thoughts of dropping EMET, or at least dropping EMET protection on Chromium. I may still use EMET to protect other programs. But I want to ensure that Chromium is performing as efficiently as possible and I have noticed some slow downs with EMET and Chromium.

So my thoughts here are: Dropping EMET protection of Chromium and switching to using either MemProtect or Pumpernickel (or both) to protect Chromium.

If I were to use MemProtect or Pumpernickel (or both) with solid, well thought out configurations, to specifically protect Chromium, do you think that I would be safe enough to drop EMET protection in that case?

 

@Dzp5t Exactly my answer

@WildByDesign
As explained in the lengthy post on exploits Memprotect sort of cages the next stages of an exploit, making it an toothless tiger. But even without any form of anti-exploit I think Chrome will be fine.

AppContainer and Win32k lockdown, limit attack surface from within Chromium/Chrome. When you use EMET's ASR to block loading scripting dll's, it sort of takes access to shell (and stops exploits after they have misused a bug in a program to take control of the flow of commands).

Yes Memprotect is a memory access sandbox and Pumpernickel a file access sandbox.

 

That is what the discussion was about. It's still not clear if MemProtect is able to block process execution like Bouncer. If not, then I wouldn't advice to dump EMET, because just like MBAE and HMPA it blocks exploits in an earlier fase, compared to anti-exe. For some reason people refuse to confirm that what Mood wrote was 100% correct:

https://www.wilderssecurity.com/thre...-tuersteher-light.359127/page-42#post-2572284

 

For everyone confused by Rasheed's post, please read this explanation Memprotect is perfectly capable of stopping exploits. Anti-exploits software is also NOT capable of preventing exploits, only patching/updating does.

In laymen's terms

• An exploit is a bug which enables a malware writer to take control over the flow of events (commands).
• All exploits start with code (scripts) which are included in rich content (a webpage, flash movie, pdf, word document, even the tiniest bits code describing the the picture ,called meta data, can code which can be exploited). Anti-executables can't stop this because they allow the hosting application (e.g. your browser, flash player, pdf reader, Word, Paint, etc).
• Anti exploit software try to compensate for a missing overflow protection in C and C++, so they look for command flow breaches. But it is like putting the cart before the horse (or like we say in Dutch putting the horse behind the cart). Only HPMA uses CPU based virtualization to prevent some forms of control flow breaches. EMET also call's itself an Enhanced Exploit Mitigation Toolkit (not Exploit Prevention).
• After the exploit has taken over the flow of commands, it has to execute additional code (usually first something planted in memory, next something downloaded to disk). Only MBAE monitors downloads and blocks execution of suspicious downloads.
• Memprotect blocks execution of in-memory code outside the memory allocated to the host application being exploited (exploit can take over control within the memory bounderies of for instance your browser, but not outside your browser). It simply jails the host explication in stead of looking at control flow for exploit like behaviour or breaches.

Like Mood wrote, Memprotect is probably the best mitigation for exploits available at the moment.

 

No offense, but I think your posts are a lot more confusing, because they are too technical, you're making it way too complex. The easiest way to interfere with exploits, is by simply blocking the execution of the malware/payload. If you have done that, you don't even need protection against code injection into other processes, that is what you fail to understand. Bouncer and other anti-exe tools are capable of doing this.

But the advantage of EMET, HMPA and MBAE is that they can also block "in-memory malware" that doesn't need to migrate to other processes. MemProtect and anti-exe tools can't protect against this. The good news is that "in-memory malware" is probably only used in targeted attacks, but it's still interesting from a technical point of view.

 

Can it also block child process execution, just like Bouncer? If so, then I don't see the need for Bouncer anymore, unless I'm missing something.

 

You have a short memory, look at your own post#1101 (it is on this page) who you quoted

There are many execution environments which are part of the OS, which are not blocked by Anti-Executables. First version of NVT-AE failed to block commands which invoked these execution environments for example. This is why Bouncer also includes Commandline scanner.

You have posted that you use NVT-AE, but NVT-AE does not monitor DLL's, you need SOB to block execution of DLL's. Even Software Restriction Policies when explicitely told to monitor/block DLL's dont block a C# DLL. A DLL written in C# invokes mscoreei.dll, the runtime execution interpreter, which is part of the dotNet execution environment. Even bouncer does not block execution of C# DLL's, because it does not block the build in execution envionments of the OS (like any Anti-Executable), you need MemProtect for that (or use EMET's ASR feature to selectively block loading DLL's).

In your hypthetical world your are definitely mising something, namely reality or practice. The proof of the pudding is in the eating.

This is really my last post. Tell Florian that Bouncer does not need Commanline scanner nor MemProtect or MemProtect does not need Bouncer, please explain it to him, not me.

 

I'm not following you. I asked you a question in that post. I wanted to know which of those 3 things MemProtect protects against, is it 1, is it 1+2, or is it 1+2+3? For some reason you chose not to respond.

EXE Radar simply tries to block payloads from running, which is the end goal of exploits. AE can block disk based payloads, but they can't block in-memory payloads, you need EMET/HMPA/MBAE for that. MemProtect will also not be able to block it from what I've read. So again, no need to compare Bouncer/MemProtect with HMPA and EMET, they both offer different protection methods.

Once again you fail to simply answer the question, if you don't know the answer simply say so, no need to come up with fancy replies showcasing all of your "knowledge", this all has no value when you can't answer basic questions.

 

@Rasheed187 @Windows_Security

Guys I think there's need for a war room where you can discuss and argue to death all your povs lol
You spoil every thread you touch. hahahaha

 

I don't know why he thinks that I'm attacking him, I'm just trying to figure things out.

 

Yes I can understand that as you are a very inquisitive person and that's good, seriously. Perhaps I'm wrong and we need to see this sort of discussions and positive contribution would outcome.

 

Well the more that they "compare notes" the easier it seems that the pertinent data continues to leak out between colors

I been on a copy/paste binge with all this because (for me) it has a tendency to too rapidly fly right over my head sometimes given the different methods/vectors/drivers details I need to cover without losing track (or sleep)

 

BTW, I made a mistake. Bouncer is of course not focused on blocking child processes specifically, it's a white-listing tool. According to Mood, MemProtect does watch for child process execution, and protects against memory reading and writing. So Bouncer still complements MemProtect. But this still doesn't change the fact, that both Bouncer and MemProtect can't block the execution of in-memory malware, you still need EMET, HMPA and MBAE for that.

 

This is also an interesting article about the difference between anti-exe and anti-exploit. Of course, MBAE has become a lot more advanced, it's now using the same kind of protection methods as EMET and HMPA, instead of using only anti-exe techniques.

https://news.saferbytes.it/approfon...ctive-approaches-to-mitigate-exploit-attacks/

 

Actually that's not correct. Bouncer's Parent Check Feature is designed to block any child process according to the user's policy. It's all in how creative the user wants to be. If I don't want to allow a process to be the parent to any .tmp, .exe, etc.. then I can do that.

Edited 4/3 @ 5:32

 

OK I see. But what I basically meant was that MemProtect is not designed to be a global white-listing tool, while Bouncer is. So you can not say that Bouncer is not needed anymore, like I did. Actually, I still don't know if MemProtect can actually block child processes, nobody has confirmed this. And I can also not find any info on the bitnuts.de site, why is MemProtect still not released officially?

 

I've had some recent conversation with Florian, so I will provide some details. I am still waiting on some other technical answers regarding MemProtect Default-Deny vs Default-Allow as brought up by Kees earlier. So I will provide updates on that when it comes as well.

• Florian is experimenting right now with the possibility of using Windows Explorer shell extension for quick and easy creation of certain rules for Bouncer (and potentially other drivers). In his testing so far, it seems to make his own personal work-flow of creating rules much faster and an overall good experience. I have not yet tested a build with this yet so I can't really comment on it.

• Soon, Florian intends on sharing with us some more built-in Windows components which can be (and have recently been) exploited by the bad guys for malicious purposes along with some other demonstrations to lock down Office, IE, etc. To quote Florian:

• My own testing of a personal build of Bouncer with the upcoming Install Mode has been going great. As a matter of fact, I've found myself utilizing Install Mode more often than I thought and find it quite useful particularly for persisting across reboots. I found one minor bug with BouncerTray with regard to the new Install Mode, so Florian is looking into that minor bug fix and hopefully it will show up in Beta Camp soon.

I think that was it for now. As I said, there are a few other technical questions that I've asked Florian regarding MemProtect Default-Deny vs Default-Allow that I am still on. It's quite likely that the answers will come over the weekend and I will share the details when it comes.

 

Thanks for update @WildByDesign