Stealing Chrome cookies without a password | Hacker News Reader

Stealing Chrome cookies without a password

mango.pdf.zone

125 pointsoctosphere45 comments

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.

> just need to be able to execute code on their computer

Hmm, so privilege de-escalation... You can just install a keylogger at that point, so I don't see the problem.

Not always. With 2FA a key-logger isn't enough, since the 2nd factor can't be replayed. A valid session cookie might be enough, though.

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.

Capture a token, use it yourself, and show the user an error so they generate a new token.

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.

I forgot to bookmark the link, but I think I read someone cracking the TOTP secret from a couple OTPs with their timestamps known.

guessing you've never tried to deploy a user-mode keylogger on MacOS. Usually doesn't end well...at all. Not to mention PSPs.

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.

correct

    $ find "$HOME/Library/Application Support/Firefox/Profiles" -name cookies.sqlite -exec sh -c "sqlite3 '{}' 'SELECT * FROM moz_cookies'" \;

Chrome stores them in sqlite as well. AFAIK on windows if running as the same user you just need to call CryptUnprotectData. No password needed.

http://raidersec.blogspot.com/2013/06/how-browsers-store-you...

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.

There is a master password to encryption password storage, cookies, history, etc.

They are encrypted at rest, and encrypted before sync.

Basically:

* 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.

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.

You can steal Firefox cookies and even passwords easier, they're stored unencrypted in the user profile directory.

yes i know

You can set a master password

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.

But Chrome can't access it until you've unlocked the keychain either, which means this "exploit" doesn't do anything...

Also I don't know about you but I've never needed to enter a password to start Chrome, so...

Code execution results in code execution, nothing new here. Or am I misunderstanding?

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.

[0] https://security.stackexchange.com/a/170485/117977

[1] Code that shows, say, a false user login screen or exploits a previously unknown OS vuln to escalate privileges.

>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.

'cause that wouldn't be hacking ;))

kidding aside, this could be run from a USB key, automatically, in a very stealthy way. so yeah, worse.

I just tested this and it doesn't work for me (macOS / Chrome).

Are you actually able to reproduce?

Edit: It works if you change the input type. Sigh. The web is brutal.

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); } }

Seems like the easiest path to steal chrome cookies would be to write a chrome extension. https://developer.chrome.com/extensions/cookies

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.

Google even provides a sample[1] that shows this works, here's a screenshot: https://imgur.com/a/FYdc0KY

As is, the example doesn't show the cookie contents, but you can make this change and see the cleartext cookie:

  //cell.innerText = cookies.length;
  cell.innerText = JSON.stringify(cookies);
  //cell.setAttribute("class","cookie_count");

[1] https://chromium.googlesource.com/chromium/src/+/master/chro...

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 don't think _many_ web sites do this.

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 just need to be able to execute code on their computer

means cookies are not encrypted, or rather are automagically decrypted by DPAPI layer, anything can read them

If I’m not misunderstood this is what Token Binding sets out to solve

I'm not sure why, but Chrome is removing Token Binding

https://bugs.chromium.org/p/chromium/issues/detail?id=875046

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).

Thanks for the additional interpretation.

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.

(deleted - sorry didn't read the title correctly)

A password manager doesn't protect your cookies. Most authentication cookies aren't bound to an IP address.

If someone is running arbitrary code on your machine, they can probably use a keylogger to steal master passwords or do other nefarious things.

Reply on news.ycombinator.com