Google and other browser makers require that all TLS certificates be published in public transparency logs, which are append-only distributed ledgers. Website owners can then check the logs in real time to ensure that no rogue certificates have been issued for the domains they use. The transparency programs were implemented in response to the 2011 hack of Netherlands-based DigiNotar, which allowed the minting of 500 counterfeit certificates for Google and other websites, some of which were used to spy on web users in Iran.
Once viable, Shor’s algorithm could be used to forge classical encryption signatures and break classical encryption public keys of the certificate logs. Ultimately, an attacker could forge signed certificate timestamps used to prove to a browser or operating system that a certificate has been registered when it hasn’t.
To rule out this possibility, Google is adding cryptographic material from quantum-resistant algorithms such as ML-DSA. This addition would allow forgeries only if an attacker were to break both classical and post-quantum encryption. The new regime is part of what Google is calling the quantum-resistant root store, which will complement the Chrome Root Store the company formed in 2022.
The MTCs use Merkle Trees to provide quantum-resistant assurances that a certificate has been published without having to add most of the lengthy keys and hashes. Using other techniques to reduce the data sizes, the MTCs will be roughly the same 4kB length they are now, Westerbaan said.
The new system has already been implemented in Chrome. For the time being, Cloudflare is enrolling roughly 1,000 TLS certificates to test how well the MTCs work. For now, Cloudflare is generating the distributed ledger. The plan is for CAs to eventually fill that role. The Internet Engineering Task Force standards body has recently formed a working group called the PKI, Logs, And Tree Signatures, which is coordinating with other key players to develop a long-term solution.
“We view the adoption of MTCs and a quantum-resistant root store as a critical opportunity to ensure the robustness of the foundation of today’s ecosystem,” Google’s Friday blog post said. “By designing for the specific demands of a modern, agile internet, we can accelerate the adoption of post-quantum resilience for all web users.”
Post updated to correct reported sizes of various items.
Cloudflare on Thursday acknowledged this failure, writing:
We failed three times. The first time because 1.1.1.1 is an IP certificate and our system failed to alert on these. The second time because even if we were to receive certificate issuance alerts, as any of our customers can, we did not implement sufficient filtering. With the sheer number of names and issuances we manage it has not been possible for us to keep up with manual reviews. Finally, because of this noisy monitoring, we did not enable alerting for all of our domains. We are addressing all three shortcomings.
Ultimately, the fault lies with Fina; however, given the fragility of the TLS PKI, it’s incumbent on all stakeholders to ensure system requirements are being met.
And what about Microsoft? Is it at fault, too?
There’s some controversy on this point, as I quickly learned on Wednesday from social media and Ars reader comments. Critics of Microsoft’s handling of this case say that, among other things, its responsibility for ensuring the security of its Root Certificate Program includes checking the transparency logs. Had it done so, critics said, the company would have found that Fina had never issued certificates for 1.1.1.1 and looked further into the matter.
Additionally, at least some of the certificates had non-compliant encoding and listed domain names with non-existent top-level domains. This certificate, for example, lists ssltest5 as its common name.
Instead, like the rest of the world, Microsoft learned of the certificates from an online discussion forum.
Some TLS experts I spoke to said it’s not within the scope of a root program to do continuous monitoring for these types of problems.
In any event, Microsoft said it’s in the process of making all certificates part of a disallow list.
Microsoft has also faced long-standing criticism that it’s too lenient in the requirements it imposes on CAs included in its Root Certificate Program. In fact, Microsoft and one other entity, the EU Trust Service, are the only ones that, by default, trust Fina. Google, Apple, and Mozilla don’t.
“The story here is less the 1.1.1.1 certificate and more why Microsoft trusts this carelessly operated CA,” Filippo Valsorda, a Web/PKI expert, said in an interview.
I asked Microsoft about all of this and have yet to receive a response.
Hackers abused an antivirus service for five years in order to infect end users with malware. The attack worked because the service delivered updates over HTTP, a protocol vulnerable to attacks that corrupt or tamper with data as it travels over the Internet.
The unknown hackers, who may have ties to the North Korean government, pulled off this feat by performing a man-in-the-middle (MiitM) attack that replaced the genuine update with a file that installed an advanced backdoor instead, said researchers from security firm Avast today.
eScan, an AV service headquartered in India, has delivered updates over HTTP since at least 2019, Avast researchers reported. This protocol presented a valuable opportunity for installing the malware, which is tracked in security circles under the name GuptiMiner.
“This sophisticated operation has been performing MitM attacks targeting an update mechanism of the eScan antivirus vendor,” Avast researchers Jan Rubín and Milánek wrote. “We disclosed the security vulnerability to both eScan and the India CERT and received confirmation on 2023-07-31 from eScan that the issue was fixed and successfully resolved.”
Complex infection chain
The complex infection chain started when eScan applications checked in with the eScan update system. The threat actors then performed a MitM attack that allowed them to intercept the package sent by the update server and replace it with a corrupted one that contained code to install GuptiMiner. The Avast researchers still don’t know precisely how the attackers were able to perform the interception. They suspect targeted networks may already have been compromised somehow to route traffic to a malicious intermediary.
To lower the chances of detection, the infection file used DLL hijacking, a technique that replaces legitimate dynamic link library files used by most Microsoft apps with maliciously crafted ones that use the same file name. For added stealth, the infection chain also relied on a custom domain name system (DNS) server that allowed it to use legitimate domain names when connecting to attacker-controlled channels.
Last year, the attackers abandoned the DNS technique and replaced it with another obfuscation technique known as IP address masking. This involved the following steps:
Obtain an IP address of a hardcoded server name registered to the attacker by standard use of the gethostbyname API function
For that server, two IP addresses are returned—the first is an IP address which is a masked address, and the second one denotes an available payload version and starts with 23.195. as its first two octets
If the version is newer than the current one, the masked IP address is de-masked, resulting in a real command-and-control (C&C) IP address
The real C&C IP address is used along with a hardcoded constant string (part of a URL path) to download a file containing malicious shellcode
Some variants of the infection chain stashed the malicious code inside an image file to make them harder to detect. The variants also installed a custom root TLS certificate that satisfied requirements by some targeted systems that all apps must be digitally signed before being installed.
The payload contained multiple backdoors that were activated when installed on large networks. Curiously, the update also delivered XMRig, an open-source package for mining cryptocurrency.
GuptiMiner has circulated since at least 2018 and has undergone multiple revisions. One searched compromised networks for systems running Windows 7 and Windows Server 2008, presumably to deliver exploits that worked on those earlier versions. Another provided an interface for installing special-purpose modules that could be customized for different victims. (This version also scanned the local system for stored private keys and cryptocurrency wallets.)
The researchers were surprised that malware that took such pains to fly under the radar would also install a cryptocurrency miner, which by nature is usually easy to detect. One possibility is the attackers’ possible connection to Kimsuky, the tracking name for a group backed by the North Korean government. Over the years, North Korea’s government has generated billions of dollars in cryptocurrency through malware installed on the devices of unwitting victims. The researchers made the possible connection after finding similarities between a known Kimsuky keylogger and code fragments used during the GuptiMiner operation.
The GuptiMiner attack is notable for exposing major shortcomings in eScan that went unnoticed for at least five years. Besides not delivering updates over HTTPS, a medium not susceptible to MitM attacks, eScan also failed to enforce digital signing to ensure updates hadn’t been tampered with before being installed. Representatives of eScan didn’t respond to an email asking why engineers designed the update process this way.
People who use or have used eScan should check the Avast post for details on whether their systems are infected. It’s likely that most reputable AV scanners will also detect this infection.
