Malwarebytes Anti-Exploit

Making a reliable exploit that can bypass /GS, SEHOP, DEP and ASLR without info leak is still not very trivial...

 

how are you guys getting chrome in a appcontainer?

 

https://twitter.com/tiraniddo/status/692485455208660995

Yes it's a Twitter post. But it's also an official one from a Google Project Zero security researcher.

 

thanks, trying it out now.

I suppose my feeling is appcontainer will make it harder to exploit the OS from the browser, but if the dll injection from stuff like HMPA stops working then the flipside is it may become easier to exploit the browser itself.

Now most processes are appcontainer, one extension crashes but from what I can see the rest (over 15) all are working.

 

Yes I know what you mean, but what I meant is that image viewers are more likely to be attacked than other type of apps.

 

From what I can see HMPA is still functioning on appcontainer processes, not only do I see the dll attached but it also has active cpu usage same as untrusted processes had.

 

I had something weird happen...I installed Shade (similar to sandboxie) and I tried bookmarking a site by dragging it to the bookmarks bar (when I click the star to bookmark MBAE is quiet) forgetting I was in shade's sandbox and MBAE kills chrome and gives me this alert.

Dragging a bookmark triggers it

 

IMO you shouldn't leave Sandboxie aside. You already know it is best of its own kind. If you are having issues then try a Windows reinstall, from scratch and give it a chance once again. I know it's a major pita but Sandboxie's worth the pain.

 

Hey Mister X, I hope all is well...I am using shade on another PC. I will NEVER stop using sandboxie

 

Ah ok! Good to know. Me too, hope all is well there.
Good luck running tests with Shade.

 

Waiting on my dang activation key

 

Another strange trigger/conflict with shade...I burned a movie and when autoplay opens and I click to open the movie in mpc-hc, MBAE gives me this alert...

 

Hello Overkill:

Please consider carefully reading [README FIRST] >>> Posts here need to include MBAE logs <<< and then opening your own topic within the MBAE developer's website in the Anti-Exploit Product Support sub-forum attaching all requested data and archives.

Thank you.

 

https://www.malwarebytes.org/support/releasehistory/

http://downloads.malwarebytes.org/file/mbae

 

I run MBAE Premium & have it set to download updates automatically. It has never done so. Ergo, each & every update must be done manually by me -- when I *happen* to hear of its existence.

Worse yet, MBAE has NO provision to "check for updates."

MalwareBytes has never notified me of updates to MBAE. It's not right that I have to consult Wilders in order to be aware of updates. I am a long-time MBAE user/supporter, but this sort of administrative glitch in an otherwise splendid program is making Hitman Alert look increasingly attractive.

@ anon - Many many thanks for the heads-up. I have updated manually (as usual).

 

You are not the only one. I don't think they have an update feature. MINE NEVER DOES EITHER

 

Maybe I am in the wrong thread or anon had more in his coffee today but his link goes to MBAM not antiexploit.
https://www.malwarebytes.org/support/releasehistory/

 

1) MBAE typically waits about a week before pushing-through a new update. This allows a smaller group of users to "test" what they believe to be a bug-free release. Anyone who wishes to manually download and "play" with it during that first week may do so. After about a week --- if you haven't manually downloaded --- you will then be advised of the new version, and depending on your settings, either have it automatically installed, or await your approval.

2) The history link given is to MalwareBytes PRODUCTS. Yes, it starts with MBAM... but if you scroll down, you'll see it also includes MBAE.

 

AH OLD TIMERS AGAIN

 

Same, here.

 

Don't beat yourself up, old timer.

It's a stupid design, and not singling out Malwarebytes here, typically "modern" and "mobile friendly" - vast expanses of nothing and the very minimum of detail presented in large fonts. Ooooooh, pretty. And you get to use your scroll wheel! Because if you're not thumb swiping/tapping the Web on a toaster pastry sized vertical screen (looking for info on primarily desktop/laptop apps, no less), you're just not Modern. Got a 1920x1080 monitor? You dinosaur. Why do you think mammals evolved a thumb?

