AppGuard 4.x 32/64 Bit - Releases

Thanks Barb, for the update.

 

Your position on program signing is well known: you consider it worthless, but then you also refuse to dump Firefox for a safe browser.

The chance of running into a stolen certficate is lower than the fail rate of any Anti Virus. But I understand that for a man using two anti executables (NVT and AppGuard) and two virtualisation solutions (Shadow defender and Sandboxie) this risk is way to high. So lets agree to disagree on the added value.

Also when Blueridge considered program signing worthless why set allowing updates of the trusted signers list as the default.

@Barb_C any info?

 

its getting worse!!! a lot more companies are going from lifetime to yearly subs.

 

AG 4.4.6.1 installer is still signed with a SHA1 certificate. A SHA256 certificate is recommended nowadays and afaik Win10 does not show a file signed after Jan 1 2016 with SHA1 as valid.

 

SOLVED

SOLVED

Under C:\Windows\Downloaded Installations\ I found two sub-directories.
Each sub-directory was named weird kinda like a registry entry, with parenthesis letters and numbers.
Each of these two sub-directories contained just one file each, named AppGuard.msi
The files had time stamps one from Feb 2015 and the other was Aug 2014.
I deleted both directories, rebooted, checked AppGuard "about" and finally get v4.4.6.1 in the "about" box.
http://s31.postimg.org/z4tcretjv/finally_4461.jpg
I am at a loss to explain why this fixed my "about" discrepancy, but it did, go figure!

 

Nice catch!
I fully backup this observation, attention BRN please.

 

@Windows_Security

It is not as difficult to digitally sign files as one would think - and it doesn't require a stolen certificate; ways to do it are all over the dark web.

Plus, if I am not mistaken, there are ways to digitally sign a file without a certificate that will make some security softs accept it - because it depends upon how a security soft detects and treats certificates. I have heard that some security softs can be fooled into accepting bogus certificates.

I have never done any certificate tinkering, but instead just read the "how to" here and there. So, I have no practical experience with it.

@cruelsister knows about this topic much more than I.

As far as AppGuard, Protected mode is vulnerable to "certificate" bypass - if the certificate is from a vendor on the Trusted Publisher list.

In that case, the only thing protecting the user is:

1. Their computing habits involving download and install of unknown\untrusted files.
2. The probability that one would come across malware signed with a digital certificate on the Trusted Publisher list is low.

Fortunately for the vast majority of us, probability almost always seems to be in our favor...

 

why stole it when you can easily buy one from Comodo

for beginners' friendliness

 

Yes some software, but we are talking about AppGuard here, you need a valid cert to bypass it. So you have more chance trashing your car than Appguard being bypassed with a malware using a valid cert.

 

OK. Given the recent provocative video by @cruelsister , this is what can be said about AppGuard:

1. Protected mode is vulnerable to a "certificate" bypass, where the digital signature corresponds to one of the publishers on the AppGuard Trusted Publisher list.

I removed 2 and 3 until we can get official explanation from BRN...

4. Guarded protection does not block macros.

5. Dependent upon what the macro does, AppGuard might or might not block the actions of any malicious download - in both Protected and Lock Down modes.

6. Malicious macros can scan for data and transmit it - and neither Protected nor Lock Down modes will block it.

It's all bad ju-ju... .........

It all sounds terribly bad - dunnit ? All things considered, AppGuard is still one of the very best security solutions available.

There's just a few things BRN will have to evaluate...

* * * * *

Easy options to compensate:

• Unless you must, don't use Protected mode; Lock Down mode is stronger protection.
• Unless you must, don't enable macros (you won't unless you have a paid office suite).
• Disable services that you do not need.

 

Thanks for coming back to us - and on vacation no less

 

And you may also do whatever it is you AG guys do with regsvr.exe also. Just sayin'.

 

Regsvr32.exe is a Guarded App by default, but should be included in User Space (blocked)...

Plus, Regsvcs.exe and InstallUtil.exe (NET Framework).

 

I wrecked my car just the other day! Just sayin'!

 

Trying Locked Down mode now, with vulnerable processes added to User Space.

A block message like this:
06/28/16 13:18:57 Prevented process <csc.exe | c:\my portable applications\open hardware monitor\openhardwaremonitor\openhardwaremonitor.exe> from launching from <c:\windows\microsoft.net\framework64\v4.0.30319>.

Do I ignore this message (my Open Hardware Monitor widget seems to be working OK) - or is there a way to allow this instance of csc.exe ... ?

 

Ive had AppGuard installed for almost 3 yrs now. The only thing it ever blocks is itself or any other proggy I try to install. IMO AG is like Barny Fife.

Deputy Barney Fife: [reading] "There once was a deputy called Fife, who carried a gun and a knife. The gun was all dusty, the knife was all rusty, 'cause he never caught a crook in his life."

I think I am going to uninstall AG. My own paranoia combined with a superior intelligence is enough to keep me safe! lmfao!!!!!

 

@locoJoe

Why took it almost three years to figure that out, did you just recently became superior intelligent after crashing your car?

