>> Thanks everyone for coming.  I'm going to be talking about cookies but first a couple of cookie related jokes.  What's milk's favorite band? Oreo Speedwagon. [Laughter].  What do you say when no one laughs at your cookie joke?  Doh, sorry that was half baked.  [Laughter].  Ok, so we're going to be talking about why someone would want to steal http cookies off of your client and we're going to talk about how that could happen and what you can do to protect yourself. SO, people stealing cookies off of the wire is kind of a well known attack over plain HTP but I'm going to talk about how they are stored on HTP clients, like your computer, and how those can be stolen.  Just before we get going, the opinions in this presentation are mine and not my employer's and the security issues I discuss are not vulnerabilities in particular websites.  You'll see some logos from screenshots, I'm not going after particular websites.  This is sort of a systemic issue that I see so don't get too excited and live tweet "oh my god, google got hacked," that's not what is happening here.  Ok, so what is an HTTP cookie?  Cookies are name-value pairs that are transmitted as HTTP headers both in requests and as responses.  A typical use case in one I'm going to focus on for pretty much the whole talk is a client sends a username and password.  So you're in your browser, you type your user name and password, you send it to a server in the login form.  The server sends back a cookie that is then used as your authentication token going forward so you don't have to constantly reenter your password.  So that is a very common use of cookies and that's what I'm going to focus on.  So, for those of you who have never seen cookies before they have some attributes besides just some name and value. They are associated with a domain.  This is a fresh request to twitter.com from an incongnito session in chromium's developer toolbar and their name space into a path so if it only applies to a part of a site the browser will only send the cookie to a certain path within the website.  They expire, a session cookie.  The term session is overloaded, so a session cookie is both a cookie used an authentication token and a cookie that expires when you close your browser.  So, here the expiration time session means when you close your browser the cookie is gone.  It expires when you close your session.  A lot of them have dates sometime in the future.  This just has the size.  The HTP only cookies cannot be seen from client side scripting like java script so this mitigates some cross side scripting attacks where normally someone could read your cookie in java script and send it to some bad server sites somewhere.  HTP only cookies can't be accessed from java script, it's only part of the HTTP request.  And secure cookies are only sent over HTPF connections, not HTP.  So if you accidently type in http://g‑mail.com, you will connect there and be redirected to the https version but your cookie won't be sent if it is marked as secure.  That is another security feature.  
So, every one knows it is bad if someone takes over your machine.  I'm going to deep dive into that a little bit.  And something that I heard other people talk about too much.  So any process that runs your user within the default configured system can read your private keys, which hopefully you have passwords for that reasons.  Some softwares stores passwords in plain texts so like IM clients and FTP clients will often, when you say save my password for pigeon or whatever your ftp client is, that is in a text or XML file.  It's just your password that you had typed in and it will send that to the server each time to authenticate.  So it is on your hard drive somewhere.  And web browser cookies are generally stored as plain text, but they are always readable as a user.  I gave a five minute talk at another conference on this called the readable data and multiple personalities because they are illustrated the same.  And the whole idea here is the data infiltration attacks.  Someone gets on the machine, they see the data they want and take it to a server somewhere and then they are done.  They don't need to ask for privileges and they don't need to persist.  
So this kind of the crux of my talk.  I believe that cookies can be more valuable than passwords some of the time.  I will go into a little more detail in the next couple of slides.  Usually people think I got to protect my password, what is a cookie?  Especially to an attacker.  But I think they are pretty valuable.  Counterpoint, cookies expire, whereas passwords sometimes expire but for web applications, often don't.  A lot of sites will make you reenter your password, before you do something special, like change your password.  You'll have to reenter the initial one or before you enter an ssh key on gethub you'll have to reenter your password.  So in that sense passwords are more important than cookies you cannot do everything with a cookie, but you can do a lot.  
So how many people use g‑mail, but do not have two factor authentication enabled?  Raise your hands.  How many passwords start with the later A?  Just kidding.  Kind of.  So two factor authentication for people who are not familiar.  There is a password, one factor something you know.  And another factor something you have, like a phone.  So the idea is, a bad guy is going to take over your account they need both your password, something you know and something you have.  So you enter your user name and password and then get a text to your phone after you a ‑‑ authenticated successfully, and then you enter the code sent to your phone in a text or a little app into the web browser to verify this is the account, the person that owns the account.  If you have a cookie you bypass this, because it is already authenticated.  So if someone sends you a g‑mail cookie they have a bypass two factor.  That is interesting.  Usually if you steal a password you cannot get in, but steal the cookie you can.  
And similar for Facebook.  If you log‑in, authenticate from a new location or new ip address you get an e‑mail to your account e‑mail and will say, hey, someone new logged in, is this you?  But if you have a session cookie and you log‑in with the session cookie, you just make it part of your HTP request, which I will show later.  You don't get this e‑mail triggered.  So in that sense, again, the cookie is more valuable to an attacker than the user name and password.  
So, we're going to take another little cookie joke break.  And be ready, prepare yourselves, brace yourselves.  What do cookies have in common with stoners?  Both are freshly baked.  So we're going to talk about the way that browsers store cookies.  Because the idea is that someone takes over your machine or on it for a temporary period of time, how do they read your cookies?  What is involved in doing that?  So most browsers store cookie as plain text.  And http only and secure flags I talked about earlier are only inside of browsers so it is up to HTTP client to store them, to protect you. So malware does not need to inforce them, malware doesn't need to respect them.  The cookies are stored in the same place. So your secure cookies are stored along side unsecured cookies.  FireFox is one of the popular browsers I'm going to talk about, I'm going to talk about five, it stores cookies in the SQL database.  So that means you can use a SQLite free command line tool.  Python has a SQLite baked in, you can link to SQLite libraries.  So an example of SQLite connection.  We, on Mac, open the database just by passing the path to the SQLite 3 command line tool.  And can you read this?  Yeah.  Cool.  And ‑‑ schema just shows how the table is created.  You can see the name and the value are both text columns at the end of the second row and the third row on the second command.  And all it takes to read the cookies out of the FireFox cookie database is select value from most cookies where name equals gx.  Where gx is the gmail cookie.  It would be pretty ironic if my dummy account got taken over, because I posted my cookie here, but it is a dummy account, I don't care.  There is a second SID cookie that google accounts uses.  I'm not too worried but I would love if someone took over the account and sent me e‑mails.  If you get bored you can try doing that but I think you'd need another cookie.  
IE is interesting.  It sorts cookies at text files not in a database.  The folder where the cookies are stored depends on the IE version.  And the file names are random.  In order to get the value you're looking for, like the GX cookie for g‑mail.  You need to iterate through the files. So your programmatically on the machine, you run a script, loop through thhe files in the directory that have random names, that you will see here, and pick out the one that you want.  So I'm reading a bunch of cookies, one of them has a GX in a place where I put the name, okay.  That's the one that I want.  You cannot just do index search, you have to loop through them all, as far as I know.  I blocked it out, its the Google analytics cookie, it's not a big deal but I'm paranoid because it's DEF CON.  
Yes? 



