
Stealing Chrome cookies without a password - octosphere
https://mango.pdf.zone/stealing-chrome-cookies-without-a-password
======
garrettr_
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.

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

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

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

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

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

~~~
kuroguro
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...](http://raidersec.blogspot.com/2013/06/how-browsers-store-your-
passwords-and.html#chrome)

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

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

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

~~~
PhantomBKB
You can set a master password

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

~~~
3pt14159
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.

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

~~~
3pt14159
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.

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

------
tyingq
Seems like the easiest path to steal chrome cookies would be to write a chrome
extension.
[https://developer.chrome.com/extensions/cookies](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](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...](https://chromium.googlesource.com/chromium/src/+/master/chrome/common/extensions/docs/examples/api/cookies/)

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

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

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

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

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

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

[https://bugs.chromium.org/p/chromium/issues/detail?id=875046](https://bugs.chromium.org/p/chromium/issues/detail?id=875046)

~~~
tptacek
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._

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

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

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

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

