Safety  2024  2023  2022  2021  2020

Google Adds Passkeys to Advanced Protection Program for High-Risk Users
10.7.24  Safety  The Hacker News
Google on Wednesday announced that it's making available passkeys for high-risk users to enroll in its Advanced Protection Program (APP).

"Users traditionally needed a physical security key for APP — now they can choose a passkey to secure their account," Shuvo Chatterjee, product lead of APP, said.

Passkeys are considered a more secure and phishing-resistant alternative to passwords. Based on the FIDO Authentication standard, the technology is designed to secure online accounts against potential takeover attacks by ditching passwords in favor of biometrics or a PIN.
Passkeys can simultaneously act as a first- and second-factor, entirely obviating the need for a password. Earlier this May, the tech giant revealed that passkeys are being used by over 400 million Google accounts.

High-risk users, who are at an elevated exposure to cyber-attacks because of who they are and what they do (e.g., journalists, elected officials, political campaign staff, human rights workers, and business leaders), can check if they have a compatible device and browser and complete the enrollment process.

"We also require you to add recovery options during enrollment (e.g. a phone number and email, or another passkey or security key), a combination of which will help you regain access to your account if you get locked out," Chatterjee said.

Google further said it's partnering with Internews to provide journalists and human rights workers with security support. The program spans 10 countries, including Brazil, Mexico, and Poland.
The development comes as Google said it intends to expand dark web reports to any user with a Google account starting later this month to check if their information has been leaked on the darknet. The feature was previously limited to Google One subscribers.

"Dark web report will become available to all users with a consumer Google Account," it noted in a support document. "Dark web report is integrated with Results about you as a combined solution to help users protect their online presence."

Google Chrome Adds V8 Sandbox - A New Defense Against Browser Attacks
9.4.24  Safety  The Hacker News
Google has announced support for what's called a V8 Sandbox in the Chrome web browser in an effort to address memory corruption issues.

The sandbox, according to V8 security technical lead Samuel Groß, aims to prevent "memory corruption in V8 from spreading within the host process."

The search behemoth has described V8 Sandbox as a lightweight, in-process sandbox for the JavaScript and WebAssembly engine that's designed to mitigate common V8 vulnerabilities.

The idea is to limit the impact of V8 vulnerabilities by restricting the code executed by V8 to a subset of the process' virtual address space ("the sandbox") and isolating it from the rest of the process.

Shortcomings affecting V8 have accounted for a significant chunk of the zero-day vulnerabilities that Google has addressed between 2021 and 2023, with as many as 16 security flaws discovered over the time period.

"The sandbox assumes that an attacker can arbitrarily and concurrently modify any memory inside the sandbox address space as this primitive can be constructed from typical V8 vulnerabilities," the Chromium team said.

"Further, it is assumed that an attacker will be able to read memory outside of the sandbox, for example, through hardware side channels. The sandbox then aims to protect the rest of the process from such an attacker. As such, any corruption of memory outside of the sandbox address space is considered a sandbox violation."

Groß emphasized the challenges with tackling V8 vulnerabilities by switching to a memory-safe language like Rust or hardware memory safety approaches, such as memory tagging, given the "subtle logic issues" that can be exploited to corrupt memory, unlike classic memory safety bugs like use-after-frees, out-of-bounds accesses, and others.

"Nearly all vulnerabilities found and exploited in V8 today have one thing in common: the eventual memory corruption necessarily happens inside the V8 heap because the compiler and runtime (almost) exclusively operate on V8 HeapObject instances," Groß said.

Given that these issues cannot be protected by the same techniques used for typical memory-corruption vulnerabilities, the V8 Sandbox is designed to isolate V8's heap memory such that should any memory corruption occur, it cannot escape the security confines to other parts of the process' memory.

This is accomplished by replacing all data types that can access out-of-sandbox memory with "sandbox-compatible" alternatives, thereby effectively preventing an attacker from accessing other memory. The sandbox can be enabled by setting "v8_enable_sandbox" to true in the gn args.

Benchmark results from Speedometer and JetStream show that the security feature adds an overhead of about 1% on typical workloads, allowing it to be enabled by default starting with Chrome version 123, spanning Android, ChromeOS, Linux, macOS, and Windows.

"The V8 Sandbox requires a 64-bit system as it needs to reserve a large amount of virtual address space, currently one terabyte," Groß said.

