Google adds account sync for Authenticator, without E2EE

Also: Your Salesforce Community site might be leaking; a new CPU side-channel; and this week's critical vunls

in brief You may have heard news this week that Google is finally updating its authenticator app to add Google account synchronization. Before you rush to ensure your two-factor secrets are safe in the event you lose your device, take heed: The sync process isn't end-to-end encrypted.

The lack of synchronization encryption was pointed out in a tweet by two-man developer and security research team Mysk, which said it found the problem by analyzing network traffic during the secret-syncing process. 

According to the pair, whose discoveries we've covered in the past, this means the seed used to generate 2FA codes is being transmitted without E2EE and is likely visible to Google when stored on its servers. Because seeds are being synced to a Google account, an account compromise would mean all those second factors are compromised, too.

Christiaan Brand, Google's product manager for identity and security, took to Twitter to reassure users they shouldn't be concerned because "we're always focused on the safety and security of Google users and the newest update to Google Authenticator was no exception." 

Brand said Google encrypts data in transit and at rest across its products. He asserted that E2EE provides extra protections, but at the cost of potentially being locked out of one's data without a recovery option. Brand added that Google is beginning to roll out E2EE in some of its products and has plans to add it to Authenticator in the future, but a Google spokesperson told The Register it didn't have a date to share when that may happen. Aside from that statement, Google referred us to Brand's comments. 

Along with those claims, Brand also said that Google believes "our current product strikes the right balance for most users and provides significant benefits over offline use," that offline alternative being the way the app functioned prior to the update. 

Brand mentioned the offline option would remain an alternative "for those who prefer to manage their backup strategy themselves." 

Our advice – especially for those that use Google Authenticator for work-related 2FA – would be to take advantage of that offline option. At least until Google can ensure its attempt to make one-time codes "more durable" doesn't also mean leaving the shed unlocked. 

Salesforce Community users, check those user permissions

Users of Salesforce Community – a cloud-based tool that lets businesses spin up quick customer-facing websites – have a problem: Many of them aren't properly configuring user permissions, so they're leaking private data.

Community websites allow administrators to set separate permissions for authenticated users and guests, the latter of whom can access limited features without signing in. As reported by Krebs on Security, a security researcher has found a "shocking number" of Community websites are leaking data because administrators are mistakenly granting guests access to internal resources. 

This isn't a limited problem, either: Several banks, healthcare providers, and even state governments have been found exposing sensitive patient and customer data, said security researcher Charan Akiri. Akiri claims he's written a program that's identified hundreds of misconfigured sites. So now's the perfect time to double-check that admin console. 

Critical vulnerabilities of the week

Maybe all the cyber criminals had their eyes turned to RSA this week, because it was somewhat quiet on the vulnerability front. 

CISA had a couple of ICS vulnerabilities to report:

• CVSS 10.0 – Multiple CVEs: Illumina's Universal Copy Service on a number of products contains a pair of flaws that could allow an attacker to take any action at the OS level.
• CVSS 9.8 – CVE-2023-1967: Keysight N8844A Data Analytics Web Service improperly deserializes untrusted data, allowing for remote code execution. The vulnerable product has been discontinued.

CISA also warned this week that the Service Location Protocol, commonly used by network-capable printers and also by VMware software, contains an as-yet unrated vulnerability that could allow an unauthenticated remote attacker to register arbitrary services and conduct a denial of service attack using SLP to spoof UDP traffic for attack amplification. CISA recommends disabling or restricting network access to SLP servers to avoid the issue.

Speaking of VMware, it reported a critical exploit this week, too:

• CVSS 9.3 – multiple CVEs: VMware Workstation Pro and VMware Fusion contain a stack-based buffer overflow vulnerability in how they share Bluetooth devices with virtual machines that can allow an attacker to execute code as the VM's VMX process. Patches are available.

New Intel CPU side-channel attack discovered

Just when you thought it was safe to go back in the water, another Meltdown side-channel attack has been discovered, and it might be worse than the original.

In a report [PDF] by a team of international researchers from the US and China, the attack affects multiple generations of Intel CPUs and targets the EFLAGS register using a transient execution flaw to change context execution time. By reading the time changes, the researchers said they were able to decode data. 

To make matters worse, the researchers indicate that their attack doesn't rely on the CPU's cache, and doesn't need to reset the EFLAGS register to its initial state – both of which may mean it's more difficult to detect or mitigate than other side-channel attacks. 

On experimental runs targeting Ubuntu 22.04 machines, the researchers claim they achieved 100 percent data retrieval on machines using Intel i7-6700 and i7-7700 CPUs, with more limited success against Intel i9-10980XE CPUs.

The researchers suggest there are a couple of possible mitigation strategies, which would require changes to how jump on condition codes (JCC) instructions are implemented (JCC timing instructions are affected by the exploit), and forcing a rewrite of the EFLAGS register after transient execution. 

"To the best of our knowledge, this is the first time that the EFLAGS register has been used as a side-channel," the researchers wrote. We'd say get patching, but there's only so much you can do about this one. ®