Bouncer (previously Tuersteher Light)

Although it would be difficult programming, I would absolutely love to see an interface similar to EMET. Particularly, a list of running processes (including Process ID) with the ability to select individual running processes to configure rules for. That would be nice. Although, of course, it would need all of the basic goodies too like step by step rule wizards and such.

I would be more than willing to donate my time to create some mock up designs along with design plans, ideas and brainstorming. But the problem is I don't have any actual coding abilities. I'll have to check in with Florian soon and see what some of the short-term plans are along with any long-term plans.

 

Well, it should be better looking than EMET.

But yes please do so, it's always fun to see GUI designs.

 

First step would be to facilitate environment variables.

 

I've just done some more testing with MemProtect this morning. This time I've done my MemProtect testing with Process Explorer instead of Process Hacker, since I'm sure more users are familiar with PE. This should work with either 32-bit or 64-bit systems.

MemProtect.ini

Code:

[LETHAL]
[LOGGING]
[WHITELIST]
C:\Windows\*>*
C:\Program Files\*>*
C:\Program Files (x86)\*>*
*procexp*.exe>C:\Windows\*
*procexp*.exe>C:\Program Files (x86)\*
*procexp*.exe>C:\Program Files\*
*procexp*.exe>*procexp*.exe
[BLACKLIST]
C:\TESTING\SpeedyFox\*>*
[EOF]

Testing Directory Structure:

C:\TESTING\
C:\TESTING\SpeedyFox\ (sandboxed directory)
C:\TESTING\Process Explorer\

So, as you can see, the only directory that has specifically been sandboxed in SpeedyFox. I used SpeedyFox again for testing because it's a rather simple, small, portable type of program.

You can run Process Explorer from other locations since we've specifically given the appropriate permissions for *procexp*.exe to run and access what it typically needs to access. However, do not run PE from within one of the directories in the WHITELIST section which has been given full access, such as Program Files, simply because based on this config, if PE were to be run from there it would be given even more access to the full system and you might potentially get different results.

Running Process Explorer, with or without Admin privileges, showed good results for what MemProtect is potential of doing. The following is just the minimal extent of the testing that I did this morning with MemProtect protecting SpeedyFox process from Process Explorer:

- view ASLR details, access denied
- kill or suspend process, access denied (even as Admin)
- Job objects, access denied
- Security related permissions, access denied to view or edit
- Change Owner for process, access denied to view or change owner
- Under Threads, access denied to both Stack and Module
- Access denied to individual thread permissions, kill or suspend threads

My skills and knowledge of Process Explorer are still quite limited, so I'm sure that there are more advanced ways in which users can test the protections of MemProtect. I just wanted to share something that users could hopefully reproduce with relative ease.

 

Chromium is the hardest metal on earth, with MemProtect even the Borg's assimilation attacks are futile

I run Chrome in AppContainer and have set a deny execute ACL on its download folder. I have isolated Chrome's with MemProtect of Excubits to protect chrome from the system and the system from chrome.

Whitelist is overruled by blacklist, Priority whitelist overrules blacklist

When something is wrong a default deny will dead lock your computer), therefore I use the allow all (*>*) in the whitelist. Chrome is protected from the system with the blacklist *>*chrome.exe and the system is protected from chrome with the blacklist *chrome.exe>* rule. By using priority whitelist rules (!), chrome is allowed to touch chrome and splwow64 (for printing) and explorer, audiodg, csrss, lsass and svchost are allowed to touch Chrome.

So when MemProtect does what it claims to do, then the sandbox enforced by Chrome can't be broken by vulnabilities in Chrome.

Code:

[LETHAL]
[#LOGGING]
[WHITELIST]
!C:\Windows\explorer.exe>*chrome.exe
!C:\Windows\System32\audiodg.exe>*chrome.exe
!C:\Windows\System32\csrss.exe>*chrome.exe
!C:\Windows\System32\lsass.exe>*chrome.exe
!C:\Windows\System32\svchost.exe>*chrome.exe
!C:\Program Files\Security\ProcessExplorer\procexp.exe>*chrome.exe
!C:\Program Files\Google\Chrome\Application\chrome.exe>*chrome.exe
!C:\Program Files\Google\Chrome\Application\chrome.exe>C:\Windows\splwow64.exe
*>*
[BLACKLIST]
*chrome.exe>*
*>*chrome.exe
[EOF]

When you want to copy this to your system, first run Memprotect with [#LETHAL] and [LOGGING]. Check whether your programs function properly, do a re-boot and check the MemProtect.txt log file in Windows folder. MemProtect is still Beta, so have an image copy for worst case scenario as backup.

I don't have other security programs running realtime, only using on demand ProcessExplorer (it is a good idea to give your security programs also priority access to chrome).

 

@Online_Sword and @WildByDesign

First futile assimilatation attempt: all HPMAlert exploits tests fail

I am unfamiliar with HPMA exploit test tool. Memprotect with above rules seems to block every exploit test of HPMA (as expected only Webcam and Keyboard test succeed). Could you also run a test, to be sure that MemProtect indeed protects against these attacks. Would be nice to have Memprotect as free alternative for HPMAlert (preventing exploits in Chrome) and Trusteer (preventing change attemps to Chrome).

 

Yes by MemProtect, that is what the HPMAlert test tool proves.

Windows own internal's Borg assimilation attempt is also futile

 

Thank you so much for helping me with the wildcards! I will try making some changes to some of my rules using your example. I was not sure how to do it, but after seeing your example I think it will work well. Your always a huge help in all things concerning Excubits!

 

I tested MemProtect against HMPA test tool about 5-6 months ago, and it passed all memory exploits on my Windows 7X64 Ultimate.

 

Thanks

5-6 months ago already? So you your nickname is correct: a cutting edge early adopter of innovation

 

Yep, that's the reason I chose my nickname lol I choose products that use innovative mitigation methods that should be able to mitigate threats from any source. I'm confident that Bouncer, MemProtect, and Pumpernickel working together would even prevent "Rare State Sponsored Malware" from infecting user's machines. It's only as limited as one's ability to write the rules. Bouncer, MemProtect, and Pumpernickel will be extremely effective in the right hands. The three working together actually work a lot like AppGuard which I have been using for a long time.

I really wanted to add MemProtect to my setup, but it's not compatible with Eset on my machines. It causes windows to hang, and I have to do a hard shutdown every time. There could possibly be something else on my machine that it's not compatible with, but I know it conflicts with Eset for sure. I tried using Whitlisting rules that allowed everything belonging to Eset in ProgramData, Program Files, and AppData. It did not work . I think it's protection would be "really good" if I could use it.

 

@Cutting_Edgetech Which version of ESET was giving you problems with MemProtect? I have been curious myself to reproduce that issue for you and to see, at the very least, if I can come up with some sort of rules within MemProtect that can help negate that conflict. I'm willing to give it a try in a VM anyway if you can point me toward a trial version of the conflicting ESET software.

One thing that I should note is that a lot of antivirus software actually utilize the underlying feature of MemProtect to protect their own executables and services. This was an underlying feature that Microsoft has built into the kernel. And so what Florian has done is simply extended that kernel feature to be configured to protect any program that the user desires.

 

Wouldn't it be better to add your other security programs to your whitelist, so that they have full access to the executable?

Like:
[WHITELIST]
!<Insert your security application here.exe>*

 

I didn't know that because i had "Show people's signatures with their messages" switched off.

Yes, for example if the protected process "goes rampage", consumes 100% CPU, or whatever... it can be quickly terminated via ProcessExplorer.

 

As told by wildbydesign Memprotect uses a Windows build in feature. That explain the tiny size of the Memprotect driver and the near zero CPU impact. Really smart program

 

Eset Smart Security Version 8, and 9. The system hang usually occurs after leaving the system idle for a while, or when accessing Eset settings. You may even try changing some of the default settings of Eset if you have trouble triggering the system hang, but just accessing the settings triggers it on my machine.

 

Thank you for the details. I will give it a try in a VM tonight or tomorrow morning and let you know if I come up with anything.

Now, just out of curiosity, did it (system hang) only happen in LETHAL mode? Do you recall if anything interesting showed up in the MemProtect log file?

 

I think it happened in nonlethal, and lethal mode. I already tried whitelisting everything belonging to Eset in Program Files, ProgramData, and AppData folders.

 

I don't get it, so how exactly is it blocking these exploits? Is it blocking the payload, or is it truly blocking the exploitation methods like MBAE and HMPA?

 

You would have to ask the developer. It works a lot like AppGuard's memory protection except AG's memory protection does not pass HMPA Test Tool. MemProtect does not allow Processes to read, or write to the memory of other processes. The user can edit the rules to suit their own needs.

 

AG use to not allow any processes to read, or write to the memory of other processes. Now AG only restricts Guarded Applications from reading, or writing to the memory of other processes. It would be interesting to see if older versions of AG would pass HMPA test Tool. Sorry for two post. I should have mentioned this in my prior post. I thought you would miss the edit if I added it.

 

I'm using Windows 7X64. Thank you for your help!

 

But if this is the case, then it probably blocks the HMPA test tool from reading the memory of the exploited process, and that's why exploits won't work. So unless I'm misunderstanding, MemProtect doesn't actually protect against remote code execution exploits.

 

If your browser is exploited then it should still contain the exploit to your browser. It should contain the exploit of any vulnerable application.

Edited 3/11 @ 7:47

 

I'm not sure if I understand it correctly, but you probably mean that it may block the exploited browser (or child process of the browser) from injecting code into other processes. This might be true, but this still doesn't mean it can block the exploit itself. Same goes for AG's Memory Guard, I remember a couple of years ago I had this huge discussion about this subject, because some member refused to understand this.