Bouncer (previously Tuersteher Light)

There seems to be quite a few bugs to work out with the admin tool. If I untick parent checking the Admin tool still adds the whitelist rule under parent checking anyways. The Admin tool should allow the user to select which part of the .ini file he/she wants to edit. Also using the Admin Tool to edit the policy file makes the Parent Blacklist heading jump to the last line in the policy file. The blacklist becomes the whitelist then. Very dangerous!

It took me for ever to get Bouncer to whitelist the single file below. I tried whitelisting the file by path, and hash but that would not work. I'm not sure how to whitelist by hash alone. I ended up having to whitelist the file by path alone. I could not find any documentation on the new whitelisting method so I had to use the process of elimination to figure out how to do it. Bouncer needs some basic documentation on how to add simple whitelisting rules by path, and hash. I used this rule to whitelist the file under Parent Whitelist. I don't know if the rule is even right. C:\Users\achilles\AppData\Local\Zemana\Zemana AntiMalware\helpers\ArchiveManager.dll*>*

C:\Users\achilles\AppData\Local\Zemana\Zemana AntiMalware\helpers\ArchiveManager.dll > a46f70b1ff72389aaa0c2dad4b623263ccc81d35bff50dc4767b668e1643d2b3

Edited 9/2 @8:58

 

What does [EOF] stand for at the end of the list?

 

Yes, End of File or similar.

I'm just trying to reproduce some of the stuff from your other comment to see what's going on.

 

I have had to move the Parent Blacklist Header in the .ini file back to where it is suppose to be 3 times. I stopped using the Admin Tool after having to move it the third time. I'm editing everything with Notepad now. It's much easier anyways.

 

I wonder if it's possible to write a rule like this under ParentBlacklist: C:\Program Files (x86)\Mozilla Firefox\*>*rundll32.exe*>*.dll* to stop rundll32 from loading unknown dll files using firefox as the parent process, or would that just crash the browser by blocking needed dlls from loading.

Edit: Maybe I should try C:\Program Files (x86)\Mozilla Firefox\firefox.exe*>*rundll32.exe*>*.dll* instead to be more specific.

 

I have tried allowing the procexp64.exe to spawn from Process Explorer using each of the following two lines below. Neither one will work. I am placing the lines under ParentWhitelist.What am I doing wrong? Thank you for your help!
C:\Users\achilles\AppData\Local\Temp\procexp64.exe*
C:\Users\achilles\AppData\Local\Temp\procexp64.exe*>*

Edit: I tried this line as well. C:\Users\achilles\AppData\Local\Temp\procexp64.exe

 

I have to get some other work done now. I have been banging my head against the door long enough trying to allow applications to execute using Bouncer. I never had these problems in previous builds of Bouncer.

 

I think I just figured out what I was doing wrong. I was using the ParentWhitelist instead of the Whitelist. It was keeping me from allowing single executables. I just tried using the other whitelist, and I was able to allow Process Explorer now. I thought Parent Check was part of the whitelist at the top of the list. I think I see how it is suppose to be used now. The only thing I can't figure out now is why the ParentBlacklist keeps getting moved to the last line in the file when using the Admin Tool. I think I understand most of the things I was doing wrong now.

 

I'm able to allow by path now, but can't get the hashing to work. I just don't know how the hash is suppose to be written in the policy. It will be easy once there is documentation explaining the policy. I will roll back to a clean image tomorrow, and try again.

 

For anyone interested.
http://malwaretips.com/threads/excubits-bouncer-giveaway.50223/
"Bouncer Giveaway starts on August 31,2015 and ends on September 21,2015"

 

I'm glad you figured out the single executable blocking with whitelist/blacklist sections.

For hashing, it goes very similar:

Code:

[#LETHAL]
[LOGGING]
[SHA256]
[#PARENTCHECK]
[WHITELIST]
534530CF9E140BF637950070E3F9B73220A3AC2CC394CB8F9BA5003096E33583
534530CF9E140BF637950070E3F9B73220A3AC2CC394CB8F9BA5003096E33583
7765DBB2325AC29307271EBE715FB172A4BC3F7C098BA18F96DA7675BE3689A4
[BLACKLIST]
852582CC88B5209CEF053E7514135EEB67662B7597C48FC1E9140DE56196CD09
[PARENTWHITELIST]
[PARENTBLACKLIST]
[EOF]

The SHA256 hashes just go within the normal whitelist/blacklist sections. I can't confirm at the moment if hashes can be used with parent process or not because I haven't tried it and my experience with parent process is still limited.

I am still trying to reproduce the moving [PARENTBLACKLIST] line within the config. But unfortunately, I have not been able to reproduce it yet. I tried quite a bit of things last night but no luck.

Here is the expected config file format (proper order) that the kernel driver is expecting:

Code:

[LETHAL]
[LOGGING]
[SHA256]
[PARENTCHECK]
[WHITELIST]
[BLACKLIST]
[PARENTWHITELIST]
[PARENTBLACKLIST]
[EOF]

I will try to reproduce later today with Admin Tool and let you know if I can reproduce it.

 

Should one whitelist the C:\Sandbox folder if you use Sandboxie? I'm guessing no. I run Firefox in a Sandboxie sandbox and when I go a search for *.exe in the C:\Sandbox\Firefox folder it comes back with no results.

 

What is the difference in WHITELIST, and PARENTWHITELIST? Whistlisting a single executable with PARENTWHITELIST sure would not work for me. I tried by path, hash, and both.

 

Thank you so much for letting us know!

 

Sorry that I forgot to answer that question previously. I am not familiar with Sandboxie, unfortunately. But as you said, you searched that directory for executables and found none. You could also consider searching the C:\Sandboxie directory for *.sys and *.dll since Bouncer filters those as well. But I would assume that Sandboxie most likely has those within C:\Windows\System32\Drivers anyway.

The best thing would be to run Bouncer with logging enabled but lethal mode disabled [#LETHAL] for a day or so and test out Sandboxie with it. If anything shows up in the logs within C:\Sandboxie that would normally be blocked, then perhaps you can create some rules based on that. And if nothing shows as being potentially blocked within that directory then you do not need to create specific rules for that.

WHITELIST section is for single executables or also multiple executables, directories, etc. plus hashes. So the typical rules go in there.

PARENTWHITELIST is specifically only for parent process checking feature [PARENTCHECK], if that is enabled. Florian describes it better here: http://excubits.com/content/en/products_beta.html

Code:

parent_exe_path>child_exe_path

Such as:

Code:

C:\Program Files\Google\*>C:\Users\*

You can also get creative and reverse that if necessary:

Code:

C:\Users\*>C:\Program Files\Google\*

If you have [PARENTCHECK] feature disabled, such as [#PARENTCHECK] then the [PARENTWHITELIST] and [PARENTBLACKLIST] sections will not be utilized.

The regular [WHITELIST] and [BLACKLIST] sections can contain path-based rules, SHA256 hash rules, etc.

Any of those sections can utilize wild cards.

The only thing that I don't know yet is whether or not the parent whitelist/blacklist specific sections are able to use hashes or not. I just haven't tested that yet since I am not very familiar with parent process checking in general.

 

Thank you! The hashing is actually super easy to use then!

 

Thank you for your detailed explanation! I think that answered all the questions I currently have. I should be able to setup a good policy file now.

 

Thanks for the assistance WildByDesign! Would you mind reading my earlier post please as I had some further questiosns there ;-)

I couldn't stand it anymore so I installed the non-hashing (ie: stable) version of Bouncer on my machine and am running it in logging only mode (#LETHAL) (exciting stuff!). I've already noticed some files in the log file for my Skype sandbox but I will let it run in logging mode for a few days. Should be interesting.

The one thing I want to blacklist is flash. I run Windows 10 and have never installed ANY Flash on my machine and yes Secunia PSI scan shows its as installed (it doesn't show in Programs and Features). The path to the Flash files are:

Code:

C:\Windows\SysWOW64\Macromed\Flash

This will be a good blacklist test!

 

@ParaXY You're welcome, my pleasure.

For Flash, you can do something like this:

Code:

[BLACKLIST]
C:\Windows\System32\Macromed\Flash\*
C:\Windows\SysWOW64\Macromed\Flash\*

Alternatively, you could get creative and have some fun with wildcards:

Code:

[BLACKLIST]
*NPSWF??_??_?_?_???.dll
*FlashUtil*.*
*Flash.ocx

The good thing about Bouncer is that it will also block the .OCX ActiveX for Flash as well as the executables and DLLs. This can be done temporarily as well with Bouncer during times when Flash has active vulnerabilities being exploited in the wild while waiting for a fix from Adobe.

I will go back over the last page or so and catch up on your questions that I missed later tonight, for sure.

 

Thank you very much!

I decided not to install Flash/Java on my machine at all thats why I am surprised its installed. But I will blacklist it. This tool is amazing!!

So far the following is showing up in the bouncer.log:

Code:

***DEMO***: C:\Users\User\AppData\Local\Microsoft\OneDrive\17.3.5907.0716\amd64\FileSyncShell64.dll
***DEMO***: C:\Users\User\AppData\Local\Microsoft\OneDrive\17.3.5907.0716\amd64\msvcp120.dll
***DEMO***: C:\Users\USer\AppData\Local\Microsoft\OneDrive\17.3.5907.0716\amd64\msvcr120.dll
***DEMO***: C:\PROGRA~1\MICROS~1\Office15\GROOVEEX.DLL
***DEMO***: C:\PROGRA~1\MICROS~1\Office15\1033\GrooveIntlResource.dll

I'm more than happy to leave OneDrive blocked ;-) Not sure when the Groove ones are so those can probably stay blocked too.

 

@ParaXY You're welcome.

Windows 10 (and I believe Windows 8.x) have Flash installed by default within the operating system, integrated with IE/Edge. So in your case, if you want nothing to do with Flash, blocking it with Bouncer is a great idea.

Code:

[WHITELIST]
C:\Users\*\AppData\Local\Microsoft\OneDrive\*
C:\PROGRA~1\MICROS~1\Office15\*

EDIT:
OneDrive is built in for the syncing of system info. You can skip that if you want. But I would suggest that you add that rule for the Office blockage.

 

I think that is fair to be ultra paranoid and I respect that, as every user has different levels of paranoia and varying levels of trust. You are correct. A determined and sophisticated attacker could certainly do more personalized attacks such as that. If you are concerned about opening up several rules within Temp, you could go without those rules and simply just disable Bouncer during those brief moments for updates if you wish. There are several other options here as well:

You could go entirely hash-based with the SHA256 hashing. I mean, no path-based rules whatsoever, just hash rules. This would likely be the most secure of possibilities here. Every executable image type (.exe, .sys, .dll, .ocx, etc.) would all be hashed and compared to your whitelist. Keep in mind though, this would go over the limit of config size for the demo version. But this is one good option though. I ran entirely hash based for a full month during testing and it was incredibly solid.

Another option here would be to use the MZWriteScanner driver. You could configure this specifically to monitor sensitive areas such as Temp areas and so on. Any type of executable that is written to disk in the areas that you have configured will be hashed and logged, and if that executable tries to run, it will be blocked based on SHA256 hash. So any more vulnerable areas could be monitored with this driver with more scrutiny.

I understand what you mean with that and I agree, that's a fantastic idea.

I think that is a great idea. But one thing that we have to keep in mind here is that the more "convenience" built into any security software tool, the more likely it could contain vulnerabilities. However, I do like the idea. As a matter of fact, maybe there could be something like multiple profiles/configs and this could be part of that type of concept. So a user could choose an Installation/Upgrade type of profile/config which would be less restrictive and allow some execution temporarily within these known temp locations.

That is a really solid setup. Nice and light, good layers and covers all your bases.

I like this concept of organization as well. This, in particular, would be a great example to use the SHA256 hashing because these are your known good, trusted program installers/packages. Even if you stuck with a mostly path-based config, you could still use SHA256 hashing specifically for the contents and sub-directories within this D:\SoftwareLibrary location.

 

Really good point. I don't use Edge and have uninstaleld IE11 in Windows 10. I plan on deleting the Edge app (like I did with Cortana). Whats interesting is that while I am running Bouncer in logging mode I can see the flash.ocx file being accessed even with no browsers running...scary! So yes, this will definitely be blacklisted. I will do the same for OneDrive (delete app in safemode AND blacklist path)

Code:

 [WHITELIST]
C:\PROGRA~1\MICROS~1\Office15\*

Its interesting that this is being logged since this path is whitelisted? Do I need to add C:\PROGRA~1 to the whitelist as well?

That is an option but, in my opinion, not a good one? Which brings me to:

I'm still waiting for the final (non beta) version of Bouncer before trying the hashing feature but this is something I am very interested in. I'm not sure I fully understand the hashing option so a questions or two:

If I have a hash of (say) notepad.exe and the hash is 1234abcd and I whitelist this hash then only a file with this hash will run (in this case notepad.exe). Is this correct? Now lets say theres an update for notepad.exe, I'm assuming the hash will change? Does that mean you need to redo the whitelist rule?

Also, how does hashing work when you whitelist an entire folder? Does it has the folder contents? And the folder?

I thought MZWriteScanner just showed you what was being written to disk? I didn't realise you could get it to monitor certain folders? Or is this a beta feature? I didn't know it did hashing either!

I agree with what you are saying however, isn't it even MORE insecure to disable Bouncer altogether while doing installs/updates? The way I see it is in the admin tool you could have a button or rule which has defined temp folder locations that are needed for the install. You could enable it when needed and then after the install you could disable it. For the forgetful (like me) there could be timeout (say after 10min) where the temp rule is disabled and locked down again.

Great idea! I really need to give hashing a try. Does anyone have an ETA for stable version of Bouncer with this feature?

One more question about the Bouncer logging. If I have whitelisted C:\Windows then I know nothing will appear in the logfile for this folder. But if I blacklisted C:\Windows\system32\calc.exe, would this appear in the log?

In other words, do ALL blacklisted items get logged? Manually blacklisted and ones that aren't?

Sorry for long post but I appreciate all your help and input. I'm really enjoying bouncer and can see myself buying a lifetime license to this after fully testing the hashing version! I haven't even begun to look at MZWriteScanner, MemProtect or any other offerings.

 

The problem here is that Microsoft's own Office software, in some instances, uses the old DOS style 8.3 short file name convention. They don't use it entire, but just for a few of their DLLs, possibly legacy or something, I can't say for sure.
If you already give permission to Program Files:

Code:

[WHITELIST]
C:\Program Files\*
C:\Program Files (x86)\*

You could also add this into your whitelist as well:

Code:

[WHITELIST]
C:\PROGRA~1\*
C:\PROGRA~2\*

This will prevent old legacy type of program errors. But since this will be few and far between, you could just keep it specific:

Code:

[WHITELIST]
C:\PROGRA~1\MICROS~1\Office1?\*

I will have to catch up on the other questions later in the day as I have more time.

 

Correct, any update to a program will result in a new hash. That updated hash needs to be added to the whitelist.

The Bouncer driver has had a stable and efficient hashing functionality (at least internal builds) for several years now and is a rock solid hashing solution. The Admin Tool, however, is lacking with regard to helping to create hashes in the whitelist/blacklist. Currently, the Admin Tool can only hash one file at a time. That is actually great as far as simple updates go. But of course, when it comes to the initial hashing of an entire system/partition, that alone does not cut it. There are programs such as HashMyFolders (http://www.nirsoft.net/utils/hash_my_files.html) which make it easy to get a list of hashes for an entire folder and sub folders. Also, personalized scripting can be done with free command line tools like OpenSSL and also Sigcheck (https://technet.microsoft.com/en-ca/sysinternals/bb897441.aspx) from Sysinternals. Personally, I use a script created for Sigcheck to do the initial hashing of the entire system which takes maybe 10 minutes, depending on system hardware and so on. After that, it's easy to update hashes after program updates.

If there is enough interest in Bouncer (and SHA256 hashing feature in particular), then the developer may create a much better built-in hashing program and database of some sort. He's got the skills to do so, it's just more the time which he lacks.

Personally, I have suggested the idea of some sort of combination between Bouncer and MZWriteScanner to the developer for assisting with the hashing database. Since MZWriteScanner already logs and keeps a list of hashes within the kernel, that could somehow be passed along to Bouncer (or some sort of database) and the user can be the one to decide which of those are safe and which may not be. The safe hashes could then be utilized by Bouncer. Anyway, that is just one thought and idea at the moment. But before he puts several weeks of development into such a feature, he wants to ensure that users have enough interest in the SHA256 hashing feature. If he put the development time and money into it, and let's say it ended up being a flop and nobody was interested, then it would be a significant amount of wasted time and money. So he is trying to play it careful and smart. If there's interest, it will happen. I see a lot of potential there.

Correct, the current stable release of MZWriteScanner just shows what is written to disk. It is the beta release that has the SHA256 hashing feature built in along with the whitelisting/blacklisting capabilities of Bouncer as well. The hashes are logged within the kernel and if those programs are executed, such as drive by download, they would be blocked based on hash.

Actually I agree with you 100% here, it does sound like your idea makes the most amount of sense and really is a great idea. I can talk with the developer about this because I do like the idea. Although it may be more involved then either of us are thinking at the moment, since different installers/updates of different programs from varying software companies use many different folder naming schemes and so on. But it's certainly possible and I imagine that, together as a community, we could share these types of known paths and get those built into the program somehow.

Realistically, I would guess about 3-4 weeks. That is just a guess though. I am personally quite confident about the stability of the beta drivers and tools. It is mostly the documentation that is slowing release down since it takes away from development time. He would likely release as stable right now if the documentation were complete, but he doesn't want to release widely with incomplete documentation. I can ask him to clarify if he has any estimate on release time frame and I will update here if I find out.

Yes, that is correct.

Indeed, yes. Bouncer will essentially log any blocked events. Or in the case of logging-enabled, lethal-disabled, Bouncer will log exactly what would be blocked if lethal (blocking mode) was enabled. That is why it's always a great idea for anyone to run it for a few days in that mode before enabling the blocking because Bouncer is extremely low level and a bad config could cause problems. Several key points for me to point out: By design, Bouncer automatically blocks anything that is not specifically whitelisted. So you only really need to blacklist things which are within an already whitelisted area. Another point to make is that blacklist always overrules/takes priority over the whitelist. For example, if you whitelisted the same executable and blacklisted as well, blacklist will always take priority and overrule.