Bouncer (previously Tuersteher Light)

LOL @WildByDesign ... most of the memory exploit stuff - like the stack, tables, ROP, etc - I know very little.

What I meant by "more comprehensive protection" is that MemProtect is not limited to one specific mode of protection. Instead, it will do as the rules specify it to do within its capabilities. AppGuard has "side-by-side" memory protection as opposed to parent > child process memory protection (because this breaks a lot of applications).

Looking back at @Windows_Security 's test of MemProtect against SurfRight's Exploit Test Tool - it appears that MemProtect is quite capable. Of course, there could be something else going on - so I wouldn't rely upon any explanations as to the results except those by the respective soft developers - namely Florian and Erik\Mark.

I'm a bit perplexed as to why\how MemProtect blocked the Webcam and Sound Recorder access - since those are not exploits in the tool.

I haven't looked at it closely, but I am thinking MemProtect just blocked the execution of calc.exe - and not the "exploit" itself. As you point out, it is difficult to know without an in-depth understanding of and access to under-the-hood mechanics. I suppose MemProtect logs would help to clarify matters. Plus it would be nice to have access to someone who could explain it in detail.

Perhaps this would be a good one to take directly to Florian. He's the developer. If anyone, can definitively explain, then it is him. If you do take it to him directly, maybe he will consider writing something about MemProtect's anti-exploit capabilities on his blog.

 

On top of mentioning it explicitely in the post, I also put on the visual How can you miss that? LOL

 

Move too fast, miss things... LOL.

Thanks @Windows_Security for pointing out my inattention.

About 100 of us missed Blue Right Networks instead of Blue Ridge Networks for over a month at MT forum...

 

OK I see. I use anti-exe + HIPS for this. You could also use anti-exploit + HIPS.

 

I tried Spyshelter 10.6.1 months ago, but there were some GUI-bugs. But i think i'll try a newer version in the next time.
Then i can learn something new

 

Yes exactly, that was also my understanding, that's why I didn't understand why member Windows_Security was so excited about it, anti-exe can do the same.

I believe code injection into child processes should always be monitored. Malware can simply start up the browser or explorer.exe and inject code into them, as seen in various leaktests. Same goes for protection against process hollowing, this also involves the monitoring of child process modification.

 

NO that is not only the reason why it passes those tests and YES even more exited about it. Just Google on protected processes feature. Do some testing and you probably be exited too.

 

I think what impressed me the most about MemProtect is the fact that it weighs in at 25-28KB depending on system architecture.

But what came to my mind just now is, what if malware were to utilize something like MemProtect? That would be a scary thought. Obviously it would require an exploit to achieve Admin privileges, but it would certainly be small enough to integrate.

As Kees had mentioned, the underlying specifications for Protected Processes were a very interesting read. Starting with Vista, but particularly with Windows 8.1 and 10, protected processes evolved with each platform. I know that there has been some recent discussion about whether MemProtect should be Default Deny or Default Allow, so that is something that I would like to talk with Florian about in the near future and see his thoughts and also see if there is a possibility to program MemProtect so that the user can choose between Default Deny and Default Allow depending on the users' individual needs and setup.

 

I think default-deny is easier to manage; requires much smaller rule-set.

 

The underlying kenel mechanism is opt-in. Therefore block mode and behavioral mode like SmartObjectBlocker woud be nice

 

Yes, this "small thing" is powerful. If you subtract the digital signature, the driver itself is even smaller (under 20KB?)

It only requires a small rule-set if you add *>* in your whitelist. But without it, you have a lot of entries.
In an earlier beta i had 10KB (without *>* in the whitelist, only c:\windows\*>*), now i have 2KB

And It depends, what you want to do.
Sure, if you only blacklist+whitelist vulnerable apps then it can be a small rule-set.
Without allowing all (*>*), but with c:\windows\*>* and adding each Program Files/-Directory I can "restrict" each application in it's own directory. Then it's a large rule-set but with a better protection.
At the moment it's not possible with this tiny 2kb-limit

 

I've read about it, but like I said this feature is not meant to block exploits/shellcode from running. It is meant to protect a process from code injection attacks. So it doesn't explain why MemProtect was able to pass the exploit tool.

http://blog.wisefaq.com/2015/11/19/passing-the-hash-protection-runasppl-and-breaking-windows-10/

 

It is meant to protect the memory marked as executable only to be changed by code which has a specific signature. So it prevents exploits injecting code among others. This explains why it passes HPMAlert tests.

