Chrome adopts app-bound encryption to stymie cookie-stealing malware

Google says it's enhancing the security of sensitive data managed by Chrome for Windows users to fight the scourge of infostealer malware targeting cookies.

When a cyber baddie gets a hold of a user's session cookies, they can use them to hijack those sessions, log into accounts they don't own, and then do anything the legitimate user could do, perhaps even selling the account on black markets.

Ideally, these cookies expire after a short period of time, in theory limiting the window in which they can be used for account hijacks. That's not always the case, though. Okta's incident last year involving the theft of HAR files, which often contain session cookies, illustrated how serious these attacks can be.

Starting in Chrome 127, the stable version of which was released last week, the browser now uses app-bound encryption primitives that encrypt data in a way that links it to a specific app.

Will Harris, senior software engineer on Chrome's security team, said that Google uses the most secure methods afforded to it by each operating system to safeguard Chrome secrets. For macOS, that's Keychain, and on Linux that's a wallet provided by the OS such as kwallet or gnome-libsecret.

On Windows, Chrome uses the data protection API (DPAPI), which offers strong protection, but not against malicious apps like infostealers from executing code as an authenticated user.

"App-bound encryption relies on a privileged service to verify the identity of the requesting application," Harris blogged. "During encryption, the app-bound encryption service encodes the app's identity into the encrypted data, and then verifies this is valid when decryption is attempted. If another app on the system tries to decrypt the same data, it will fail.

"Because the app-bound service is running with system privileges, attackers need to do more than just coax a user into running a malicious app. Now, the malware has to gain system privileges, or inject code into Chrome, something that legitimate software shouldn't be doing. 

"This makes their actions more suspicious to antivirus software – and more likely to be detected. Our other recent initiatives such as providing event logs for cookie decryption work in tandem with this protection, with the goal of further increasing the cost and risk of detection to attackers attempting to steal user data."

• 'LockBit of phishing' EvilProxy used in more than a million attacks every month
• W3C says Google's cookie climbdown 'undermines' a lot of work
• Oops. Apple relied on bad code while flaming Google Chrome's Topics ad tech
• Forget security – Google's reCAPTCHA v2 is exploiting users for profit

Over time, Google plans to roll out this same tech to protect other secrets like authentication tokens, passwords, and payment data.

The app-bound encryption supplements existing measures such as device-bound session cookies, which were rolled out in April. These tie a user's session to their device, meaning any stolen cookies being abused on a device that doesn't belong to the genuine user won't benefit attackers at all. They won't work.

Last week, Google also improved the security of Chrome's downloads UI, offering users more detailed explanations as to why a given download was blocked – a measure designed to make it easier for users to understand what could happen if they choose to run a malicious download, such as an infostealer.

App-bound encryption works a little like how the device-bound session cookies do in that the encryption key associated with the Chrome secret is strongly bound to the user's machine, so business users won't be able to benefit from it if they use multiple devices.

Where device roaming is essential to a given user's job, Google says to follow its best practices guide, or use the ApplicationBoundEncryptionEnabled policy. ®