What We Can Learn from Google's Fight with Phishing

[Music]

by Taco it worked this is the biggest room I've this is the biggest elevation change room I've ever talking talk can you see hard the slides okay from all the way back there my name is Neil Mueller I work on the product team at Google on security and you're joined by Colin yeah my name is Colin I'm a cloud security engineer so I work on like data protection and data privacy for our cloud customers what we're gonna do today is a bit different than you might see normally we're gonna do the demo first because we think that's what you want to see we're mostly going to talk about research which is public so if you got

to talks and you want to be both at the same time you can see all of our slides on the website and all the stuff we're talking about is public research so if you want to be in two places at once now is the time for you to do that but stay for the demo because it's amazing that's just the first five minutes we're here to talk about something called phishing it's the scourge of the internet and people like to pretend that it's why really really valuable stuff gets stolen but we know that's not true that's rubber hoses which you can see in here right now here in this cartoon right now it's SK CD on the left you've got them

talking about you know super RSA stuff and on the right you've got a rubber hose just wanted to put it in context of how the real world works but let's talk about information sec so we've got two things that will try to persuade you of during this talk the first one is that the paradigm of passwords as a sole authentication factor is outdated we all agree on this we might not all agree on this yet but we're here to persuade you of that fact that the assumption that control of a phone number is sufficient proof of identity that's false because your phone number can be ported I can be slammed we will walk you through all

that stuff in a few minutes but first a demo yeah so one of the things I wanted to show people is that sufficient pages are getting very sophisticated and so we built one you know there's there's a lot of training that you know companies put employees through to say like make sure you you look really carefully at every link you click on and read the you are are really carefully the data we have suggests that's a really bad idea to you know count on the human to read every URL bar especially after midnight so this is a phishing site if you look really carefully up here you'll notice the URL is just not exactly right but

that's really the only thing wrong like this like in chrome that says secure if I reload the page we have the little animation here pixel for pixel this is really just a reverse proxy okay it's sitting in between the user and the actual Google login page is maliciously the best part you know about being a reverse proxy is when you sign in it does exactly what the Google login page does so in this case I put in my username the challenges for a password if I type it wrong it will prompt me and say that's wrong when it sends the text message it comes from actually from Google so let's see is this the most

recent one there it is yeah so this is actually coming from two two zero zero zero just like it would from Google this also works if you're using push if you're using the Google prompts or Authenticator any 2p OTP and also if we type it wrong so here's the actual code if I change the code to zero it says that's not right right so again the Fisher is really smart it's really just sending your keystrokes to Google and then whatever Google reports back it will return when you're all the way through it puts you to a page like this and again it's really hard to tell but if you look I'm not signed in right so so the problem

here is the user got tricked and it's really hard for them to tell something went wrong ok so for us the belief is you need to actually provide a credential to do this check for the user rather than count on the user to do it themselves let me clear my data real quick and then I'll show you what this is like when you are using a strong authentication method so if we go back to the phishing site I'm just going to change to a user that is required to use au tau2 f-secure D key so literally no different same user same password but when I get here I fail out and this is exactly what we want to happen okay we

want the user to fail out and not be able to provide a credential like I can try all I want I can try another way but really it's gonna say you have to sign in with a security key and what's going on here is no the user can't tell that it's not the correct HTML the technology is preventing them from making a mistake yeah exactly so even if your laptop was further pwned and this URL was actually says google.com because your host file is compromised we still fail out here and I'll show you why so what's going on in the background is we're actually doing bi-directional authentication so it's not sufficient that the user has to

demonstrate that they are who they say they are to the server the the server has to demonstrate that to the client as well ok so the server sends its identity saying hey I'm Google com you know I'm gonna tell a state with you that's in this state and then I need you to demonstrate that you have an end-user in front of you and the client responds in kind it says you know I'm connected to this particular URL google com I'm gonna TLS state with this connection state I sign that response with a private key so I don't actually divulge it but I prove that I have the private key I sign it and I send it to the

