Bouncer (previously Tuersteher Light)

To clarify, the discussion was more about if it makes sense to claim certain things. If people want to compare tools, they should give us the full view. But it's obvious that tools like Bouncer/MemProtect are quite powerful that was never questioned by me. Now, if he would only build a nice and handy GUI.

 

You're welcome. I do recall Florian once saying that a user could theoretically use MemProtect alone, with a proper configuration, and it would secure a system extremely well even without Bouncer. So there must be some method of blocking execution involved, whether that be directly in memory or whatever.

I would really like to run some tests Process Monitor next time and log some more details of what is occurring.

 

The question is dead simple: have you ever started a thread ever?

 

OK thanks, I see. I wonder if the fact that it blocks calc.exe from loading when the ETT is protected, is sort of like a side effect. AFAIK, MemProtect is not an AE like Bouncer and AE's will also easily pass all tests, by simply blocking child process execution.

And when you think of it, let's say you block explorer.exe from access to memory of other processes, will it then also not be able to launch any other processes? It doesn't make any sense to me, but perhaps I'm missing something.

Are you being for real? You can check this your self. Let's focus on the technical discussion.

 

@WildByDesign thanks for the tests. I can also confirm and did more test myself (dll injection tool, and also with code injection tool using exe as injector and using powershell injector).

@Rasheed187: I think this is side effect. To my understand MemProtect is just able to limit how process can interact with other process. It is very open in config, so you can protect process A from accessing any other processes B, C, D... You can also protect process A being accessed from other process B, C, D. As a side effect this can help that a exploit from Process A can inject code into other processes. If you want this, you can limit any access from Browser to other processes. Then a exploit in browser cannot inject code into explorer.exe or other processes. You are right with assumtation: the exploit in browser still executing, but it cannot go to ohter process. With nice side effect of also blocking process execution it cannot also execute malware additionaly loaded.

So as a result this can helps to protect from exploration, but depending on exploit and how attacker manages to execute code there are scenarios where code can be executed in the application itself (which is for me logical and cannot be blocked without additional code flow analysis ==> api and process hooking need). Like with all security solutiuons there is way to come around

Think of MemProtect as shelter for browser or ms word for example. You can set it up a way that browser can only access its own memory, same for ms word. So worst things that can happen is, that exploit code gets executed in browser/ms word itself. If you are purist this is rated a succesful attack. The question is how far attacker then can come (I think: not very far). I think in most cases attacker want more to do, but this is then blocked with MemProtect (and/or Bouncer), so it is quite good protection. Together with AntiVirus and additional EMET for example you have a very good protection level. I hope this helps to clarify and you understanding.

 

Well even according too purist definition it was not a succesfull exploit: exploit means that you are able to exploit a bug by changing the flow of events in a reliable manner (being able to replicate resulting in a predictable outcome). When it does not reach the planted code elsewhere the exploit did not take over the execution flow and failed. When the invaded application crashes or hangs, the exploit is not succesfull. That is why they always proof having taken over control by launching an application (PoC's often launch calc.exe).

Your explanation about MemProtect's capabilities is spot on by the way

 

See post 1473 (as explained by WildByDesign) now read what these capabilities do (as explained by Microsoft) link

So how would you start another process when these capabilities are removed, Microsoft mentions only these link

When you know of more, let's team up, I will happily be your mate in the next Pwn2own. I will massage your shoulders, I will call you Rasheed-SAN and get your coffee and thee as long as we split the bounties you earn from undocumented process starts in the Windows OS.

 

Further MemProtect testing findings with ProcMon and Process Hacker::

I am seeing process creation for calc.exe, however showing as a Suspended process with a memory footprint of 80 KB. Whereas, when calc.exe is properly initialized into memory we would be looking at something more like 10,000 KB+. I am also seeing a few AcroRd32.exe processes, Suspended, weighing in at 72 KB memory footprint along with some chrome.exe processes, Suspended, 56 KB, This was after dozens of attempts to obliterate my protected processes of Chromium and Adobe Reader with HMPA Exploit Test Tool along with various DLL injection tools and so forth.

So MemProtect is definitely functioning quite a bit differently from traditional anti-executable software. Rather interesting. While it is not specifically blocking process execution per traditional means, it is most definitely not allowing processes to communicate with the memory of other processes nor is it allowing processes to fully initialize their memory footprint.

 

With the proper rules it is possible to enforce memory integrity (prevent overflows) at process level and compensate for structural weaknesses in certain programming languages, see Wiki explanation: link

That is why I like Memprotect's ability to use protected processes feature (link)

 

Your definition and explanation makes sense Thanks.

I thinks this is artifact stub created maybe initially by the OS loader - before the actual executables code is copy to the memory location. As far as I know Windows create initial objects and stuff before loader puts exe code into mem, so this is not from executable, it is from OS. For me it seem not dangerous, because nothing is executed. A suspended stub is not dangerous (it uses useless mem, this is something you can complain, but this is not dangerous).

 

Yes exactly. I don't believe that MemProtect is designed to be an exploit blocker, it should be used as a companion to Bouncer. The fact that it passes the ETT, doesn't tell the whole story.

 

An exploited process simply tries to run a malicious child process, no matter if it's running as a protected process. Let's say you make explorer.exe a "protected process", I suppose it can still load apps? Of course other processes, will not have access to its memory, and can't manipulate it.

These type of statements confuse me. I don't think that the "protected process" feature is meant to prevent or mitigate memory corruption. Do a search on the web, and nowhere you will find the "protected process" feature mentioned as a way to mitigate exploits.

LOL, good one.

 

Actually, this also happens with EXE Radar and SpyShelter (SS) and back in the days I had the same with SSM on Win 32 bit. It's normal for blocked processes to show up as suspended. I did notice that if I make a block rule with SS, the child process never gets loaded.

 

Well, at the same time anti-exploit techs are prone to be bypassed. I think there's no better or worse in both types of tech.
I've been consentrated on my study.

 

As to user mode hook or KMD, generally speaking it can't be said KMD approach is always better. I mean, it is better as long as it does not cause serious problems & expose attack surface.
Many AV have been suffering by serious flaws, i.e. KMD vuln which gives attacker all the priviledges.
In this regard, Bouncer has advantages. It doesn't install service, doesn't scan files nor is remotely exploitable. Also its quite small code base will make vuln mngmnt easier.

As to usability, I think its not the matter of expertise for those of Wilders regular member. It will be more matter of one's character, personallity and custom. If you're accustomed to Linux long year, editting text file for configuration should be just an common work. But so there's many choices for many types of ppl as you guys said. (In Linux, there's not so many choices.)

