AppLocker Publisher Rule

I wonder one thing about AppLocker. It's Publisher rules use digital signature of an application. How can't malware has a signature to bypass publisher rule condition?

 

It can't IMO.

Ms had an option to bypass (so not a breach, but by design) AppLocker protection from a for instance a VB script. There is a patch for it, which users can install when they want. May be you heard about this, but as far as I know Applocker publisher rules are really solid.

 

Yeah, I've read about the patch in the WS forums. I've installed it before tormenting my PC with AL.

I guess these Public Rules must be as solid as the Hash Rules.

I've read what I could but no real info how these digital signatures are verified except a well known cryptographic approach of 2 keys: Public and Private.

If understood it correctly Applocker even don't need connection to some database via the Internet to check the validity of a digital signature.

All accessible info is somehow vague. Can somebody shed light on the issue?

 

The problem are not AppLocker or any other similar mechanism that provides Publisher rules; the problems are the CAs (certificate authorities) themselves and cyber criminals who do manage to steal valid certificates.

I don't recall where I read it, but according to an article (in one of those security websites) malware is being seen using valid signatures, either stolen or issued* to them.

* I remember a recent situation where a CA issued a certificate to a bogus** company (one that no longer existed). This means that this CA failed to do a background check on the company requesting the certificate.

** By bogus, I mean that people requested a certificate using the name of a company that didn't exist anymore. The CA failed to verify that.

So, the question you got to ask is: Are CAs doing what they're suppose to do to prevent any of these situations, certificates being stolen and issues without background checking? Recent events say different. Therefore, I wouldn't put much trust in Publisher rules. If you ask me, they give a false sense of security, given these scenarios.

Either use Path rules for important system areas, such as Program Files and Windows (default rules) and Hash rules for user profile areas.

 

Thank you.

So Publisher Rules can be compromised by malware with valid digital signature.

 

No the certficate is read and an additional condition is applied

a) signed

and

b) being from a certain publisher


Some problems in the past with stolen certificates, weak certificates (e.g. Comodo offered a certificate without checking the company/requestor in advance).

See http://msdn.microsoft.com/en-us/library/windows/hardware/ff547660(v=vs.85).aspx and https://www.wilderssecurity.com/showthread.php?t=346918 and google on Deepdefender of McFee to get some explanation also

 

Then I just cannot get enough info to understand why a malware cannot get all this to look like routine soft. All I feel here is that Publisher rules must be same reliable as Hash rules.

Here again no info why a malware cannot bear all this phony data. I guess some simple picture of a few elements could explain it.

This is a nice instruction to manually check if a suspicious Windows executable was really signed. Though it says: "file probably includes an embedded signature". So no definite answer here and only manual check.

Yeah, it's cool. I would call it (as I got it from scanning various sources) "pre-OS behavior-blocker with hardware virtualization" and what not else is there. Maybe they've opened new direction in prevention. Though it does not have connection to OP.

Thank you.

 

Deepdefender blocks temp signed files/drivers. Temp signed, weak certificates/Comodo certificate practice, stolen certificates the most common ways of circumventing unsigned software restrictions/policies. The marketing story on Deepdefender explains why those extra checks are needed, hence you can understand the current limitations of software signing.

I have a deny install/elevate unsigned policy. Some time I get fresh samples from a honey pot. Since 2010 I have only encountered one misuse of software signing. According to 'breaking news' of AV vendors, this misuse should be applied on a large scale now. I do not think it is as bad as the AV vendors are telling. On the other hand, I have recently added a third party security application (first time since running lazy/safe admin setups), because of the volume of signed malware which supposingly is sneeking around in the wild.

 

There's a small element of risk using Publisher rules as opposed to Hash rules, sure, but for me it's so insignificant in the grand scheme of things, so when I weigh the risk of a certificate breech against the ongoing hassle of maintaining Hash rules, I far prefer Publisher rules. I know m00nbl00d showed a while back how Powershell could be used to maintain Hash rules, but it just wasn't for me.

You can see there can be a scope of three criteria (four if one wants) having to be met with a Publisher rule, enhancing the security at least somewhat.