server so this all happens behind the scenes really quickly and the phishing demo I showed you two things fail the first one is the URL doesn't match so that fails out right away before we even go to sign it with the private key it also fails the TLS check so again even if we're you know in the middle of a Fisher who's got our URL we still won't match TLS States so really helpful really powerful stuff amazing yeah I think that's it yeah yeah how many people nerve I've ever seen a security key yeah most of you this is amazing how many people use security keys ok we are preaching to the choir that's good great

one of the reasons why security keys are so important is because of blogs like this which is a two year old blog on the coinbase blog which is one of the only Bitcoin exchanges that hasn't been pumped yet but they've been attacked many times and I'll summarize what I read in this blog is I thought it was so interesting this was the first alert that they got at 10:00 12:00 p.m. that it looked like one of their employees phone numbers had been ported what you can read here on the top it's Verizon saying thanks for doing so much great stuff with us let's give you a survey to tell us and we are and then it says that

they someone had changed the password on so this was the first thing is basically we six we ported your number and the second thing says okay you changed your password so you could do some more manipulation on the account we just wanted to alert you of that or something like that they've successfully recovered the password the following day and then the following day after that it got ported again and this happened to multiple employees and what happened when the number got ported they used that to take over Facebook accounts and other messenger accounts and then send messages to the CEO and other execs asking them to change their corporate passwords which corn-based has multiple controls in place the point of their

blog was to talk about all these controls the damage that was done from this attack was they said minimal so I'm guessing probably zero because any kind of Bitcoin damages major because it's irreversible their point was that they had multiple controls what they learned from this is that using text messaging into a fate while better than nothing is not a really good place to rely because numbers can be ported so often the learning that the lesson they had at the very end was that you should call your your provider and have them put a port block on your account which I did after reading that blog post and I recommend all you guys do - okay that was the demo

portion of the top and now kolinar gonna be splitting up the next couple of slides where we talk about some really interesting research that we published relatively recently there's a number of people that published it if you guys went to Berkeley you'll recognize professor Vernon Paxton's name and a number of other Googlers what we did here is we we had the first longitudinal measurement study ever of the underground credential spilling market and it looked at three ways that credentials gets built large breaches phishing and key loggers so we'll talk about each of them in turn we're essentially doing this you don't have to read the paper what do you guys think these are you should meet you okay I mean I'm at a

security conference that you guys are well-versed this is the number one most popular password in 2015 and the number two most popular password in 2015 according to splash data who does a report of the worst passwords every single year they basically don't change people don't get smarter except for us we're smarter but the people are protecting aren't the password the the phishing pages that you see not Collins but like main ones that are much worse Collins is probably way more successful from this which is not a good thing but the average phishing site is we will take over someones credentials with a 42% likelihood so even if you train all of your users this is the average that

you'll get to a lot of people get their accounts taken over and we spend a lot of our time cleaning all of that up in a self-reported study by the Pew chair will trust they found that 15% of people had experience account takeover we suspect it's much higher in fact we know it's much higher because we do a lot of the cleanup after the fact and a lot of users don't even know that they've been taken over banks do this too we do this a lot of the other big platforms as well too and so they get taken over and then we clean it up and then they are they're asked to reset their password we do this very

regularly and so we suspect that this number is much higher in reality okay I mentioned these three these are the large sources of stolen passwords let's talk about them each in a very unique way being Google we've got access to some unique data but I think you'll enjoy learning about how we anonymously use first one is phishing let's talk about how a phishing page works I think given the number of hands that have been raised previous questions I'm gonna go through this really fast a phishing page is put up it looks very similar to a page that you think you're logging into but it's not actually it's a standard there's a PHP back-end that then

exfiltrate the data usually via SMTP often to Gmail 72% of samples report via Gmail look at the blue arrow on the left this is a sample code from a very popular fishing kit this means we as the managers of gmail will have access to it so what we do and I like to read this so that I just say to innovate it's very clear so we modified Gmail's anti abuse detection systems to look for signatures that we found in 10,000 phishing kits over the course of March 16th to March 2017 this identifies the exfiltration points receiving stolen credentials the volume of messages in each account it receives and the volume of messages per kit template so we basically are modifying

