Trust in digital certificates cannot be taken at face value

happygeek 1 Tallied Votes 285 Views Share

Security vendor Malwarebytes has reported that a new variation of an old password stealing Trojan is out in the wild, but all is not as it may seem. Notably, this particular Trojan is signed with an apparently 'genuine' digital certificate that authenticates the file. Which rather prompts the question: "say what?" Or to put it another way, if the billion-dollar digital certificate and encryption market can't actually guarantee squat, then what's the point of it?

The Trojan, it appears, evades many security barriers by a system of spoofing that involves the criminal enterprise behind the scheme setting up a bogus company which in turn has obtained genuine , legitimate and otherwise perfectly valid digital certificates of trust from Digicert. "This allows the cybercriminals to slide an infected PDF file into a large number of organisations, since the certificate is the equivalent of the baggage checked tag on luggage as it is carried by an airline to its destination" warns Calum MacLeod, a director at security vendor Venafi, who continues "in this case, everyone in the electronic chain takes the certificate - as they should – at its face value and the legitimate certificate authenticates the Trojan". MacLeod blames the trust management rather than the certificate authority schema in this case, explaining that "it is management and control flaws like this that undermine confidence in the structural status quo of Internet security – and this is not good for anyone, or any user, of the World Wide Web, email and other forms of IP communications".

Truth be told, this is nothing new. Certificate and Certificate Authority abuse has been far from hypothetical for some time. Equally, the inability of business to control trust is a rabbit that is not able to hide in the hat any longer. If we are to continue along the road of depending upon both encryption and digital certification to help secure our data, than more effective trust management is required and urgently. Heck, how many organizations have the faintest idea about the total number of keys and certificates that exist within their own networks? Or in the cloud? Or on the mobile devices they have deployed? Let alone understanding how these are being accessed and by whom.

Dani AI

Generated

Noting 's observation and 's concern about trusting vendor-signed binaries, the practical conclusion is this: a valid, publicly trusted certificate is a useful signal, not an automatic guarantee. Historic CA mis-issuance and related failures show that ownership and monitoring controls matter as much as the certificate itself. Background on the problem and CT as a mitigation. (developer.mozilla.org)

Concrete, immediate priorities for organisations are inventory, protection, and automation. Inventory every certificate and private key (including cloud, mobile and test systems); enforce least‑privilege access and store long‑term signing keys in HSMs or a certified key‑management system; centralize lifecycle management so issuance/renewal is auditable. Where possible automate issuance and rotation using ACME or an equivalent process. See NIST guidance on key management and the ACME specification for automation. . (csrc.nist.rip) ACME (RFC 8555). (rfc-editor.org)

Reduce external issuance risk with controls and monitoring. Publish DNS CAA to limit which CAs can issue for a domain, require/monitor Certificate Transparency logs for unexpected certificates, and prefer short‑lived certificates or frequent rotation so revocation gaps matter less. Combine CT monitoring with an incident playbook that can rapidly revoke and replace suspect certs. CAA (RFC 8659). (rfc-editor.org) Certificate Transparency (RFC 6962). (rfc-editor.org) Short‑lived certs in practice (Let's Encrypt). (letsencrypt.org)

Quick checklist and two one‑line checks to start discovery and inspection:

  • Build a centralized cert/key inventory and alert on new public certs for owned domains.
  • Require CAA, enable CT monitoring, enable OCSP stapling and rotate private keys in HSM/KMS.
  • Automate renewals (ACME) and adopt short lifetimes where feasible.
openssl s_client -connect example.com:443 -servername example.com -showcerts
openssl x509 -in cert.pem -noout -text

References above give implementation details and standards to follow; the operational steps (inventory, HSMs/KMS, automation, CAA/CT monitoring, short‑lived certs) are the practical controls that restore meaningful trust to certificate-based protections.

Member Avatar for Member #949455
Member #949455

Trust in digital certificates cannot be taken at face value.

I still do look at the Trust in Digital Certificates because it's hard to not to trust the software company.

It's hard to separate the the Real Digital Certificates from a fake Digital Certificates.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.