Feature request: (is it correct place to write this?)
+Pls enable DEP (& ASLR for EventSource.dll) for all its component. I know they're not remotely exploitable, and I can see tray app has quite restrictive token, but I think there's no reason not to enable them.

+Singer white / black list. When I quickly looked at SOB, this feature seems facinating. Unfortunately SOB is in early beta and its development has long been stopped. Anyway, singer rule will:
1. be able to reduce ammount of rules
2. make Bouncer much more friendly for new user (it may also be possible including some default white list for e.g. Microsoft, Google etc.)
3. allow those paranoia to make even more robust security (combining path & singer rule to block possible bypass)

+ Installer option which asks whether to install driver & tray apps is really needed? I denyed it and later installed the driver via inf file, but couldn't make it to work. 'sc query bouncer' said the driver is in stop state, and netsh said there's no such service. Also tray apps are actually there in tools folder, so they're just not registered in Run registry key.

 

Some AE's block before any process is ever created though. Bouncer, SecureAPlus, and AppGuard do this. The only exception with AG is when it allows something to run with limited rights due to being in Protected Mode instead of Locked Down Mode. AG may allow some things to run momentarily (sometimes only a second, or less) until it breaks one of AG's policies. ERP even blocks process creation on my machine if it's in Locked Down Mode. I have run test on all these using Process Hacker, Process Explorer and KillSwitch, and no process was ever created, not even in a suspended state.

 

But all of this stuff can get bypassed, that's not the point. It's a cat and mouse game.

Good to know that you're focused on your study.

 

Good point, so it depends on whether the app is in alert-mode or not. In block-mode no process is created, but in alert-mode the suspended process needs to be created because it awaits on user decision, so it's quite logical when you think about it.

 

SecureAPlus does not run processes in a suspended state in Alert Mode. I don't know how hard it is to code this type of design, but SecureAPlus does it.

I sent Andreas a message a few years ago, and he informed me the reason he runs the process in a suspended state in Alert Mode is so that he can collect information about the process that is attempting to execute. He said it would not be possible to provide some information that ERP does without running the process in a suspended state.

SecureAPlus seems to collect quite a bit of info without running the process in a suspended state. I do remember that it at least shows if the executable is signed, or not in Alert Mode. I have not used SecureAPlus in a while so I don't remember what all info is available for attempted executions in Alert Mode.

 

Yes that's a truth, but just as my personal feeling, bypassing anti-expl seems to be rather trivial than full layeres of OS-enhanced (kernel-based) lockdown (as long as properly configured).
I think the Achilles' heel of anti-expl is performance effect. It is theoretically possible to make hard-to-bypass anti-expl, just imagine if EMET checked all functions rather than just critical functions. This will prevent bypassing stack pivot protection by unpivotting before critical function call. But that will cause serious performance issue and our computer will not be usable.
Day by day, year by year, many new anti-exploit techniques have been published. But most of them has not been widely adopted, mostly because performance effect. CFG/CFI is quite an old technology, Microsoft has been warming it 10 years but only recently came true in productive environment, again w/ compromise w/ performance by only monitoring CALL (at least in Win 10 TP), which can allow bypass.
It's undeniable fact that hooking have performance effect even w/ those compromise, we all know current anti-expl products have it. Compared this, kernel-based security has little impact and bypassing it is often tough except obvious logical flaw (this is why proper config & attack surface reduction is important).
Anyway, my point is there're many way to protect our PC and everybody can choose any of them according to his belief and preference.