Sheldon of the Big Bang Theory television series is also a superior intellect and he can't drive a car either. So these two capabilities must be correlated. You are a blessed man, with superior intellect. I see you are like Sheldon trying to get grips on sarcasm and irony (that is why choose the nickname loco joe, while you obviously are not loco). Your avatar has a reference to the big bang theory also, the dog is producing a big bang so it seems. Am I posting with Sheldon himself (I thought he favored Linux)?

I have a driving license and not wrecked a car recently, so won't claim to have superior intellect.

 

@Windows_Security
lol Andy gave Barney along time (more than 3 yrs) to shape up.
lol The car wreck statement was sarcasm.

 

I wanted to make this post much sooner, but my internet has been out since my last post. We don't have internet here when it rains which is quit often. I have horrible ISP.

The literature on AG's .dll policy is not very clear. The way it is worded could also lead one to believe that .dlls are allowed to execute as long as their parent is signed with any digital signature, not just digital signatures on the Publisher's List. If that was actually the case then I think the RAT previously mentioned would be successful as long as it was signed with any valid digital signature. Cruel Sister tried some malware signed with a digital signature not on the Publisher's List a few months ago (i'm pretty sure the digital signature was not on the Publisher's List), and AG allowed the .exe, but blocked the .dll in Protected Mode. That should mean that AG only allows .dlls to execute if their parent is signed with a digital signature on the Publisher's List. I didn't see any mention of AG .dll policy in the current manual, but I have not read it all yet. Below is a snippet from an outdated AG manual. I think BRN needs to clarify their policy on .dll execution. Maybe they removed their .dll policy from the manual to prevent targeted attacks like the RAT.

I was thinking about the most likely method of delivery for the RAT. There are two likely methods that would be used, or three depending on how you look at it. The easiest, and cheapest would be to use Social Engineering to convince the target to willingly execute the malware. The target receives an email with a fake invoice, etc.. which they are fooled into opening. The Second would be by exploit where the user lands on an infected web page, or is using another web application with a vulnerability. The third would be a combination of Social Engineering, and using an exploit. The user receives an email with an infected pdf file, or word document using an unpatched vulnerability in the host application itself. Exploits take a lot of time to develop, and would most likely be used only on high priority targets. The more the exploit is used the greater the chance the exploit will be discovered.

 

From my understanding, any digitally signed file can be executed in User Space while running AG in Protected mode. However, they are run Guarded. So, in other words, I am of the understanding that digitally signed files - with any digital signature - can execute, but cannot install. Only with a digital signature from one of the Trusted Publishers can an install (with Admin privileges) be accomplished.

I agree -- the AG policy on *.dlls is not explicit. However, in the video AG generated a block notification for the unsigned *.dll - but it was still loaded.

It will be interesting how this all pans out...

 

I forgot to attach the Snippet I mentioned in my post above. I just attached it. It says the .dll will be Guarded if the Process that loaded it is Guarded. Anything ran from the user-space is Gaurded so .dlls should be Guarded as well.

edited

 

Well, if that is the case, then AG should not have blocked the unsigned *.dll - as shown in the video - according to the policy.

I suspect that the policy was applied correctly - as the *.dll was obviously loaded - but the *.dll block alert was a false positive (an alert when there should have been none = bug).

The RAT executable was digitally signed with a certificate from one of the default vendors on the Trusted Publisher's list. Which means Protected mode allowed it to execute with Admin privileges and the unsigned *.dll should not have generated any AG alert.

So, at least on the surface, there appears to be a bug involving the loading of unsigned *.dlls from User Space while in Protected mode.

* * * * *

The bottom line - which we all knew prior to all of this - is that Protected mode is vulnerable.

I don't see the rationale in deleting all the Trusted Publishers (I keep only Microsoft and BRN) - and trying to turn Protected into Lock Down mode; it just makes sense to always run in Lock Down mode.

 

Edge- Regarding methods to distribute the RAT, remember that things like this one are Governmental in creation and distribution, so they would never go the Script-Kiddie route by either using email or social engineering. The methods of distribution are much more insidious, to the extent that you may have one running on your system as you are reading this post and not know it.

Not that I want to darken your day, of course...

 

In the video, the signed RAT is run with Admin privileges because it was digitally signed with a certificate from a vendor on the Trusted Publisher's list - so it was run un-Guarded. Admin privileges\un-Guarded... you just know the outcome of that...

If it was signed with a certificate from a vendor not on the TP list, then the RAT would have run Guarded.

Avast was allowed to execute in Protected mode - because it was digitally signed - but not allowed to modify the registry - because it was executed Guarded. Same with the M$ file using an *.msi; it was blocked by Protected mode - even though signed, M$ is not set to Install in the Trusted Publisher's list. Only BRN installers are permitted to use *.msi installers using the default TP list.

I think the video revealed a bug - the update.dll should not have been blocked -- because the RAT was executed with Admin privileges and was digitally signed.

 

Theoretically the .dll should be run after starting the signed (+unguarded) executable.

...and i don't understand why they removed Locked Down from the GUI some time ago. It's only accessible via right-click on the tray-icon.
Better Protection = "harder" to reach