[crowd question]>> In that case how does a company know which cookies are theirs?  So, lets say I'm shopping on Amazon, I go back on, how does Amazon know which cookie to utilize, i.e. know which cookie is associated with Amazon?


>>So only the ‑‑ the web browser says, you said on the twitter slide ‑‑ this is an Amazon.com cookie, this is a twitter cookie.  So the only cookie that are sent to the site are one that are marked by the client as belonging to the site.  Make sense?  The question was how do you know ‑‑ how are particular cookies sent to the right site?  
Okay.  So Opera and Safari use custom binary formats to store their cookies.  But they are freely available software tools for parsing them.  It is not hard to read safari is binary cookies, in case you didn't think cookies are in there and opera it's called cookies4.dat.  So just a quick example of the free software tools that I didn't write.  One is a github, and one is a blog post.  Python script to read cookies and find Yahoo ones is not that interesting compared to anything else.  Opera is the same thing.  They just put a bunch of debug info in their parsing, they didn't clean it up because this is just a demo.  
Okay.  Chromium is by far the most interesting browser for cookies I'm going to focus on the most.  So chromium, in recent versions, encrypts cookies.  It got a lot of press in January for doing that so it's been there for a little while.  It was in the diversion for months before it made it into the main line chrome.  When I say chromium I'm talking about the open source version of the chrome browser.  They are pretty much equivalent.  Chrome just has Google branding.  So it stores cookies in the SQLite database.  Before, just like Firefox there was a name and a value text column but now there is an encrypted value blob column which means binary data can go in there.  It was still use the text column, the value, but it will look in the encrypted value field and see if there is an encrypted cookie set and I'll show more about that.  In Linux there is no single standard key chain.  KDE, Gnome, the different desktop environments all have their own key chain.  There is no Linux key chain.  The key chain being a place where you type in your password and you want to save this in a secure place that is encrypted.  There is one master password for all of your system passwords for the user.  So Linux doesn't have a centralized one.  So on chromium what they did for Linux encryption of cookies they used AES, which is symmetric key encryption and used a hard coded key in salt in the course code.  If you encrypt your cookies on one machine they can be decrypted on any machine because you can just read the source code, the key in salt and decrypt the cookies.  So I say it is offuscated and not encrypted.  There are comments in their source code about that they just haven't fixed that yet.
  So reading, what I did was ‑‑ I linked against the chromium libraries.  So you can just call code to decrypt, undo the encrypt they are doing, but I decided to reuse their code because I'm lazy.  The way that works is ‑‑ there's a binary blob that looks like garbage here, but when you call the code to decrypt it is the same DQAA prefix cookie, it was on FireFox.  The GX cookie again.  You don't have SIDS you can't take over my account I don't think.  So what this means, the black shell, one computer reads the cookie out of the database, you're some malicious actor, then you bay 64 code it, send it over the wire and in my case just copy and paste it into a text file because it's in a VM.  You can read it on another computer and decrypt it on another computer.  It is not really encrypted.  Windows is encrypted.  It uses a Crypt/Protect/Data function to encrypt cookies for chromium on windows.  That's a windows cyrptography API so it's part of the system libary, it's standard stuff for windows.  It uses login credentials as part of the encryption.  If you have access to someone's computer, power it off, you need their login credentials to decrypt the cookies.  Whereas on Linux that is not the case, you can just implement them on any machine.  
