Blog Hackers Beat Chrome’s App-Bound Encryption For Session Hijacking

Internet browsers are a major initial access attack vector for cyber attacks simply because most people are continuously using them, and they always seem to have active zero-day vulnerabilities. One need look no further than CISA's KEV to find how many Chrome vulnerabilities have been actively exploited in the past few years. 

In  the next episode of the browser hacking saga, hackers recently announced they have successfully bypassed Chrome’s App-Bound Encryption feature. This feature was only recently introduced in Chrome version 127, released July 23, 2024. This security feature was designed to protect browser-associated data—such as authentication cookies—by encrypting it, similar to how macOS Keychain encrypts data tied to app identity.

The bypass has been confirmed by several infostealer developers, including Vidar, Lumar, Lumma, Meduza, and WhiteSnake. By circumventing App-Bound Encryption, these InfoStealer malware developers have regained the ability to steal sensitive user data from Chrome, such as authentication cookies and plaintext user credentials. The stolen data can be used to hijack user sessions, gain unauthorized access to accounts, and extend attack campaigns by pivoting to new assets.

In this article we will look at the recent changes to Google Chrome intended to protect user credentials from being stolen by attackers for so called "session hijacking" attacks, and review what Google intends to do next after their solution was quickly circumvented by attackers.  Finally, we will provide a review of what session hijacking is and how cyber criminals leverage the technique for unauthorized access. 

What is Session Hijacking?

Session hijacking, also known as "cookie hijacking," is a cyber attack technique where a malicious actor takes over a legitimate user session to gain unauthorized access to web applications, services, or systems. Attackers often achieve this by intercepting or otherwise stealing session cookies or tokens. These small pieces of data are stored in the user's browser and transmitted back and forth between the user and the web server to identify the user’s active session from other people using the website. 

This type of attack allows an adversary to impersonate the victim, giving them the same privileges and access rights as the hijacked account. As a result, the attacker can perform any actions that the legitimate user is authorized to do, such as accessing sensitive data, executing transactions, or modifying user settings.

Attackers can use techniques like InfoStealer malware, packet sniffing, man-in-the-middle (MitM) attacks, or cross-site scripting (XSS) to capture these cookies.

What is Google's App-Bound Encryption?

App-Bound Encryption feature in July 2024 included in Chrome version 127. The primary purpose of App-Bound Encryption is to counteract malware, such as infostealers. After gaining initial access to a victim's computer (first-stage), second-stage malware often operates with the same privileges as the logged-in user and can therefore access sensitive data like cookies, passwords, and payment information.

App-Bound Encryption was intended to enhance data protection on Windows systems by encrypting data so only the specific application that owns the data can access it, and preventing InfoStealers from grabbing it. App-Bound Encryption binds the data to an application identity, making it accessible only to that specific application. 

However, only a few months after the technology was rolled out, hackers claim to have broken it.  Google now plans to replace App-Bound Encryption with Device Bound Session Credentials (DBSC) described below.

What is Google's New Device Bound Session Credentials (DBSC)?

Device Bound Session Credentials (DBSC) is a security feature designed to mitigate the risk of account hijacking caused by cookie and credential theft. It achieves this by introducing a new authentication mechanism that binds session credentials to a cryptographic key which is also tied directly to the user’s device. This binding ensures that even if session data, such as cookies, is stolen, it cannot be used on any device other than the one it originated from.

Technical Description of How DBSC Works

DBSC offers two key differentiators compared to traditional cookie-based authentication and previous proposals like Token Binding. Firstly, DBSC enables websites to tie session credentials closely to the user's device, making sessions more secure and controllable. Secondly, DBSC introduces a mechanism for the browser to periodically provide "proof of possession" of the session key to the backend web server. 

By binding sessions to cryptographic keys that remain on the device, DBSC significantly limits the ability of malware to use stolen cookies for session hijacking, thereby enhancing security for users and reducing the likelihood of unauthorized access.

Here is a high-level description of the DBSC process:

• Session Initialization: When a user signs into a website, DBSC informs the browser that a session has started and triggers the creation of a device-bound cryptographic key. This key is unique to each session and cannot be exported from the device.

• Session Maintenance and Proofs: DBSC instructs the browser to present a proof of possession of the cryptographic key periodically while the session is active. The proof is sent to a dedicated special refresh endpoint specified by the website. If the session key is valid, the server issues new short-lived cookies via the standard Set-Cookie header method.

• Device Binding and Cryptographic Keys: DBSC leverages cryptographic keys stored in the device's Trusted Platform Module (TPM) to prevent exfiltration by malware. The TPM is a cryptographic enclave. Even if session cookies are stolen, they cannot be used to authenticate on any other device since they have been digitally signed by the user's device.

• API Integration: Websites can use a new DBSC API in Chrome to control the lifetime and renewal of session keys, enabling more secure session management and reducing the risk of session hijacking.

Conclusion

The bypass of Chrome's App-Bound Encryption by InfoStealer malware developers demonstrates the ongoing challenge of securing web sessions against hijacking. Google plans to replace App-Bound Encryption with Device Bound Session Credentials (DBSC), a new feature that binds session credentials to a cryptographic key unique to the user’s device. This approach aims to provide enhanced security against credential theft, ensuring that stolen session data cannot be used on unauthorized devices, even if intercepted.