Thanks.

Maybe that has sth to do w/ the fact SAP is not a simple AE but AE + AV.
The signature info is actually not a process' info but file's. As it scans those executable file, it may not be so wonder that it gets some info about it.

 

Can anybody teach me about Bouncer rule?
if I blacklisted hoo.exe, i.e.

[BLACKLIST]
C:\hoo.exe

Then, these rules doesn't make sense, right?

[PARENTWHITELIST]
C:xxx.exe > C:\hoo.exe
[CMDWHITELIST]
C:xxx.exe > C:\hoo.exe

If I want to ALLOW hoo.exe ONLY WHEN proper command line is passed via certain process BUT don't want to allow in other occasion, what rule should I make?

I thought, do not blacklist hoo.exe, and

[PARENTWHITELIST]
!C:xxx.exe > C:\hoo.exe
[PARENTBLACKLIST]
* > C:\hoo.exe
[CMDWHITELIST]
C:xxx.exe > C:\hoo.exe -propercommandline

But in this case direct execution of hoo.exe will be allowed...

I saw many system executables are in black list of some ppl here, but doesn't it really cause matter?

 

Yeah, I think your right about how it obtains the digital signature.

 

@142395 The command line scanning functionality is not my stronger point, so I had to put some thought into this overnight and also do some testing with it.

So just to clarify, you want C:\hoo.exe to execute only when triggered via command line? Therefore, you want C:\hoo.exe denied execution if run directly?

One important note is to ensure that you don't have any spaces within the rule lines (example, before or after > symbol)

From your example:

Code:

[PARENTWHITELIST]
C:xxx.exe > C:\hoo.exe
[CMDWHITELIST]
C:xxx.exe > C:\hoo.exe

Should be with removed spaces such as:

Code:

[PARENTWHITELIST]
C:xxx.exe>C:\hoo.exe
[CMDWHITELIST]
C:xxx.exe>C:\hoo.exe

My understand is that, with the rules which you tested, C:\hoo.exe is still executing when run directly?

I'm wondering if C:\hoo.exe being allowed to run because of the [PARENTWHITELIST] rule !C:xxx.exe>C:\hoo.exe

You could try blocking out that rule temporarily when testing to determine if that rule is allowing the execution. Anytime you would like to disable a specific rule (as opposed to deleting the rule line) you can simply add # at the beginning of that line and restart the Bouncer driver for the updated rules to take effect.

Regarding the [CMDWHITELIST] section:

You can achieve the same result with wildcards as well to keep things simple or as strict as you would like. These are just examples.

Code:

[CMDWHITELIST]
C:xxx.exe>C:\hoo.exe -propercommandline
?:xxx.exe>C:\hoo.exe -propercom*
*>C:\hoo.exe*

For purposes of testing and trying to dial down what you are trying to achieve, one thing that would could also try here is to disable the parent check feature temporarily so that you can work specifically with traditional whitelist/blacklist and get the command line section working first so that the parent check does not interfere. Also, I don't know if this specific use-case example of C:\hoo.exe requires parent process as part of execution or not or specifically just command line, since I am not familiar with it. But anyway, you can make it easier to dial down on your config for now by disabled parent check feature with [#PARENTCHECK] at the top of your config and restart the driver. Quite often I recommend users to configure one section at a time to get a good idea of how the different features and rules work together in combination.

The [BLACKLIST] rules which some of us have shared here are not required. They were examples are Windows built-in executables which can (and have been) utilized for malicious purposes and also as ways to bypass traditional application whitelisting. The developer of Bouncer is a security researcher and compiles this list as an example of ways he has seen malware utilize built-in Windows components. Most regular use-case scenarios, using that [BLACKLIST] examples should not cause problems in day-to-day use. However, everyone's systems are configured different and there is certainly the potential that some of those could cause conflict. Myself, for example, quite often had blockages regarding the blacklist rule for *msiexec.exe. Therefore I have blocked it on my list with # *msiexec.exe for the time being. Although I quite often make use of Bouncer's Install Mode now when installing/updating software and other administrative duties and so I quite likely don't need to block that rule out anymore. But anyway, if you were to use that list, keep in mind that you can always block any rules with # if they cause problems for your system.


Please let us know how your config regarding command line goes. If you have any other issues, feel free to let us all know or if you find a solution, let us know as well since we can all benefit from your example because it is a quite interesting concept to allow only by command line and block via other execution methods.

 

That's interesting, so apparently it can be done. But I don't think it's a big deal though.