AppGuard 4.x 32/64 Bit - Releases

AppGuard dialog warning AppGuard stop suspicious spframe.
07/09/15 17:22:31 Prevented process <spframe.dll | C:\Windows\System32\rundll32.exe> from launching from <c:\users\bjms\desktop>.
Either I'm traveling in different circles or removing Publishers did something. Interesting.

Update: 07/09/15 19:03:06 Prevented process <hpsfupdater.exe | c:\windows\system32\svchost.exe> from launching from <c:\programdata\hewlett-packard\hp support framework\resources\updater7>.

Months of Lockdown and not a peep. I've changed or something changed.

 

I've got customize and variations on customize...
let me clarify what I've posted not what you should do

I have what I've been told by BRN with regard to Sandboxie and HitmanPro.Alert
Above that I've added just to see hmpalert as Power and I've removed Publishers except BRN
BRN does not have recommends for HitmanPro.Alert as they do not run HMPA in house.
BRN is guessing for HMPA
We can discuss via conversation.
I'm hesitant do post settings I cannot substantiate.
I have what others say and variations.
Bottom line: I may be playing with too many toys.
I've posted over at HMPA my cryptoguard tests.

 

The manual was only talking about the Publisher's List in that section so the data is correct. Maybe they could go ahead, and explain in that section that any signed executable will be allowed to execute with limited rights in the user-space to make it easier for the user to see the overall picture of how AG handles signed executables.

 

Does anyone think doing away with Power Apps, and using hashing instead would be feasible? Would it facilitate everything that the Power Apps feature does? I think it would. It seems like it would be simpler, and easier for users to understand. A good example is Process Explorer. I run Process Explorer from the Programs Files (x86) folders. I have to make it a Power App to allow processexp64.exe to spawn in the Appdata Folder. I could just allow this process by hash instead if AG supported hashing. Hashing would give greater control over what is allowed to spawn from any executable. This would work out really well if you needed to make a special exception for a web app that needs to spawn an executable in the user-space. You could allow only the executable needed by the web app without compromising security. Power Apps do not facilitate this needed functionality. You should never make a web app a Power App, but one could easily allow needed executables to spawn in the user-space using hashing.

 

Attempt to open zip again...
07/10/15 17:29:03 Protection level is set to <locked down>.
07/10/15 17:28:23 Protection level is set to <off>.
07/10/15 17:27:54 Prevented process <combase.dll | C:\Windows\System32\rundll32.exe> from launching from <c:\sandbox\bjms\firefox\drive\c\windows\system32>.
07/10/15 17:27:54 Prevented process <shlwapi.dll | C:\Windows\System32\rundll32.exe> from launching from <c:\sandbox\bjms\firefox\drive\c\windows\system32>.
07/10/15 17:27:54 Prevented process <imagehlp.dll | C:\Windows\System32\rundll32.exe> from launching from <c:\sandbox\bjms\firefox\drive\c\windows\system32>.
07/10/15 17:27:54 Prevented process <msvcrt.dll | C:\Windows\System32\rundll32.exe> from launching from <c:\sandbox\bjms\firefox\drive\c\windows\system32>.
07/10/15 17:27:54 Prevented process <user32.dll | C:\Windows\System32\rundll32.exe> from launching from <c:\sandbox\bjms\firefox\drive\c\windows\system32>.
07/10/15 17:27:54 Prevented process <hmpalert.dll | C:\Windows\System32\rundll32.exe> from launching from <c:\sandbox\bjms\firefox\drive\c\windows\system32>.
07/10/15 17:26:37 Protection level is set to <locked down>.
07/10/15 17:24:52 Protection level is set to <install>.
07/10/15 17:24:50 Prevented process <combase.dll | C:\Windows\System32\rundll32.exe> from launching from <c:\sandbox\bjms\firefox\drive\c\windows\system32>.
07/10/15 17:24:50 Prevented process <shlwapi.dll | C:\Windows\System32\rundll32.exe> from launching from <c:\sandbox\bjms\firefox\drive\c\windows\system32>.
07/10/15 17:24:50 Prevented process <imagehlp.dll | C:\Windows\System32\rundll32.exe> from launching from <c:\sandbox\bjms\firefox\drive\c\windows\system32>.
07/10/15 17:24:50 Prevented process <msvcrt.dll | C:\Windows\System32\rundll32.exe> from launching from <c:\sandbox\bjms\firefox\drive\c\windows\system32>.
07/10/15 17:24:50 Prevented process <user32.dll | C:\Windows\System32\rundll32.exe> from launching from <c:\sandbox\bjms\firefox\drive\c\windows\system32>.
07/10/15 17:24:50 Prevented process <hmpalert.dll | C:\Windows\System32\rundll32.exe> from launching from <c:\sandbox\bjms\firefox\drive\c\windows\system32>.
07/10/15 17:24:19 Prevented process <combase.dll | C:\Windows\System32\rundll32.exe> from launching from <c:\sandbox\bjms\firefox\drive\c\windows\system32>.
07/10/15 17:24:19 Prevented process <shlwapi.dll | C:\Windows\System32\rundll32.exe> from launching from <c:\sandbox\bjms\firefox\drive\c\windows\system32>.
07/10/15 17:24:19 Prevented process <imagehlp.dll | C:\Windows\System32\rundll32.exe> from launching from <c:\sandbox\bjms\firefox\drive\c\windows\system32>.

