Bouncer (previously Tuersteher Light)

I don't want to say with certainty because I don't want to be wrong. But what I do know is that whenever Florian has some sort of design idea to accomplish through programming, he often seems to achieve his goals quite fast because he seems to enjoy the challenge aspect to things of that nature. It is more when it comes to the testing/QA aspect that he is more cautious. Anyway, if I had to guess, I'd say more likely to be some features to play with in a few weeks. He did mention that he wants to get a fresh build going in Beta Camp for Pumpernickel anyway and so hopefully he can get that feature in successfully in the near future. With the recent advancements in ransomware these days along with a stronger need for privacy in general, I think that this would be a welcome addition to the Pumpernickel driver. It would be great to set rules on certain folders and files in such a way that the user can allow certain programs to access, while blocking other programs, etc., similar in nature to what Secure Folders was doing. That is my hope.

 

@FleischmannTV Thank you for confirming the similar behaviour with Firefox/Explorer as seen through AppGuard. Were you also blocking that behaviour with AppGuard without any negative effects?

 

Ok, thanks. Then maybe in a few weeks it's ready for the beta camp.

Regarding MemProtect:
I had some sideeffects after protecting Firefox and had to allow Firefox to access Explorer.exe
Edit: #1083

 

@mood
What were the side effects with Firefox?

@WildByDesign
Since you are helping Firefox to become a safer browser by providing a process (memory) sandbox, why not startup Pumpernickel to add a file (disk) sandbox as well?

To make dealing with updates easier one could also use the idea of application containment. Windows and all security programs are allowed to modify all programs in Program Files Folders. Each vulnarable program would only be allowed to modify its own root folder.

Code:

[LETHAL]
[LOGGING]
[DEFAULTALLOW]
[WHITELIST]
!C:\Windows\*>C\Program Files\*
!C:\Windows\*>C\Program Files (x86)\*

!C:\Program Files\YOUR ANTIVIRUS\*>C\Program Files\*
!C:\Program Files\YOUR ANTIVIRUS\*>C\Program Files (x86)\*

!C:\Program Files\LibreOffice*\*>C:\Program Files\LibreOffice*\*
!C:\Program Files\LibreOffice*\*>C:\Windows\splwow64.exe
!C:\Program Files\LibreOffice*\*>C:\Windows\explorer.exe

!C:\Program Files\Mozilla Firefox\*>C:\Program Files\Mozilla Firefox\*
!C:\Program Files\Mozilla Firefox\*>C:\Windows\splwow64.exe
!C:\Program Files\Mozilla Firefox\*>C:\Windows\explorer.exe

!C:\Program Files\Mozilla Thunderbird\*>C:\Program Files\Mozilla Thunderbird\*
!C:\Program Files\Mozilla Thunderbird\*>C:\Windows\splwow64.exe
!C:\Program Files\Mozilla Thunderbird\*>C:\Windows\explorer.exe


[BLACKLIST]
C:\Program Files\LibreOffice*\*>*
C:\Program Files\Google\*>*
C:\Program Files\Mozilla Thunderbird\*>*

C:\Users\Public\*>*
[EOF]

This would not offer the tightest protection, but would raise the bar for exploits and script based malware

 

Have a look at this: #1083
Missing extension-icons, Firefox-GUI can't be customized, some crashes...
There can be maybe more hidden sideeffects (I tested all versions -- stable, Beta, portable versions,...)
But all Problems are gone with the explorer-rule.
!*firefox.exe>C:\Windows\explorer.exe

If your Firefox is not affected, then that's fine.
But on my System Firefox needs access to explorer.exe

 

Ok thanks, I don't run Firefox, was just cureous

 

@ All

I was thinking that someday as any of us have a bit of spare time, collaboratively as a community, we should try to come up with some pre-set rules for protecting vulnerable applications which are often subject to being targeted with exploits.

For example, Adobe Reader / Adobe Reader DC (or other PDF reader), is spread across many millions of computers around the world and often targeted. We could create some rules that allow certain binaries that are necessary, but also specifically deny other binaries which would be used as "stepping stones" in making the exploit successful. Of course there are other examples as well, such as Java, but that would be better off uninstalled in the first place. Also the .NET Framework, Powershell, etc. With the various drivers such as MemProtect, Pumpernickel, or also Bouncer with command line and parent process control, the sky is the limit when it comes to ultimate control over our systems. Anyway, this was just some food for thought. This is something that I would like to assist with as well as time permits because I always do wish to help other users and to prevent more people from becoming victims to ransomware and such, particularly innocent victims.