"The sandbox is motivated by the fact that current memory safety technologies are largely inapplicable to optimizing JavaScript engines. While these technologies fail to prevent memory corruption in V8 itself, they can in fact protect the V8 Sandbox attack surface. The sandbox is therefore a necessary step towards memory safety."

The development comes as Google highlighted the role by Kernel Address Sanitizer (KASan) in detecting memory bugs in native code and help harden Android firmware security, adding it used the compiler-based tool for discovering more than 40 bugs.

"Using KASan enabled builds during testing and/or fuzzing can help catch memory corruption vulnerabilities and stability issues before they land on user devices," Eugene Rodionov and Ivan Lozano from the Android team said.

Google Chrome Beta Tests New DBSC Protection Against Cookie-Stealing Attacks
3.4.24  Safety  The Hacker News
Google on Tuesday said it's piloting a new feature in Chrome called Device Bound Session Credentials (DBSC) to help protect users against session cookie theft by malware.

The prototype – currently tested against "some" Google Account users running Chrome Beta – is built with an aim to make it an open web standard, the tech giant's Chromium team said.

"By binding authentication sessions to the device, DBSC aims to disrupt the cookie theft industry since exfiltrating these cookies will no longer have any value," the company noted.

"We think this will substantially reduce the success rate of cookie theft malware. Attackers would be forced to act locally on the device, which makes on-device detection and cleanup more effective, both for anti-virus software as well as for enterprise managed devices."

The development comes on the back of reports that off-the-shelf information stealing malware are finding ways to steal cookies in a manner that allows threat actors to bypass multi-factor authentication (MFA) protection and gain unauthorized access to online accounts.

Such session hijacking techniques are not new. In October 2021, Google's Threat Analysis Group (TAG) detailed a phishing campaign that targeted YouTube content creators with cookie stealing malware to hijack their accounts and monetize the access for perpetrating cryptocurrency scams.

Earlier this January, CloudSEK revealed that information stealers like Lumma, Rhadamanthys, Stealc, Meduza, RisePro, and WhiteSnake have updated their capabilities to hijack user sessions and allow continuous access to Google services even after a password reset.

Google told The Hacker News at the time that "attacks involving malware that steal cookies and tokens are not new; we routinely upgrade our defenses against such techniques and to secure users who fall victim to malware."

It further recommended users to enable Enhanced Safe Browsing in the Chrome web browser to protect against phishing and malware downloads.

DBSC aims to cut down on such malicious efforts by introducing a cryptographic approach that ties together the sessions to the device such that it makes it harder for the adversaries to abuse the stolen cookies and hijack the accounts.

Offered via an API, the new feature achieves this by allowing a server to associate a session with a public key created by the browser as part of a public/private key pair when a new session is launched.

It's worth noting that the key pair is stored locally on the device using Trusted Platform Modules (TPMs). In addition, the DBSCI API permits the server to verify proof-of-possession of the private key throughout the session lifetime to ensure the session is active on the same device.

"DBSC offers an API for websites to control the lifetime of such keys, behind the abstraction of a session, and a protocol for periodically and automatically proving possession of those keys to the website's servers," Google's Kristian Monsen and Arnar Birgisson said.

"There is a separate key for each session, and it should not be possible to detect that two different session keys are from one device. By device-binding the private key and with appropriate intervals of the proofs, the browser can limit malware's ability to offload its abuse off of the user's device, significantly increasing the chance that either the browser or server can detect and mitigate cookie theft."

One crucial caveat is that DBSC banks on user devices having a secure way of signing challenges while protecting private keys from exfiltration by malware, necessitating that the web browser has access to the TPM.

Google said support for DBSC will be initially rolled out to roughly half of Chrome's desktop users based on the hardware capabilities of their machines. The latest project is also expected to be in sync with the company's broader plans to sunset third-party cookies in the browser by the end of the year via the Privacy Sandbox initiative.

"This is to make sure that DBSC does not become a new tracking vector once third-party cookies are phased out, while also ensuring that such cookies can be fully protected in the meantime," it said. "If the user completely opts out of cookies, third-party cookies, or cookies for a specific site, this will disable DBSC in those scenarios as well."

The company further noted that it's engaging with several server providers, identity providers (IdPs), and browser vendors like Microsoft Edge and Okta, who have expressed interest in DBSC. Origin trials for DBSC for all supported websites are set to commence by the end of the year.