Google Spent Years Securing Cookies — Hackers Took 16 Hours to Break It
Google rewrote cookie security — and accidentally helped hackers break Windows.
Google is once again in the cybersecurity spotlight after implementing a new data protection mechanism in Chrome called AppBound Cookie Encryption. Despite aiming to enhance privacy, researchers have discovered vulnerabilities in the system that allow attackers to bypass restrictions and access cookies — even with minimal privileges.
From DPAPI to AppBound Encryption
Before AppBound Cookie Encryption, malware needed access to two key files on Windows systems: the SQLite cookie database (holding encrypted data) and the Local State JSON file (holding the decryption key). The key was protected using Windows Data Protection API (DPAPI), but the system had a flaw: any process running under the same user context as the browser could decrypt the cookies.
To fix this, Google introduced a more complex encryption scheme. The new method layered in DPAPI at the SYSTEM level, restricting access to cookies to processes with SYSTEM privileges. Since Chrome itself runs as a standard user, Google introduced a special elevation service — a COM server running as SYSTEM. When cookies need to be decrypted, the browser sends a request to this service, which performs double decryption and returns the key.
Bypass Techniques: COM Hijacking and C4 Attack
Despite the architectural complexity, researchers discovered two main bypasses:
1. COM Hijacking
The elevation service is a standard COM server, making it vulnerable to hijacking. Attackers can redirect the path to the service’s executable to a fake or missing DLL. Chrome, failing to contact the proper service, falls back to the older encryption method — one vulnerable to traditional attacks. While this doesn’t expose already-stored cookies, malware can wait for new cookies to be saved and decrypt them using this legacy method.
2. C4 (Chrome Cookie Cipher Cracker)
The more dangerous flaw is C4, based on a Padding Oracle Attack — a known cryptographic technique that targets AES-CBC encryption with PKCS7 padding. While AES is secure by design, its implementation in chained block mode (CBC) is exploitable if error messages leak decryption success/failure.
In this attack, the malicious process repeatedly modifies encrypted cookie data and sends it to the elevation service for decryption. Windows logs act as an oracle by revealing whether decryption was structurally valid. Byte by byte, the attacker reconstructs the encrypted content, even though it's protected by SYSTEM-DPAPI.
Once the outer SYSTEM layer is removed, the remaining data — encrypted for the user — can be decrypted via CryptUnprotectData, since the malware runs under the same user context. Chrome applies post-processing using a hardcoded key and XOR operation, but researchers bypassed that as well.
Practical Implications
Although the C4 attack takes up to 16 hours of computation, it breaks the assumption that cookies in Chrome are securely isolated. Worse, it’s not just Chrome — any data encrypted using SYSTEM-DPAPI becomes a target.
Examples include:
- SYSTEM-DPAPI encrypted SOAP-XML credentials in Windows Credential Manager
- Scheduled task passwords saved via Task Scheduler
Security Lessons
This case highlights the risks of building new security layers on top of legacy mechanisms. AppBound Cookie Encryption, while well-intentioned, inadvertently opened new vectors for abuse by leveraging old components like DPAPI and AES-CBC.
The research team reported the vulnerabilities to Google and Microsoft:
- Google acknowledged the issue and has released a partial fix, currently disabled by default. Full patches are expected in upcoming Chrome versions.
- Microsoft declined to treat it as a security issue, citing the need for physical access and specific exploit conditions.
In conclusion, the C4 attack and AppBound Cookie Encryption flaws show that even the most advanced security systems can fail when built on imperfect foundations.
