Equimelt Vulnerability Explained in More Detail

My original post last week detailing what I call the Equimelt Vulnerability caused somewhat of a stir, as well as some healthy debate. As such, I would like to further clarify some of my key points and break down the real problems impacting cyber security.

After having heard from multiple sources that the integrity of the Public Key Infrastructure (PKI) was compromised, I decided to perform a manual examination of the approved trusted root hash certificate authorities as published by Microsoft, then compare the actual certificates that existed on a number of Windows 10 Pro computers from different corporations and sources in an effort to identify any non-approved Certificate Authorities in the root of trust of Windows 10 Pro computers.

To be crystal clear, the trusted root certificates serve as the foundation for securing hardware, software and connections between computers. Having confidence in the reliability and integrity of the Certificate Authorities trusted by your computing equipment is critical to cyber security.

Last week, I shared the results of an audit I performed on the root certificate authorities that exist in the trusted root folder of Windows 10 Pro computers. I discovered four certificates that were widely distributed across U.S. companies that lacked any clear reliable and trustworthy attribution. As of yet, I have been unable to find any official sources that will attest to the four “rogue” keys I have identified.

  1. GeoTrust Inc. – Issued November 26th, 2006, SHA1 Algorithm 323c118e1bf7b8b65254e2e2100dd6029037f096 (SHA1 Thumbprint)
  2. Thawte Premium Server CA – Issued July 31, 1996, MD5 Algorithm 627f8d7827656399d27d7f9044c9feb3f33efa9a (SHA1 Thumbprint)
  3. VeriSign, Inc. – Issued January 28th, 1996, MD2 Algorithm 742c3192e607e424eb4549542be1bbc53e6174e2 (SHA1 Thumbprint)
  4. Equifax Secure Certificate Authority – Issued August 22nd, 1998, SHA1 Algorithm d23209ad23d314232174e40d7f9d62139786633a (SHA1 Thumbprint)

Some have taken issue with my characterization of the keys by debating the strength of the SHA1 algorithm and the difficulty in brute forcing a fabrication that could undermine the integrity of those Certificate Authorities. My primary concern has nothing to do with the usage of weaker crypto algorithms (that is a concern but a lesser one), but more to do with the integrity of the source of the Certificate Authority and lack of reliable attestation to the key’s integrity by Microsoft, the computer’s manufacturer or by the U.S. government.

If the Equifax Certificate authority, or one of their child certificates was used to sign a specific hardware driver or related software, I would like someone reputable to go on the record and state which piece of hardware needs the Equifax Certificate Authority on their computer for it to function. If that happens, everyone can chose to use or remove those devices. I have added the Equifax Certificate Authority to my untrusted list, effectively revoking trust of that Certificate Authority on my computer and my computer continues to function without problems. Some have claimed the certificate is there to ensure legacy support of older components. It makes no sense that modern computers in use today need drivers signed by a 20-year-old Certificate Authority!

Here’s an analogy that might assist in understanding the risks, and the root of my argument: A builder constructs a spec home in 1998 using a predefined blueprint with a standard list of parts, including specific locks for the front door, garage door, and other entrances. When the buyers of that house take possession, they elect to forgo rekeying the locks as they have trust in the integrity of the builder and his staff. “He’s an old pal,” the buyers think to themselves, “no need to change the locks.”

However, one day the buyers get a call from their trusted builder who tells them that his company has been compromised from a security standpoint. The buyers immediately ask “do you know where the original master key to our house is?” The builder responds, “I do not know, and cannot be sure that the key and your address have not been compromised as well.” To make matters worse, another house built by the same builder had similar circumstances and has changed hands several times, leaving those residents completely unaware of who has what type of access to their home.

The issue of integrity and trust relates to the confidence that keys to those locks have not fallen into untrustworthy hands, rather than it being a matter of how formidable those locks and keys are in and of themselves.