So crypt/unprotect/data is sort of the twin function of crypt/protect/data, you must call it as the same user that encrypted on the same machine.  Chromium on mac is perhaps state of the art of cookie storage in browsers.  So in the system key chain they store an encryption key.  If there is not one at the beginning they have a random one to put in there.  And use AES to encrypt/decrypt with that protected secret.  One thing to note, if you an unsigned app and try to access the key chain there will be a pop up for users.  If you have some random Malware on your computer trying to access your key chain you will get notified.  It will look like that.
  In that sense it is harder for an app that you don't trust to read secrets out of your key chain in general, it's a mac security feature, which is cool.  Okay.  So in summary, chromium encrypts cookies on windows and mac, it offuscates them on Linux and other popular browsers for the cookies as plain text.  And FireFox, Opera and safari store them in plain text in a binary file format, they are just there to read.  
Okay.  So we're going to talk about some attack vectors.  I try to come up with more cookie jokes but they are all too crummy.  So the first one, which I alluded to earlier is physical access, which is someone gets access to your powered off machine.  You don't have dis-encryption on, they turn it on and read the cookies.  Chromium actually protects you from this on Windows and Mac; do the encryption, that is cool, that is novel, that did not exist until eight months ago.  That cool.  So social engineering is another attack vector.  So someone gets you to run an excel or Word document with a macro in it, they can run visual basic for applications code on your computer and then call code from the Internet to read the cookies and just read the cookies and ship them somewhere else.  I have a demo of this later, or slides of the demo.  So again you don't need to install anything, it's a data filtration attack, if someone is attacking you where they just get on your machine, get the cookie, leave and then reuse it before it expires.  It is kind of scary.
Malware is similar to social engineering, it kind of overlaps.  Someone drops and runs an executable there is a whole metasploit.  You've got code execution on the machine.  Again, any process that runs with a user for the cookies.  The idea from attacker perspective would be I want to send the cookies over HTTPS or just plain HTP to a server somewhere and then use them myself.  Does that make sense?  Cool.  So here is a proof of concept that I did.  So what I did was I wrote some code to read cookies off of the client in various situations.  So chromium on windows, for chromium on Linux and for Firefox.  And I ran that in other machines, so one is a VM, these are both VM's, the top one, Google one is a windows VM and the other one is a Linux VM.  So I ran the malicious code that I wrote for myself and then sent the cookies to my listening server, which is a cookie capturing server and ‑‑ then when I, in the admin interface clicked use cookies in browser and pressed the go button.  It creates a temporary profile with cookies in it in chromium and logs in to the accounts from another setup.  So you're able to use the cookies to login, kind of semi automated.  Bypassing two factor, bypassing the new login location notification email.  At this point, I milked all of the cookie jokes for all they are worth.  So dis-encryption prevents against physical access.  That is kind of good idea from a security perspective in general.  With data exfiltration or just someone reading your comptuer that you don't want to and in this particular situation, it is good if you have dis-encryption that will protect you from physical access.  Application firewalls are an interesting tool.  The idea you can block or allow traffic based on server port pairs per application.  You can say this application can access this server and this port.  So if another application tries to do the same thing you will get a pop up.  So, example, chromium can access google on port 443 for HTTPS.  Little snitch is a popular way for doing this for mac.  It's a commercial product.  Windows I think that limiter is one thing that does the same thing.  Linux is an interesting case.  There are not any stable currently maintained application firewalls for Linux that I know of.  I would love to hear if you know.  There are a couple different products that are supposed to do it open source, but there is a currently maintained one on stable, and not currently maintained.  So that would be great to see going forward.  
Little snitch here, is an example of it, just to illustrate when I tried to read from an HTP request from the command line it says hey your command line is trying to access reddit, do you want to allow it permanently or just once.  SELinux is another thing that helps with this kind of attack.  It segments your applications from each other.  Before I was saying if a process runs the user can read all of your files, SELinux and other tools like it have sort of extra access controls that you can apply on top of normal UNIX access control.  You can say I own these two files, but only one process can access this one and only this process can access that one.  If a third process spins up it's just Malware, it's random, they will not be able to access, even if they are all owned as my user.  
One idea I have, I don't know it will be implemented for cookies is a master password for cookies.  The idea is your cookies are stored encrypted on your hard drive.  It's kind of a two factor idea, you need to enter a password at the beginning of your browser session to decrypt your cookies before you can access them.  It is not too inconvenient, you only have to enter your password once per session and FireFox actually does this to protect passwords.  Cromium doesn't, they made an intentional decision not to.  So here's what it looks like for Firefox's password manager and you can imagine sending similar cookies.  So the idea here is if the passwords are stored on the hard drive they can be read by any process or user, but they are encrypted unless you enter this password.  Then one interesting defense is tying a session cookie to the login ID.  So when someone authenticates initially the first time, they authenticated from this IP address.  If they try to log in from a different IP address later with that cookie, it will reject and make them re-authenticate, it will only work with that IP address.  cPanel, which is a web hosting configuration tool actually does this optionally.  The bunch of people who are actually confused on their forums.  They log‑in, and they go to somewhere else, they have to relogin everytime they go to the coffee shop and come back home.  So it is a trade‑off of a security versus convenience.  I think that is a little bit too extreme.  But you can do, which g‑mail does, you can say, where have I logged in from recently?  So I have logged in from five countries this month.  I haven't been traveling, I should probably do something about that.  
Okay.  I think I blew those these pretty fast.  Cookies should be handled with care.  And client side cookie security is not a solved problem, it is something that I think needs more thought going forward.  And that is how the cookie crumbles.  Any questions?  Yeah?  
So the question is how do you protect the hard drive?  With cookies or in general?  Okay.  So having an encrypted hard drive is a form of protection, and how does that work is the question.  The way it works, if someone accesses your computer, before they can mount the hard drive, before they can read the files on your hard drive, they need to enter the secret, the password, the key.  If that password is strong they have to guess that key before they can read the files on the computer.  Dis-encryption prevents someone from accessing your computers and opening up and reading the files.  If it is not encrypted, someone can put in a Linux live CD and they'll be able to read all of the files on your hard drive.  Correct.  So the question ‑‑ if they have physical access, this encryption helps.  If they are accessing you remotely, encryption doesn't help, everything is in memory, anyway.  Yeah?  So the question, is the encryption on chromium enough for this type of attack?  Mathematically it is.  So it is good encryption, but on Linux they use a hard coded key.  So ‑‑ in that sense, the encryption doesn't matter, because you can traverse it trivially, on the other two, it should be, it should be good.  I think.  Yeah?  So the question is, why didn't the encryption prevent the cookie from being exfiltrated?  So the reason the cookie was exfiltrated it is decrypted on the client where it lives.  You call code to read the cookie and decrypt it and then you send it somewhere.  No.  It's, it's, actually I e‑mailed the chromium security team about why it is different on Linux.  They said the main reason they wanted to protect people on windows without full dis-encryption, that was their main intention.  So it's ‑‑ by design in some sense.  So the question, does Cserve protection help?  Ah ‑‑ I'm not sure I understand how ‑‑ okay.  So the question is does Cserve protection which invalidate sessions in that in sense, does that protect people from this kind of attack.  I would say no.  Once you get the cookie into the browser like in the proof of concept, then you are just that user.  You are in the browser as that user.  So it will do all of the normal Cserve stuff, it will read the tokens and send them along with the request.  I'm sorry.  Can you repeat that?  So the question is, could you have cookies that belong to multiple sites?  I think the browser, the way cookies are stored probably doesn't support that.  I think domain is just a column one right now and just one thing.  And I think the secure implications these that are kind of scary if you sent ‑‑ well ‑‑ it would be ignored by the site unless there was some collaboration between the two sites on the back end.  If I had Yahoo! and Google cookie that goes to both of them, it is from Yahoo!, Google would need to know about that, it would need to have something on it's session on the server saying this is a valid cookie.  So in that sense, it wouldn't get too much more with having just two separate cookies.  Anyone else?  Yes?  Does client side JavaScript have access to non HTML in the cookies.  I think that is the main idea, I think that's what HTML means for that site.  Not just for any is site in the world.  Someone else over here?  Right.  So if you're really paranoid, what you do is you just don't save cookies.  You have everything via session cookie and it expires when you close your browser and then you are happy.  Again, it is annoying, you have to reauthenticate all of the time.  I think application firewalls are a good choice for.  No one is doing this kind of attack, but if it happened, application firewalls would be a good choice, like SELinux to segment the applications from each other would be a good choice.  I think application firewalls performance because you have to inspect packets as they go out saying hey, does this meet all of the rules.  That will slow you down, I think encrypting the cookies, the master password is a decent idea.  I have not seen discussion of that.  I know chrome said this is not a good idea, it is not really extra security.  If someone is on your machine, you're in trouble anyway.  We don't want to give you a false illusion if someone is on your machine your are going to be ok because you have a password; a master password for your passwords.  That's why they didn't implement that in chrome as far as I know.  So ‑‑ um ‑‑ but I think a master password for cookies is decent.  So question is how can you help the client be as secure as possible with cookies as a developer?  So sending cookies as secure and HTML only, you don't need the java script to read it, they are accessible from JavaScript.  That is the thing that everyone should be doing all of the time.  HTPS versus HTP.  If you have any login or any sensitive information, you definately want to use HTPS.  There are a couple of older attacks sniffing Wi‑Fi on the network.  And a cookie going HTP you can sniff the cookie and steal it that way, that is fairly well known.  Using HTTPS and sending you cookies HTP only and secure and using HTTPS are sort of the fundamental things you can do.  Everything more is that browser‑implementer level.  So I thought about that.  The question is, has someone thought about going down a layer to the Mac address rather then time the session cookie to the IP tying it to the mac address.  I think there are two problems.  One is if you are just a web server listening the cookies are mostly set at the web server level.  You don't want to try to read the packets as they come in for Mac addresses.  The more fundamental thing is that someone on your computer is sniffing a Mac address and spoof it when they are trying to login as you from another machine.  They can render commands to read the Mac address that you're using now, possibly try it with multiple interfaces if your computer has ethernet and wi-fi and then spoof it later.  So I don't think that will protect you.  So the question is, if a cookie is used multiple times, is there a way for the server to know it is two different sessions?  And ‑‑ I think the IP way is one, unless you are the same network, and then it just looks like the same IP and the host, but ‑‑ right now I think most sites just look for the same session and it looks like one user because what happens is you log in and get the cookie back.  You log in again and get the different cookie back.  If you use the same cookie it is the same entry in the session store usually in the database.  I think.  Anyone else?  Question is, can cookies from the client extend their expiration date.  The answer is usually it is set on the server.  You would not want people be able to steal them and to extend them like that.  I haven't seen any applications are like, when you log in, do you want to stay logged in for two weeks, four weeks or a year.  I haven't seen that.  Yeah.  Are we done?  
Okay.  Thanks guys.
[ Applause ]
"This text is being provided in a rough draft format.  Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings."