← All talks

BG - Chrome Cookie Theft on macOS, and How To Prevent It

BSides Las Vegas15:44581 viewsPublished 2024-09Watch on YouTube ↗
About this talk
Breaking Ground, Tue, Aug 6, 17:30 - Tue, Aug 6, 17:50 CDT If you had a shell on someone’s MacBook, could you read their Chrome cookies? This talk will survey a broad set of techniques that will do just that. Then, I’ll share my experience using open-source tools like Santa and osquery to prevent and detect these attacks on macOS. People Nick Frost
Show transcript [en]

what's going on we're here to talk about MacBooks so my name is Nick I work at the uh security team at a company called figma and recently our team was thinking about if we had malware on one of our company laptops what would one someone want to do with this malware right all of our laptops are MacBooks our employees use Chrome the obvious answer is they'd want to read people's Chrome cookies like we don't have interesting data on our laptops anymore our emails are in Gmail or other interesting data in other SAS apps on the internet this is the actual data you want off a laptop um so if you have a shell on someone's

MacBook can you read your CH their Chrome cookies and how do you do it and I I can detect that like some security people are skeptical of this idea right the answer is of course this is a law of nature right if if you have a malicious program running as you surely that program can take over any other program running as you right like you can you can use GDB or lldb or something to take over code execution you can launch Chrome as a subprocess and like read its memory after it's launched to read cookies TR out of memory maybe you can take over the computer's Mouse on their their MacBook and click around fall else

fails right open the debug console go to like where you as a user would read the cookies just read them directly out of there right so surely you can always do this stuff anyway if you're running as as the user except that's not true on a Mac you see apple built iOS iOS is crazy right you run potentially malicious programs on your iPhone um and you can mostly trust that those programs can't take over other apps and like 10 years ago they brought this stuff into Mac OS a uh a program on Mac OS that is running under a different Apple developer under code signing cannot take over another program necessarily this is what underpins like

accessibility permissions so you can't take over the mouse this is what decides whether you get like Bluetooth access things like that um so you can't just take over chrome necessarily now I'm going to tell you that you can but it doesn't have to be that way right this is a design feature of the way that Chrome is built so what we're going to talk about is I'm going to give you three attacks that you can use to steal cookies on Chrome there are more attacks but these are just three that I think are interesting I'm going to tell you a couple ways you can prevent some of these attacks from being done but not all of them I haven't come up with

protections for all of them and for the ones that we can't prevent we can at least try to detect whether are happening so first one I want to talk about is the Chrome Remote debugger right there's this thing that you can use if you're if you're running like selenium on your computer for example and it like takes over chrome and clicks around to run like automated tests the way it works is it runs Chrome with this remote debugging server um where you can send it commands to tell it to click on things if you Google how to steal cookies on a MacBook like you find this blog post that explains how to do this from 2018 it's super cool uh basically

you you launch Chrome you tell it listen on this port uh I'm going to connect to that port and I'm going to tell it I would like you to give me the list of the users cookies like all of them for all the websites and says sure yeah one one big response it sends you all the cookies um this was cooler in 2018 when you could launch Chrome in headless mode and so the user wouldn't even know this this happening these days headless chrome doesn't have the same cookies as normal guey Chrome so this doesn't work as well um but you could still you could launch like normal Chrome and the user would see something weird happening but

you could steal their cookies so that's one way another attack is like surely Chrome has to store the cookies somewhere right when you reboot your computer you're still logged into Facebook where does it store them it stores them in this file uh it's got all the fields that cookies have like which website they're for whether it's an HTTP only cookie stuff like that but the file does not contain the actual cookie value it encrypts the cookie value and it encrypts it with an encryption key that's in your login keychain this is where stuff gets kind of cool who can read this encryption key if you're Chrome and you have uh Google's Mac OS code signing certificate you can read

this key no problem if another program tries to read this key uh your MacBook prompts the user for their password um so if you just ask the keychain for the key you probably can't get it or honestly the the message is not that clear what it is that the user is being asked for they might just type through it that might work so if you want to decrypt something you can either get the key or find a way to attack the crypto right um so if you can read this file you can probably right to this file right you can copy paste a cookie that you want to steal to a new cookie in a

new row in this sqlite database for another website um a website that you control and just wait for the user to visit that website or you can like I don't know you can launch Chrome pointing at that website and make them send cookies to you right uh you could imagine that you could imagine a crypto scheme where the encrypted value takes into account like which website the user is using or something um so that a cookie for GitHub is not valid for a different website uh but they they currently don't do this cool so that's another way the third attack that I want to talk about uh I honestly think this is the coolest one we're going to take

advantage of the fact that Chrome is not one process right it is a complicated multi-process program the way that Chrome Works is when uh you launch the Chrome main process it the one of the first things it does is it asks the keychain for your cookie encryption key and then it starts off this other process that's responsible for doing a lot of things but one of the things it does is read the actual cookie database read andw write your cookies and decrypt them it sends the encryption key to this other process the network service they're both signed by Chrome but they have different like signing IDs and then the network service actually reads your cookies so one thing that's cool is if

you are an attacker you can replace the binary where the network service binary lives in like the Chrome application bundle with malware and then kill the process because you have user permissions right you can still kill other processes the user is running and chrome is very helpful it'll say oh my gosh the network service is Crash I got to relaunch the network service and it will do the startup process again it'll send the cookie encryption key to this uh malicious process you've now gotten it to launch uh that process is going to launch the network service send the encryption key to it and then it can start speaking IPC to the network service and just tell it please like

