Hash

[bellgamin]

Reference SecureAPlus's fingerprints of signatures. There is a discussion of this matter at Wilders Security forum, starting HERE and continuing HERE and then HERE.

As to SecureAPlus, we are concerned as to how collision-proof its fingerprints are because of several technical articles such as THIS.

Consider using SHA256, please.

[GrDukeMalden]

Yeah, there's a lot of new ways to fool a whitelisting application that only uses digital signatures now.

[bellgamin]

I am well aware that SecureAPlus (S.A.P.) does not depend solely on signatures. It does use signature "fingerprints" in the form of hashes. I do NOT know which type of hashes are being used. My post was merely suggesting that the proponents of S.A.P. take another look at this matter.

[GrDukeMalden]

I am well aware that SecureAPlus (S.A.P.) does not depend solely on signatures. It does use signature "fingerprints" in the form of hashes. I do NOT know which type of hashes are being used. My post was merely suggesting that the proponents of S.A.P. take another look at this matter.

Yeah, I get that, but the default settings of S.A.P. only check a digital signature.
(edited a day later past this)

People like us, advanced users are the only ones who would change that setting. Average users and something I call "helpless users" (Computer users that don't know anything at all and never learn) are never going to change that setting to the correct one. Much less the configuration I call the "paranoid setting" where you turn off the "trust based on digital signature" option all together.

The video I linked to on wilder's explicitly stated that the vulnerability they were talking about had already been patched by microsoft.

My concern however is that there are most assuredly MORE vulnerabilities that would allow a bad actor to spoof a digital signature.

[hendy]

I am well aware that SecureAPlus (S.A.P.) does not depend solely on signatures. It does use signature "fingerprints" in the form of hashes. I do NOT know which type of hashes are being used. My post was merely suggesting that the proponents of S.A.P. take another look at this matter.

You are right, SecureAPlus is not solely depending on the digital signature.
SecureAPlus whitelisting is based on SHA256 hash. To achieve trust by hash only, you may turn off the trust by digital signature (https://support.secureaplus.com/how-can-i-manage-my-application-whitelisting-mode-using-digital-signature/)

If the trust by certificate is turned on, which is the default settings, it means that if the hash of the file (the sha256 hash) cannot be found in SecureAPlus internal whitelist database, it will check the digital signature of the file. This digital signature is the same as if you right click on the file, select "Properties", and go to digital signature tab. This digital signature nowadays are usually either sha1, sha256, or both. The way to validate this digital signature, is not only based on the hash, but it based on the certificate trust chain. For example, a self signed certificate, will not be trusted, even though if the hash is correct. The other example of the situation where the digital signature is not trusted although it has a correct hash, is when the digital certificate has been revoked.

Here is the example of a real application, signed by Adobe.
Once there was a case that this certificate was stolen (https://www.silicon.co.uk/workspace/adobe-security-hacked-certificate-attacks-94414)
Adobe revoked this certificate. As you can see from the picture below, even the hash is valid, but the certificate is invalid.



In this case, SecureAPlus also will not trust this file, even if the trust by digital signature is turned on.

[GrDukeMalden]

I am well aware that SecureAPlus (S.A.P.) does not depend solely on signatures. It does use signature "fingerprints" in the form of hashes. I do NOT know which type of hashes are being used. My post was merely suggesting that the proponents of S.A.P. take another look at this matter.

You are right, SecureAPlus is not solely depending on the digital signature.
SecureAPlus whitelisting is based on SHA256 hash. To achieve trust by hash only, you may turn off the trust by digital signature (https://support.secureaplus.com/how-can-i-manage-my-application-whitelisting-mode-using-digital-signature/)

If the trust by certificate is turned on, which is the default settings, it means that if the hash of the file (the sha256 hash) cannot be found in SecureAPlus internal whitelist database, it will check the digital signature of the file. This digital signature is the same as if you right click on the file, select "Properties", and go to digital signature tab. This digital signature nowadays are usually either sha1, sha256, or both. The way to validate this digital signature, is not only based on the hash, but it based on the certificate trust chain. For example, a self signed certificate, will not be trusted, even though if the hash is correct. The other example of the situation where the digital signature is not trusted although it has a correct hash, is when the digital certificate has been revoked.

Here is the example of a real application, signed by Adobe.
Once there was a case that this certificate was stolen (https://www.silicon.co.uk/workspace/adobe-security-hacked-certificate-attacks-94414)
Adobe revoked this certificate. As you can see from the picture below, even the hash is valid, but the certificate is invalid.



In this case, SecureAPlus also will not trust this file, even if the trust by digital signature is turned on.

Okay, so what if there's another hack at a software distributor like what happened with Verisign a little more than 9 years ago now?

I've said this before. A long time ago, when I was still in highschool, Verisign hot hacked and the bad actors in question managed to get valid digital signatures from Verisign on malware.

It took a LONG time for Verisign to get that fixed.

But like I said, there's absolutely more vulnerabilities that would allow a bad actor to spoof a digital signature.

So if SAP doesn't have the SHA256 hash in the cloud to find and that spoofed signature looks exactly the same as one of the signatures in the locally stored database on the user's PC. What would happen then?

[hendy]

With the default settings, SecureAPlus checks the software publisher's name in the trusted certificate list.
For example, if the attacker managed to sign as Verisign, although the certificate is valid, but it is not in the trusted certificate list, so the file will still get blocked.


In most cases, spoof certificate usually was signed by untrusted root certificate.
In this case the certificate is invalid, so even the publisher's name is in the trusted certificate list, it will also get blocked.

What if the the attacker sign using a spoof certificate, the publisher's name is in the trusted certificate list, and the root CA is also trusted?
In this case, with the default settings, SecureAPlus will allow it to run.
Set to trust based on certificate's thumbprint, could help in this case.

What if the attacker steal the vendor's certificate? It will have the same publisher's name and thumbprint.
To prevent this kind of attack, turn off the trust by digital signature.