And is it necessary to list on the same screen 26 items for MBAM releases going back over six years??

Yeah, that would be a nice feature. And/or an option for a tray notification. Maybe those are on pbust's to-do list.

Anyhow IMHO, MBAE Premium is the best anti-exploit on the market and I just renewed my license for another year. But having been whacked too many times by automatic updates since some one thought that was a good idea ~20 years ago, if I have an app where it can be disabled, it gets disabled. (As well, that feature is involved when considering a purchase.) Then I just pay extra attention to the news for releases. Even if that means checking in on Wilders.

 

BTW I found out about MBAE not being able to inject its DLL in an AppContainer process.

See Windows Sandbox thread. I will do a recap so you don't have to go through every thing. A new Windows mitigation (win 8.1 and 10) does not allow code injections (ProcessDynamicCodePolicy). This is not a watertight DLL block, because still 2 means of injecting DLL exists (obviously one of them is used by HPMA).

Chrome will facilitate site-isolation soon (available as experimental switch), Chrome is also nearly ready for Control Flow Guard (link), on top of that it applies all new Windows Mitigations (e.g. ProcessSystemCallDisablePolicy is Win32k lockdown) and facilitates AppContainer, so injecting a DLL (in an AppContainer proces) now is only a marketing gig.

You can use MBAE happily for Chrome Broker process (Medium IL) with MBAE. I can understand that MBAE representatives are not answering, since you need a lot of info and reading to understand the validity of NOT injecting the AppContainer Chrome processes. In the end you are better of with MBAE (only protecting broker) than HPMA (injecting in every process and increasing the attack surface, hence weakening Chrome's build in protecting against exploits). -------

Mind you that all exploits Poc attack the Medium IL broker and there is no PoC breaking out of the LOW IL Sandbox (remember my critism of the MRG synthetic tests), so with the new protection mechanisms in place chances of those sandboxed processes being exploited only reduce further.

EDIT: changed/removed remarks which triggered ErikLoman to respond

 

ok I understand now, it has the option to upgrade to newer version but sounds like that don't happen until a week after the release. instead up upgrading from the links here, I will wait to see how long it takes next time
if you loo at my sig I could be called overkill 2
as long as I keep quietzone enabled, even if I were to get infected, after reboot all is gone supposedly.

 

I'll bring you up to speed...

A sandbox processes starts as a regular process. But once it has set up it drops its integrity level. If the process would start at eg. untrusted integrity level it would not even be able to load kernel32.dll or setup a channel to the controlling process that manages the sandbox.

So a sandbox process starts as a regular process and then drops its rights.
If you inject after it has dropped its rights you are too late as it is prevented by Windows.

HMPA injects slightly earlier into a process (when the rights have not yet been dropped). You see it as marketing, we see it merely as a technical thing to stay compatible with other security products. If you can see who is injecting you can see who placed a hook in a process; was it a security product or potential malware? That is why we came up with a way to inject earlier: for compatibility. Nothing more, nothing less. Its was added to Alert 2.6 in 2013. Nothing has changed since in terms of the actual injection.

I agree with you that a security product can increase the attack surface. Everything you add increases attack surface, even video driver DLLs.
HMPA is compiled with CFG since November 2015 (since Visual Studio added support for it). I wonder how much other security products compile their injected DLLs with it (you can check with ProcessHacker). CFG is only useful if all DLLs in a process have it enabled. If a DLL isn't compiled with CFG it becomes the weakest link. Similar to a DLL that has no ASLR support, it makes the process vulnerable.

Regarding sandboxes, they aren't bulletproof. They raise the bar, just as anti-exploit, but in a different way. A sandbox weakness is that they have to communicate via a broker to do anything meaningful. Hacking team got around the Chrome sandbox for quite a while until they got exposed.
http://arstechnica.com/security/201...y-potent-enough-to-infect-actual-chrome-user/

The fact that no public exploit exists, doesn't mean there is no escape. Isn't this the case for all zero-days?