This is also mentioned in link you posted, so I guess you missed that (and probably the reason you don't understand why MemProtect passes the HPMA-tests).

Advice: why don't you install and throw some tests at memprotect.

 

If that's the case then that is disappointing. I wonder if AG memory protection allows parents to modify child's memory to avoid conflict, and so applications can update while in Protected Mode/Medium Mode. I think Excubits MemProtect will be more effective than AG's memory protection. I use MBAE, but I would like to use MemProtect also.

 

BRN said that parent > child memory modification blocking breaks too many applications. In some future version of AG they might implement something, but not now.

 

You need an ELAM enabled driver to use protected processes. When malware is capable of installing a driver then it is game over any way.

The excitement is that a 25kb driver using OS features build in the kernel provides as much memory protection as say HPMA which needs 5MB code to accomplish this.

Look at the visual: after Memprotect driver is started (see the allow rule in Spyshelter), the protected processes feature of Windows (which is enabled with MemProtect) blocks DLL injections and Memory modifications, just like Microsoft promised Spyshelter does not kick in to block the HPMAlert tests anymore (because Windows OS blocks it in the kernel). Pretty cool to enable such strong mitigations with such a small program like MemProtect.

 

I'm protecting Firefox with MemProtect, and with a high probability the Crashreporter is shown after exiting Firefox. It doesn't matter what version - Firefox 43,44,45, portable, ...

With an old beta of MemProtect (August 2015) it happened every time (100%)
With this new MemProtect beta with a probability of "only" 40-60%.

I used normal rules, nothing special:

Spoiler: MemProtect - Firefox

[WHITELIST]
!C:\Program*\*Firefox\*>c:\Program*\*Firefox\*
*>*
[BLACKLIST]
c:\Program*\*Firefox\*>*

Is anybody protecting Firefox with MemProtect and has this problem too?

 

Testing won't help me to understand how it blocks exploits. I wonder if the developer can chime in?

What's mentioned in the link hasn't got anything to do with blocking exploits.

You seem to be misunderstanding. HMPA blocks both exploits and payloads. Bouncer/MemProtect only blocks the payload. Based on what I've read, the only reason why it passed the HMPA Test Tool is because either MemProtect denied it from reading memory, or it's able to block process execution.

 

Wait a minute, so MemProtect blocks the HMPA Test Tool from injecting code into the exploited process? Doesn't this already explain why MemProtect passes the test? This is not a valid way of exploit testing. The HMPA Test Tool needs access to a process in order to simulate the remote code execution attack.

 

@Rasheed187 Again, do some testing yourself

 

Has anyone done a succesfull Windows update by just allowing Windows and Program Files?

I tried and it deadlocked the PC. I urge Florian to set the default to OPT-in (in stead of default deny).

 

I tried to replicate this issue by using your posted config in lethal along with Firefox 45.0.1 (installed) regular x86 build on 64-bit Windows.

I received consistent logging for blockages for Explorer:

Code:

C:\Program Files (x86)\Mozilla Firefox\firefox.exe > C:\Windows\explorer.exe

But surprisingly caused no issues or crashes. I tried regular browsing along with opening and closing Firefox approximately 40 times. No crashes yet.

The only time where I experienced some sort of lock up of Firefox, but not complete browser crash, was when clearing history/cache with the logging relating to Flash (likely clearing Flash data).

Code:

C:\Program Files (x86)\Mozilla Firefox\plugin-container.exe > C:\Windows\SysWOW64\Macromed\Flash\FlashPlayerPlugin_21_0_0_182.exe

Do you have Firefox configured to automatically clear history/cache upon closing Firefox?

Is your MemProtect log showing any blockages around the time of these crashes?

If the Flash executable is causing your crash, try the config below. You don't necessarily need the Explorer rule since it doesn't appear to be causing the crash, but maybe worth trying to help troubleshoot the issue. Please let me know if you have any logging activity for anything being blocked.

Spoiler: MemProtect.ini

Code:

[LETHAL]
[LOGGING]
[WHITELIST]
!C:\Program*\*Firefox\*>c:\Program*\*Firefox\*
!C:\Program*\*Firefox\*>C:\Windows\Sys*\Macromed\Flash\FlashPlayerPlugin_??_?_?_???.exe
!C:\Program*\*Firefox\*>C:\Windows\explorer.exe
*>*
[BLACKLIST]
c:\Program*\*Firefox\*>*
[EOF]

 

Well, @Rasheed187 yes this is what MemProtect does. It blocks attempts of (malicious) processes to gain access on them. So it can effectivley block an exploit. What else should MemProtect do? This is, what is described on Florian's blog, so I do not see/share your concerns.

Regarding "HMPA blocks both exploits and payloads": Well, they _also_ must do something to detect that a (foreign) process access some other process or that a process turns amok and gets internally exploited, they are not the inventor of snake oil, they are just yet another company claiming to have *the* best antoi exploit technology (like so many other IT sec companies). Usually this is done by implementing massive API-hooking technology. Most solutions I saw just hook on typical win32 APIs and then detect that an exploited process does calls to suspicious API calls. Or they do stack and heap checks all the time and can detect that a ROP chain is currently onworking.

So at the end HMPA just _reacts_ on suspicious behavior and then warns the user (or decides to block such attempts). I really do not see the *real* benefit here. By the way: There are exploits that can bypass such protection technolgy, do not feel too safe with an anti-exploit tool, because it is not! Like with anti-vm detection, HMPA can also be detected by a smart exploits and trust me, hackers move around.

You are right if an app gets exploited internally and does not try to escape by dropping an exe or injecting into another process, MemProtect cannot detect such attacks. Hey man, this is not they way 99% of exploits work today. They always try to get persitant, they download a dropper, then start that dropper or inject an executable/dll into another process and this is where MemProtect perfectly turn in.

What you are talking about all the time are very special *targeted* exploits that hit just one app and stay there while the app is running (by the way: if you are an attacker and harvest an app with exploit you cannot be sure that the exploited app will work anymore, most apps just crash and this is why attackers often get out of the harvested/exploited app as they can, so they inject into other app or start dropped executable). That is not mainstream and intelligence service related attack - not the ordinary spyware, ransomware or trojan software, ordinary people get exploited. If we are talking about such targeted exploits I am sure that such attackers will also spend the time to bypass HMPA! That is for sure! So, for the scenario you are debating here with regards to HMPA I would suggest to use EMET and not HMPA

 

Great reply . I have used the real world analogy that you don't need to remove a car's wheels, steer, battery, distribution cap, sparks, fuel pomp, timing belt, etc to stop a car from driving (one will do). For an exploit to succesfully survice reboot it has to pass a few critical threat gates. It needs to pass all to be succesfull.

HPMA fanboys claim that features matter, so MemProtect 'only using one OS feature' and WinAntiRansomware and MBAE, EMET not having that much advanced features, automatically implies HPMA provides superior protection. IMO there is elegance in simplicity and results matter (not features).

 

(My underlining added.) Two very key points there; short, sweet and to the point. End results are of great importance, as is simplicity and efficiency of hardware resources.