Microsoft Keys

Back in 2021 I gave a Talk At Berkeley's Information Access Seminar that summarized two long posts from two years before that:

• Certificate Transparency
• Securing The Software Supply Chain

On Friday 25^th Dan Goodin had two posts documenting that even the biggest software companies haven't fixed the problems I was talking about:

• Renegade certificate removed from Windows. Then it returns. Microsoft stays silent.
• Microsoft signing keys keep getting hijacked, to the delight of Chinese threat actors

Below the fold I update this sorry state of affairs, which I first started cataloging a decade ago.

The technology used to secure Internet communication, for example via TLS, the basis for the HTTPS protocol, and for protecting the software supply chain, is based on public key encryption. For example, to start an HTTPS connection between Alice and Bob using Diffie-Hellman-Merkle key exchange, they each use their private key and the other's public key to compute aa shared secret key used to encrypt the communication.

How does Alice know Bob's public key, and vice versa? Alice obtains Bob's certificate, which contains Bob's public key. Alice can trust that the public key in the certificate belongs to Bob because it is signed by the private key matching the public key in the certificate of a Certificate Authority (CA) she trusts.

How does Alice know to trust the CA? Her browser has a list of certificates for CAs the browser vendor trusts, and Alice just accepts the browser vendor's judgement. Similarly, Alice can trust software packages signed by a CA she trusts to sign code. How does Alice know to trust this CA? Her operating system vendor has provided a code-signing certificate and Alice just accepts the vendor's judgement.

This all works great in theory, but in practice not so much. There are many ways in which the system can fail:

• The CA might be an organization Alice might not want to trust. For example, among the CAs Firefox trusts are several Chinese government organizations. Rusted Anchors: A National Client-Side View of Hidden Root CAs in the Web PKI Ecosystem by Yiming Zhang et al documented that:
  

  recent security incidents and studies show that the management of local root stores can be the "Achilles’ heel" of Web PKI security. By injecting self-built root certificates into local root stores, local software such as anti-virus and parent-control applications creates a man-in-the-middle proxy to filter SSL/TLS-encrypted traffic. This approach can also be used by government agencies or malware, in order to monitor web users’ online behaviors. For instance, reports in 2019 show that citizens in Kazakhstan were forced to import government-built CAs on their devices.

• The CA might have been compromised. For example, Dan Goodin wrote in 2018's One-stop counterfeit certificate shops for all your malware-signing needs:
  

  Barysevich identified four such sellers of counterfeit certificates since 2011. Two of them remain in business today. The sellers offered a variety of options. In 2014, one provider calling himself C@T advertised certificates that used a Microsoft technology known as Authenticode for signing executable files and programming scripts that can install software. C@T offered code-signing certificates for macOS apps as well. ... "In his advertisement, C@T explained that the certificates are registered under legitimate corporations and issued by Comodo, Thawte, and Symantec—the largest and most respected issuers,"

  Much of history's most notorious malware was signed with compromised certificates, for example Stuxnet
• The CA might be incompetent. For example, in 2012 Goodin wrote:
  

  Critics are calling for the ouster of Trustwave as a trusted issuer of secure sockets layer certificates after it admitted minting a credential it knew would be used by a customer to impersonate websites it didn't own.
  
  The so-called subordinate root certificate allowed the customer to issue SSL credentials that Internet Explorer and other major browsers would accept as valid for any server on the Internet.

  And in 2015 Goodin wrote:
  

  In the latest security lapse involving the Internet's widely used encryption system, Google said unauthorized digital certificates have been issued for several of its domains and warned misissued credentials may be impersonating other unnamed sites as well.
  ...
  The certificates were issued by Egypt-based MCS Holdings, an intermediate certificate authority that operates under the China Internet Network Information Center (CNNIC). The Chinese domain registrar and certificate authority, in turn, is included in root stores for virtually all OSes and browsers.

  Six months later Goodin wrote:
  

  Symantec has fired an undisclosed number of employees after they were caught issuing unauthorized cryptographic certificates that made it possible to impersonate HTTPS-protected Google webpages.

  But it was far worse than Symantec admitted. Two years later a Google investigation revealed that Symantec CAs have improperly issued more than 30,000 certificates.
• The CA's certificate might have been spoofed. This is what the Certificate Transparency (CT) system is intended to detect. Five years ago I wrote about how CT secures the certificates that secure HTTPS:
  

  The basic idea is to accompany the certificate with a hash of the certificate signed by a trusted third party, attesting that the certificate holder told the third party that the certificate with that hash was current. Thus in order to spoof a service, an attacker would have to both obtain a fraudulent certificate from a CA, and somehow persuade the third party to sign a statement that the service had told them the fraudulent certificate was current.
  ...
  Clients now need two lists of trusted third parties, the CAs and the sources of CT attestations. ... In the real world it isn't feasible to solve the problem of untrustworthy CAs by eliminating the need for trust. CT's approach instead is to provide a mechanism by which breaches of trust, both by the CAs and by the attestors, can be rapidly and unambiguously detected.

  Google Chrome has required Certificate Transparency for all "Extended Validation (EV)" certificates since 2015.
• The CA might have created a certificate chain by delegating trust to another organization, that might be compromised or incompetent.
• One of the keys in the chain might not be long enough to be secure.
• One of the keys in the chain might not be truly random. Users who generated a vanity wallet address using the Profanity service lost their coins for this reason.
• Someone might have developed a sufficiently powerful quantum computer.

The first of the two Goodin posts above harks back to the Symantec disaster. Godin writes:

