You can trust me, I’m digitally signed!

There is a broadly adopted notion that digitally signed software objects are more trustworthy than those which are not signed. There is an element of truth to this concept, but be careful this belief can produce a false sense of security that may not be warranted, leading to the installation of a “digitally signed” software object that can cause serious damage to your digital ecosystem, and your finances as you try to recover from a cybercrime induced disruption to “life as usual”.

I’m going to describe an actual case that I recently encountered with a software installation package provided by one of the 4 letter acronym U.S. government agencies that we all look to as experts for cyber security guidance. I won’t mention the name, but suffice it to say – if they can get bitten by this situation then we're all at risk! For this article, I’ll refer to the government entity that is using these risky practices in their software supply chain as ZZZZ.

A few days ago, I downloaded a software package from ZZZZ’s website, let’s call this software TRUSTME.

I ALWAYS perform a software supply chain risk assessment using SAG-PM™ before I attempt to install any software package. I want to know if there is any risk before I install software in my digital ecosystem; I can’t afford to pay the ransom. The introspection step in SAG-PM™ determines the Licensor Name and other information about the software and produces an SPDX SBOM of all the information that can be extracted from the TRUSTME installation package. Sure enough, ZZZZ is listed as the Licensor Name along with details about the product name, TRUSTME and its version number 0.0.0 (also fabricated for this article). The process continues into the “verify digital signature” step of the SAG-PM™ risk assessment process. HALT, what is this, the party that signed the TRUSTME software from ZZZZ is identified in the digital signature’s certificates as someone other than ZZZZ, let’s call the signing party “Trusty”. SAG-PM™ reports a dire warning about this ZZZZ-Trusty risky situation “---->WARNING: Unable to match digital signature with Product Licensor Name in File Properties: VERY HIGH RISK”

I reached out to ZZZZ, several times and have received no response.  I wanted to explain that this is a “red flag” situation within the SCRM vendor community and that ZZZZ may want to take steps to address the matter. Still no response from ZZZZ and it’s been a few days. I tried going through another colleague in government to nudge ZZZZ to respond; still no response. I’ve stopped trying to contact ZZZZ.

Then I thought, can anybody sign ZZZZ’s TRUSTME software and have it pass the “valid signature test” that a product like signtool performs. So, I tried to sign the TRUSTME software with my own signing key – guess what IT WORKED! The ZZZZ software remained in tact with all of the original information provided by ZZZZ, however now the signer is reported as me. This means that anyone can sign ZZZZ’s TRUSTME software and it will be reported as valid, by signtool.

The big missing piece from the puzzle is an assertion by ZZZZ that the TRUSTME software was signed with a digital certificate owned by ZZZZ (that matches the Licensor name embedded in the file); this will allow parties to verify that the party that licensed a software package, ZZZZ, is indeed the party that signed the TRUSTME software, using a digital certificate issued to ZZZZ by a trustworthy Certificate Authority. Anytime a party wants to check a digitally signed software package MAKE SURE the digital certificate’s Owner Name, matches the Name of the Product Licensor embedded in the software, in order to prevent from becoming a victim of cyber-crime. Don’t just blindly trust that everything is ok when you see a successful result from a digital signature validation, as shown below:

----> :Successfully verified: TRUSTME Software

----> :Number of files successfully Verified: 1

----> :Number of warnings: 0

----> :Number of errors: 0

Never trust software, always verify and report!™