an existing system that's designed to protect Gmail from abuse and we're having it look for signatures that you saw from the previous this right here we're looking for these signatures in email this is not a complete data set for one it doesn't take account of existing phishing kits that might use non SMTP or non Gmail repo it also doesn't it take account for phishing kits have been modified to hide themselves from our signature detection anyway these are the signatures that we're looking for and we found a lot what we did is we took it we took a look at the signatures from 10,000 phishing kits we did static analysis and found signatures that we could pull from the

majority of them and from there by going through Gmail using this anti abuse technology we were able to pull 12 million estimated credentials and so we believe that this is a low estimate of the total number that in a single year were spilled by adversaries that are using these phishing codes we're able to learn quite a bit from this there are a relatively small number of phishing operators operating in a relatively small number of places it's only 19,000 fishers out there based on our you know this is a segment of a segment of a segment but we found 19,000 of them which was fewer than we expected the vast majority are working out of one

country nigeria and they're targeting us and this isn't the case of keyloggers and breaches we'll talk about those in a second but we are we as Americans in America are are targeted by phishing kits more than the rest of the world this is also interesting so like right around the time when I graduated college I heard of Howard fishing kids and they basically haven't changed the front ends and the customer service that supports the people that buy these fishing kits for like $35 have changed you know they're slicker now but the PHP back ends have been unchanged in twenty years keyloggers the most popular key logger is a product called Hawkeye which is $35 we were able

to find 3,000 known victims by taking a look at 15,000 sample buying areas of which Hawkeye was one it uses signatures as well many of which that use the SMTP protocol to point to Gmail which you can see on the lower left here so we followed the same exact process that we followed for fishing and we were able to find a smaller number of estimated spilled creds and that allowed us to do some initial and some additional analysis like what we did with fishing but in this case for keylogging and the results are very different so 26% of the hijackers are operating out of Nigeria Brazil and Senegal so more diverse than fishing because we're adding Brazil and Senegal here

fishing was just about Nigeria also we're targeted a lot less we presume that's because of antivirus maybe Chromebooks also however those in Brazil and India and a couple of other countries Malaysia is not on this list but they're also very high are targeted by key loggers okay a third source of spilled creds breaches we've all heard of these many of them have happened a long time ago but a lot of these passwords still work we even validated them all on our platform and all the other major platforms have been validated them there as well but smaller platforms haven't and so they really work a lot of them are on pastebin but there's a lot of

other forum sites out there we took a look at 16 blackhat forum sites and 115 paste sites and we used a tool that's available to all of you google.com and we can look through the search index and I've got some detail on that as well then hopefully I pasted it in this little notepad of mine hmm I didn't but I know where to find it

that's what I wanted to read you so we know that our coverage of these pasted sites is is incomplete because we don't have act we don't crawl all of the sites on the Internet and we also to make a more economical study we only took a look at some of the sites so basically we look we took a look at any site that included at least 10 to 1,000 of the most common passwords well you already know two of them 1 2 3 4 5 6 and password or the md5 and shock woodlands along with email suffixes for popular mail providers like at Yahoo at Comcast at Gmail at hotmail and we used that I mean that was the majority of the

initial query and from that we were able to find two billion credentials exposed and just like the other two analyses this is a partial analysis this is a fraction of a fraction of a fraction of what is actually out there because we don't crawl the entire web and because we weren't looking at sites that had relatively small numbers of credentials spilled on them just ones that had large numbers of creds but using that were able to find a whole bunch really interesting stuff which we'll turn to second ok people are using passwords a lot but we Hjelm knew this because many of us until recently were the sites where they're using them the most our

sites that might not be common to us but are common to a lot of people in the rest of the world and password reuse is across a lot of major sites ok so in summary we found three point seven million creds because of phishing 3000 creds because of key logging and two billion creds because of third-party breaches now all of these credentials were invalidated on our platform in most cases a long time ago but they still work on a lot of other platforms and so they're useful for the adversaries in various ways now what does this mean in terms of risk so the current shalls' that we found like I said we invalidate it at an all Google properties but not

all of them were for even even valid ever on Google but let's say for the for phishing if they were valid on 28% of them if they were fished were were we're valid on Google accounts and if they were ever there is the passwords still working well in 25 percent of the cases the password is still working for fishing so if the password is valid was the account ever taken over and there's a 400 X percent chance that the password was that the account was taken over if it's from phishing it's much much lower for key logging and third party breach and this huge multiplier that you see with phishing might cause you to ask why