For three days, system administrators have been troubleshooting errors that have prevented Windows users from running applications such as QuickBooks and Avatax. We now know the cause: an unannounced move or glitch by Microsoft that removed a once-widely used digital certificate in Windows.
...
Just minutes before this post was scheduled to go live, researchers learned that the certificate had been restored in Windows. It’s unclear how or why that occurred.
...
Microsoft has yet to respond to a request to explain the errors. It may be that a glitch caused Windows to remove the root certificate. It’s also possible the removal was intentional, given that it’s one of several that faced an industry-wide blockade following the discovery in 2015 that its parent issuer at the time, Symantec, had improperly issued certificates for google.com, www.google.com, and one other domain.

Why was this certificate, first issued in 2006 and blockaded in 2015, still trusted by Microsoft? In 2017, Google published the result of investigating Symantec's CA:

Google's investigation revealed that over a span of years, Symantec CAs have improperly issued more than 30,000 certificates.

The right thing for security would have been to revoke every certificate that Symantec had issued, but:

Symantec's repeated violations underscore one of the problems Google and others have in enforcing terms of the baseline requirements. When violations are carried out by issuers with a big enough market share they're considered too big to fail. If Google were to nullify all of the Symantec-issued certificates overnight, it might cause widespread outages.

Given a choice between keeping customers secure and keeping customers working, the tech industry adopted "too big to fail". Since they didn't revoke or remove the certificate, the applications dependent upon it kept working and their developers didn't notice that their security was compromised for six years. Unless Microsoft deliberately glitched the system to wake people up, their security will continue to be compromised until it expires in 2036, more than two decades after it was revealed that Symantec's credibility as a root of trust was worthless.

There are CA certificates that my Firefox trusts that don't expire until 2046! If it is effectively impossible to remove or revoke widely used certificates, it seems insane that CAs are allowed to create certificates valid for a quarter of a century. Doing so allows users of those certificates to completely ignore the issue of replacing their root certificates because by the time it is needed I'll be gone and you'll be gone. Because users can ignore the problem, the inability to remove or revoke compromised certificates becomes entrenched. A friend remarked "This is industry self regulation doing what it does".

Goodin's other post, Microsoft signing keys keep getting hijacked, to the delight of Chinese threat actors, is even more worrying:

In July, security researchers revealed a sobering discovery: hundreds of pieces of malware used by multiple hacker groups to infect Windows devices had been digitally signed and validated as safe by Microsoft itself. On Tuesday, a different set of researchers made a similarly solemn announcement: Microsoft’s digital keys had been hijacked to sign yet more malware for use by a previously unknown threat actor in a supply-chain attack that infected roughly 100 carefully selected victims.

Goodin continued:

In July, security firm Sophos reported its discovery of 133 malicious drivers, 100 of which had been digitally signed by Microsoft and the remaining ones by other trusted parties that went unnamed. The signings dated as far back as April 2021. In December, Sophos reported its discovery of another malicious driver signed by Microsoft.

The Sophos July report coincided with related posts from security firm Trend and Microsoft. Trend said it had unearthed newly discovered malware that came as a standalone kernel driver signed directly by Microsoft through its hardware compatibility program. Compromised signatures are “an evolving attack vector that has been frequently appearing in today’s malware landscape,” Trend researchers wrote. “Despite how complex [it] is to build such capabilities, it seems that current malicious actors are exhibiting competence and consistent usage of such tools, tactics, and procedures (TTPs), regardless of their final motive and objectives.”

Microsoft, meanwhile, published a post that said the malicious signings were the result of “several developer accounts for the Microsoft Partner Center… engaged in submitting malicious drivers to obtain a Microsoft signature.”

Microsoft placed the accounts on a "block list" but:

Last year, researchers showed that despite repeated Microsoft assertions to the contrary, the block list failed to work.

Microsoft’s July statement was almost a verbatim copy of one it issued last December, after being told two months earlier by security firms SentinelOne, Mandiant, and Sophos of similar abuse of its driver-signing program.

In I Solemnly Swear My Driver Is Up to No Good: Hunting for Attestation Signed Malware Mandiant researchers wrote:

Mandiant has continually observed threat actors use compromised, stolen, and illicitly purchased code-signing certificates to sign malware, lending legitimacy and subverting security controls such as application allow-listing policies. Attestation signed drivers take the trust granted to them by the CA and transfers it to a file whose Authenticode signature originates from Microsoft itself. We assess with high confidence that threat actors have subverted this process using illicitly obtained EV code signing certificates to submit driver packages via the attestation signing process, and in effect have their malware signed by Microsoft directly.

SentinelOne concluded that the compromised certificates were probably purchased from a supplier similar to the ones Barysevich identified in 2018.

Goodin described more instances of Microsoft signing malware, including:

In June 2021, for instance, the company gave its digital imprimatur to a driver with the innocuous name Netfilter. A researcher from security firm G Data later discovered it was a rootkit that decrypted encrypted communications, most likely to eavesdrop on SSL communications.

After pointing to Microsoft's opaque responses to recent breaches of its cloud systems Azure and Exchange, Goodin concludes:

Virtually all of the key-hijacking incidents reported in recent years have been attributed to Chinese hackers, usually for espionage purposes. Microsoft’s string of failures in locking down its certification program, and its reticence when disclosing them, are undermining the entire concept of security, much to the delight of these adversaries.

Microsoft's business model, as a operating system vendor and a follower in cloud markets, depends upon being perceived as a safe choice for enterprise applications. Thus it has a strong motivation to play down and obfuscate serial security lapses such as these, and to avoid any security fixes that would significantly impact customers. Thus we can expect the parade of security lapses to continue.