Oh yes, I do remember that problem that you were having. I think that in some circumstances, some users will need to allow that rule since that is the expected behaviour. I tried again today to replicate that crash by doing more customizations within Firefox, adding/removing icons to the bar, etc. but unfortunately was not able to replicate the crash. It could end up being more of a system dependent thing or also could be down to an extension/add-on, it's difficult to say. But in your case, you definitely need to allow that rule. Although at least you are still able to shield Firefox process from different Windows scripting binaries and much more, so I don't believe that you are any more vulnerable for having that rule enabled.

 

Firefox is not my main Browser, so it's not a big risk for me to allow Firefox to access explorer.exe
It's only a "second opinion-browser"

 

@WildByDesign, @mood, @Online_Sword

Yes a community based set of rules would be great. But I don't have at the moment. So I would suggest the reverse.

Open a seperrate thread for MemProtect. Let people use the logging facility to gather the exception rules and post them as an attachement, so one of the MemProtect power users can evaluate them and comment on it, suggest improvements. Their are basically two scenario's

Mitigate: prevent a specific program to infect the rest of the system (only outbound),

Code:

[#LETHAL]
[LOGGING]
[DEFAULTALLOW]
[WHITELIST]

[BLACKLIST]
#outbound: protect others
*PROGRAM.EXE>*

[EOF]

Isolate: protect a specific program from other programs and vice versa (outbound and inbound)

Code:

[#LETHAL]
[LOGGING]
[DEFAULTALLOW]
[WHITELIST]

[BLACKLIST]
#outbound: protect others
*PROGRAM.EXE>*

#inbound: protect against others
*>*PROGRAM.EXE

[EOF]

Post the logs and some power users will suggest priority whitelist rules. When log is clear and program works okay (no side effects), change [#Lethal] to [Lethal].

Mitigate would be good enough for Office, PDF, Media and Mail programs and secundary Browsers. Isolate would be suitable for WebBrowsers being used for online transactions/shopping/banking.

A pitty Comodo already had a product called Comodo Memory Firewall, otherwise this would have been a great name for MemProtect. Florian needs to load his label, so it would be better to incorporate the name of the company in the product (like MalwareBytes does), because for consumers it is easier to understand (company+function of the program) and (take my word for it) investors like it also (explain in a 6-10 second pitch).

Bouncer > Excubits Execution Bouncer
MemProtect > Excubits Memory Guard
PumperNickel > Excubits Disk Guard
MZWriteScanner > Excubits Dropper Guard

Following the naming logic: Bouncer would run in Default Deny mode and the others in Default Allow mode. But this is the last time I will mention the need for a hard coded default allow. MZWriteScanner should get the same set of rule options as the other programs.

 

If other security apps are running, they should be allowed to access the protected executables.
This can be an additional exception in the whitelist. But only if a strict configuration is used.

A "relaxed" configuration can look like this:

The protected executable can access all in C:\Program Files\ and C:\Windows\
There is a minimal chance now that the program crashes/freezes.
If there are no problems after some days (or nothing in the log), then the configuration can be changed to a more strict version.
But this relaxed version is still secure, because the Protected executable needs write-access for downloading files to these directories (where the execution of the downloaded files is allowed).

The Priority Rule in the Blacklist is blocking all files in the temporary directory, even if there is a Priority Rule in the Whitelist.
Maybe C:\Windows\Temp\* can be changed to *\Temp\* so that the temporary directory of the User / Administrator is included.

Some more things can be done with "Priority Blacklisting":

In this example the executable can access all files in the .NET-Directory, but csc.exe and InstallUtil.exe are always blacklisted.

 

Wow, just when I was about to tear my foot off, I come across this post...

I was looking at trying out MemProtect and Pumpernickel, so followed the install instructons from here... but I kept on getting this...

Spoiler

So... tracked down KB3033929, installed it and woo hoo, successfully started...

EDIT: Finally, there might be a chance to stop this nuisance "C:\ProgramData\NVIDIA Corporation\Drs\nvdrssel.bin"

 

Florian has completely recreated the BouncerTray app to make it more functional and better organized. The internal version is working wonderfully and should be ready for release soon.

Screenshots:

Spoiler: Screenshots

BouncerTray Layout:


Submenu to control driver: Start, Stop, and Restart


Submenu for Install Mode:


Yellow icon to indicate when Install Mode is ON:

In addition:

Empty Log File - This option automatically stops the driver, clears the log file, and starts the driver again.

Open Config File - Initially this option just opened the config file in Notepad as is. But I suggested to Florian to make this option provide a UAC prompt to open the config file within an elevated Notepad so that the user can easily modify bouncer.ini config while in the Windows directory.


As always, the BouncerTray app does not request elevation itself otherwise that would bother users with a UAC prompt everytime Windows boots. So it only requests UAC prompt elevation only for functions which specifically need Admin privileges, so that way BouncerTray is not running elevated at all times.

After testing this new version of the BouncerTray app, it's really quite nice and much more functional. This way we can do much of what we need to do within the tray app. The idea is always to keep things simple and efficient.


I have some new details regarding Pumpernickel as well but I've run short of time right now and will post about that a bit later.

 

Florian mentioned to me just recently that Pumpernickel driver has been receiving quite a bit of attention. I personally didn't think that it would receive quite the attention that Bouncer or MemProtect has had, but I suppose with ransomware increasing as it has lately, Pumpernickel has got huge potential there. So I will share a quite below from Florian regarding Pumpernickel downloads.

I've heard back from Florian regarding the possibility of adding this feature to Pumpernickel. He was experimenting with this recently but had significant problems at the moment. I will share his responses below in quotes. My assumption is that there are sometimes different roadblocks to certain methods within the kernel and there may be multiple ways to achieve some specific function, and the method that he had initially tried has failed quite badly. At the moment it is not a priority for him in comparison to the rest of his development, but at some point in the future he may try again and figure out a more elegant method that isn't so disruptive to system performance and stability. I don't like to deliver bad news, but I wanted to ensure that I followed up with your question/suggestion appropriately.


From 2016-04-24:

From 2016-04-29:

 

Ok, thanks.
But even without read-protection it's still very powerful.

Yes, nearly each week now there are new Variants of Ransomware discovered.
With Ransomware that is encrypting/modifying important data, People want to protect their files from being modified.

2016 - "The Rise of Ransomware"
Pumpernickel was developed at the right time.

 

According to Pumpernickel instructions and if I get them rightly, using the following ini will lock my USB drive and put an impenetrable barrier crypto-malware proof between it and the rest of my PC?

Code:

[LETHAL]
[LOGGING]
[WHITELIST]
[BLACKLIST]
*>T:\*
[EOF]

 

I asked @Windows_Security a similar question in a PM: 'Would Pumpernickel be easy to configure to protect a whole USB backup drive as read only except for certain backup programs? That is how I have Secure Folders configured now.'

His response would confirm your ini above (if that's OK, @Windows_Security )

Yes it would. Wildbydesign has explained on how to install the driver of Excubits MemProtect here , Excubits is installed in the same (go to x86 or x64 and right click choose install, after having edited the Pumpernickel.ini file with the code below (and copy it to Windows folder).

[#LETHAL]
[LOGGING]
[WHITELIST]
!*BACKUP.exe>X:\*
[BLACKLIST]
*>X:\*
[EOF]

Where BACKUP.exe is the name of the main executable of your backup program and X is the alphabetic character of your drive. Test these rules (try copying a file with explorer and run a backup). Check the Pumpernickel.txt logfile in Windows. Now only explorer should be mentioned in the log. When this is the case, remove the # for Lethal and and a # for Logging. Stop and start the Pumpernickel driver to effectuate the new rules.

 

If you are using:
!*BACKUP.exe>X:\*
all executables with this name have write-access to X:\
even malware with "backup" in it's name.
for example: c:\windows\temp\malware_backup.exe

To be sure, you can add the whole pathname of your backup-program.
example:
!C:\Program Files\Backup\Backup.exe>X:\*
or
!C:\Program Files\Backup\*.exe>X:\*
or at least mention Program Files:
!C:\Program Files\*Backup.exe>X:\*

 

!C:\Program Files\Backup\Backup.exe>X:\*

If Pumpernickel supports HASH value, use the Hash in the above line would be great and easy to rule out all other even malwares. Because the programs in the white list are only a few, it is also easy to maintain the hash list.

 

Thanks a lot @paulderdash @mood @kakaka

I think this ini is working good so far and much more robust than SecureFolders:

Code:

[LETHAL]
[LOGGING]
[WHITELIST]
!C:\Program Files\Backup\Backup.exe>.exe>T:\*
!C:\Program Files\CloudBackup\CloudBackup.exe>T:\*
[BLACKLIST]
*>T:\*
[EOF]

Problem is File Explorer can still read my drive. How can I block explorer.exe?

 

I just wanted to confirm with absolute certainty first before answering. So just to clarify, File Explorer (explorer.exe) is not able to delete, rename, move, etc. files on your T: drive? However, File Explorer (explorer.exe) is able to Read/View within T: drive?

If that is correct, that is simply because the Pumpernickel driver does not yet filter the Read attributes due to Florian running into issues with performance impact. However, if time goes by and more and more users think that filtering Read attributes would be beneficial similar to Secure Folders, then possibly Florian can give it another try using different methods to achieve filtering of Read attributes without performance impact sometime down the road. Another possibility would be for him to temporarily create another driver that only filter Read attributes to be able to hide files/folders, then once that functionality becomes stable and efficient it could be moved over into Pumpernickel driver at that time. I'm wondering if developers such as Florian are able to somehow analyze other drivers (Secure Folders, in this case) to visualize how it is achieving Read attribute filtering within the kernel without stability and performance issues.

 

Exactly. Moreover, I did a test by opening a txt file, read its contents then select it all and copy - paste to a blank txt file on desktop. In other words I was able to copy-paste as well and if I can malware does too.

Don't want to be ungrateful but I don't like this alternative @WildByDesign. Too much hassle would be to maintain an extra driver.

This would be so great. I hope Florian could analyze them and find a solution to adapt to existing Pumpernickel.

Thanks a lot for your kind help.

 

It would be not easy to maintain the ini-file if only the hash is used:
!*D8F0DCAEE90F374C9A57ABF547052E0A06319D585B3E0D3C8CFDA7997F1D030F>*
Maybe this would be better:
!C:\Program Files\Backup\Backup.exe (SHA2568F0DCAEE90F374C9A57ABF547052E0A06319D585B3E0D3C8CFDA7997F1D030F)>X:\*
But Pumpernickel doesn't support Hashes

 

@mood Thanks for this tip.

 

My Pumpernickel .ini to protect my backups on attached USB drives:

[LETHAL]
[LOGGING]
[WHITELIST]
!C:\Program Files\Bvckup 2\bvckup2.exe>D:\*
!C:\Program Files\Macrium\Reflect\reflect.exe>E:\*
[BLACKLIST]
*>D:\*
*>E:\*
[EOF]

Are these log entries of consequence? Should I refine my rules to allow these? e.g. replace E:\* with E:\Macrium Reflect\* in whitelist and blacklist?

*** excubits.com beta ***: 2016/05/06_14:41 > C:\Windows\System32\SearchIndexer.exe > E:\System Volume Information
*** excubits.com beta ***: 2016/05/06_14:41 > C:\Windows\System32\svchost.exe > E:\System Volume Information\tracking.log

 

Try [#LETHAL] and run it for some days, to see if more executables wants write-access to D: or E:
Or Blacklist only the directory you want to protect *>E:\Macrium Reflect\*
Or add these two files (mentioned in your logfile) to the whitelist
C:\Windows\System32\SearchIndexer.exe>E:\System Volume Information*
C:\Windows\System32\svchost.exe>E:\System Volume Information*

In some cases you have to remove the trailing slash.
For example if a file wants to modify the directory itself:
*** excubits.com beta ***: C:\Windows\System32\SearchIndexer.exe > E:\System Volume Information
In that case whitelisting E:\System Volume Information\* is not enough.
You have to use E:\System Volume Information*

Or you can whitelist this specific directory for all volumes
Variant a)
*>*:\System Volume Information*
Variant b)
C:\Windows\System32\*>*:\System Volume Information*
Variant c)
C:\Windows\System32\SearchIndexer.exe>*:\System Volume Information*
C:\Windows\System32\svchost.exe>*:\System Volume Information*

Do you have System Restore enabled? If yes, than it's better to allow write-access to the "System Volume Information"-directory
Are you using the Recycle Bin? If yes, then allow the write-access to "$Recycle.Bin"

Now you have several choices.
But I would recommend [#LETHAL] and keep an eye on your log-file for a while.