The Equifax Secure Certificate Authority, while no longer owned by Equifax, has changed ownership many times since the suspect Equifax Certificate Authority was originally created in 1998. With each transaction of ownership, (Equifax -> GeoTrust in 2001, Geotrust -> VeriSign in 2006, VeriSign -> Symantec in 2010, Symantec -> Thoma Bravo LLC in 2017, Thoma Bravo LLC -> Digicert in 2018) the likelihood of compromise of the private key used to create that Certificate Authority increases. The private key used to generate the Equifax Certificate if compromised can be used to take full control over any computer that trusts that Certificate Authority as a trusted root CA. Who in their right mind would want to use the same original key that allowed access to your new home purchased in 2018 knowing that the same key had persisted across four prior owners?

I cannot prove with information in my custody today that the private key Equifax used to generate the 1998 certificate was compromised as part of their recently reported data breach or during transfer of ownership of the Certificate Authority business through various parties. However, it makes absolutely no difference how strong or weak the lock is if the private key has been compromised. I would rather have a weaker lock with confidence that the private key hasn’t been spread around everywhere on the dark web.

Many of the detractors to my research are focusing on theoretical attacks based on the strength of the encryption mechanism. They are missing my primary point, which is one of trust and confidence that the private key has been adequately safeguarded for the last 20 years. Key lifespans today are now usually two years or less, which lessens the likelihood of bad actors getting their hands on private keys that can unlock and compromise computing devices. Few people would own a home that had several prior owners in the last 20 years without swapping out the locks.

If you owned that 1998 spec home and discovered that jewelry was stolen out of your home with no apparent forced entry, would you rekey your home? If that builder reported a sensitive theft of assets and information last year, would you still trust that your home’s locks are secure?

The debate over the strength of the lock is not relevant to the integrity issue I am most concerned about.

Why are these 4 keys present in many U.S. Corporations, but not on Microsoft’s list of Trusted Certificate Authorities?

Why hasn’t Microsoft whitelisted these four “rogue” Certificate Authorities if they are “necessary for legacy software and hardware” as some claim?

What software or hardware specifically needs the Equifax Certificate Authority in the trusted root of Windows 10 Pro in order for hardware to function?

Sure there may remain debate over the plausibility of compromise of a lock based on its inferior part compositions, but that is not my primary concern – integrity of the Public Key Infrastructure (PKI) is.

Someone needs to take ownership for why these 4 keys have to be on the Windows 10 operating system. Until that happens, I strongly recommend making these keys untrusted.

If the keys are required to run the Windows 10 OS on a specific computer made by a specific manufacturer, then that manufacturer needs to attest to the integrity and necessity of the keys, mapping out why 20-year-old keys must be used. The keys made 20 years ago are using less secure crypto. Cryptographic attacks have been successful against SHA1, MD5 and MD2 algorithms, but that is not my main point, nor one that I want to waste time arguing about. Integrity and trust of the person who made the lock (Certificate Authority) and confidence that the private key hasn’t been compromised is primary.

Why would anyone want to keep a lock on their home if they knew that the builder who retained a copy of the master key to your locks had been compromised recently? Would you need to see the key to your home in the hands of a burglar before you became concerned and changed your locks? Would you wait until one of the builder’s past clients had an actual break-in reported before you took action? You don’t have to be a crypto genius to understand the common-sense concerns involved with trusting an organization unworthy of public trust!

Even the IRS recently yanked a contract with Equifax after they spread malware from their website late last year.

I cannot prove that the private key from Equifax was compromised at this time, but any reasonable person would be concerned over the trustworthiness of the Equifax certificate authority created in 1998 if it is used to secure their computing platform.

I found a great article that discusses in more technical detail the role trusted root Certificates Authorities play in securing computing devices. Check it out here: http://www.umiacs.umd.edu/~tdumitra/papers/CCS-2017.pdf

Your feedback is welcome!

Facebook Comments

1 Comment on "Equimelt Vulnerability Explained in More Detail"

  1. It appears that Google Chrome is following my recommendation to revoke trust in Equifax!

Leave a comment