 Please welcome our next speaker, Sherry Cowley and Dennis Taggart on Two Steps to Owning MFA. Hey, well you guys having a good time at DEF CON so far? All right, so this is our first time at DEF CON, like my first time even being here, which, and I've worked in this space for quite a long time, so it's surprising this is my first time. In fact, the last time I was here in Vegas at a computer conference was Comdex. I don't know, yeah, see, there's a couple, a few people. Yeah, I remember the Comdex computer conferences. It was just a little, little while back. But, and so I started programming at a really young age. I started hacking things at a young age. That was like high school for me. So once I finished high school, I started off with a company that traveled me around to a lot of different computer conferences. But the first time I actually saw some girls at a computer conference was Vegas. And I was really excited because I came into the conference and there's all these girls at these software booths. I thought, this is fantastic. I'm going to have women that I can talk to about technology, you know, some role models in this space. So I started, there's a few people smiling because you know where I'm going with this. Yeah. So I start talking to these girls and I'm thinking, this is going to be great. We're going to geek out. We're going to talk about photography and technology and programming. No. So most of them were dancers here in Vegas or models. And they were just hired to pretend that they worked for these software companies so they could draw guys in and pretend that they had women working for them. So we've definitely come a long ways since that. Right. I see a few girls here, which I'm really excited about walking. So walking through the halls here, I see so many women and these women, we're all excited about technology. We're excited about cryptography and about programming and about biohacking and social engineering. Right. This is exciting to us. So it's great to be here. And just a little bit about myself. So I told you I started off programming at a pretty young age, hacking at a young age. I've worked in software engineering, managed software engineering. For the last six years, I've been a manager in identity and access management and security. And that's where I thought, you know, breaking multi-factor authentication sounded like a lot of fun. So hopefully you guys enjoy this topic because we've had a lot of fun putting this together. And I've asked Dennis to present with me because first of all Dennis is one of the most brilliant pen testers that I know. He also recently won Net Wars, which that's pretty cool way to go Dennis. So I thought he'd have some valuable insights into this topic as well. And so we're going to tag team. So I'm going to have Dennis start us off with the first method, and then I'm going to jump in and we're just going to go back and forth. So hopefully you guys learn a lot. Thanks, Sherry. So when Sherry asked me, hey, Dennis, we're going to present, we're going to submit to DEFCON. I'm like, DEFCON, I've never been there and those people know a lot more than me. But with Sherry, I trust her and I've been so excited preparing for this presentation. So here's a little about me, just I was kind of a liberal arts guy through college. So I studied a lot of international relations and political science. So I like analysis and it kind of to pay for that, I needed to do some kind of work. So I was in a call center and I got really interested in tech. I love hands on work like small amount diode is really fun. If probably a lot of you went over to the hardware hacking, I don't know what that village is called here, but I saw like the chip removal stations and stuff. That was fun. I've been a pen tester for a couple years. Just we're just trying to give an educational presentation here. So just standard disclaimer, we're not sponsored by anybody or endorsed or anything. And we want everybody to be ethical and use good professional and legal judgment, you know, be smart with what we talk about. So with MFA, we're going to just go over basically the something you have portion. We're not going to talk much about any biometrics or passwords per se, but really focus on something you have in the real heart of what we want to get at here. It's funny how much when you start presentation, how many opportunities you have to find weird problems with implementations out there. While I was preparing, I had to get some receipt from a big health provider out where I live. And so I'm calling the help desk. Hey, I need this receipt for this medical record. They authenticate me, you know, with birthday and whatever else. Okay, we're going to email you this record now with your PHI. Thanks. Hang up with the representative, get a mail, email and inside of that is this link. So okay, I have to click this link. So I open it and it's got this, it says this is an encrypted message. Do you want to sign in with your Microsoft account, your personal one or your professional Microsoft account? I'm like, you don't have either of those for me. I don't want to authenticate with either of those things. What's another option? Send me a link, send me a code. Okay, click this. I'm like, where are they going to send me a code to? To my email, the same email I was just in got my code into my like PHI, super secure, right? And so it just really goes to show that security for the sake of security doesn't really get us many places. And I think that's really the heart of what we're trying to talk about today. Doesn't get us many places good. Anyway, it'll get us somewhere. But so we'll go through SMS, TOTP, and talk about push notification and finish up with U2F. This is kind of our plan for today. So another just amazing, I was really sad for Reddit. I think it was nice that they were so open with what happened. So not a roast on them, but what timing like the week before we present on this SMS is used, it's bypassed to get into their information on their users. One of the things they said was we learned that SMS based authentication is not as strong as we hoped. So they're urging companies and users to move away from SMS based to another form of multi factor authentication. And then I was interested also to find that NIST even in 2016 referred to SMS as a deprecated form of two factor. And I they ended up kind of softening that back in 2017 to say it's restricted. So basically it's risky. Like we wouldn't recommend it kind of a thing. But interesting because I feel like I'm just getting I'm seeing most of the places I am online now finally accepting SMS as a form of MFA. So now we're already needing to kind of move past it. A little bit about how it's working. You've got this application that's just working with an SMS broker. So when once the user logs in, the app is going to send it's going to communicate with some API like Twilio or somebody to say, hey, send a message out over the publicly switched telephone network. PSTN is how NIST refers to it to the phone. And they'll get you'll get this code. It doesn't have to be even any specific algorithm. It could be just a pseudo random code. They could just dump whatever they want across there. And then you have to as the user now type that into the app and then you get authenticated or not. You have a lot of entry points as an attacker. If you can get on the phone or before the network, you attack this broker, you know, you have you have quite a few places. So bypassing it's this is becoming this is becoming a big I'm seeing this I don't know if this selection bias or what like almost every article I'm seeing like Krebs just published something like on the 7th of August about a big ring of people stealing SIM cards calling pretending to be employees or working with employees for carriers and getting SIM cards sent to to the attacker. So they plug it into their device and now the target loses my phone's not working. Meanwhile, all their two factor messages are going across to the attacker controlled device. Now another you could also just there's another one online I've read about social engineering. So basically, this scam involves calling calling this marks number. So you get their username and password already. Now you just need to get their two factor. So you call them up. Hey, is is Bob there? No, you've got the wrong number. Oh, wait, wait, wait, wait, hey, before you hang up, I fat fingered you. I was I was trying to call my mom. I'm getting booked into jail or something like my you got to get my son just call call this number so that you give some big story right call this number so so that my son's not waiting there and you decide to do it for some reason because you're a nice person. And what happens is you hang up you dial the string of numbers he gave you but all you've done is initiated call forwarding. So something like star seven nine or whatever and now all the phone number phone calls coming in or going to this attack or controlled phone where this gets real crazy. I mean, a lot of in case that SMS broker goes down, there's a lot of sites that'll let you use another, you know, get a phone call or something because they don't want to get they don't want to DOS you if if the SMS third party broker is down. So you just get a is the attacker you've got the username, password, now you've got the phone calls, select to get a select to get a call instead of a text message and you've gotten in fishing here. And this is one of those things where you can kind of feel like fishing doesn't affect me anymore. I've got to, you know, multi factor enable here. But really, if an attacker can get a user to put in a username and a password, they can also trick the user to enter in whatever they're getting on their cell phone. So really fishing is a very relevant attack here as well. And here's just an example of how much it can look real. I mean, this this could be an attacker controlled page. We've got this kind of typo squatting type domain name. And if you're not paying attention as a user, you can get fish truly easily. And that's really one of the main points that's important here is just being vigilant with where we're going. I think with this crowd, we're probably pretty good about that. But really educating others on you need to you can't trust what's being presented to you. So I was interested to find that fishing with by SMS has its own name smishing. I thought it was humorous. I thought it was kind of lonely guy sounding. So I don't know. I just love that meme. And I thought we've got fishing smishing. I thought spear fishing could be called spishing probably. And that would be cool. And then if we recall whaling whale fishing, which would be bio, you know, that's not correct, but pushing, I thought would be cool. Kind of like a hot rod reference or something. But really, I just like to call it fishing. So I don't confuse myself. Another thing similar to fishing really, if you can get somebody to click a link and install mobile device management software or something. Now you're just reviewing this user's messages remotely, because they've signed up to be monitored by you. There's an example there of the text coming in and can view the target's messages easily. Finally, how many places do we get SMS messages? You can get them on your laptops. You can get them on web applications. They can be popping up on little alerts on your mobile, on your laptops. And really, if you're at work and you're leaving your desktop unlocked or something and your coworker that's decided they want to get into your account for some reason, they can just look over there and get right in. Another example is there's a lot of providers that actually provide kind of a second messaging app that you can install or sign up for. So messages plus or whatever is one. And if you do this, you can view all of your mobile messages. You can view all of your messages on the provider like Verizon's website. So basically, if you don't have two-factor setup on your carrier account, like to get into Verizon.com, but you have this messages app setup, you could just log in and view your messages on the web application. And if an attacker can get in there, they can get your two-factor as well. So really, as we know, we're only as strong as the weakest link. So if we're getting SMS messages to places that are not protected by multi-factor auth, it's a potential point for an attacker to get in and target us. To prevent this, really using something besides SMS is a really good idea, if at all possible. Using some form of multi-factor, but using something else if possible. Requesting port-out authorization can be a good way to have it so that the providers don't just so easily let you port your number somewhere else. And if an attacker were to call and say, hey, I'm getting a new phone number, will you transfer this number over to this one? If the carrier needs to contact you first, it'll make it harder for the attacker to do that. Also, application security must not be neglected here. If you do all this work for two multi-factor and then once you get in, there's some persistent cross-site scripting vulnerability sending your cookies somewhere else, the attacker doesn't need to do multi-factor once you're already authenticated. So train on phishing, train on malware, document a strategy for response, and then handling these unsolicited notifications if they come. So was it really unsolicited as something you have to ask? Sometimes you might freak yourself out, maybe it'll come a little bit late or you've started doing something else. Make sure it really is unsolicited. If you're working for somebody else or protecting somebody else's account, how was this person a big target? And changing the password as soon as possible because if you've verified you're getting a solicited request, somebody's got the password out there. Identify all the attacker activity because what would be really bad is if you go through all the work, you run the incident, you change the password, and then the guy, there's some vulnerability out there still getting the account re-compromised. So identifying how the initial compromise is happening also helps and continue to monitor. Yeah, yeah, yeah. So how do you deal with the timing for how long the token is good for? It's a great question. So there's a couple of parameters. You've got the how long is it livable for and then there's also the how many times can it be used because we hope that it's only allowed to be used once. And we hope usually it's something like with the SMS ones, you'd have to have some application logic to really rock that down because it's not necessarily a time-based one-time password, which we're going to get a little bit of a talk on here in a little bit. You hope that you're only getting maybe five minutes or something or less, but you have to leave some lead time for how long did it take to go through the broker and get through. But great question. I hope if there's more at the end, let us know. But Sherry's going to talk about time-based one-time password which will speak more to what you're asking, I think. Okay, so let's see at the end. Well, thanks for your question. All right, Sherry. Sweet. All right, so I'm just going to add to that too. So it kind of depends on the application. So it could be five minutes or 20 minutes is common for an SMS code to live. And typically there's going to be brute force protection, you would hope if you're creating an application, you're going to want to have brute force protection. So you're only allowing maybe a few three, five times to enter the code in in case, you know, a grandma fat fingers or grandpa or whoever, fat fingers, that number, and you give them a couple of tries. But usually you want to keep that condensed so people can just brute force that right and figure out your six digit code without having the code on the phone. Well, I'll talk to you afterwards. So if you want, yeah, yeah. In fact, if we run out of time, because we do have a lot of material, so if we run out of time, I'm going to show you my Twitter handle, you're welcome to reach out to me or we can talk afterwards because, yeah, this is a field that I love to talk about. You're great. So, you're good. So the next one we're going to talk about is TOTP. So this is really similar to the question we just got. So this is a time-based one-time password. So you guys are probably more familiar with this with Google Authenticator, right? So Google Authenticator, Microsoft Authenticator, Authy, Duo, all those things that you probably use for your company, hopefully your bank, maybe school, right? These these things run off of what's called TOTP. So it's a time-based algorithm. So it's a one-time password. And typically it generates every 30 seconds, right? If you look at your Google Authenticator app, you're going to see every 30 seconds you get get a code. They usually have about a minute and a half padding around that too. So it lasts typically about a minute and a half, maybe two minutes is really the length that that code will last. And this is based off of the oath standards. The only reason I mentioned that, one is just kind of nice to know where things come from, but also just because this gets confused a lot with OAuth2. So any people who are familiar with identity, if that's your space, OAuth2 is Federation, Authentication. So that's totally different. And I'm going to talk a little bit about that later. In fact, I'm doing some research right now on breaking OAuth2. So if anyone's interested in having that discussion, I'd love to collaborate with you. So this is based off of the oath standards. So it's a set algorithm. And it's good to know that because you're going to see that there's some great vulnerabilities in the fact that it's using this common algorithm everywhere. So there's different types. This one's time-based. There's also a counter-based, which is H-O-T-P. And that just means that the one time you use the password, it then creates a new one or a new code. And it does that every time you create, every time you use it. So that's H-O-T-P. So this is probably what you're used to seeing. When you set up Google Authenticator, you're going to see a QR code. And you're going to see, if you scanned that or if you went to Can't Scan It, that's typically you're going to see something like Can't Scan It or Copy Code Manually. If you click on that, then you're going to see the shared key. And I'm going to explain to you why that's important, why we want to know what that shared key is. Because that right there, that's like the valuable piece with T-O-T-P. You get that, you're golden. So this is usually what you're going to see. Now what's happening behind the scenes? So we got this shared key. And all we do is hash that with the time. And this is looking at the Cisco time. This is our server time. So if you were to take this into a calculator right now, you would see that it would be today at 11 o'clock. So we take the time of right now and add that with a shared key. And then we just get a hash. And I know when we see algorithms, we get a little nervous, but I'm just going to break this down. And it's actually really simple. So you'll see how this works. All right. So we got this hash. And now all I do is I look at the last character or the last four bits, but we're just going to say the last character, which is f in this case. And the decimal value of f is 15. So I'm going to offset this by 15. Right? And then you'll see I have it broken up in pairs. So if I just count that, starting with zero, you get to 15. That's where 4b is. That's highlighted in red. So we take the next four bytes after we offset it by 15. Pull that and then convert it from hex to decimal. Right? And then you mod that by a million because all you're trying to do is just get six digits. That's typical. Usually you only have six digits that you type in. So they mod that by a million, which all that is, is you divide it by a million and you take the remainder, which is six digits in this case. And that's your TOTP code. That is the standard algorithm that's used every single time. And it's nice to know that because if I get your shared key, I mean I could be, you know, for fun, I could calculate this myself, or of course I could just use an application to do that. But the important part of this is the fact that there's a shared key. Right? All I have to do is get a hold of that. That's your golden ticket. And the fact that that's available, now I just have to think about, okay, well, where did they store the shared key? Well, it's stored on their phone because Google Authenticator knows it. So it's going to be stored in the phone's database, the app's database. So if I get full control of their phone, I could extract that key and now I can generate my own six-digit code for them. Or if I get a hold of the application or figure out how to compromise the application, I can also get that shared key. And I'm going to show you just a quick demo here of how you could do that. And nothing like demo is when you're being recorded and presenting your first time at DEF CON, right? Right. So I created a really simple web application and this intentionally has lots of vulnerabilities on it, just for demo purposes and for fun. But you know what? It's actually pretty realistic with a lot of sites out there. So we're going to sign in. I kind of have this ode to the women of technology going on. So I'm going to sign in as Ada Loveless. If you don't know who Ada Loveless is, you should look it up. 1800s. She helped came up with algorithms that we use today in programming. All right. So this site, it's pretty awesome because it has two-step verification, rare multi-factor authentication on it. So this makes you feel nice and warm and fuzzy because we know that they take security seriously. Oops. Let me get two. So I have an OTP manager installed on my, this is a Windows machine. If you're using a Mac, you can use J off. So you can install your own desktop OTP manager as well, which is convenient because in this circumstance, I don't have to go to a phone. So I'm just going to copy Ada's second factor, paste that in here. Right. Now I signed in. It's a really simple app. All it's doing is showing my account settings. Oops, scroll down so you guys can see that a little better for Ada. And so this, I brought this up because, I mean, obviously this is a pretty insecure app. Usually you're not going to show your password in plain text right there, right? But some apps will still give you access to that shared key. They may allow you to go into Google Authenticator or Authenticator app or whatever they call it, Duo or whatever in order to edit your shared key or add another device. If it lets you do that, all you have to do is they're signed in. You just come across, access their account settings and you're able to grab that shared key. Now let's imagine, though, that I don't have access to this website. And I'm just going to do basic hacking 101, right? I'm just going to put in here. Oops. I guess I have to type it in. So I'm just going to put in some basic SQL injection, right? Or one equals one, right? Old school. But what's funny about that is that Verizon data breach report just showed last year that this is still the second most common way that data breaches happen is through SQL injection. So we put in some SQL injection. It doesn't know who to give us, so it gives us the entire database. Isn't that convenient? And this, unfortunately, is a vulnerability that, like I said, is pretty common. So since they've stored the shared key right along with the username and the password, I now have the username, I have the password, and I have the shared key that I can just now generate my own TOTP. So if we wanted to sign in, that's Hedy Lamar, who we should also look up. Hedy was a famous Hollywood actress. And yeah, she also invented spread spectrum, which is used in Wi-Fi, Bluetooth, and that's pretty cool. So if I wanted to, in fact, let's go over here. Oops. So if I wanted to sign in as Hedy, all I have to do, I could just go through that algorithm myself, do the offset, or I can be lazy because hackers are typically lazy. So I'm just going to save this here. And now it just generated, it went through that same algorithm I showed you, and it just generated that six digit code. This app is, there you go, a little chintzy. So now all I have to do, back to here, put in, since I have Hedy's password, because I got that as well, I now sign in, put this in here, and it signs in. So if you imagine if this was like the administrator, right, I got into that database, I now just elevated my privileges by logging in now as the administrator of the system. So what this teaches us is that application security is still important no matter what, right. If I can get into the database, if I can get access to the database of where that shared key is stored, if I can find some vulnerability on your web application, I might be able to get it to extract that shared key and still be able to get past that second factor. So just because you have multi-factor authentication in place, it doesn't mean that your sites can automatically be secure. And if we just look at, I mean here, two steps in order to get in, I exploit either the user, right, social engineering is always a great target or a great avenue to take. I can exploit the application like I just did, right, SQL injection, cross-site scripting, cores, try and find some vulnerability in the application, see if I can get into that database, or take advantage of the phone. If I can control the phone, I can get the shared key from there as well. And then obviously get into the target's account. So how do we prevent this? So first of all, you want to make sure you're diligent about application security. You can't take application security lightly. So you need to make sure you're securing your sites. And you got to think about the fact that, I mean, how many, if you have multiple apps in your company, make sure that all of them are protected, that no one's allowing you to get into your identity database. And where you store that shared key is important. If you're storing it right alongside the username and password, right, if someone can get your username and password, they're going to be able to get that too. So all the same things, all the same ways that people can get access to the database, they're going to just do that same thing and get access to the shared key. So you want to make sure that either you store it in a separate location, you encrypt it, you're putting monitoring in place, you're protecting it, you're treating that just like a password because that's what it is. And then of course, TOTP can also be phished. And then you want to protect it against all other vulnerabilities that are out there. All right. So the next thing we're going to jump into is push notification and then we'll dive into U2F security keys. Thanks. So Jean noticed when Sherry, she used that one-time password and you saw that bar kind of getting close to where it was going to reset. And I was like, oh no, it's not going to work. But Sherry taught me something I think you'd all think this is interesting too. I mean, there's usually a pad of 30 seconds or so on either side, isn't it? On either side. So just one of those things to keep in mind that you got to have account for network lag times, server times, whatever problems in between it. So that's why that code still worked, even though if we had looked at the screen right before she'd enter, there would have been another code there. And I just think that's cool. So push notifications. There's an example. Do you want to sign in? Yes, no. That kind of thing. How does it work? What's cool is you're kind of getting away from the whole PSTN side of things that we were talking about earlier. You've got this potential trust issue where you're writing over a network and you've got all these other pieces in between that you don't know if you trust so much. Well here, we still obviously are talking, communicating over a network. But you basically, when you log in, the application, instead of talking to an SMS broker, is going to talk to some service provider. We're talking Google or Apple a lot of times, the most popular. And the application is going to include an application or a device token and the query. That goes out to the service provider who's going to also forward that along. But using the device token, looking up the device, sending it to the actual user device, when you respond, it goes back to the same channels. And the response based on that allows access into the application. What's really unique here and important to remember, so this device token is the same across. You've got it on the application, you've got it on this service provider, and you've got it on the device. So how are we going to bypass that? Well, getting access to try to change that token is really what you want to do. And if you can find as an attacker, if you know what your device token is, and you can impose that on a target user's device, then all of the messages destined for them are going to come to your device. So ways to do that. I mean, Sherry gave that great example with, you know, SQL injection. If you can get in through that kind of weakness and inject your device token over other users, then that will get you what you're trying to do. Also, if you can just log into the database potentially bad passwords, if you've got some maybe indirect object references or insecure direct object references and some API, this is totally out there. Or maybe as you're logged in, you can make a change to, instead of just updating your account, maybe you can change another user's account through some parameter tampering or something and update also the device token. Those are all some examples. We'll give, let's kind of show what that would look like. So go back to that same application, same user here, we'll log in as Ada and we're going to try to change, we'll change Hedy's device token to Ada's. So we'll get the messages destined for Hedy. Too much trackpad, sorry. Okay. So here we are, familiar screen, we're going to look at our push notification options saved though for this user. Let's view the device token before we try to change it, huh? Okay. So here's the device token, you can see here we've got 64 characters, so it's a little longer. It's mostly random, but at the end, we've got a little homage to DEF CON. Let's remember that too, because this is too long to remember all of these things, but we're going to change Hedy's to be this key, this device token. So let's update. How are we going to do it? I can't mess with this. Let's look at the URL. There's some parameter tampering potential right here. Sorry, that's small, and I can't make that bigger right now. But the ID says one, two, three, eight for Ada. Let's just change that to one, two, three, nine, because that's what, let's see. So we've got Hedy's. So now we've got this QR code here. This is the kind of thing, we've just got an endpoint where if you, usually these things just, when you scan them, all it's doing is sending whatever information is needed to update that token. So, you know, we sat here and scanned this, and what would happen here, let's go look at hers. We've got the same, say, now we have Ada's token in place of where Hedy's was, and that would be a really bad vulnerability to have, right? Nobody has that, but no, they do. And that really exists out there, where these values, they're not totally obvious maybe what they're used for to maybe the user, but if an attacker can get control of them, it's end game for the security of that MFA token. Let's go to the next slide here. Let's go to the presentation too. So defending against that, just like what Sherry was saying, application security is really important here as well. It kind of goes back to that first example we talked about too, where I got that email that, hey, it's an encrypted document with PHI, it's so encrypted and send me a token to my email, you know, and I just walked through the MFA. It all comes down to implementation. That wasn't the provider's fault. That's just the way it was implemented. And same thing, if you go through all this work to set up MFA, you've got this, I know SMS is maybe not as secure, so I'm going to do push notifications on my app, but then you've got some roundabout way of just walking in, the whole thing falls apart. So phishing and social engineering here as well, if you can get the user to click yes on your bad site, you can capture these tokens as well. Understanding how to respond to unsolicited push notifications, everything's always worse when the world's on fire and you don't, is my account compromised? You bound to make more mistakes that way. For example, trying to get some kind of downgrade attack to happen. If let's say the user is seeing a lot of push notifications coming across and they're just sick of it and they just go and log in and turn off push notifications, that would be a really dumb thing to do, but that could totally happen. Their work is interrupted, they need to get back to work, so I'm done with this broken technology that doesn't work, right? Having a strategy for how to respond can prevent silly things like that from defeating the multi-factor Roth. Social engineering calling up if an attacker were to call up to the help desk and hey, I lost my, I don't know, I don't have my phone today, I need, we just got to do something else about this, I can't get in. Can you turn off multi-factor for the day? If the attacker can successfully imitate the user and get them to just turn it off for maybe even just eight hours, just the work day, that's a huge window. Session hijacking is still very much applicable here as well. Once the session has been, once you've got that session made, all the two-factor multi-factor, all that stuff is done, so that needs the session to be protected. I think that's pretty good on this one. Oh, accidental approval, no, we need to talk about that one for a second. So statistically, if, and this could go into some more social engineering too, so you could just as an attacker just log in, hopefully the attacker knew, especially if you're a big corporation, you don't want to blow maybe your offset or something if you're a pen tester, but hopefully you knew if they had MFA on or not. But even if you didn't and the pop-up goes up and the user's clicks yes without really kind of thinking, maybe just muscle memory or something, that could get you in. It can be that simple. Or more social engineering instead of going against the help desk, going against the user themselves, hey, we're testing out some functionality, we had some complaints, so will you just click one of the buttons when it comes up? You're going to get a notification. There are studies out there, statistically, the user will select yes more than no. And so that sounds so dumb, but that's true. And it can be that simple. So all this work, all this architectural design, all this engineering can all be foiled by kind of one silly thing. So it's important to consider when we're implementing one more thing. I thought of one other thing, arbitrary code in the target devices. So you're getting, you've got this push notification popping up. If the attacker can control what's going to be sent in the message to the user, you can try to run maybe cross ice, you can try to run JavaScript or something in that target user device. And depending on the device, you might have, you might have some success there. And depending on how much validation's going on client side and what's, you're actually able to submit to the user device. And with that, I think that rounds out push pretty well. All right, sweet. The finale. All right, so we're going to end on U2F security keys. And this one is definitely my favorite. There's a lot of incredible controls here, but we're going to show you still some ways to get around this. And one thing that, as Dennis was mentioned, arbitrary code with push notification, that's intriguing to me because you think that push, if you gain control of that, you could send whatever messages, whatever code, whatever anything you wanted to do to someone's phone if you owned that application that's sending those messages. So that's just kind of interesting to think about. But all right, so U2F security keys, the way this works. So it's security key. If you haven't used one, it's kind of like a thumb drive. It goes into your USB or USB-C port. You just type in your password, press the button, and then it logs you in. And security keys, especially, well, there's many different types of security keys, first of all. So there's some that do just like Google Authenticator does, generates just a code. You can get past that in the same way as you can get past Google Authenticator or similar. You could still fish. But with U2F, it has additional controls that are in place. So just know that not all security keys are the same. So U2F was created by the FIDO Alliance. And they, multiple organizations, mostly UBICO and quite a few other impressive organizations came together to try and make authentication stronger. So what they came up with has so many controls. And as Dennis mentioned, Reddit was just recently in the news about their data breach. Reddit is now looking at using, they've mentioned using security keys. I don't know if they are yet, but this is, if I were to talk to them, I would tell them to make sure they're using U2F security keys. Don't use Google Authenticator or one of the other options. I just go straight here. And that's what Google is using today, too. Google has advertised that this is their way to get past phishing is using U2F security keys. So some of the benefits and the reason why there's some great controls here. It uses public private key on the initial handshake. So it's going to pass a key, first of all, and then it's also going to pass a origin ID when I'll dive into that a little bit more that helps you avoid phishing. And it's also going to use token binding, which we'll dive into as well, because that's kind of, that's pretty exciting and interesting. You can't write to the security key. It's right blocked. So unlike a phone, a phone, I can get control of this, right? You're, you're browsing the internet with your phone. So there's multiple ways to get control of someone's phone, but a security key, you can't write to it. So I can't get remote access to your security key. I also, they use a nonce. They use a counter. So I can do a replay attack on it. If I get the messages it's transferring across, I can't use it more than it can only use once, right? So I can't replay if I grab a message. And it requires human interaction. So that means for QA testing, it's kind of a pain because you have to have a human actually push the button. But for hackers, it's even more of a pain because you can't automate that, right? So some really cool things that U2F offers. So origin bound, oh, this just shows kind of that process, that initial setup. So you're going to see, and this is good to know because there's always a message or some data that's going to be stored on both sides, right? So the security key is going to store that public private key, the origin ID, the TLS channel ID or token binding. You're also going to have that same thing stored on the application. So if you can get access to that, right, swap out your message with someone else's, then you can just use your security key. So know that there's some storage that takes place, really similar to push notification. You still could take advantage of this, but you'd have to get access to the identity provider database. All right, so just a little bit more about origin binding. So this binds against the domain name. And so like with phishing, I'm going to pretend Google1.com, right? You may not notice. You think you're on the real side, but with origin bound, it's going to look at the URI. So it's not going to allow me to fish the web application. Token binding, now this is a little more complex, but how token binding works. So this is at the TLS layer, so at the transport layer. So during TLS, you're doing a handshake, right, that takes place. And TLS, if you just picture it like a tunnel, right, or a straw, right, so that whole tunnel is protected. But you don't know if it's going from point A to point B, if someone got in the middle of that and interacted with that message, you actually with TLS, it doesn't protect you against that. But TLS token binding does. And this is something you're going to hear about this more and more with a lot of different technologies because it does allow us to protect against man in the middle and session hijacking. Now if you used, you'd have to use token binding to protect your access token or your ID token, if you're using OpenID Connect. If you protect those tokens with token binding, then you would be able to protect against session hijacking. Now the interesting thing here, right, so there's all these complexities that go with token binding, which is really, really cool, but it's also complex and it's fairly new still. So there's a lot of servers, so web servers, network systems that may not be able to support this yet. So if you look at the U2F specs, you're going to see that this is listed as optional. So token binding, even though it's super cool and it protects against man in the middle and protects against session hijacking, it's optional, which means that not all companies have probably taken advantage of this yet. So you have to have a web server, Apache does support it, but there's some web servers that don't. So you'd have to have a web server that supports token binding in order to be able to use it. You'd have to use this throughout your network, right? If you think about kind of all the hops that are taking place, if you're not using token binding at one spot, then that area is still going to be vulnerable to man in the middle of text. So there's still, even though I mean we hear about this and it sounds super cool, there's still ways around it. And if they're not using token binding with all their access or refresh tokens with OAuth2 or OpenID Connect, then you still would probably be able to use, well you would, be able to use session hijacking. So if I was a pen tester of a large organization and we just announced that we're going to switch over to U2F security keys, this is one thing I'd want to test to see, okay, yeah, it advertises it can do this, but is our company actually doing this? Because this is an architecture change. You actually have to think about the architecture throughout your network in order to make sure you've implemented this correctly. And so even though it's awesome, right, it opens you up to some vulnerabilities right there. All right, well I'm going to try and speed through the rest of this. But, you know, so know that U2F is still not totally foolproof. Obviously physical attack would be probably your easiest method, right? Just get access to the security key and then now you just get the password like you always did before and you can get in. You can manipulate the database like we talked about, switch out the message, it's usually a JSON message, you can switch that out with your own and you can get in. Social engineer, the support team, try a backup method. That security key is so small, it's easy to leave it home or to lose. They may have set up a backup method like SMS, which would obviously be a lot easier to get past. So as we were looking to this, we kind of reminded us of that comic. I think you guys have probably seen this before, you know, how can we get past this complex encryption system? Kind of the same thing with security key, you know, how can we get past U2F? We could create this, you know, try and create some type of expensive solution or I could buy a $5 wrench, hit somebody on the head and ask them to give me their security key, right? And that's probably your easiest solution is just get access to the security key. Social engineer, the support team, that's probably the simplest way to get past it, but then there's also still some vulnerabilities. All right, to protect, we want to protect the authentication database, make sure that someone can't get access to that. If I was able to do SQL injection still on the database and do an update, I might be able to just swap out my security key message with yours and now I'm using my security key and nobody would know. Patch, monitor, all of your systems obviously protect against malware, so all the basics. So end result, you know, is multi-factor a silver bullet? Is it going to protect you against everything? No. I mean, obviously it's an incredible layer, you know, security is all about complexities and we want to have as much complexity as we can to deter people from getting into our systems, to add more controls that people have to get past, but with those complexities there's always going to be some vulnerabilities that people can get by and hopefully we're able to show you some of those vulnerabilities. I know we're running out of time, so I apologize we don't get a chance to ask any questions, but Dennis and I will be out in the hall. You can talk to us or feel free to send us a message on Twitter. I'm pretty easy to find, just Sherry Cowley and Dennis. Feel free to add us and ask us any questions and we'd love to collaborate. So thank you very much.