well I think that's a very good question we have a theory and our theory has to do with geospatial information and knowledge of the target so what you get when you use these phishing kits especially the most popular one is a lot of blue so you can see blue is represented by the AB the average fishing kit red is is the average key logger and gray is the average data breach the majority of data breaches only spill the username and the password and that's it and nothing else but on modern websites today our platform and most of the other majors that's not going to get you in you need a lot more like if you're gonna get past I mean

yours mentioned phone number there's lots of others they would mention you know user agent or where the where the IP address was coming from you get that from key loggers and phishing kits and you get it a lot more from phishing kits look at the blue on the bottom here user agent you get a lot from key loggers but you get phone number and secret question with a lot of the very popular out-of-the-box phishing kits and we think that's why the likelihood of account takeover is much higher for phishing targets than it is for key logger targets ok yeah not take over sure so last we kind of we want to talk through what we

can do to protect users and there's a lot of technologies that you've seen that are that are very and the first one is Safe Browsing so Safe Browsing is using the indexer to do things like look for phishing sites we do that by looking for these very common kits we also look for pages that appear to be masquerading another right so if you're a reverse proxy and we know your proxying a page that's a real login page and you just are trying to look like the OWA page will know that the Safe Browsing should block that for those of you who are system administrators you can control the behavior of this so meaning if you don't want users to have

the button to click through this and say I understand the risk you can take that away very popular setting especially in large companies where you just you want to defer you know intelligence to Safe Browsing and don't trust a human secondly is Google's doing some analytics behind the scenes to determine when we should challenge for 2fa so one of the most common things that we used to see is like cookie pulling where you would hijack the device pull the cookie and then attempt to reuse the the auth cookie on another device Google is fairly clever at understanding like this this thing was just transported off I should reach allenge all of your cookies for to a peg and so you'll see us

programmatically ask you you know you should sign in again like I want you to go through the full off stack and again like if you're being phished and it's just like a phone number an OTP code this will still fail but it still helps prevent just like cookie hijacking by malware lastly we'll do things like this where we'll say hey we saw that that cookie actively used twice and we might actually suspend your account and so so if you're a high risk account will actually do things like this to say hey we stopped an account from signing in they've taken something from you and will recommend changing password and will serve us as much information as we

can we also know that's because we've done over 67 million per octave password resets where we've literally sent someone a text and say hey your account is compromised please reset your password and it's also it's fairly difficult for us to actually crack these so they don't look like phishing pages you know one of the problems we have here is like you know we're telling you click on a link and reset your password we've worked really hard with UX to try to make that as the least stressful on them as possible because again if you're trained did not be phished this will looks scary so lastly a couple things I want to say use defense-in-depth part of the way we

design our systems at Google is we anticipate systems will fail so you know like we can't you know count on Safe Browsing to catch every single page you know at some point there will be an exploit that will make a security key fail what I want to do is have a lot of layers that all need to break at once in order for me to fail you know for a bad actor to get a credential so so the idea is like put multiple layers we've talked about at least three while we're here and I think we want to talk a little bit about what Google's experience has been this I forgot to mention Google we use

about 38 different indicators of trustworthiness so you know part of what bad actors we see do is if they are trying to steal a good name password yeah security key yeah why what am i using yeah geolocation so they literally put the right key address in the same zip code as you to try to fool geolocation so G of X and 32 I can't think oh yeah there's a whole bunch more yeah don't have the same user agent they'll have the same IP address it'll it'll it's really really easy for them to basically say yep I'm right over there so we have a lot of other ways we can actually signal and look for the device to be is

this the same thing a lot of using security keys this is great the advice I will give you here is security keys are really really important for privileged users and they're also very very important for non-technical users okay like the best technology this is the best defense for non-technical users people who don't you know use technology is their primary job right like if you're if you're an HR person or an accountant if you issue them this token I will feel so much safer knowing that their account back can't be hijacked and I don't have to teach them read the URL of the thousand web pages you click on every day you can do this you can use