seems I can't reach app to open zip
any ideas... not even in the know what opens zip on W8.1

 

So, AG policy includes file attribute "signature". Does AG verify valid signature each launch or just one time presence of a (generic) signature. I mean is there a cache somewhere or each launch is a new event.
RE: Power App....so, the caveat only security program to be added and only if....is not enough...? Just asking.

 

I don't know what you mean by file attribute signature. AG verifies valid signatures each launch, and anytime a file attempts to execute AFAIK. I think that question would have to be answered by BRN. I don't know if AG has a cache of it's own.

 

I meant files have attributes .. one being signature.
How does AG verify....signature as valid current or what ever..?
OK...posted here. We'll see BRN reply.

 

AG has the digital signatures for files that are on the Publisher's List. If a file attempts to execute in the user-space in Medium Protection Mode then AG simply checks for the presence of a valid digital signature AFAIK.

 

I don't think it builds a cache of digital signatues for files in the user-space if that is what you are asking, but you would have to ask BRN to be sure.

 

Oh, I misunderstood thinking AG checks all signatures not just publishers.
So, publisher signature would have to be checked against some data somewhere...?
Haven't has much joy reaching BRN of late. May be vacation times.
I'll list my questions and send em' off again. Thanks

 

Would it compromise security to add c:\sandbox\bjms\firefox\drive\c\windows\system32 as include=no under User Space?

 

BRN tells me = Yes
I can only add c:\sandbox

 

AppGuard does not permit all digitally signed installers (msi, msps) from running in Medium level - only those that have Install setting to "Allow" in the publishers list. In medium, AppGuard permits all digitally signed executables (exes, dlls) to launch after validating that the signature is valid (using Microsoft Crypt APIs).

In Medium AppGuard chooses to white-list all digitally signed applications. In this case AppGuard is permitting them to run, but containing them so that they cannot alter the system or read/write the memory of other running applications. If you prefer a more restrictive policy you can always use Locked Down.

BTW, in Medium level, AppGuard stops all of these attacks without any policy tweaking - some with stolen certificates!:



If you want to see AppGuard vs. these malware, you can participate in a webinar. Email AppGuard@BlueRidge.com and we can let you know of upcoming demos.

 

In medium, AppGuard permits all digitally signed executables (not msi, msp) to run in User-space. In that case when an executable tries to launch from user-space, the signature trust chain is validated (using Microsoft Crypt APIs) and if it is valid AppGuard permits it to run. Unless there is a publisher policy that says otherwise for that digital cert, AppGuard Guards the running process so that it cannot alter the OS or read/write the memory of other processes.

 

One could do this (add c:\sandbox to userspace and then make exceptions as required to the subdirectories), but AppGuard's official recommendation is to make c:\sandbox an exception folder (on the Guarded Apps tab) and NOT to add c:\sandbox to user-space policy.

