Google Workspace (formerly G Suite) now has stronger protections for risky account actions, automatically blocking hijacking attempts with identity verification prompts and logging them for further investigation.
This added layer of security will block threat actors who gain access to a user’s account to protect personal data and sensitive information belonging to their organization.
The enhanced account protection capabilities are available to all Google Workspace customers, including legacy G Suite Basic and Business customers.
“Google will evaluate the session attempting the action, and if it’s deemed risky, it will be challenged with a ‘Verify it’s You’ prompt,” Google said.
“Through a second and trusted factor, such as a 2-step verification code, users can confirm the validity of the action.”
For instance, this new feature would block sensitive actions such as attempts to change the account’s name until “the true account owner can verify that this was intentional.”
Admins can disable it for users stuck behind login prompts
Google added that admins could also temporarily disable login challenges triggered on sensitive account actions for users who can’t get past the verification prompts.
“In the Admin console under Users > ‘UserName’> Security, admins can toggle login challenges OFF for ten minutes if a user gets stuck behind a ‘verify it’s you prompt’,” the company explained.
“We strongly recommend only using this option if contact with the user is credibly established, such as via a video call.”
It’s also important to mention that this feature only supports users using Google as their identity provider, blocking actions taken within Google products, with SAML users not being supported now.
Google has further secured Workspace users from attacks by rolling out new Google Drive warning banners in January to warn them of potentially suspicious files used for malware delivery and phishing attacks.
A new large-scale phishing campaign targeting Coinbase, MetaMask, Kraken, and Gemini users is abusing Google Sites and Microsoft Azure Web App to create fraudulent sites.
These phishing pages are promoted through comments posted to legitimate sites by a network of bots controlled by the threat actors. Posting links to phishing pages on various legitimate sites aims to increase traffic and boost the malicious site’s search engine rankings.
Furthermore, because the phishing sites are hosted in Microsoft and Google services, they aren’t flagged by automated moderator systems, allowing promotional messages to stay in the comment section for longer.
The new campaign was spotted by analysts at Netskope, who noted that this tactic has allowed some of the fraudulent sites to appear as the first result in Google Search.
Even worse, as shown below, Google has also included the phishing pages as featured snippets, giving them the highest exposure possible in the search results.
Abusing legitimate services
Google Sites is a free web page creation tool, part of Google’s online service suite, allowing users to create websites and host them on Google Cloud or other providers.
Similarly, Microsoft’s Azure Web Apps is a platform helping users create, deploy, and manage web applications and websites.
Both services are trusted by internet security tools, offer competitive pricing and high availability, so they are a good option for creating phishing pages.
The crooks in the campaign seen by Netskope created sites that mimicked Metamask, Coinbase, Gemini, and Kraken, targeting people’s wallets and their assets.
The sites are just landing pages, and their visitors are redirected to the actual phishing sites when they click on the “login” buttons.
Targeting wallets and services
The phishing campaign is currently attempting to steal MetaMask wallets and credentials for crypto exchanges, such as CoinBase, Kraken, and Gemini.
The MetaMask phishing site attempts to steal the user’s password and wallet’s secret recovery phrase (seed phrase). This information allows the threat actor to import the wallet on their own devices and drain the contents.
For the crypto exchange phishing pages, the threat actors attempt to steal their login credentials.
In all four cases, users who enter their credentials are redirected to a fake 2FA (two-factor authentication) page that requests the victim to provide their phone number.
After entering the code, the websites generate a fake error alleging unauthorized activity and authentication problems, prompting the victim to click on an “Ask Expert” button.
This takes the victims to an online chat page where a scammer pretending to be a customer support agent promises to solve the problem by directing the victim to install the TeamViewer remote access tool.
The remote access is likely to allow the threat actors to retrieve the multi-factor authentication codes required to log in to the exchanges with the stolen credentials.
Don’t get phished
When attempting to log in to a crypto exchange, always make sure you are on the platform’s official website and not on a clone.
Users of locally installed cryptocurrency wallets, such as MetaMask, Phantom, and TrustWallet, should never share their recovery phrase on any website, regardless of the reason.
It is also important to remember that Google Ads can be abused, and Google Search SEO can be manipulated, so the ranking of the results shouldn’t be seen as a guarantee of safety.
Finally, protect your cryptocurrency exchange accounts with MFA and keep most of your crypto investments on cold wallets that are much more challenging to hack.
Google on Wednesday said it’s once again delaying its plans to turn off third-party cookies in the Chrome web browser from late 2023 to the second half of 2024.
“The most consistent feedback we’ve received is the need for more time to evaluate and test the new Privacy Sandbox technologies before deprecating third-party cookies in Chrome,” Anthony Chavez, vice president of Privacy Sandbox, said.
In keeping this in mind, the internet and ad tech giant said it’s taking a “deliberate approach” and extending the testing window for its ongoing Privacy Sandbox initiatives prior to phasing out third-party cookies.
Cookies are pieces of data planted on a user’s computer or other device by the web browser as a website is accessed, with third-party cookies fueling much of the digital advertising ecosystem and its ability to track users across different sites to show targeted ads.
Privacy Sandbox is Google’s umbrella term for a set of technologies that aim to improve users’ privacy across the web and Android by limiting cross-site and cross-app tracking and offering improved, safer alternatives to serve interest-based ads.
While Google had originally planned to roll out the feature in early 2022, it revised the timeline in June 2021, pushing its proposal to transition from third-party cookies over a three-month period, starting in mid-2023 and ending in late 2023.
“It’s become clear that more time is needed across the ecosystem to get this right,” the company noted at the time.
In February 2022, the U.K. Competition and Markets Authority (CMA) formally accepted commitments from Google over how it develops the technology, pointing out the need to flesh out Privacy Sandbox such that it promotes competition and supports publishers to raise revenue from ads while also safeguarding consumer privacy.
Under the new plan, Privacy Sandbox trials are expected to be expanded to users globally next month, with the number of users included in the tests ramped up throughout the rest of the year and into 2023.
Google also emphasized that users will be shown a prompt to manage their participation, adding it intends to make the APIs generally available by Q3 2023, with third-party cookie support tentatively dropped in H2 2024.
The CMA, for its part, acknowledged today that it’s aware of “alternative proposals being developed by third-parties,” and that it’s “working with the [Information Commissioner’s Office] to better understand their viability and likely impacts.”
Posted by Matthew Maurer and Mike Yu, Android team
To help keep Android users’ DNS queries private, Android supports encrypted DNS. In addition to existing support for DNS-over-TLS, Android now supports DNS-over-HTTP/3 which has a number of improvements over DNS-over-TLS.
Most network connections begin with a DNS lookup. While transport security may be applied to the connection itself, that DNS lookup has traditionally not been private by default: the base DNS protocol is raw UDP with no encryption. While the internet has migrated to TLS over time, DNS has a bootstrapping problem. Certificate verification relies on the domain of the other party, which requires either DNS itself, or moves the problem to DHCP (which may be maliciously controlled). This issue is mitigated by central resolvers like Google, Cloudflare, OpenDNS and Quad9, which allow devices to configure a single DNS resolver locally for every network, overriding what is offered through DHCP.
In Android 9.0, we announced the Private DNS feature, which uses DNS-over-TLS (DoT) to protect DNS queries when enabled and supported by the server. Unfortunately, DoT incurs overhead for every DNS request. An alternative encrypted DNS protocol, DNS-over-HTTPS (DoH), is rapidly gaining traction within the industry as DoH has already been deployed by most public DNS operators, including the Cloudflare Resolver and Google Public DNS. While using HTTPS alone will not reduce the overhead significantly, HTTP/3 uses QUIC, a transport that efficiently multiplexes multiple streams over UDP using a single TLS session with session resumption. All of these features are crucial to efficient operation on mobile devices.
DNS-over-HTTP/3 (DoH3) support was released as part of a Google Play system update, so by the time you’re reading this, Android devices from Android 11 onwards1 will use DoH3 instead of DoT for well-known2 DNS servers which support it. Which DNS service you are using is unaffected by this change; only the transport will be upgraded. In the future, we aim to support DDR which will allow us to dynamically select the correct configuration for any server. This feature should decrease the performance impact of encrypted DNS.
DNS-over-HTTP/3 avoids several problems that can occur with DNS-over-TLS operation:
As DoT operates on a single stream of requests and responses, many server implementations suffer from head-of-line blocking3. This means that if the request at the front of the line takes a while to resolve (possibly because a recursive resolution is necessary), responses for subsequent requests that would have otherwise been resolved quickly are blocked waiting on that first request. DoH3 by comparison runs each request over a separate logical stream, which means implementations will resolve requests out-of-order by default.
Mobile devices change networks frequently as the user moves around. With DoT, these events require a full renegotiation of the connection. By contrast, the QUIC transport HTTP/3 is based on can resume a suspended connection in a single RTT.
DoT intends for many queries to use the same connection to amortize the cost of TCP and TLS handshakes at the start. Unfortunately, in practice several factors (such as network disconnects or server TCP connection management) make these connections less long-lived than we might like. Once a connection is closed, establishing the connection again requires at least 1 RTT.In unreliable networks, DoH3 may even outperform traditional DNS. While unintuitive, this is because the flow control mechanisms in QUIC can alert either party that packets weren’t received. In traditional DNS, the timeout for a query needs to be based on expected time for the entire query, not just for the resolver to receive the packet.
Field measurements during the initial limited rollout of this feature show that DoH3 significantly improves on DoT’s performance. For successful queries, our studies showed that replacing DoT with DoH3 reduces median query time by 24%, and 95th percentile query time by 44%. While it might seem suspect that the reported data is conditioned on successful queries, both DoT and DoH3 resolve 97% of queries successfully, so their metrics are directly comparable. UDP resolves only 83% of queries successfully. As a result, UDP latency is not directly comparable to TLS/HTTP3 latency because non-connection-oriented protocols have a different notion of what a “query” is. We have still included it for rough comparison.
The DNS resolver processes input that could potentially be controlled by an attacker, both from the network and from apps on the device. To reduce the risk of security vulnerabilities, we chose to use a memory safe language for the implementation.
Fortunately, we’ve been adding Rust support to the Android platform. This effort is intended exactly for cases like this — system level features which need to be performant or low level (both in this case) and which would carry risk to implement in C++. While we’ve previously launched Keystore 2.0, this represents our first foray into Rust in Mainline Modules. Cloudflare maintains an HTTP/3 library called quiche, which fits our use case well, as it has a memory-safe implementation, few dependencies, and a small code size. Quiche also supports use directly from C++. We considered this, but even the request dispatching service had sufficient complexity that we chose to implement that portion in Rust as well.
We built the query engine using the Tokio async framework to simultaneously handle new requests, incoming packet events, control signals, and timers. In C++, this would likely have required multiple threads or a carefully crafted event loop. By leveraging asynchronous in Rust, this occurs on a single thread with minimal locking4. The DoH3 implementation is 1,640 lines and uses a single runtime thread. By comparison, DoT takes 1,680 lines while managing less and using up to 4 threads per DoT server in use.
Safety and Performance — Together at Last
With the introduction of Rust, we are able to improve both security and the performance at the same time. Likewise, QUIC allows us to improve network performance and privacy simultaneously. Finally, Mainline ensures that such improvements are able to make their way to more Android users sooner.
Special thanks to Luke Huang who greatly contributed to the development of this feature, and Lorenzo Colitti for his in-depth review of the technical aspects of this post.
Some Android 10 devices which adopted Google Play system updates early will also receive this feature. ↩
Google DNS and Cloudflare DNS at launch, others may be added in the future. ↩
DoT can be implemented in a way that avoids this problem, as the client must accept server responses out of order. However, in practice most servers do not implement this reordering. ↩
There is a lock used for the SSL context which is accessed once per DNS server, and another on the FFI when issuing a request. The FFI lock could be removed with changes to the C++ side, but has remained because it is low contention. ↩
ChromeOS Flex is a lightweight operating system from Google, which you can install on Windows, Mac, and Linux computers with older hardware, such as an old laptop or desktop computer. The operating system is based on Linux which uses web apps and the Chrome browser as the main interface.
The operating system also gives you security protection from threats such as malware and ransomware, and users will get a fast and modern work environment with background updates reducing downtime while boosting productivity.
Although Google offers many Chromebooks from different manufacturers that come preloaded with ChromeOS, the company now provides the ChromeOS Flex variant to give old computers a second life, especially for devices not compatible with Windows 11.
This guide will teach you the steps to install ChromeOS Flex on an old Windows-based computer.
Click the Extension button and select the Chromebook Recovery Utility extension.
Click the Get started button.
Select the Google ChromeOS Flex option.
Select the ChromeOS Flex option.
Click the Continue button.
Select the USB flash media from the list.
Click the Continue button.
Click the Create now button.
Click the Done button.
Once you complete the steps, you can proceed with the clean installation of ChromeOS Flex.
Install ChromeOS Flex
To install ChromeOS Flex on a Windows device, use these steps:
Start the laptop with the ChromeOS Flex USB.Quick note: If the computer can’t boot from USB, you may need to update the BIOS/UEFI settings. This process usually requires pressing one of the function keys (F1, F2, F3, F10, or F12), the ESC, or the Delete key. For more accurate instructions, visit your PC manufacturer’s support website.
Click the Get Started button.
Select the “Try it first” option.Quick note: In this guide, we’ll use the “Try it first” option, but if you plan to dedicate the device to the operating system, select the “Install CloudReady 2.0” option.
Click the Next button.
Select the wireless network.
Confirm the Wi-Fi password.
Click the Connect button.
Click the Accept and continue button.
Select the You option to create an account.
Click the Next button.
Confirm your Gmail account.
Click the Next button.
Confirm the account password.
Click the Next button.
Complete the account verification.
Click the Next button.
Click the Accept and continue button.
After you complete the steps, the operating system will install on the computer.
A group of academics from the New Jersey Institute of Technology (NJIT) has warned of a novel technique that could be used to defeat anonymity protections and identify a unique website visitor.
“An attacker who has complete or partial control over a website can learn whether a specific target (i.e., a unique individual) is browsing the website,” the researchers said. “The attacker knows this target only through a public identifier, such as an email address or a Twitter handle.”
The cache-based targeted de-anonymization attack is a cross-site leak that involves the adversary leveraging a service such as Google Drive, Dropbox, or YouTube to privately share a resource (e.g., image, video, or a YouTube playlist) with the target, followed by embedding the shared resource into the attack website.
This can be achieved by, say, privately sharing the resource with the target using the victim’s email address or the appropriate username associated with the service and then inserting the leaky resource using an <iframe> HTML tag.
In the next step, the attacker tricks the victim into visiting the malicious website and clicking on the aforementioned content, causing the shared resource to be loaded as a pop-under window (as opposed to a pop-up) or a browser tab — a method that’s been used by advertisers to sneakily load ads.
This exploit page, as it’s rendered by the target’s browser, is used to determine if the visitor can access the shared resource, successful access indicating that the visitor is indeed the intended target.
The attack, in a nutshell, aims to unmask the users of a website under the attacker’s control by connecting the list of accounts tied to those individuals with their social media accounts or email addresses through a piece of shared content.
In a hypothetical scenario, a bad actor could share a video hosted on Google Drive with a target’s email address, and follow it up by inserting this video in the lure website. Thus when visitors land on the portal, a successful loading of the video could be used as a yardstick to infer if their victim is one among them.
The attacks, which are practical to exploit across desktop and mobile systems with multiple CPU microarchitectures and different web browsers, are made possible by means of a cache-based side channel that’s used to glean if the shared resource has been loaded and therefore distinguish between targeted and non-targeted users.
Put differently, the idea is to observe the subtle timing differences that arise when the shared resource is being accessed by the two sets of users, which, in turn, occurs due to differences in the time it takes to return an appropriate response from the web server depending on the user’s authorization status.
The attacks also take into account a second set of differences on the client-side that happens when the web browser renders the relevant content or error page based on the response received.
“There are two main causes for differences in the observed side channel leakages between targeted and non-targeted users – a server-side timing difference and a client-side rendering difference,” the researchers said.
While most popular platforms such as those from Google, Facebook, Instagram, LinkedIn, Twitter, and TikTok were found susceptible, one notable service that’s immune to the attack is Apple iCloud.
It’s worth pointing out the de-anonymization method banks on the prerequisite that the targeted user is already logged in to the service. As mitigations, the researchers have released a browser extension called Leakuidator+ that’s available for Chrome, Firefox, and Tor browsers.
To counter the timing and rendering side channels, website owners are recommended to design web servers to return their responses in constant time, irrespective of whether the user is provisioned to access the shared resource, and make their error pages as similar as possible to the content pages to minimize the attacker-observable differences.
“As an example, if an authorized user was going to be shown a video, the error page for the non-targeted user should also be made to show a video,” the researchers said, adding websites should also be made to require user interaction before rendering content.
“Knowing the precise identity of the person who is currently visiting a website can be the starting point for a range of nefarious targeted activities that can be executed by the operator of that website.”
The findings arrive weeks after researchers from the University of Hamburg, Germany, demonstrated that mobile devices leak identifying information such as passwords and past holiday locations via Wi-Fi probe requests.
In a related development, MIT researchers last month revealed the root cause behind a website fingerprinting attack as not due to signals generated by cache contention (aka a cache-based side channel) but rather due to system interrupts, while showing that interrupt-based side channels can be used to mount a powerful website fingerprinting attack.
New survey reveals lack of staff, skills, and resources driving smaller teams to outsource security.
As business begins its return to normalcy (however “normal” may look), CISOs at small and medium-size enterprises (500 – 10,000 employees) were asked to share their cybersecurity challenges and priorities, and their responses were compared the results with those of a similar survey from 2021.
Here are the 5 key things we learned from 200 responses:
1 — Remote Work Has Accelerated the Use of EDR Technologies
In 2021, 52% of CISOs surveyed were relying on endpoint detection and response (EDR) tools. This year that number has leapt to 85%. In contrast, last year 45% were using network detection and response (NDR) tools, while this year just 6% employ NDR. Compared to 2021, double the number of CISOs and their organizations are seeing the value of extended detection and response (XDR) tools, which combine EDR with integrated network signals. This is likely due to the increase in remote work, which is more difficult to secure than when employees work within the company’s network environment.
2 — 90% of CISOs Use an MDR Solution
There is a massive skills gap in the cybersecurity industry, and CISOs are under increasing pressure to recruit internally. Especially in small security teams where additional headcount is not the answer, CISOs are turning to outsourced services to fill the void. In 2021, 47% of CISOs surveyed relied on a Managed Security Services Provider (MSSP), while 53% were using a managed detection and response (MDR) service. This year, just 21% are using an MSSP, and 90% are using MDR.
3 — Overlapping Threat Protection Tools are the #1 Pain Point for Small Teams
The majority (87%) of companies with small security teams struggle to manage and operate their threat protection products. Among these companies, 44% struggle with overlapping capabilities, while 42% struggle to visualize the full picture of an attack when it occurs. These challenges are intrinsically connected, as teams find it difficult to get a single, comprehensive view with multiple tools.
4 — Small Security Teams Are Ignoring More Alerts
Small security teams are giving less attention to their security alerts. Last year 14% of CISOs said they look only at critical alerts, while this year that number jumped to 21%. In addition, organizations are increasingly letting automation take the wheel. Last year, 16% said they ignore automatically remediated alerts, and this year that’s true for 34% of small security teams.
5 — 96% of CISOs Are Planning to Consolidate Security Platforms
Almost all CISOs surveyed have consolidation of security tools on their to-do lists, compared to 61% in 2021. Not only does consolidation reduce the number of alerts – making it easier to prioritize and view all threats – respondents believe it will stop them from missing threats (57%), reduce the need for specific expertise (56%), and make it easier to correlate findings and visualize the risk landscape (46%). XDR technologies have emerged as the preferred method of consolidation, with 63% of CISOs calling it their top choice.
The OpenSSL Technical Committee (OTC) was recently made aware of several potential attacks against the OpenSSL libraries which might permit information leakage via the Spectre attack.1 Although there are currently no known exploits for the Spectre attacks identified, it is plausible that some of them might be exploitable.
Local side channel attacks, such as these, are outside the scope of our security policy, however the project generally does introduce mitigations when they are discovered. In this case, the OTC has decided that these attacks will not be mitigated by changes to the OpenSSL code base. The full reasoning behind this is given below.
The Spectre attack vector, while applicable everywhere, is most important for code running in enclaves because it bypasses the protections offered. Example enclaves include, but are not limited to:
The reasoning behind the OTC’s decision to not introduce mitigations for these attacks is multifold:
Such issues do not fall under the scope of our defined security policy. Even though we often apply mitigations for such issues we do not mandate that they are addressed.
Maintaining code with mitigations in place would be significantly more difficult. Most potentially vulnerable code is extremely non-obvious, even to experienced security programmers. It would thus be quite easy to introduce new attack vectors or fix existing ones unknowingly. The mitigations themselves obscure the code which increases the maintenance burden.
Automated verification and testing of the attacks is necessary but not sufficient. We do not have automated detection for this family of vulnerabilities and if we did, it is likely that variations would escape detection. This does not mean we won’t add automated checking for issues like this at some stage.
These problems are fundamentally a bug in the hardware. The software running on the hardware cannot be expected to mitigate all such attacks. Some of the in-CPU caches are completely opaque to software and cannot be easily flushed, making software mitigation quixotic. However, the OTC recognises that fixing hardware is difficult and in some cases impossible.
Some kernels and compilers can provide partial mitigation. Specifically, several common compilers have introduced code generation options addressing some of these classes of vulnerability:
GCC has the -mindirect-branch, -mfunction-return and -mindirect-branch-register options
LLVM has the -mretpoline option
MSVC has the /Qspectre option
Nicholas Mosier, Hanna Lachnitt, Hamed Nemati, and Caroline Trippel, “Axiomatic Hardware-Software Contracts for Security,” in Proceedings of the 49th ACM/IEEE International Symposium on Computer Architecture (ISCA), 2022.↩
Posted by OpenSSL Technical Committee May 13th, 2022 12:00 am
Microsoft has introduced a new Microsoft Defender for Endpoint (MDE) feature in public preview to help organizations detect weaknesses affecting Android and iOS devices in their enterprise networks.
After enabling the new Mobile Network Protection feature on Android and iOS devices you want to monitor, the enterprise endpoint security platform will provide protection and notifications when it detects rogue Wi-Fi-related threats and rogue certificates (the primary attack vector for Wi-Fi networks).
Threats it can spot include rogue hardware such as Hak5 Wi-Fi Pineapple devices which both pen-testers and cybercriminals can use to capture data shared within the network.
MDE will also alert users to switch networks if it spots a suspicious or unsecured network and push notifications when it discovers open Wi-Fi networks.
While the feature is enabled by default on mobile devices, Microsoft also provides detailed info on configuring network protection on Android and iOS devices via the Microsoft Endpoint Manager Admin center.
“As the world continues to make sense of the digital transformation, networks are becoming increasingly complex and provide a unique avenue for nefarious activity if left unattended,” the company said this week.
“To combat this, Microsoft offers a mobile network protection feature in Defender for Endpoint that helps organizations identify, assess, and remediate endpoint weaknesses with the help of robust threat intelligence.”
Cross-platform endpoint security platform
This is part of a broader effort to expand Defender for Endpoint’s capabilities across all major platforms to allow security teams to defend network endpoints via a single, unified security solution.
One month later, Microsoft announced that threat and vulnerability management support for Android and iOS reached general availability in Microsoft Defender for Endpoint.
Android and iOS vulnerability management lets admins decrease mobile endpoints’ surface attack and, in the process, increase their organization’s resilience against incoming attacks.
“With this new cross-platform coverage, threat and vulnerability management capabilities now support all major device platforms across the organization – spanning workstations, servers, and mobile devices,” Microsoft said.
Earlier this month, Redmond also said that a new MDE feature allows admins to “contain” unmanaged Windows devices on their network if they were compromised or are suspected to be compromised to block malware and attackers from abusing them to move laterally through the network.
Google has released Chrome 103.0.5060.114 for Windows users to address a high-severity zero-day vulnerability exploited by attackers in the wild, the fourth Chrome zero-day patched in 2022.
“Google is aware that an exploit for CVE-2022-2294 exists in the wild.,” the browser vendor explained in a security advisory published on Monday.
The 103.0.5060.114 version is rolling out worldwide in the Stable Desktop channel, with Google saying that it’s a matter of days or weeks until it reaches the entire userbase.
This update was available immediately when BleepingComputer checked for new updates by going into Chrome menu > Help > About Google Chrome.
The web browser will also auto-check for new updates and automatically install them after the next launch.
Attack details not revealed
The zero-day bug fixed today (tracked as CVE-2022-2294) is a high severity heap-based buffer overflow weakness in the WebRTC (Web Real-Time Communications) component, reported by Jan Vojtesek of the Avast Threat Intelligence team on Friday, July 1.
The impact of successful heap overflow exploitation can range from program crashes and arbitrary code execution to bypassing security solutions if code execution is achieved during the attack.
Although Google says this zero-day vulnerability was exploited in the wild, the company is yet to share technical details or a any info regarding these incidents.
“Access to bug details and links may be kept restricted until a majority of users are updated with a fix,” Google said.
“We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.”
With this delayed release of more info on the attacks, Chrome users should have enough time to update and prevent exploitation attempts until Google provides additional details.
Fourth Chome zero-day fixed this year
With this update, Google has addressed the fourth Chrome zero-day since the start of the year.
The previous three zero-day vulnerabilities found and patched in 2022 are:
The one fixed in February, CVE-2022-0609, was exploited by North Korean-backed state hackers weeks before the February patch, according to the Google Threat Analysis Group (TAG). The earliest signs of in the wild exploitation was found on January 4, 2022.
It was abused by two North Korean-sponsored threat groups in campaigns pushing malware via phishing emails using fake job lures and compromised websites hosting hidden iframes to serve exploit kits.
Because the zero-day patched today is known to have been used by attackers in the wild, is it strongly recommended to install today’s Google Chrome update as soon as possible.