General Category > Suggestions


<< < (2/2)


--- Quote from: hendy on January 28, 2020, 09:55:09 AM ---
--- Quote from: bellgamin on January 27, 2020, 03:05:54 PM ---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.

--- End quote ---
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 (

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 (
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.

--- End quote ---

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?

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.


[0] Message Index

[*] Previous page

Go to full version