read these cookies and do these things with it um so the important thing here is that Chrome and the network service are the only processes that are actually talking to the keychain and the cookie file right malware is like getting launched by Chrome and it's launching another process but it's not actually reading these files and the reason that's important I'll get into later uh and don't even think about like trying to use file permissions to fix this because the malare could just bring it own copy of chrome right or you could like download it from the internet and even if it's not the same Chrome binary the user usually uses it's still a signed copy of chrome it still can read the

keychain it can still write to this file okay what are some things we can do about this the first thing we can do is if you pay Google for Chrome Enterprise there's a flag you can turn on to disable the remote debugger so when you set remote debugging allowed false uh and then you try to launch Chrome with a remote debugger it just prints out an error message it doesn't work um everyone should turn this on this is super cool you you might have trouble as I did with like you have actual Engineers who use tools like selenium so you just probably just have to exempt it for those those Engineers um but you can

maybe get away with like telling them to run Chrome with a different user data directory or something like that so that if someone manages to launch Chrome with a remote debugger it's not getting their real cookies okay so that's one one approach uh another thing you can do is you can use this program called Santa and this is a Mac OS talk any hands in the air for people who know what Santa is any familiarity awesome so most folks know Santa as this like binary authorization tool but it's also got this thing called file authorization and the idea is we can tell the OS whenever someone tries to open one of these files in this case

we're going to talk about the the cookies file I want you to ask me the the Santa agent uh whether that process should be able to open the file and this is at like the OS levels this is not just file permissions um so the ideas is like Chrome tries to open the cookies file another program tries to and even if it has user level permissions at the kernel level gets blocked so my recommendation is you should have two rules in Santa for which processes can open the cookies file you should tell you should tell Santa to let the network service which is that Chrome com. google. chrome. Helper process open the file don't let normal Chrome open

the file uh because if malware like from the CLI launches Chrome like application whatever the path is to Chrome and then the path of the cookies file Chrome will open the cookies file and say oh my gosh this is a binary file they must want me to download the file and it'll copy it to your downloads folder so don't do that um and the second thing you should protect is if you're using the remote debugging alloud flag you should protect the policy folder because malware can just delete this folder uh when you Chrome Enterprise Flags it tells Chrome that or what what Chrome does it saves locally which flags you have set there like cool like pki and signing to make

sure that it's actually from a Google server but if the files where it stores those just aren't there it assumes it's not managed um and when Chrome launches there's a couple seconds before it actually goes and redownload its managed policy and that's plenty of time for the remote debuger to launch and for you to steal the cookie so protect the the policy directory uh I have no ideas for how to fix the IPC problem so if you have ideas please let me know so if you want to detect someone doing this weird IPC attack we're going to try to find cases where the network service is getting launched by another process that isn't Chrome and the thing that we did at

figma to check check it for this is we use this thing called osquery um some of you may be familiar with this it's like a cool logging tool where you can write SQL queries to like give you logging pipelines for things that are happening in the operating system and basically you want to look for uh processes getting launched you have to like kind of build a table of parent processes and child processes but you have to look for processes where um the target process getting exact is the network service and the parent process is not actual Chrome that's what I have for you do you have any questions yes

the question is what about session cookies uh that are not like they don't have a max age and they don't expire they die when you're Chrome process size I think they only live in memory that's my memor my my recollection so they don't actually get persistent to dis so I think you I think you'd also have a hard time uh I think trying to steal session cookies you'd have a hard time using any of the attack I listed because you'd have to attack like the active running process that the user has launched from their guey that they're clicking around in and that's when they like logged into an application um and so I think like

mucking around with the network service through IPC for example would uh cause the session cookies to go away other

questions yes

do we have another mic

cool the question is about other browsers uh I think on Mac OS there's like three browsers that exist it's like Safari Firefox and other things that are chromium based browsers that kind of reskin chrome um so all of the chromium browsers typically encrypt cookies on dis so the attacks against crypto all work um and I think like Arc and brave and browsers like that do not have uh a remote debugging tool that you can launch they just like don't exist um so I guess they're a little bit more protected against this problem um Firefox stores cookies unencrypted on dis so you can also use santa to just protect the file where it stores the cookies and Safari I don't

actually understand how this works but Safari like Mac OS builds in something like what we're trying to do with Santa here where it just prevents other programs from opening the Safari cookies database um and I guess another interesting area is electron apps so it's actually an optional flag that you don't have to turn on in electron if you're running an electron app to encrypt cookies on disk uh a lot of apps don't have this turned on if an app does have it turned on you can still like try to use IPC to either get the main process to tell you the encryption key and then go read it out of memory out of the file um or you can

do the IPC attack to read it out of the network service

yes I was hoping someone would ask about extension so I I don't actually know what um all of the protections that Chrome has here but it seems hard to as malware put malicious extensions into someone's user data directory maybe someone else here knows the details here but there's at least some like pki that Chrome does or make sure that the extension at least has been published on the Chrome web store so if you mess around with like either the content of an existing extension it checks that uh the extension is actually signed by um the certificate for that extension there's like a per extension certificate and then that gets signed by the Chrome web store um but like I guess you could

write a malicious extension and then publish it and then put that in someone's user data directory that'd probably work uh so I'd also recommend using osquery to get a list of people's Chrome extensions and I don't know have a sense of whether they seem like malicious extensions or not um some some companies do extension allow listing so that when Chrome launches it just doesn't let you run with malicious extensions or with extensions that are not on your allow list installed this is obviously disruptive because people have to ask some it person to let them use an extension um yeah any other questions all right thanks