This a nice practical technique for extracting Chrome cookies, and is slightly less work than the alternative of writing a cookie db decyptor based on Chromium’s publicly available source code.
On platforms that have a decent OS-level keychain API (not Windows), this technique does not actually bypass password encryption and may trigger a password prompt/require the user to enter their password. This depends on whether the user previously granted permanent access to a given secret by a given application (e.g. by clicking “Always Allow” in the macOS keychain prompt). The author of the exploit probably did this at some point and forgot about it, which is why this appears to be a bypass of Chrome’s cookie db encryption.
Ultimately, encrypting the cookie DB provides limited protection anyway and if you have user privileges then you’ll eventually be able to access their data. This is not news, although it was the topic of some controversy back when Chrome resisted making changes to support this specific threat model, which is impossible to completely defend in the general case from the POV of a typical application developer on a modern desktop OS.
Depends how the encryption works - you only need to compute the cookie database key once.
Of course, regardless of what they do, you could probably just run a quick Frida (https://frida.re/) script to patch into Chrome and dump the key to disk when the decryption function is called.
From the 10 immutable laws of security:
Law #1: If a bad guy can persuade you to run his program on your computer, it's not solely your computer anymore.
Replayed later no, but a naive TOTP implementation will likely allow you to reuse an code more than once as long as you log in within the 30-second x N-lookback window.
If you prefer, as a local physical user you can also install a physical keylogger between the keyboard and computer. Or replace the executable with one that is backdoored, and read the cookies directly from memory.
The point is that you pwned the computer already, and this is just one of dozens of things you could already do with that privilege.
If memory serves me Firefox cookies are stored unencrypted in an sqlite database with user level permissions. Haven't dug too deep, so I could be missing something, but last time I peaked down the rabbit hole that's what I remember.
Windows’ OS keychain API is pretty weak, accessing secrets does not require user authorization. macOS and some Linux desktops environments do it slightly better, but there’s only so much you can do to defend against an attacker with the same privileges as the user.
unencrypted if you want to. firefox always allowed a password so it is encrypted at rest. you will have to pry it out of the process memory after the user type the password.
Why can't any code that want's to steal your passwords in firefox's DB just use firefox's open source code to decrypt? Firefox requires no password to start up and access your passwords so why couldn't any other code just follow the same process?
True. They suggest you use a master password, which solves this problem. But if you ignore that it will generate one for you which will only make it a little bit more annoying for anyone trying to steal directly from the offline file.
* Normally you can't access Chrome's decrypted cookie storage unless you're in an interactive session and you've unlocked the keychain.
* An attacker running code on your computer (nefarious NPM package, etc) can spawn a headless chrome session with remote debugging enabled and then slurp out all the decrypted cookies through the remote debugging socket
Chrome is very frightening to me. It's just this massive God program that has a huge attack surface and a lot of really valuable goodies like this that attackers would love to get at.
Most desktop OSes aren't designed to defend applications run by the same user from one another. As a consequence an attacker running unsandboxed code with your user privileges is an attack that's very difficult to defend against.
Chrome is very frightening to me. It's just this massive God program that has a huge attack surface and a lot of really valuable goodies like this that attackers would love to get at.
I think the right way to look at it is that it's a smaller OS. Different in nature, but browsers are now in the OS league for how much damage a compromise can do.
The issue is that normally a user has to enter their password in Chrome or, if you want their cookies, you need to modify the chrome binary itself to steal them. The problem with headless chrome is that any application can now steal these cookies. Before if you wanted to do that with local malware you needed to do something much more noisy (create a fake chrome window, etc). You couldn't just do a File.read("chrome/cookies.txt").
Now you can, and that is stupid. To enable headless mode should require root.
If you can run code with the same privileges as Chrome (under an authenticated user account), then on most desktop OSes, you can do whatever Chrome can do, including access the password
store.
This may be a more convenient way to do so, but ultimately it's an attack that's rather hard to defend against under the usual desktop user-based access control model.
If the passwords are encrypted at rest via secure enclave then that isn't true[0] aside from other noisy attacks[1]. Yes local untrusted code is bad and a dedicated attacker attacking a specific target can probably escalate to stealing a full chrome cookies file, but that type of attack won't be worked into random malware floating around.
>The issue is that normally a user has to enter their password in Chrome or, if you want their cookies, you need to modify the chrome binary itself to steal them
or you could go to the site, autofill the password, then extract the password input's value using the dev console.
To reproduce, or utilize [it's a feature not a bug ;)] Whenever I forget my password to enter on a secondary device and don't want to unlock the keychain, I just go the site, logout, let it autofill the password and paste my lame script in the console. Whee!
var inputs = document.getElementsByTagName('input');
for(var i = 0; i < inputs.length; i++) {
if(inputs[i].type.toLowerCase() == 'password') {
alert(inputs[i].value);
}
}
Disguise it as an extension with other functionality to get people to download it. Or, like this posted thread, if you have access to the PC, just install and run it.
I dont know if it counts, but I have used a version of this (without the decryption) to restore all my settings after I reinstalled Chrome. (I dont use chrome's google sign in or auto sync). Here is what I did. I am sure you can write/execute code on any computer to do that.
1/ Take the backup of Data/Profile X folder under AppData/Local/Google.
2/ Did a fresh Chrome uninstall and install.
3/ Copy paste and override the folder.
It worked flawlessly and I got my old settings/sessions etc. back.
I have tried it doing it from one machine to another - it worked, and with certain subfolders. You only need a few files. I took cache folder just to be safe and things like history, session, bookmarks, along with Cookies, Cookie journal, and local storage. (you might not need the last two.). Of course, this is a year old, and could be patched. But I was able to get my logins back with no debugger needed. A handy way if you are looking to do a fresh install and get rid of faulty chrome. But someone somewhere can write a powershell script to do this (and transfer on cloud) and a lot of gullible folks can fall for this in the promise of things like 'Faster chrome', 'improve speed of your chrome' etc. and should be patched.
So... basically... the same thing you could already do with sqlite?
ETA: And really, more websites need to bind cookies to an IP address (or at least a /24). Although if the attacker's got code execution that won't really help. (Nothing will.)
I travel quite a lot, and sometimes connect without a VPN. Last time I login to Google was from Sri Lanka, and now I'm in Georgia, having g traveled everywhere in Europe and South East Asia (so not the same /24), but I never had to log in again.
The same goes for Facebook, GitHub, HN, Reddit, Yahoo, and Hotmail. These are enough to ruin someones life I guess.
I love how Github's access system works. Everytime I want to delete something, add SSH/GPG keys, etc, they prompt the passwords again.
You can just read the thread linked from that bug.
* Endpoint compromise is (and has been for awhile) outside of Chrome's threat model. This comes up a lot. The simple way to understand it is that the Chromium team refuses to get into an arms race with malware developers to protect secrets from code running at the same (or greater) privilege level as Chromium itself.†
* Token Binding is a particularly complicated feature, so the effort/reward calculation was unfriendly.
* Nobody was using it (on the clientside, with extension developers or people enabling the feature flag, or on the serverside, with major sites actually enabling it).
* Token Binding alters the semantics for cookies, which the rest of the development ecosystem generally assumes to be simple bearer tokens, which has the effect of breaking features and extensions that depend on those semantics. Again, if the reward were higher, this wouldn't have been a dealbreaker.
Token binding is, I think, pretty much a dead letter at this point.
† FWIW: I think this is a super-reasonable position for them to take.
Token Binding protects against more than just endpoint compromise. It protects against users who copy and paste their cookies somewhere (possibly due to phishing, or due to just debugging why a request is failing). It protects against webservers that log cookies, and those logs leak or are disclosed wider than they should be. It sometimes provides protection against https MITM (via stolen or mississued https certs/private keys). It provides protection against other types of cookie leakage, for example Cloudbleed.
I'm just recapping the thread. I don't have a strong position on token binding (we wrote about it a tiny bit in our inter-services authentication post).
Chrome is encrypting the cookies at rest so there is some protection of the secrets. I wish Chrome would allow a master password (per profile) to further protect the stored passwords and cookies.
On platforms that have a decent OS-level keychain API (not Windows), this technique does not actually bypass password encryption and may trigger a password prompt/require the user to enter their password. This depends on whether the user previously granted permanent access to a given secret by a given application (e.g. by clicking “Always Allow” in the macOS keychain prompt). The author of the exploit probably did this at some point and forgot about it, which is why this appears to be a bypass of Chrome’s cookie db encryption.
Ultimately, encrypting the cookie DB provides limited protection anyway and if you have user privileges then you’ll eventually be able to access their data. This is not news, although it was the topic of some controversy back when Chrome resisted making changes to support this specific threat model, which is impossible to completely defend in the general case from the POV of a typical application developer on a modern desktop OS.