My recommendation is generally that if you make an exception for Guarded apps that you add the exception to user-space protection. This is best practice and works most (>90%) of the time, BUT Sandboxie is not following Microsoft’s best security guidelines and normal programming practices (for instance most apps only write to local app data folders and not to root folders and most apps don’t launch out of a root folder). I don’t mean to criticize Sandboxie, because security products often do have to deviate from the norm, but because Sandboxie is behaving outside the norm, adding it to AppGuard’s user-space protection is causing issues.

I hope that settles the Sandboxie/AppGuard settings and I hope my previous answers (as reported by bjm_) haven't confused everyone.

Edited Below:

Since, this post was quoted in the Sandboxie forum (thanks BJ_M), I want to post the reference for Microsoft's security practices that I am referring to. From (https://msdn.microsoft.com/en-us/windows/desktop/dn385721.aspx#windows_security_best_practices_test):

All app data exclusive to a specific user and not to be shared with other users of the computer must be stored in Users\<username>\AppData.

All app data that must be shared among users on the computer should be stored within ProgramData.
​

I also wanted to re-iterate that I don't mean to criticize Sandboxie - just trying to explain why it causes a problem for AppGuard's default policy.

 

We check against the CryptoStore on the OS.

 

We validate using Microsoft CryptoAPI.

 

Thank you for the info!

 

So, is c:\sandbox No better than Yes. Or, best practice (now) is not to add c:\sandbox to User Space..?
Not to belabor. I have quotes: when you add to Exception then add the same to User Space Yes.
So, if User Space re Sandboxie is now not suggested. Then c:\windows\cryptoguard added to User Space is also not suggested..? I have quote: telling me to add c:\windows\cryptoguard to User Space.

What's difference between Install Allow and Level Install

and Locked Down black-lists all digitally signed...?

Are Publisher settings for default Publishers. Just an example or BRN recommended for all added Publishers. I added a Publisher and settings were different from the default Publishers. Where did my added Publisher get it's settings.

 

Not sure what you're getting at. Best practice from AppGuard's perspective would be add any exception folder to user-space, but since that seems to break sandboxie (due to how sandboxie is implemented different than most applications), then it cannot be done without making additional sub-folder exclusions. Therefore for Sandboxie, you should make an exception to AppGuard Guarded Apps policy and not add it to user-space protection.

I think your question regarding Sandboxie has been answered sufficiently at this point: Add c:\sandbox as a Guarded Application exception folder. Do NOT add it as a user-space folder.

I'm sorry for steering you wrong initially (with our standard recommendation regarding exceptions/user-space and that it doesn't work for Sandboxie).

 

Sorry, I was still re-working my message. I had to study your clarification re Sandboxie.
Sandboxie is now understood as the odd man out. Thanks
So, I'll put c:\windows\cryptoguard back to User Space Yes because as of now we don't know for sure what to do..? and general Best Practice is User Space Yes. Even though AG warns c:\windows subdirectory not recommended to User Space.

and AppGuard is saying Sandboxie does the opposite of most apps...

Can you re-read #3396 and touch on my other questions.

 

I haven't used Sandboxie for a long time, but AG shows those file paths inside the sandbox, perhaps the SBIE users here know the explanation.

 

Does latest AppGuard 4.x work on Win 10 x64 Pro build 10166?

 

You can try adding CrytoGuard to user-space, but you MAY have the same issues as you did with Sandboxie. Blue Ridge cannot possibly determine what the settings are for all programs in the universe (especially if we want to continue to make AppGuard affordable to the mass market) and especially if the applications deviate from standard programming practices. CryptoGuard is also not following Microsoft rules because they are causing programs to write to c:\windows.

From the AppGuard Help Topic on Trusted Publishers (perhaps you could try reading the help in the future ):

• Install: Indicates whether user-space install files from this publisher are permitted.
• Level: Indicates whether AppGuard should automatically switch to the Install Protection Level when a user-space application from this publisher is executed.

In Locked Down only programs digitally signed by Microsoft are permitted to run from user-space.

Just an example. Probably should change this in the future.