the same key for multiple sites so like my key you know unlocks you know five different Google accounts as well as you know my github account and you know there's tons of sites that support this the cryptography behind this I can talk to about it afterwards but there's a unique key that actually signs for every site so there's not a risk of like credential reuse as you as you move from service to service further what Google found is when we roll this out internally is that security keys are a much better user experience for our end users than OTP so Google Authenticator used to be the standard that we used internally and we measured two things how long does it take to

login and the long story short here is that security keys are much faster you can log in with the security key in about 10 to 11 seconds OTP codes you are usually at 20 so it's about half as fast to login and more importantly our helpdesk ins is went down so the number of you know has support incidences that say hey something's wrong with my security key like they're they're very very small it's like less than five percent relative to like what we saw with OTP right we saw tons and sounds like because you know this makes sense if your phone gets reset or if you're like me and you flash new build of Android twice a month you have to

reconfigure Authenticator all the time and that's really difficult for a non-technical user or if you're relying on SMS you know there's a whole mess of problems there that I don't need to tell you guys about so long story short here is security keys will cause fewer incidents which means you can actually work on something important instead of helping people set up two OTP codes with that I want to thank everyone for the attention and you know are we taking questions yeah yeah we have three minutes we can take a question if we want yeah we have lots of time for questions please yeah

I get like like it was this conversation right yeah I'm yeah this is the question was how did we do this without impacting the users and we couldn't do this for everyone so we did this for folks who have a phone number associated so in this case we're assuming that they can they can still get to their phone so essentially what we do is disable their password when they use their last known password we send their phone a link to say hey like prove your you by having your phone number so we're kind of like passively enabling 2fa for them but that's what we're using we're using a second factor to essentially validate the rule because again they're their

email is going to be where this link exists and so if we send them a link to an account that's compromised your euro loop Facebook has done some neat work there where you can add trusted friends and then your friends can get you out of jail other questions yeah it's TLS so we check the URL as well as the TLS stayed so distribute the question he was asked if you falsified dns yeah if you if you spoof the host file and you say Google com is now 27001 or something crazy we check the TLS state so the server will be in a TLS connection with the Fisher and again the Google report I'm gonna tell a state and you know that's

condition blue and the client will say I'm in condition red it will it will mint like we won't match and will fail out

yeah yep so so we make sure that the client is really connected to the person that sent the challenge yeah yeah yeah we have to so there's there's two white papers ones beyond Corp on corpse a little more general and then we have one that's the it's on the it's actually on Google's experience with security keys it's very similar to the one you referenced the thing I would say is like you know Google had a phishing incident rate you know that some percentage prior to rolling out security keys in the four years we've had these 100 percent deployed we've had zero successful fishing incidents we've had lots of attempts right but no incidents in four years and I think that's really

like do you want to drive this thing to zero because if you do this is the proven researched way to do it what's that program advanced something protection oh the other thing is if you're if you're not enrolled for your personal gmail account get to security keys and you can roll in what we call advanced protection which will essentially protect your consumer gmail account the exact same way we protect our corporate counts where requires security fees to log in and we do heightened monitoring of that account to look for things like takeover and hijacking you know I'm on if you have an iPhone make sure one of your keys is Bluetooth and if you want strategy of

how to communicate this to executives the advanced protection website I just google it or you know us will give you like good things to say the product page for that is really nice yeah one more question

[Music]

yeah so the question is security keys are great that they work almost nowhere did I characterize that correctly it's it's a problem it's also a problem that the largest deployment of security Keys is us we think both of those are problems and we're working really hard on them yeah we've done what Google normally does which is open source it so it's open source anyone can use it and it's free and we've we've essentially published research about how great it is you know short of paying people to do it where we're thinking about next sets yeah the the biggest bird burden that we recently overcame was how to make it work with phones and so there's there's

a Bluetooth key that works really well the first one didn't work so well the next one that I've used works really well and it lets you log into all of my corporate goog stuff via a push button which is really nice that was one of the big hurdles and so we just keep stepping over all these riddles yeah your points well-taken well thank you man I think we're yeah yeah I'm sorry I have to cut it off great everyone's [Applause]