Microsoft gave its digital imprimatur to a rootkit that decrypted encrypted communications and sent them to attacker-controlled servers, the company and outside researchers said.

The blunder allowed the malware to be installed on Windows machines without users receiving a security warning or needing to take additional steps. For the past 13 years, Microsoft has required third-party drivers and other code that runs in the Windows kernel to be tested and digitally signed by the OS maker to ensure stability and security. Without a Microsoft certificate, these types of programs can’t be installed by default.

Eavesdropping on SSL connections

Earlier this month, Karsten Hahn, a researcher at security firm G Data, found that his company’s malware detection system flagged a driver named Netfilter. He initially thought the detection was a false positive because Microsoft had digitally signed Netfilter under the company’s Windows Hardware Compatibility Program.

After further testing, Hahn determined that the detection wasn’t a false positive. He and fellow researchers decided to figure out precisely what the malware does.

“The core functionality seems to be eavesdropping on SSL connections,” reverse engineer Johann Aydinbas wrote on Twitter. “In addition to the IP redirecting component, it also installs (and protects) a root certificate to the registry.”

A rootkit is a type of malware that is written in a way that prevents it from being viewed in file directories, task monitors, and other standard OS functions. A root certificate is used to authenticate traffic sent through connections protected by the Transport Layer Security protocol, which encrypts data in transit and ensures the server to which a user is connected is genuine and not an imposter. Normally, TLS certificates are issued by a Windows-trusted certificate authority (or CA). By installing a root certificate in Windows itself, hackers can bypass the CA requirement.

Microsoft’s digital signature, along with the root certificate the malware installed, gave the malware stealth and the ability to send decrypted TLS traffic to hxxp://110.42.4.180:2081/s.

Serious security lapse

In a brief post from Friday, Microsoft wrote, “Microsoft is investigating a malicious actor distributing malicious drivers within gaming environments. The actor submitted drivers for certification through the Windows Hardware Compatibility Program. The drivers were built by a third party. We have suspended the account and reviewed their submissions for additional signs of malware.”

The post said that Microsoft has found no evidence that either its signing certificate for the Windows Hardware Compatibility Program or its WHCP signing infrastructure had been compromised. The company has since added Netfilter detections to the Windows Defender AV engine built into Windows and provided the detections to other AV providers. The company also suspended the account that submitted Netfilter and reviewed previous submissions for signs of additional malware.

Microsoft added:

The actor’s activity is limited to the gaming sector, specifically in China, and does not appear to target enterprise environments. We are not attributing this to a nation-state actor at this time. The actor’s goal is to use the driver to spoof their geo-location to cheat the system and play from anywhere. The malware enables them to gain an advantage in games and possibly exploit other players by compromising their accounts through common tools like keyloggers.

It’s important to understand that the techniques used in this attack occur post-exploitation, meaning an attacker must either have already gained administrative privileges in order to be able to run the installer to update the registry and install the malicious driver the next time the system boots or convince the user to do it on their behalf.

Despite the limitations the post noted, the lapse is serious. Microsoft’s certification program is designed to block precisely the kind of attack G Data first discovered. Microsoft has yet to say how it came to digitally sign the malware. Company representatives declined to provide an explanation.

https://arstechnica.com/?p=1777105

OpenSSL, the most widely used software library for implementing website and email encryption, has patched a high-severity vulnerability that makes it easy for hackers to completely shut down huge numbers of servers.

OpenSSL provides time-tested cryptographic functions that implement the Transport Layer Security protocol, the successor to Secure Sockets Layer that encrypts data flowing between Internet servers and end-user clients. People developing applications that use TLS rely on OpenSSL to save time and avoid programming errors that are common when noncryptographers build applications that use complex encryption.

The crucial role OpenSSL plays in Internet security came into full view in 2014 when hackers began exploiting a critical vulnerability in the open source code library that let them steal encryption keys, customer information, and other sensitive data from servers all over the world. Heartbleed, as the security flaw was called, demonstrated how a couple lines of faulty code could topple the security of banks, news sites, law firms, and more.

Denial-of-service bug squashed

On Thursday, OpenSSL maintainers disclosed and patched a vulnerability that causes servers to crash when they receive a maliciously crafted request from an unauthenticated end user. CVE-2021-3449, as the denial-of-server vulnerability is tracked, is the result of a null pointer dereference bug. Cryptographic engineer Filippo Valsorda said on Twitter that the flaw could probably have been discovered earlier than now.

“Anyway, sounds like you can crash most OpenSSL servers on the Internet today,” he added.

Hackers can exploit the vulnerability by sending a server a maliciously formed renegotiating request during the initial handshake that establishes a secure connection between an end user and a server.

“An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client,” maintainers wrote in an advisory. “If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack.”

The maintainers have rated the severity high. Researchers reported the vulnerability to OpenSSL on March 17. Nokia developers Peter Kästle and Samuel Sapalski provided the fix.

Certificate verification bypass

OpenSSL also fixed a separate vulnerability that, in edge cases, prevented apps from detecting and rejecting TLS certificates that aren’t digitally signed by a browser-trusted certificate authority. The vulnerability, tracked as CVE-2021-3450, involves the interplay between a X509_V_FLAG_X509_STRICT flag found in the code and several parameters.

Thursday’s advisory explained:

If a “purpose” has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named “purpose” values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verification routines, but it can be overridden or removed by an application.

In order to be affected, an application must explicitly set the X509_V_FLAG_X509_STRICT verification flag and either not set a purpose for the certificate verification or, in the case of TLS client or server applications, override the default purpose.

OpenSSL versions 1.1.1h and newer are vulnerable. OpenSSL 1.0.2 is not impacted by this issue. Akamai researchers Xiang Ding and Benjamin Kaduk discovered and reported the bug, respectively. It was patched by Tomáš Mráz, a software developer who contracts with OpenSSL Software Services.

Apps that use a vulnerable OpenSSL version should upgrade to OpenSSL 1.1.1k as soon as possible.

https://arstechnica.com/?p=1752244

A major operational error by GoDaddy, Apple, and Google has resulted in the issuance of at least 1 million browser-trusted digital certificates that don’t comply with binding industry mandates. The number of non-compliant certificates may be double that number, and other browser-trusted authorities are also likely to be affected.

The snafu is the result of the companies’ misconfiguration of the open source EJBCA software package that many browser-trusted authorities use to generate certificates that secure websites, encrypt email, and digitally sign code. By default, EJBCA generated certificates with 64-bit serial numbers, in keeping, it seemed, with an industry mandate that serial numbers contain 64 bits of output from a secure pseudo-random number generator. Upon further scrutiny, engineers discovered that one of the 64 bits must be a fixed value to ensure the serial number is a positive integer. As a result, the EJBCA default produced a serial number with 63 bits of entropy.

The 63 bits is far off the mark of the required 64 bits and, as such, poses a theoretically unacceptable risk to the entire ecosystem. (Practically speaking, there’s almost no chance of the certificates being maliciously exploited. More about that later.) Adam Caudill, the security researcher who blogged about the mass misissuance last weekend, pointed out that it’s easy to think that a difference of 1 single bit would be largely inconsequential when considering numbers this big. In fact, he said, the difference between 2⁶³ and 2⁶⁴ is more than 9 quintillion.

Section 7.1 of the Baseline Requirements for publicly trusted certificates is clear that the minimum threshold for serial numbers must be no fewer than 64 bits of entropy. The 2016 ballot that enacted this requirement referred to a 2008 proof-of-concept hack in which researchers, using a raft of PlayStation consoles to generate cryptographic collisions in the MD5 hash algorithm, essentially became a rogue authority that could generate browser-trusted certificates at will. In 2012, state-sponsored malware dubbed Flame used a similar technique to hijack Microsoft’s widely used Windows update mechanism.

Almost no chance of exploitation

With all that said, despite the shortcomings of the misissued certificates, there is very little chance their non-compliant entropy can be exploited. Certificates are now generated using SHA256, a modern algorithm that doesn’t have the known vulnerabilities of MD5. The 64-bit requirement, rather, is more a matter of insuring against new attacks that will likely be discovered in the coming decades.

What that means is that, while the revocation and reissuance of between 1 million and 2 million certificates (at the time this post went live, researchers were still debating the number) is a major undertaking, there is virtually no security threat posed by the error.

“This is a big deal for CAs and their customers,” Caudill told Ars. “The impact of replacing large numbers of certificates is substantial. From a threat perspective though, this isn’t exploitable. It would require a major breakthrough in cryptography, and even then, 63 bits of entropy provides a huge safety margin. This is a problem because of impact to people and companies; hackers aren’t going to start forging certificates because of this.”

In online forums discussing the problem, a GoDaddy official initially said his company issued more than 1.8 million certificates that didn’t comply with the 64-bit requirement. Under industry rules, GoDaddy had five days to revoke the certificates, but GoDaddy said it wouldn’t be able to make that deadline for all the certificates identified.

“Within the next 30 days”

“Our goal is to reissue all the certificates within the next 30 days,” wrote Daymion Reynolds, who is senior director of SSL/PKI security products at GoDaddy. “We have started the revocation process. We have a significant number of customers that use manual methods for managing their certificates, so being agile for them is difficult. We want to keep our customers using https through the entire revocation period. Due to the large number of certificates and the benign nature of the issue, our plan is to revoke in a responsible way.”

In an update posted Tuesday, Reynolds revised the estimate of misissued live certificates to about 12,000 and another 273,784 certificates that were “orphaned,” meaning they were stopped in mid-issuance for reasons including requestor cancellation and system errors. Reynolds said that the original estimate of more than 1.8 million certificates was based on a “more aggressive criteria than necessary.” Caudill and other researchers asked Reynolds to provide additional details before accepting the revised number.

An Apple official said here that the total number of non-compliant certificates his company issued was about 878,000, although the number of certificates that were still valid, and not expired and not revoked as of last Thursday, was about 558,000. A Google official, meanwhile, estimated the company had issued more than 100,000 non-complying certificates since 2016, but that as of late last month, only about 7,100 of them remained valid.

Both Apple and Google use their publicly trusted authorities to issue certificates for use internally and by affiliated organizations. Caudill said additional certificate authorities may also be affected.

An Apple representative told Ars the company has taken the following steps:

• Stopped issuance of certificates with non-compliant serial numbers, and is continuing to work with users to revoke impacted certificates
• Configured the software to generate serial numbers with 16 octets, ensuring entropy greater than 64 bits
• Reinstated alerts for detecting serial numbers suspected to be insufficient in length
• Enhanced validator software that checks certificates for SSL Baseline compliance to evaluate collections of certificates instead of individual certificates. These enhancements are expected to be implemented by April 30, 2019.

A Google representative provided this link as comment for this post.

https://arstechnica.com/?p=1472479

Enlarge (credit: Sennheiser)

Audio device maker Sennheiser has issued a fix for a monumental software blunder that makes it easy for hackers to carry out man-in-the-middle attacks that cryptographically impersonate any big-name website on the Internet. Anyone who has ever used the company’s HeadSetup for Windows or macOS should take action immediately, even if users later uninstalled the app.

To allow Sennheiser headphones and speaker phones to work seamlessly with computers, HeadSetup establishes an encrypted Websocket with a browser. It does this by installing a self-signed TLS certificate in the central place an operating system reserves for storing browser-trusted certificate authority roots. In Windows, this location is called the Trusted Root CA certificate store. On Macs, it’s known as the macOS Trust Store.

A few minutes to find, years to exploit

The critical HeadSetup vulnerability stems from a self-signed root certificate installed by version 7.3 of the app that kept the private cryptographic key in a format that could be easily extracted. Because the key was identical for all installations of the software, hackers could use the root certificate to generate forged TLS certificates that impersonated any HTTPS website on the Internet. Although the self-signed certificates were blatant forgeries, they will be accepted as authentic on computers that store the poorly secured certificate root. Even worse, a forgery defense known as certificate pinning would do nothing to detect the hack.

Read 10 remaining paragraphs | Comments

https://arstechnica.com/?p=1419427

Enlarge (credit: Rainway)

Tens of thousands of Fortnite players have been infected by malware that hijacks encrypted Web sessions so it can inject fraudulent ads into every website a user visits, an executive with a game-streaming service said Monday.

Rainway CEO Andrew Sampson said in a blog post that company engineers first detected the mass infections last week when server logs reported hundreds of thousands of errors. The engineers soon discovered that the errors were the result of ads that somehow were injected into user traffic. Rainway uses a technique known as whitelisting that permits customers to connect only to approved URLs. The addresses hosting the fraudulent addresses—hosted on the adtelligent.com and springserve.com domains—along with unauthorized JavaScript that accompanied them made it clear the traffic was generated by malware infecting a large number of game players using the Rainway service. Rainway is a cloud-based service that lets people play PC games remotely, similar to PlayStation Now.

“As the errors kept flowing in, we took a glance at what these users had in common,” Sampson wrote. “They didn’t share any hardware, their ISPs were different, and all of their systems were up to date. However, one thing did stand out—they played Fortnite.”

Read 5 remaining paragraphs | Comments

https://arstechnica.com/?p=1339741

A surprisingly big number of top-name websites—Facebook and PayPal among them—recently tested positive for a critical, 19-year-old vulnerability that allowed attackers to decrypt encrypted data and sign communications using the sites’ secret encryption key.

The vulnerability in the transport layer security protocol for Web encryption was disclosed in 1998 when researcher Daniel Bleichenbacher found it in the TLS predecessor known as secure sockets layer. A flaw in the algorithm that handles RSA encryption keys responded to certain types of errors in a way that divulged potentially sensitive information. With enough specially formed queries, attackers could exploit the weakness in a way that allowed them to decrypt ciphertext even when they didn’t have the secret decryption key. SSL architects responded by designing workarounds that suppressed the error messages rather than removing or rewriting the faulty RSA algorithm.

Researchers call the class of crypto vulnerability an Oracle because it provides only “yes” or “no” answers that, over time, can reveal detailed information about the contents of encrypted data. The information allows hackers to carry out what’s known as an “adaptive chosen-ciphertext attack.”

Hiding in plain sight

On Wednesday, a team of researchers said an Internet scan conducted last month found that 27 of the 100 most-visited websites—including Facebook and PayPal—were vulnerable to what was essentially the same attack. About 2.8 percent of the top 1 million sites also tested positive. The researchers also identified developers of firewalls, load balancers, and other large-scale applications that made websites vulnerable to the decryption and impersonation attacks. The findings, the researchers said, underscore the inadequacy of current processes for securing transport layer security, the HTTPS-scheme that’s a cornerstone of Internet security.

“We were able to identify eight vendors and open-source projects and a significant number of hosts that were vulnerable to minor variations of Bleichenbacher’s adaptive-chosen ciphertext attack from 1998,” the researchers wrote in a research paper. “The most notable fact about this is how little effort it took us to do so. We can therefore conclude that there is insufficient testing of modern TLS implementations for old vulnerabilities.”

In a blog post, the researchers were similarly blunt when they wrote:

The surprising fact is that our research was very straightforward. We used minor variations of the original attack and were successful. This issue was hiding in plain sight.

This means neither the vendors of the affected products nor security researchers have investigated this before, although it’s a very classic and well-known attack.

To prove the potential severity of ROBOT—short for “Return Of Bleichenbacher’s Oracle Threat”—the researchers digitally signed a message using the secret key for Facebook’s TLS server. They said Facebook engineers accidentally added the vulnerability to their site when they wrote a custom patch for the OpenSSL crypto library the site used for TLS. The researchers privately notified the social media giant of the vulnerability, and engineers deployed new patches within a week. After refining their ROBOT exploit, the researchers discovered the fix was incomplete. Within a week, Facebook implemented a new fix. Prior to the fix, Facebook’s instagram.com and fbcdn.com domains were also affected, the researchers said.

Websites can also be exposed as a result of using products or projects from a variety of developers. At the moment, the list includes:

The researchers aren’t naming developers of other vulnerable software who have fixes pending. The researchers also warned that sites that didn’t test positive in the recent scans may still be vulnerable to variations of the exploit.

No patch for widely used Cisco product

The vulnerability of Cisco’s ACE is concerning, because Cisco stopped supporting it several years ago and the researchers said the company has no plans to patch the product line. Even worse, it’s not possible to disable RSA encryption in the product, leaving users unable to follow one of the few possible workarounds for those unable to patch. What’s more, the researchers said Cisco is currently using ACE to serve content on cisco.com. In an email, Cisco officials wrote:

Cisco is aware of the newly discovered industry-wide vulnerability that potentially affects products that encrypt using RSA Public-Key Cryptography Standard #1 v1.5. When issues such as this arise, we put the security of our customers first and ensure they have the information they need to best protect their networks. Cisco PSIRT has issued a security advisory to provide relevant detail about the issue, noting which Cisco products may be affected and subsequently may require customer attention. This ensures customers are aware of the vulnerability, so they can put best practices in place to mitigate risk and actively monitor their networks for any potential abnormal behavior.

The Cisco advisory is here.

Exploits typically require an attacker to make tens of thousands of connections to a vulnerable site. The requirement puts ROBOT well below the severity of Heartbleed, the critical 2014 vulnerability in OpenSSL that could be exploited in a matter of seconds. Still, ROBOT is serious enough that it deserves immediate attention. Engineers and administrators should make it a top priority to investigate if their sites are vulnerable, either by using this tool or other means. Anyone using a recently patched product should upgrade as soon as possible. Over the longer term, the researchers recommend sites disable RSA encryption in favor of schemes using the Elliptic-Curve Diffie-Hellman key exchange.

https://arstechnica.com/?p=1231441

For a decade, some security professionals have held out extended validation certificates as an innovation in website authentication because they require the person applying for the credential to undergo legal vetting. That’s a step up from less stringent domain validation that requires applicants to merely demonstrate control over the site’s Internet name. Now, a researcher has shown how EV certificates can be used to trick people into trusting scam sites, particularly when targets are using Apple’s Safari browser.

Researcher Ian Carroll filed the necessary paperwork to incorporate a business called Stripe Inc. He then used the legal entity to apply for an EV certificate to authenticate the Web page https://stripe.ian.sh/. When viewed in the address bar, the page looks eerily similar to https://stripe.com/, the online payments service that also authenticates itself using an EV certificate issued to Stripe Inc.

The demonstration is concerning because many security professionals counsel end users to look for EV certificates when trying to tell if a site such as https://www.paypal.com is an authentic Web property rather than a fly-by-night look-alike page that’s out to steal passwords. But as Carroll’s page shows, EV certs can also be used to trick end users into thinking a page has connections to a trusted service or business when in fact no such connection exists. The false impression can be especially convincing when end users use Apple’s Safari browser because it often strips out the domain name in the address bar, leaving only the name of the legal entity that obtained the EV certificate.

“With enough mouse clicks, you may be able to open a system certificate viewer or get your browser to show you the city and state,” Carroll wrote. “But neither of these are helpful to a typical user, and they will likely just blindly trust the bright green indicator.”

Carroll’s demonstration comes three months after researcher James Burton exposed a different way EV certificates can be used to trick end users. He established a business named “Identity Verified” and showed how the resulting EV certificate might be used to add the air of authenticity to a scam site. Both Carroll and Burton said little effort was necessary to create the legal entities. Carroll said the demo cost $177: $100 in incorporation expenses and $77 for the certificate.

The demonstrations are generating productive discussions among developers about the way EV certificates should be treated in browser user interfaces. Security professionals are also openly discussing whether certificate rules should be modified to prevent these types of cases.

For the time being, people should remember that EV certificates aren’t automatically a panacea for online fraud. In some cases, certificates could make an otherwise obvious scam site seem legitimate. When in doubt, end users should carefully inspect the certificate and ensure it was issued to the operator of the trusted site.

https://arstechnica.com/?p=1230939