Google’s Solution to Cookie Theft: New Device-Bound Cookies

We seamlessly surf the web, switch between websites, interact with various contents, and session cookies do their work in the background quietly, making our interactions with websites smooth and efficient. They play a crucial yet often unnoticed role in improving our online experiences. Whether you’re adding items to your shopping cart, logging into your favorite social media platform, or simply browsing different pages of a website, session cookies are at work behind the scenes.

However, the nature of these cookies, which makes them useful, also makes them vulnerable to threats, such as cookie theft. These threats exploit the way session cookies store and transmit session data. The stolen data, as well as the credentials extracted from the device, can then be sold on various dark web forums. One of the malware types that steal information from the device is stealer malware. You can check our blog post to find out more about their workings or download our Whitepaper on stealer logs to find out how these stealers target different regions or industries.

The Google Chrome team has been developing a new feature that would bind authentication sessions to the device to disrupt the cookie theft industry. With this development, threat actors will be forced to work locally on the device, which makes their operations even harder.

In this blog post, we will explain cookies briefly, how threat actors target them and give details about the new Device-Bound cookies the Google team is working on. Feel free to jump to any section you desire.

How Does Cookie Theft Work?

The goal of the Google Team that created the DBSC cookies is to reduce pass-the-cookie attacks, a method of session hijacking that gives attackers access to accounts that have session cookies saved in individuals’ browsers.

By taking session cookies from a user’s web browser, an attacker can impersonate the user and access their accounts without authorization. This technique is known as session hijacking. This can happen via a number of techniques, including phishing attacks when the user is misled into visiting a fake website that enables the threat actor to carry on, Man-in-the-Middle (MitM) attacks, Cross-Site Scripting (XSS), as well as by using other malware. After obtaining the session cookie, the attacker can exploit it to get access to user accounts by posing as the user and entering it into their own browser. Since the service the attacker is trying to access will receive a cookie it already recognizes, it will allow the attacker in.

Do you want to ensure that your organization is safe from stealers? You can check our Identity & Access Intelligence to find out if threat actors are selling your employees’ passwords on malicious forums. Our module also gives you insights about the location of the malware so you can clear your systems.

What is the Problem With the Current System for Cookies

Cookies are small pieces of data stored by a web browser that can hold various information, including authentication details. In our current systems, possession of the cookie is enough to grant access to a specific service that requested the creation of that cookie in the first place. Anyone who has the cookie can authenticate, regardless of who they are. The primary issue here is that there is no verification of the identity of the holder of that cookie beyond possession of it. This is a security risk because when someone else gets hold of the cookie, they can impersonate the legitimate user.

For the browser to function correctly and maintain sessions, it needs access to these cookies, making them potentially vulnerable to malware because if malware is present, it can access the same resources that the web browser can access, including cookies. And since the ability of an operating system to separate and protect different applications from each other is not good, if one application is compromised, it can affect others.

However, the system Google is trying to bring comes with private keys. This private key authentication system involves using a private cryptographic key to authenticate a user. Unlike the regular system we have now, this method relies on cryptographic proof rather than simple possession of the cookies. Here, Google mentions the use of system-level protection. Many operating systems provide strong protections for cryptographic keys, such as Hardware Security Modules (HSMs) or secure key storage areas. The protection Google plans to use comes from TPMs.

What is TPM?

Using a TPM (Trusted Platform Module) enhances your computer’s security. It can be used to safely generate and store cryptographic keys and verify that the firmware and operating system on your device are what they should be and haven’t been altered. Previously, there was a need for a separate chip for the TPM. With the TPM 2.0 standard, the need for a separate chip on the motherboard dedicated to TPM is now gone. Chipset makers can now incorporate TPM functionality directly into their chipsets.

Google Chrome Team is also studying the TPM’s current status which is a worry for the implementation of DPSC due to TPM’s latency and its not very widespread use but according to their statement “TPMs are widely available, with a latency and consistency that is acceptable for the proposed usage.”

What is the Solution DBSC Brings?

DBSC uses cryptographic keys tied to a specific device, which cannot normally be transferred from the device. This concept is referred to as “device binding” by the Google Chrome Team. DBSC provides an API that websites can use to manage the lifespan of cryptographic keys. These keys are associated with sessions, and there’s a system in place to regularly verify to the server that the keys are still in the user’s possession.

The API allows servers to establish sessions that are linked to specific devices. When a user signs in, the API notifies the browser that a new session has begun, prompting the generation of a new cryptographic key. These sessions can be periodically renewed with a cryptographic proof to confirm that the session is still connected to the same device.

The API directs the browser to check for specific cookies every time a request is made during an active session. If the required cookies are missing, DBSC will pause network requests and contact the specified endpoint to obtain the necessary cookies before proceeding. By linking the private key to the device and regularly proving key possession, the browser can reduce the risk of malware transferring the key for misuse elsewhere.

Speaking of APIs and working with 3rd parties, how sure are you about the approach of your business partners to security? Do you want to make sure that the dark web forums are not full of credentials from your suppliers? Well, you can check our Supply Chain Intelligence module to see if the organizations you work with have any security problems. By having a comprehensive understanding of your surroundings, you can build a better cooperation mechanism and make sure that none of your business partners are creating security risks.

Conclusion

Cookies have long been a staple of web authentication due to their simplicity and ease of use. However, they come with inherent security risks. By the use of device-specific cryptographic keys and periodic checks, DBSC can bring a higher security standard for cookie management.

While it is not a certain solution to cookie theft, obtaining those cookies will be a lot harder for criminals and the time threat actors can exploit those cookies will reduce significantly due to routine checks. The approach of device binding and regular verification not only mitigates the risk of cookie theft but also empowers browsers and servers to detect and respond to potential security threats more effectively. We can expect further advancements here with the development of different solutions to this approach, enhancing the security of sessions and improving cookie management.

Google is developing this new approach in the open. You can follow their GitHub page for the developments or their estimated timeline. Their goal is to allow origin trials for all interested websites by the end of 2024.