BYO-Disaster and Why Corporate Wireless Security Still Sucks
Hoover, Josh (Djwishbone )
Snodgrass, James (PuNk1nPo0p)
Right when you thought this topic had been beaten to death, something new emerges. This horse isn't dead yet! This talk will focus on a completely new vulnerability in the way some devices handle MsChapV2 and present some newer methods for capturing clear text credentials easily and without heavy processing power. We will walk you through a full attack against WPA2 enterprise networks using a special patched version of radius that makes this all possible. But wait, there's more! Act now, by coming to the talk, and you'll receive access to new automation tools to do a lot of the work for you. If you're lazy like us and would like access to credentials without a math degree this talk is for you! James Snodgrass enjoys pumping iron and flattening hats. His greatest aspiration in life is leveling his Ford truck and finding that next tight t-shirt. Josh Hoover has spent over a decade in computer security, focused on digital forensics and penetration testing. He has been attending DEF CON for 14 years but this is the first time he has ever spoken at one.
 So anyway, our talks on we call it B.O.I.O. disaster and why corporate wireless security still sucks. A little bit about us. Let me push some buttons. Anyways, my name is James. I also go by punk and poop online back in the old air, sea days and stuff. Independent security researcher, just an all around nerd, boring guy. And with me I have Josh Hoover here, the guy that pooped today. Can you hear me? No, you can not. You're talking on us. That's fine. I'll switch over here. Yeah, I'm Josh. I've been coming to DEF CON since, well, since I had hair and some of my friends over here were just starting to grow hair. So we've been here for quite a while. Privilege to be here. Thank you for coming to our TBA talk. This picture, the gym selected of me is supposed to be kind of a joke. Did you guys read our profiles at all online? You probably can't see in the book, but online. Anyway, there's a funny profile I wrote for Jim and this is his way of getting back at me. I told him to pick any random picture he could find on Facebook. So that's the evil one he picked of me. So anyways, at the end of the day we're just nerds with random ideas and inconsistent results. That's been the story of our lives. So what we're going to talk about today is we're going to show you some ways to obtain clear text credentials without cracking a single hash for a PIP-enabled WPA2 enterprise networks. There's been a lot of research and work in the past that is involved gathering hashes and cracking them offline using like brute force dictionary attacks and those kind of things. We're pretty lazy. We don't have time or want to spend a lot of time cracking hashes. So our whole thought was to come together and try to find an easier way, a faster way of capturing clear text credentials to gain access to networks. Secondly, we're going to release a tool that kind of automates the whole process and does things for you right out of the gate really fast. So if anybody's done these attacks in the past to set up the interfaces and all that, it can be kind of time consuming. So we've kind of automated that whole process for you. How we're going to do this is we're going to explore a new functionality issue and I'll get into that more later that we found with how iOS and OXX devices are handling MSChat v2. Secondly, we're going to demonstrate the use of EAPGTC as an inner authentication mechanism in place of MSChat v2. So I'll go ahead and give it to Josh here and he's going to kind of take you through some of the technicals for MSChat v2. So how many people here have showed hands that have ever set up a WPA2 enterprise network or know the ins and outs of that? You shouldn't, but anyway, that's great. That's what that guy said right there. So it looks like there's a fair amount of you that haven't yet. So I'm going to kind of go over some of the technical details on exactly what our research was looking at. I'm sure most of you have set up a WPA2 personal at home where you set a pre-shared key of some kind and you gave it a sit and you connected to it and you knew what the password is and you signed into it. Basically, WPA2 enterprise just adds one extra component to that, usually a back end authentication server of some kind. In this particular instance, it's the radius server box you see on your right, I guess, of the screen. And that just adds another layer of the indication so you can authenticate every single client that connects to your network instead of just having one key that you'd use maybe at your home network. So you have a client that you see there on the left, an AP in the middle, and then we're adding an extra component for WPA2 enterprise, which is the authentication server. In this particular instance, it's going to be a radius server, but there are other options there for different kinds of servers, but this is what we're centering on for the MSChat V2 and GTC stuff. And it's a lot of what you'll see in enterprise-level networks and crazy people like us like to run this kind of thing at home for some weird reason. So what's the first thing that happens when you connect to an AP, right? I mean, most people are familiar with that, right? You pick your SID and you connect right up to it. You pick your network name there and that's pretty easy. I'm going to blow your mind with technical details here, right? I'm not going to go into that portion of it, but it's worth mentioning that this is the first layer of attack for a lot of people that want to set up what's called an evil twin network. And basically what you're doing is you're mirroring the exact same SID that your target is using and hoping that clients will connect to you instead of to the actual AP. And so that's the first layer of attack called the evil twin. And that has to do with the dangerous. These guys are going to be very angry at me because I actually don't drink, so. My Jim's got to drink double because I can't drink, so. You guys can throw things at me instead if it makes you feel better, though. No way. We're here to help you. Here's for you. Here's for your co‑speaker. You know how many times in my career I've had to take one for the team for this guy? And also, as you may be familiar, raise your hand if this is your first F‑con. Why is it everybody's new? Wait, why are we pointing at him? All right. You get up here. That's her first F‑con. And the lady down here with the striped dress on. I got to suffer your suffering, too. Wait, wait, wait. What are you doing? Hey, we don't have people up here. Where's mine? Two more. Bear with us. They know it was my first time. They know. Did you pick it up from the bar? I know it's a double. No, we did not do that last time. I tried. What, we got more? Geez, all right, everybody, come on. We're actually out of coffee, so. All right. To all of you newbies, welcome. I'm sorry, your time is up now. Thanks, Ravines. It's already coming out the other end. I have no idea what I was doing. Where am I? Drink one? No. So, association stuff, right? We got the shots covered. Okay. So, association stuff. We're connecting to Evil Twin, blah, blah, blah. That's the first layer attack. We're excited about that. Let's move on. The next portion that happens in WPA2 enterprise is what's called an EAP proposal. What's EAP? EAP is extensive authentication protocol. Basically, that's just a fancy acronym for a methodology or a framework that's used for authentication of all kinds of services. This particular service is going to be Wi-Fi. It allows you to add user name and password or certificates or one-time password, something like that to some kind of service. The first thing that will happen here in this proportion is that the AP is going to request identity from the client. The client gets a pop-up on most clients that says nothing more than user name and password. That's all it says. That will be important later. We haven't really established exactly what kind of authentication we're even using yet. So, anyway, the client sends that over. Doesn't actually send the password over yet, but does send over the identity, which in this case is the user name or some kind of login name. This is another layer of attack that a lot of people like to use because now you could just stop here if you wanted and just gather user names all day long. That's boring. We want passwords. We don't want to have to crack them. We don't have to brute force it. That only gets us one step. So after it sends it over to the radio server, the radio server says, okay, that's good. It's going to send over what's called a peep start. So what's peep? Peep is protected extensible authentication protocol. And basically that's just a fancy way of protecting EAP. So, unfortunately, EAP by itself isn't inherently secure. So if you were sending over hashes or whatever you're sending over using just regular EAP, you can pick them up usually over the air because at this point there's no encryption at all at this point. So you could pick up anything. And so this is a way to protect that data. What peep does is it makes what's called an outer authentication and inner authentication. The outer authentication is not very fancy. It's just an encrypted tunnel. And the inner authentication is the actual users or clients information. So it's attempting to protect that information inside of an encrypted tunnel, which is great if you're sitting on the outside and you're just sniffing it, but if you're the evil twin, they're sending it all to you. But you've got to make sure all this stuff happens otherwise the client's going to freak out and it's not going to send you its credentials. And it's goodies that you want to get so you don't have to goodies, except word. So what happens next? So anyway, the outer authentication happens next. Again, part of peep. I'm not going to do a lot of technical details here. It's TLS setup stuff. So you guys can look up TLS if you're not familiar with it. But there's a server search that's on the radio server that gets sent over and it establishes a TLS tunnel in order to start sending over all the goodies, all the good authentication portions of whatever you happen to do. So after that, you go into the inner authentication portion. That's inner eep. In this particular instance, we're going to be talking about MSChap v2. Now, v2 differs from v1 and I'll explain that in a second. But MSChap is generally used for NT or domain or whatever, Windows login. So username and password. It's a way to allow people to use that in order to log into a wireless network. So this is kind of important for a lot of enterprises out there because they want to make it easy. They don't have to worry about passwords or have to worry about key management or people want to bring in their BYOD devices and just connect up to the network and this enables them to use their normal login that they would use on the corporate network or whatever network they're using. So the first thing that happens in this inner authentication portion is what's called ‑‑ oh, sorry. It just sends the identity again. Actually sends the identity again over to the radio server. So it requests it and sends it. Yeah, great. We've already got that. That's something new. So the first thing that happens from the radio server, it sends over a challenge. It must have a V2 challenge. The client takes this challenge and takes its password and makes a hash from it. And then it sends it back to the radio server. Now, an important part of V2 over V1 is that there's a dual authentication happening here. Both the client and the radio server want to make sure that each other actually knows the password. So the radius creates a challenge and sends it over to the client and says, hey, here's a challenge, use this challenge portion to create a password for me, a hash, and send it back to me. And the client says, okay, no problem. I will take that challenge, my password, create a hash, send the hash over to you. It's a hash. There's lots of people here that can tell you how to crack those, but we're lazy and we still consider that too difficult for our small minds. So it'll send that back over with an actual challenge of itself and say, okay, here's my hash, but I want you to tell me that you know my passwords. Here's my own challenge. Create this challenge, hash it with whatever you think is my password, and send it back to me. So the race says, okay, if I do actually have your password, I'm going to do that and I'm going to take your challenge and send a response back to the client. At this point, the client looks at it and says, okay, does this match? If it does not match, it's supposed to drop the connection at this point, which may or may not happen as we see here going on. But this is an important part of V1 versus V2. Microsoft and Cisco specifically created this in order to try to circumvent some of what's going on here in the attacks you'll see here in a second by making sure the client says, well, I'll give you my hash, but I'm not going to connect until I'm sure you actually know my password. So again, if that does work and it does actually know the password, then the radius server will take that. It'll make its actual response and say, okay, your password was successful. Here's the response to your challenge. The client looks at that and says, okay, you do actually know my password, no problem. Let's send over a success to the radius server. The radius server says, great, we're all good. Let's start our connection. It sends over what's called an EAP-TLV success. The client acknowledges that and we're golden. So the inner authentication has happened correctly. Again, this is with MSChat V2. So what happens next is basically just an EAP success portion here. We're installing some special keys onto the AP to start up the actual encrypted network connection so they can get the rest of their IP address and everything that they need to in order to get access to the actual network. And again, I'll blow your mind here with some really fancy technical details, finishing the connection stuff. I won't really go into that. But again, what we're really concentrating on here in our attack is the inner authentication portion because we want the password. We want them to make a full connection to us so we need to convince them that we know the password. We want them to send the password to us anyway. And so this is where our research is really focused. Anybody who's done ‑‑ how many people out here do security research other than showing up to DEF CON? I guess that's considered security research, right? So a few of you, you're probably familiar with how difficult this can be, especially if you run into stuff like this where you're trying to get a full connection and MSChat is hitting you in the face and saying, no, you can't have that connection and you try again and it hits you in the face and whatever happens. So we found this funny little video that kind of reminds us ‑‑ some of you have probably seen this before, kind of reminds us exactly what this feels like. Yeah, it's not a whole lot of fun, but, you know, she's okay. So you'll be okay too. You know, you take a few hits in the face, you know, you can get back up and she actually did get back up and she had to finish this. But anyway. So that's a little overview, quick overview of the way that our research ‑‑ exactly what our research is looking at technology was. I think everyone loves that video. Okay, Jim, I'm going to pass over Jim here and he's going to tell you about our actual first attack. Thank you for sitting through all of that technical detail. All right. So, you know, I have to say that I purposely only had like three drinks when I was coming to. That's just to take the edge off. So the crap that they just gave me just kind of pushed me over my edge. So I'm going to do my best to get through these slides. So anyways, the first attack. We call it the iPoner because it's central around iOS and OXX devices. On the left side there you see the mobile device of phone and then on the right side we have the actual radio server. We didn't put the AP in the middle but if you can imagine, there's obviously an AP in the middle of this thing. So we've ‑‑ the radio server is a patch version that we wrote that kind of puts the exploit into there. Kind of like what Josh Wright's done in the past with his patch for radius for capturing hashes and cracking those offline. We kind of did the same type of thing in a different ‑‑ I guess a different way. But anyways, the first thing that happens is the server challenges the client like what Josh was talking about earlier. The client gets that. It's going to send its MSChap response back along with its peer challenge. And that peer challenge is basically the client's way of authenticating the server to itself. It's basically to make sure that both people have knowledge of the clear text credentials. So once the server gets that in response, it's going to look in its database and obviously as the attacker, we don't know what the user's password is at this point. So we have two choices. We can either tell them, cool, your password is good or hey, your password is wrong. So the first thing we tried obviously is we accept everything. And if anybody has used the patches that have been out in the past, they've been designed to say success for everything. Any password you send it is going to send a success in response. When we do that, the peer challenge doesn't match for all devices. It looks it up in its database and says, hey, you're full of crap. What you sent me back is wrong. And typically it drops a connection or it sits in kind of a limbo state. It won't actually establish a connection to the network, which is what we're after. So we start over. You know, we actually tried a lot of things, but we're consolidating this into the one that worked for you guys at stake. But anyways, so we reject the password. We just tell them, yep, what you sent me is incorrect. So the server then sends a TLV success at the end. So we tell the user send us this password, we send it back saying, no, whatever you sent me is incorrect. Expecting the client to drop the connection. For some reason, IOS and OXX devices don't drop the connection. So we follow that up with a TLV success, basically telling the client that everything's good. We're going to go ahead and finish this connection and I'll send you a DHCP address and start sending you network services. OXX devices go, well, you know, I don't really know what this means, but okay, cool. We're good. So right. So the client sends us a TLV success at that point, meaning that they're ready for a DHCP address and everything else is going on. So the client checks for a captive portal. Another crappy thing about your IOS and OXX mobile devices, most devices, when you're connecting to a secured wireless network, it knows that there's not a captive portal. So there's no reason to send a probe out saying there's a captive portal there. IOS and OXX devices don't do that. They send that probe no matter what. So what we do is we capture that probe and say, sure, there's a captive portal on your secured network that you don't need. And we forward that on. So basically, we send them the captive portal, which is an HTTP, right? They type in the password again and we get it in clear text. That's how the attack basically works. We're very happy. So right. So we're not... So from a user's perspective, you know, what does this look like from your mobile phone? So you get some manager that brings his personal phone to work and he wants to check his email because he's late for a meeting, all that jazz, even though he knows it's not allowed, but he doesn't care. He's a manager, right? So he pulls up his iPhone, he's looking at it, like Manny right here in the front, Tony and Manny right here, like those guys. Anyways. So you got your MSChep test network. That's what we're calling it in this case. So you select it. It prompts you for your username and password like you're used to. You type that in. It's going to pop up a cert, right? How many users always accept a cert no matter what it says? It could say you're a douchebag on the cert and they'll say, okay, cool, I'll accept it. So it really doesn't matter what you put there. Most people just click okay. So the next thing they see is this captive portal login. You can make this login look whatever you want, but we just took a standard one. So the very next thing pops up like, oh, what the hell, I already typed it in. Maybe I got my password wrong. So they type it in again. And basically that sends us over to your passwords in clear text. This last screenshot is what it looks like from an OS X device like your laptops, your Apple laptops. It actually tells you that you have authenticated via MSChap, me too, when obviously we just showed you that that's not accurate. So at the end of the day, you're getting your clear text passwords. You have a full man and middle connection at this point. So the sky is basically the limit. You can do whatever you want with them at this point. So a recap of basically the attack that we just went through. So the subliquents on OS X and iOS devices, they don't appear to be handling MSChap v2 properly. They don't require that you send it as success or just they're not paying attention to it for whatever reason. They don't really know. But basically at that point, so much for mutual authentication. MSChap v2 is there specifically for mutual authentication. In this case, it's not working. So we're bypassing that inner authentication mechanism. We can say whatever we want at that point and we're just letting it go through and then establishing that connection. We're trapping a captive portal, probe requests, it's defaultly sent by these mobile devices and just forwarding them onto our malicious captive portal. Like you would if you were mimicking a hotspot network at Starbucks or someplace like that. Not that we've done that, but just saying. And then the users enter their credentials again and it's an HTTP so it's going to be sending clear text and we're there to capture them. Oh, I love Apple. So anyways, I'm going to ‑‑ or actually the next slide here. So we'll talk about responsible disclosure. I'm going to say first off responsible disclosure because Josh gives me crap all the time when I tell him how. I really feel about it. But it's a good thing and we encourage people to do that. It's kind of like telling a kid in elementary school that you're going to tell on him before you tell on him, right? He's in trouble. You're just, I'm going to tell. You know, so whatever. So anyways, so here's how it went in this particular case. So we found a new issue. We're going to report it up the chain. Typically what happens is, hey, I discovered this thing that exposes your back door and I urge you to patch it before someone dumps a nasty payload in it. Nobody's laughing because you guys don't have a six since the humor like me. But anyways, so that's what happens. Then the sociopath, right? The corporate because they really don't care. They don't have a personality. Their responses, thank you. Though you're probably wrong, we will have some of our outsourced managers put ten tards on it right away and never get back to you. That's typically how it goes, right? Actually, in this case, they did respond with their generic message right away. So anyways, so a month later, hey, can I get a status on, you know, that ticket I submitted, number 99, whatever. And then you get a response, hey, me, Josh, 4379, I see not what you say. I like gummy bears. Ticket closed. Basically meaning that whatever you just told us is crap and have a nice day. So, okay, cool. So this is their actual response that they sent back. So basically they're telling us that it's nothing. And then they tell us at the end here, hey, why don't you try this GTC thing because that will just send the shit to you in clear text. So thanks, Apple. So we're going to go ahead and start our next attack. Wow, Apple, thanks. I don't know what to say. It's early Christmas. I mean, I'm not sure what's going on there. But with all this said, we actually were experimenting with GTC before they even said anything, but we just thought that was absolutely hilarious that they were giving us our next attack. So what's GTC? Well, GTC basically replaces the portion of the inner authentication that's in this chat. And it was a protocol that was developed by Microsoft and Cisco for PEEP version one. And it was created basically for token cards and one-time passwords. So you guys have probably seen those secure ID cards. You can kind of see them on the page there. If you've ever worked for a major corporation, I'm sure you've seen something like this or played lots of video games these days. They're giving them out like handy these days. It's very similar to PEEP version zero with MSChat v2, except it doesn't have a peer challenge. So a lot of it, I'm not going to go over the whole interaction again because it's all the same except instead of the dual challenge and all of that stuff, it just sends over the one-time password. So it's similar in operation in that regard. And so you guys remember what I said about the server not actually telling the clients what kind of password and username it was asking for? Well, this is one of those areas where it might come in handy, right? If your client pops up and says, give me username and password, you're like, oh, that must be my username and password from my NT login, right? Why wouldn't it be? It doesn't say one-time password. It doesn't say give me your token card. It just says, give me your username and password. And this is kind of a weird, funky thing with clients. We'll get into here in a second. And think about how we can use that to our advantage. I'm sure all your brains are turning there with that. It's probably pretty obvious. But let's take a look at it. So this is our next attack. It's called the peeping Tom. Basically, the same kind of setup. There's an AP in here you don't see, but you've got your client in this case. It can be an Android or an iOS device. The last attack was iOS only. And just before I get into this attack, this doesn't invalidate MSChat v2. And I think that's kind of what Apple was saying. But for some reason, you know, peep version 1 leaves or peep version 2 comes out and people decide they don't want to support GTC or something anymore. Apple still hasn't fixed their problems. So that's still a valid attack vector. Just because this is out doesn't mean another vector is not open. Something about front doors and back doors and anyway. So what happens with our first attack here is we replace the radius server with an attack server just like the other one, exactly the same. The server requests, well, you do the identity thing right in the beginning where it sends over the identity just like in MSChat v2. The server says, send me one-time password. And again, the client is already interacting with the user. So the client just for some reason is like, oh, okay, well, I've already got the password that he entered. Why not? Let's send that over. So the client responds with, sure, this is a GTC password. Why not? I just asked the client for username and password. So the radius server obviously in this attack instance, we don't actually know the password. So GTC fails and says no password for user. We don't care where the radius server is patched and it doesn't care what it gets. It's going to send success anyway. So it's a little short of the MSChat v2, but the server sends over TLV success anyway and says, okay, your password looks good. And the client is like, sure, I trust you. Why not? I send over the password. I'm not authenticating that you know it. It's a one-time password. Why would I do that anyway for a one-time password? And the client accepts and responds to TLV success and we have a full connection there and a full connection is established. And at this point, we can do all kinds of things. We already have the password, which I'll show you in a second, but you could use SSL strip or any of your normal men in the middle attacks that you might want to do against a client after you get him to connect to you. And so once again, we're extremely excited and dancing because we got the client to attach to us. Great. Okay, great. Everyone's excited about that. Yeah, yeah, yeah. Jim liked his video better. Peanut Butter Jelly Time is old school, right? Okay. So what does the client look like in this instance? Again, this works on iOS, but I'm going to use an Android device because something different happens here with Android. See if you guys can catch on what it is that's missing from this that was in the MSChap attack with the client. So the first thing that happens is, right, DefCon secure. You guys all use the DefCon secure network this weekend, right? Yeah, right. So that was MSChap E2, just saying. Anyway. Great. So we connected DefCon secure. It's peep, awesome, you know. Let's type in our username and password. Again, it just says identity on Android, but whatever. Most people think of that as their username and password. And bam, we're connected. So what's missing here? You. That's right. There is no acceptance of the cert. Our cert's bogus. It's example.com or goofball.com or whatever. Dooshier.com. Android doesn't actually ask you to accept a cert, which is interesting because that means later there's no user interaction. So this client interaction would change. If they've already connected to the corporate network or DefCon secure network and then they connect to your evil twin, it's a different cert, but Android doesn't care, accepts it anyway and just sends the password right on over. Okay. Awesome, right? I mean, anyway. Anyone see this this weekend at all on the DefCon network? Not one person? Well, we saw it a couple of people's networks. You know, shameless plug for our TBA talks since no one had any idea that we were even in here and what we were doing. So we basically took a ‑‑ with one of my buddies down here that helped me. You can raise this hand if you want to. That's a notoriety. We basically took a Raspberry Pi and used our same attack tools in a slightly different configuration and basically just set up a captive portal that anytime somebody connected to us instead of DefCon secure, they got this captive portal page that popped up and said, hey, Jim doesn't know about this yet. This is a surprise for him. I took a lot of his work to do this, but I was going to fill him in later. He came a little late. Convenient for you. Yeah, convenient for me. But you know, it's promoting for us. So anyway, that's what we were doing there. So clear text anyway. So where did we get the password in this particular instance? We didn't have a captive portal. Well, gee, radius, it was totally awesome for you to put your clear text passwords in your debug file for us. Cool. That's kind of weird, right? But if you think about it, it's a one-time password. So if somebody sees it in a radius debug, what does it really matter? Well, unless it's an actual MSChap V2 password that somebody mistaken for a one-time password. Because again, the way the clients are developed, and I know I keep going back to this, but this is a big thing. The way the clients are developed, they just ask you for username and password. You don't have any indication on exactly what they're looking for. So that's a big deal there. And again, this is actual screenshot from this weekend from the DefCon secure network. I blanked out the passwords because I don't know why, who cares. But I did anyway. There's my test one in there. That one's not blanked out. But I don't know if anybody notices their password. We've got an MAA in there and a W. Gretz user and a RFDESO. Anyway, so that was from this weekend. Just to show you just another example. I just want to say I had nothing to do with his attack that he did today or over the weekend. Sure, sure. You say that now. So let's talk about it. Let's do a recap on exactly what happened here. What does it work on? So PEEP version one works on anything that GTC, that PEEP version one works on natively. So that includes things like iOS and OS X again, so your actual Mac computer or your personal device. It works on Android again without assert at all, which is a huge deal in these attack environments because it just sends you that password right on over. I don't care if it's a one-time password. Here's my goodies. Unix will work, but the user is really going to have a lot of interaction here. They're really going to see what's going on a little bit more with, say, like Ubuntu or something. I didn't do an exhaustive test on all of the different platforms out there, but with Ubuntu, the attack would work. But typically, I'm just going to say it outright, Linux users typically have a little bit more about what's going on and why is that, why is that, say, butthole.com instead of example.com or whatever it's supposed to. Windows, there's no native. If you know this, the P version 1 was developed by both Cisco and Microsoft, there's no actual native support. So somebody would have to install a supplicant or some kind of other software in order to get P version 1 and Windows to work. But again, that wasn't really our focus. Our focus here is execs or people that just want to bring in their phones or whatever mobile device or whatever device they have, they're bringing their own device, bring their own disaster kind of crap and connect up to the network because that's who they are and they can. So that was really the focus here, but again, it doesn't really work on Windows for once ever, right? That's kind of a rare thing, but whatever. No cap to portal required, right? The man-middle-tack is trivial because it includes clear text passwords. We don't have to do a cap to portal. We could in this instance, I use it to advertise, but you could just serve them off to the Internet or even more fun, you could have them connect to Def Con secure and serve them off to regular Def Con because that's fun. Sorry. Anyway, instant capture of MSChab v2 passwords on iOS devices after the user accepts the cert from the Evil Twin. So on iOS, you will actually have to accept the cert, so it won't just happen in their pocket, right? I mean, we were doing this with friends of ours that were around, just kept saying their password over and over and over again because they were on Android, but if you're in iOS, it'll actually pop up and say, I don't recognize this cert. And most people are like, yeah, I want my porn. Give me access, okay? So anyway. So we're going to go into our demo here and the tool that we spend a lot of time on. I'm going to hand it over to Jim because he's going to give you the intro and then we'll pull the tool. Cool. You're going to pull it up? So anyway, so things you'll need to run this attack. You're going to need some type of Linux system. We've used Ubuntu 1204, both in the server and the desktop versions work great out of the box. So if you want to download those, you can. Any Wi-Fi adapter is needed. The alpha version there is the one that we've used. The important thing is we're using host AP in our tool set. So if as long as your card is supported by host AP, it should work just fine. Our custom patch that we made, it just basically goes in and changes some of the modules built into radius, the PAP module and the MS-Chap B2 module to send the right stuff over to these clients and get them to establish the full connections. So you want to download that. And then the LootBooty Wi-Fi tools is just a tool set that we developed. We wrote it in Ruby and I always, people always ask, well, why the hell did you guys use Ruby? So Ruby basically, to me it's like the canvas for people that can't draw because I suck at coding. So you could take a giant shit on the canvas and smear it around with your hands and it always works. And once you guys download the tool and you look at the code, you're going to go, now I know why he said that because he does suck at coding. And I do. I just have enough energy to make things work. I don't do it right by any means. So here you want to take this? Yeah. Is that mic working? Hello. Yes, sweet. So Josh is going to pull up our live demo here and we encourage you guys to try this. Those of you that were not smart enough to turn your phones off before you came in. This is really meant to use in a VM, by the way. You probably don't want to run this just the way it's set up right now. I mean, you can just download and look at the code and do it however you want like we did on a Raspberry Pi. But anyways, it's a menu driven system. So we've got two of the attacks built into there, the two attacks that we talked about today. The first one is ‑‑ I can't even see it from over here. So the peeping Tom attack. We're doing that first. We're going to do the Iponer first. So you go ahead and select option two. It's going to tell you a brief description of what the attack is going to do. So you kind of have an idea of what's going on. Can you guys see that at all? Okay, let's make the font bigger here. Sorry. There we go. Jerk. That's right. How about that? Is any better? Even bigger? I'll say. Okay, we'll try it. Huge! I know you can ‑‑ Size matters, right? Size matters. Huge. Says the lady in the front right here in the stripe skirt. This is as big as it goes, though. No more medicine for me. Anybody notice her limp when she walked in the room today? That was me. Just saying. Use your imagination. Team, my buddy. Jesus. It was this crap they made me drink. You took one from the team for me, too. That was yours. You put me over the edge. So anyways, menu driven system, cool pictures, asky art, we like that. How many people like colorize with Ruby? Nobody. Thank you. It looks really cool, though, right? Old school, kind of neat. Josh likes colors. So start. How hard is that, right? You type in your wireless interface, in this case we're using WLAN1. We're going to tell it the network name that we want to clone. Whatever company you're working for, you want to type that in there. We're using my computer. My company rules. My company rules. When you see the cert, connect to it, please. Seriously, we're not going to steal your stuff. If you want to spoof a MAC address, you can. We put that functionality in here because it's fun to do. If you just hit enter, it's going to take whatever your card's default MAC address is. You can select the channel if you'd like. If you hit enter, it's going to default to nine. I don't know why I picked nine. I just did. But anyways. So it's going to go ahead and start a bunch of stuff. What it's starting is it's starting a free radius. If you guys have ever used that, on the top left there, that's your free radius. On the bottom left corner, it's your web server. That's going to show you the captive portal. That's all in Ruby as well. It's using things called web brick. You'll see as people are trying to hit your portal. Over on the right-hand side, you're going to see host AP. That's basically if you want to see from an access point standpoint, you're going to see all the people associating with your access point. Their MAC addresses and those kinds of information. The big screen in the middle is basically your captive portal creds, which is what you're waiting to pop up. That's when people have made the connection. They've accepted your cert. They've been forwarded to your captive portal. And then they're going to type in their credentials again. So hopefully somebody is doing it. It looks like we've got plenty of activity here. I will say you can type in whatever you want. So if you want everybody to see it, go ahead and do it now. Just try not to make it totally horrible. And again, this is iOS only. So if you're trying this with your Android device, it won't work because MS-Chap v2 vulnerability is only hacked. I'm a loser. What is that? You're not a loser. You're good. You're good. Well, nobody's done something really offensive. Bring it. Yeah. Well, yeah. I mean, this is the kind of place you'd expect to be. Nobody's been afraid. You're afraid, right? So this is it. If you're doing a penetration test in a corporate environment that's using WPA2 Enterprise, which most of them do, you know, you spend this tool up and you wait 10 minutes or 15 minutes until... Somebody fucked your mom, Jim. Oh. I fucked your mom. I know I've tried to talk her to her about that a few times, but she does her own thing. I encourage her. Go for it. Good for you. Remember to do the pole and pray. Okay? Let's do the other two. All right. So the next attack is the peeping Tom one. So the first one only works in iOS and OXS because that's the only people that are screwing up MS-Chap v2 at this point in time. So the second attack is peeping Tom. That works on basically everything that supports GTC. So the same type of thing. You hit start. Yeah. Let's interface it. You've got plugged into your machine. That's my company rules, right? My company rules is the... My company rules, yeah. You're right. And if you want to spoof a MAC address, no, we're not going to in this case. We go ahead and hit enter. We don't care what channel we're using. And basically the same things are starting up. You've got your radio server starting up so you can see what's going on from that perspective. You've got your AP starting up so you can see from that perspective. And then you've got your GTC passwords. The cool thing about this, so if you've ever connected to my company rules before and you've accepted the cert or whatever, it's automatically going to send your stuff over now to this one because your Android devices are going to ask you to set the cert. It's just going to automatically send us your stuff. Yeah. And all you people that are already connected with iOS, as soon as we spun this up, it automatically sent your password over without doing anything because you've already accepted that same cert, right? Otherwise you would have to accept the cert. But this is just a demonstration. Holy s***, I like the monkey balls. Who did that? Raise your hand. You're my hero. All right. You're my monkey balls. We love you. Thank you. So anyway, yeah, I mean it's just a great way to see exactly how the attack works right in a row, right? First attack was you logging into your company. The second attack is no ‑‑ it's not even asking you for your credentials again. It's just logging in. If you had an iOS device and you did that. So how many people are familiar with Air Crack, sweet? Everybody's used that, right? You know that the thing they got were just automatically response to any probe request. So imagine if you were just responding to anybody's probe request in this scenario that connected to a corporate network before, you know, and you're spinning up a fake corporate network, it's going to automatically start sending you their logins and passwords that they use in the past, which is kind of a big deal. Just saying. Yeah. So anyways, I'll pass you back over here to Joshy Poo, the guy that didn't drink his alcohol. Boo. Boo. Don't hate me. I'm sorry. You could beat me all later, I swear. We got five minutes, Homs. Okay. I get that right. Oh, you can just do it. You can take my word for it. All right. Where are we? Let's see. We're beeping. All right. How about that? Okay. So let's talk a little bit about how we came about with this. What was our goal and how do we achieve it? So historical perspective, the first thing we decided was, wow, you know, Josh right, and who's the guy that did the divide and conquer talk? Anyway, Moxie, it was Moxie, right? I think anyway. Yeah, anyway, so there's been a lot of really good talks on how to crack passwords from WPA2 or crack the actual hash. And I don't have access to a giant web infrastructure or giant virtual infrastructure online or 10,000 GPUs or 10,000 PS2s or whatever the cool kids are doing these days. So we really wanted to make it easy and we're just like, you know, we're lazy, cracking caches is too hard. There's got to be another way to do this. Can we just trick the client into giving it to us? That way, establishing some kind of full connection and maybe just, you know, hand it over directly to us so we don't have to crack it. Obviously that's what you guys just saw. So then we started going down the path of how WPA2 works. Well, like you guys saw, what if we just accepted everything that Radius actually got sent and sent it back? Well, then you saw that in that, there was actually some problems with that. We're in this chat B2 actually worked correctly and just dumped the connection. So we started playing with that idea of, you know, what if Radius just said everything was okay? Can we trick the client somehow into making a full connection with us and then do something with them later to get the password? And so basically we started with some past work. Josh writes some really good work on patching Radius to actually output the hashes directly in the Radius Debug file so then you can take those hashes and try to crack them offline or do one of the other different attacks or brute force it or whatever you want to do, which again was too hard for us. But we started kind of with that and then we moved on from there and said, well, you know, what else do we need to do with Radius? And I basically put Jim in a little box and I didn't let him come out for air for two or three weeks, a month, something like that, a month. And I started going through every single module and we said, well, what about that one? What about that one? What if we send this back here? And a lot of people seem kind of interested in that and how we figured that out. And neither of us are coders at all, right? We started with somebody else's work. We didn't want to crack the hashes. We did this tool in Ruby that's really kind of scripty. So how can we do this to make this easy? And again, starting with this work from ‑‑ great work from others. And then yielded unexpected discoveries, right? We ended up finding a vulnerability as far as we know for iOS that has never been reported. You know, when we told Apple about it, obviously they told us to get stuffed, but in so many words. But you know, that it was just random. I really encourage you guys that are interested in this kind of stuff to test things that people say work, right? Don't have to necessarily write a buffer overflow or stand in your head and do naked cartwheels or whatever it is to take you to do where you want to go. But just test things that you think should work that way. If they say it should work that way, test it and make sure. There were times ‑‑ I was like, well, I missed chat, V2 doesn't work that way. There's no way that will work. But here it is, undiscovered discoveries here. So you know, no, we didn't invent time or the flux capacitor or anything really cool like that. But what we did come up with is this patch. Again, I put him in this box and he came up with this crazy patch for radius that allowed us to test this and allowed us to see what would happen when we just accepted everything in certain ways. And so that was where the meat and potatoes of what we're giving to you guys today other than anybody ever set up wireless attacks. It takes some time. One minute. Okay, good. Perfect. It can take some time to set that stuff up. So what we're giving you today is the patched so you can test this against your own infrastructures or wherever else you want to test it. And some easy ways to set up the tools really, really quickly. So I'm going to pass over here to Jim to the last slide. He's going to tell you where to get some of this stuff. The last 30 seconds. So lubuddy.com, it's basically just going to forge you on to our GitHub site. You can download the tool. You can download the patch. It has an installer script that you can run. It's called sysprep. It's basically just going to do an app get and download some of the libraries that you're going to need and just make things a lot easier for you. But again, read the code. Make sure you understand what's going on before you run it against your guys' own corporate environments and all that jazz. I promise it won't send your passwords over to us. You should check, though. Yeah, literally check. And then the picture is just a jab at what's going on in the media today. You know, stop spying on me. I don't do anything cool. I promise. Anyways, that's our talk. We appreciate you guys taking the time to listen to us. Thank you. Thanks.
 So anyway, our talks on we call it B.O.I.O. disaster and why corporate wireless security  still sucks.  A little bit about us.  Let me push some buttons.  Anyways, my name is James.  I also go by punk and poop online back in the old air, sea days and stuff.  Independent security researcher, just an all around nerd, boring guy.  And with me I have Josh Hoover here, the guy that pooped today.  Can you hear me?  No, you can not.  You're talking on us.  That's fine.  I'll switch over here.  Yeah, I'm Josh.  I've been coming to DEF CON since, well, since I had hair and some of my friends over here  were just starting to grow hair.  So we've been here for quite a while.  Privilege to be here.  Thank you for coming to our TBA talk.  This picture, the gym selected of me is supposed to be kind of a joke.  Did you guys read our profiles at all online?  You probably can't see in the book, but online.  Anyway, there's a funny profile I wrote for Jim and this is his way of getting back at  me.  I told him to pick any random picture he could find on Facebook.  So that's the evil one he picked of me.  So anyways, at the end of the day we're just nerds with random ideas and inconsistent results.  That's been the story of our lives.  So what we're going to talk about today is we're going to show you some ways to obtain  clear text credentials without cracking a single hash for a PIP-enabled WPA2 enterprise  networks.  There's been a lot of research and work in the past that is involved gathering hashes  and cracking them offline using like brute force dictionary attacks and those kind of  things.  We're pretty lazy.  We don't have time or want to spend a lot of time cracking hashes.  So our whole thought was to come together and try to find an easier way, a faster way  of capturing clear text credentials to gain access to networks.  Secondly, we're going to release a tool that kind of automates the whole process and does  things for you right out of the gate really fast.  So if anybody's done these attacks in the past to set up the interfaces and all that,  it can be kind of time consuming.  So we've kind of automated that whole process for you.  How we're going to do this is we're going to explore a new functionality issue and I'll  get into that more later that we found with how iOS and OXX devices are handling MSChat  v2.  Secondly, we're going to demonstrate the use of EAPGTC as an inner authentication mechanism  in place of MSChat v2.  So I'll go ahead and give it to Josh here and he's going to kind of take you through  some of the technicals for MSChat v2.  So how many people here have showed hands that have ever set up a WPA2 enterprise network  or know the ins and outs of that?  You shouldn't, but anyway, that's great.  That's what that guy said right there.  So it looks like there's a fair amount of you that haven't yet.  So I'm going to kind of go over some of the technical details on exactly what our research  was looking at.  I'm sure most of you have set up a WPA2 personal at home where you set a pre-shared key of  some kind and you gave it a sit and you connected to it and you knew what the password is and  you signed into it.  Basically, WPA2 enterprise just adds one extra component to that, usually a back end  authentication server of some kind.  In this particular instance, it's the radius server box you see on your right, I guess,  of the screen.  And that just adds another layer of the indication so you can authenticate every single client  that connects to your network instead of just having one key that you'd use maybe at your  home network.  So you have a client that you see there on the left, an AP in the middle, and then we're  adding an extra component for WPA2 enterprise, which is the authentication server.  In this particular instance, it's going to be a radius server, but there are other options  there for different kinds of servers, but this is what we're centering on for the MSChat  V2 and GTC stuff.  And it's a lot of what you'll see in enterprise-level networks and crazy people like us like to  run this kind of thing at home for some weird reason.  So what's the first thing that happens when you connect to an AP, right?  I mean, most people are familiar with that, right?  You pick your SID and you connect right up to it.  You pick your network name there and that's pretty easy.  I'm going to blow your mind with technical details here, right?  I'm not going to go into that portion of it, but it's worth mentioning that this is the  first layer of attack for a lot of people that want to set up what's called an evil  twin network.  And basically what you're doing is you're mirroring the exact same SID that your target  is using and hoping that clients will connect to you instead of to the actual AP.  And so that's the first layer of attack called the evil twin.  And that has to do with the dangerous.  These guys are going to be very angry at me because I actually don't drink, so.  My Jim's got to drink double because I can't drink, so.  You guys can throw things at me instead if it makes you feel better, though.  No way.  We're here to help you.  Here's for you.  Here's for your co‑speaker.  You know how many times in my career I've had to take one for the team for this guy?  And also, as you may be familiar, raise your hand if this is your first F‑con.  Why is it everybody's new?  Wait, why are we pointing at him?  All right.  You get up here.  That's her first F‑con.  And the lady down here with the striped dress on.  I got to suffer your suffering, too.  Wait, wait, wait.  What are you doing?  Hey, we don't have people up here.  Where's mine?  Two more.  Bear with us.  They know it was my first time.  They know.  Did you pick it up from the bar?  I know it's a double.  No, we did not do that last time.  I tried.  What, we got more?  Geez, all right, everybody, come on.  We're actually out of coffee, so.  All right.  To all of you newbies, welcome.  I'm sorry, your time is up now.  Thanks, Ravines.  It's already coming out the other end.  I have no idea what I was doing.  Where am I?  Drink one?  No.  So, association stuff, right?  We got the shots covered.  Okay.  So, association stuff.  We're connecting to Evil Twin, blah, blah, blah.  That's the first layer attack.  We're excited about that.  Let's move on.  The next portion that happens in WPA2 enterprise is what's called an EAP proposal.  What's EAP?  EAP is extensive authentication protocol.  Basically, that's just a fancy acronym for a methodology or a framework that's used for  authentication of all kinds of services.  This particular service is going to be Wi-Fi.  It allows you to add user name and password or certificates or one-time password, something  like that to some kind of service.  The first thing that will happen here in this proportion is that the AP is going to request  identity from the client.  The client gets a pop-up on most clients that says nothing more than user name and password.  That's all it says.  That will be important later.  We haven't really established exactly what kind of authentication we're even using yet.  So, anyway, the client sends that over.  Doesn't actually send the password over yet, but does send over the identity, which in  this case is the user name or some kind of login name.  This is another layer of attack that a lot of people like to use because now you could  just stop here if you wanted and just gather user names all day long.  That's boring.  We want passwords.  We don't want to have to crack them.  We don't have to brute force it.  That only gets us one step.  So after it sends it over to the radio server, the radio server says, okay, that's good.  It's going to send over what's called a peep start.  So what's peep?  Peep is protected extensible authentication protocol.  And basically that's just a fancy way of protecting EAP.  So, unfortunately, EAP by itself isn't inherently secure.  So if you were sending over hashes or whatever you're sending over using just regular EAP,  you can pick them up usually over the air because at this point there's no encryption at all  at this point.  So you could pick up anything.  And so this is a way to protect that data.  What peep does is it makes what's called an outer authentication and inner authentication.  The outer authentication is not very fancy.  It's just an encrypted tunnel.  And the inner authentication is the actual users or clients information.  So it's attempting to protect that information inside of an encrypted tunnel, which is great  if you're sitting on the outside and you're just sniffing it, but if you're the evil twin,  they're sending it all to you.  But you've got to make sure all this stuff happens otherwise the client's going to freak  out and it's not going to send you its credentials.  And it's goodies that you want to get so you don't have to goodies, except word.  So what happens next?  So anyway, the outer authentication happens next.  Again, part of peep.  I'm not going to do a lot of technical details here.  It's TLS setup stuff.  So you guys can look up TLS if you're not familiar with it.  But there's a server search that's on the radio server that gets sent over and it establishes  a TLS tunnel in order to start sending over all the goodies, all the good authentication  portions of whatever you happen to do.  So after that, you go into the inner authentication portion.  That's inner eep.  In this particular instance, we're going to be talking about MSChap v2.  Now, v2 differs from v1 and I'll explain that in a second.  But MSChap is generally used for NT or domain or whatever, Windows login.  So username and password.  It's a way to allow people to use that in order to log into a wireless network.  So this is kind of important for a lot of enterprises out there because they want to  make it easy.  They don't have to worry about passwords or have to worry about key management or people  want to bring in their BYOD devices and just connect up to the network and this enables  them to use their normal login that they would use on the corporate network or whatever network  they're using.  So the first thing that happens in this inner authentication portion is what's called ‑‑  oh, sorry.  It just sends the identity again.  Actually sends the identity again over to the radio server.  So it requests it and sends it.  Yeah, great.  We've already got that.  That's something new.  So the first thing that happens from the radio server, it sends over a challenge.  It must have a V2 challenge.  The client takes this challenge and takes its password and makes a hash from it.  And then it sends it back to the radio server.  Now, an important part of V2 over V1 is that there's a dual authentication happening here.  Both the client and the radio server want to make sure that each other actually knows  the password.  So the radius creates a challenge and sends it over to the client and says, hey, here's  a challenge, use this challenge portion to create a password for me, a hash, and send  it back to me.  And the client says, okay, no problem.  I will take that challenge, my password, create a hash, send the hash over to you.  It's a hash.  There's lots of people here that can tell you how to crack those, but we're lazy and  we still consider that too difficult for our small minds.  So it'll send that back over with an actual challenge of itself and say, okay, here's  my hash, but I want you to tell me that you know my passwords.  Here's my own challenge.  Create this challenge, hash it with whatever you think is my password, and send it back  to me.  So the race says, okay, if I do actually have your password, I'm going to do that and I'm  going to take your challenge and send a response back to the client.  At this point, the client looks at it and says, okay, does this match?  If it does not match, it's supposed to drop the connection at this point, which may or  may not happen as we see here going on.  But this is an important part of V1 versus V2.  Microsoft and Cisco specifically created this in order to try to circumvent some of what's  going on here in the attacks you'll see here in a second by making sure the client says,  well, I'll give you my hash, but I'm not going to connect until I'm sure you actually know  my password.  So again, if that does work and it does actually know the password, then the radius server  will take that.  It'll make its actual response and say, okay, your password was successful.  Here's the response to your challenge.  The client looks at that and says, okay, you do actually know my password, no problem.  Let's send over a success to the radius server.  The radius server says, great, we're all good.  Let's start our connection.  It sends over what's called an EAP-TLV success.  The client acknowledges that and we're golden.  So the inner authentication has happened correctly.  Again, this is with MSChat V2.  So what happens next is basically just an EAP success portion here.  We're installing some special keys onto the AP to start up the actual encrypted network  connection so they can get the rest of their IP address and everything that they need to  in order to get access to the actual network.  And again, I'll blow your mind here with some really fancy technical details, finishing  the connection stuff.  I won't really go into that.  But again, what we're really concentrating on here in our attack is the inner authentication  portion because we want the password.  We want them to make a full connection to us so we need to convince them that we know  the password.  We want them to send the password to us anyway.  And so this is where our research is really focused.  Anybody who's done ‑‑ how many people out here do security research other than showing  up to DEF CON?  I guess that's considered security research, right?  So a few of you, you're probably familiar with how difficult this can be, especially  if you run into stuff like this where you're trying to get a full connection and MSChat  is hitting you in the face and saying, no, you can't have that connection and you try  again and it hits you in the face and whatever happens.  So we found this funny little video that kind of reminds us ‑‑ some of you have probably  seen this before, kind of reminds us exactly what this feels like.  Yeah, it's not a whole lot of fun, but, you know, she's okay.  So you'll be okay too.  You know, you take a few hits in the face, you know, you can get back up and she actually  did get back up and she had to finish this.  But anyway.  So that's a little overview, quick overview of the way that our research ‑‑ exactly  what our research is looking at technology was.  I think everyone loves that video.  Okay, Jim, I'm going to pass over Jim here and he's going to tell you about our actual  first attack.  Thank you for sitting through all of that technical detail.  All right.  So, you know, I have to say that I purposely only had like three drinks when I was coming  to.  That's just to take the edge off.  So the crap that they just gave me just kind of pushed me over my edge.  So I'm going to do my best to get through these slides.  So anyways, the first attack.  We call it the iPoner because it's central around iOS and OXX devices.  On the left side there you see the mobile device of phone and then on the right side  we have the actual radio server.  We didn't put the AP in the middle but if you can imagine, there's obviously an AP  in the middle of this thing.  So we've ‑‑ the radio server is a patch version that we wrote that kind of puts the  exploit into there.  Kind of like what Josh Wright's done in the past with his patch for radius for capturing  hashes and cracking those offline.  We kind of did the same type of thing in a different ‑‑ I guess a different way.  But anyways, the first thing that happens is the server challenges the client like what  Josh was talking about earlier.  The client gets that.  It's going to send its MSChap response back along with its peer challenge.  And that peer challenge is basically the client's way of authenticating the server to itself.  It's basically to make sure that both people have knowledge of the clear text credentials.  So once the server gets that in response, it's going to look in its database and obviously  as the attacker, we don't know what the user's password is at this point.  So we have two choices.  We can either tell them, cool, your password is good or hey, your password is wrong.  So the first thing we tried obviously is we accept everything.  And if anybody has used the patches that have been out in the past, they've been designed  to say success for everything.  Any password you send it is going to send a success in response.  When we do that, the peer challenge doesn't match for all devices.  It looks it up in its database and says, hey, you're full of crap.  What you sent me back is wrong.  And typically it drops a connection or it sits in kind of a limbo state.  It won't actually establish a connection to the network, which is what we're after.  So we start over.  You know, we actually tried a lot of things, but we're consolidating this into the one  that worked for you guys at stake.  But anyways, so we reject the password.  We just tell them, yep, what you sent me is incorrect.  So the server then sends a TLV success at the end.  So we tell the user send us this password, we send it back saying, no, whatever you  sent me is incorrect.  Expecting the client to drop the connection.  For some reason, IOS and OXX devices don't drop the connection.  So we follow that up with a TLV success, basically telling the client that everything's good.  We're going to go ahead and finish this connection and I'll send you a DHCP address and start  sending you network services.  OXX devices go, well, you know, I don't really know what this means, but okay, cool.  We're good.  So right.  So the client sends us a TLV success at that point, meaning that they're ready for a DHCP  address and everything else is going on.  So the client checks for a captive portal.  Another crappy thing about your IOS and OXX mobile devices, most devices, when you're  connecting to a secured wireless network, it knows that there's not a captive portal.  So there's no reason to send a probe out saying there's a captive portal there.  IOS and OXX devices don't do that.  They send that probe no matter what.  So what we do is we capture that probe and say, sure, there's a captive portal on your  secured network that you don't need.  And we forward that on.  So basically, we send them the captive portal, which is an HTTP, right?  They type in the password again and we get it in clear text.  That's how the attack basically works.  We're very happy.  So right.  So we're not...  So from a user's perspective, you know, what does this look like from your mobile phone?  So you get some manager that brings his personal phone to work and he wants to check his email  because he's late for a meeting, all that jazz, even though he knows it's not allowed,  but he doesn't care.  He's a manager, right?  So he pulls up his iPhone, he's looking at it, like Manny right here in the front, Tony  and Manny right here, like those guys.  Anyways.  So you got your MSChep test network.  That's what we're calling it in this case.  So you select it.  It prompts you for your username and password like you're used to.  You type that in.  It's going to pop up a cert, right?  How many users always accept a cert no matter what it says?  It could say you're a douchebag on the cert and they'll say, okay, cool, I'll accept it.  So it really doesn't matter what you put there.  Most people just click okay.  So the next thing they see is this captive portal login.  You can make this login look whatever you want, but we just took a standard one.  So the very next thing pops up like, oh, what the hell, I already typed it in.  Maybe I got my password wrong.  So they type it in again.  And basically that sends us over to your passwords in clear text.  This last screenshot is what it looks like from an OS X device like your laptops, your  Apple laptops.  It actually tells you that you have authenticated via MSChap, me too, when obviously we just  showed you that that's not accurate.  So at the end of the day, you're getting your clear text passwords.  You have a full man and middle connection at this point.  So the sky is basically the limit.  You can do whatever you want with them at this point.  So a recap of basically the attack that we just went through.  So the subliquents on OS X and iOS devices, they don't appear to be handling MSChap v2  properly.  They don't require that you send it as success or just they're not paying attention to it  for whatever reason.  They don't really know.  But basically at that point, so much for mutual authentication.  MSChap v2 is there specifically for mutual authentication.  In this case, it's not working.  So we're bypassing that inner authentication mechanism.  We can say whatever we want at that point and we're just letting it go through and then  establishing that connection.  We're trapping a captive portal, probe requests, it's defaultly sent by these mobile devices  and just forwarding them onto our malicious captive portal.  Like you would if you were mimicking a hotspot network at Starbucks or someplace like that.  Not that we've done that, but just saying.  And then the users enter their credentials again and it's an HTTP so it's going to be  sending clear text and we're there to capture them.  Oh, I love Apple.  So anyways, I'm going to ‑‑ or actually the next slide here.  So we'll talk about responsible disclosure.  I'm going to say first off responsible disclosure because Josh gives me crap all the time when  I tell him how.  I really feel about it.  But it's a good thing and we encourage people to do that.  It's kind of like telling a kid in elementary school that you're going to tell on him before  you tell on him, right?  He's in trouble.  You're just, I'm going to tell.  You know, so whatever.  So anyways, so here's how it went in this particular case.  So we found a new issue.  We're going to report it up the chain.  Typically what happens is, hey, I discovered this thing that exposes your back door and  I urge you to patch it before someone dumps a nasty payload in it.  Nobody's laughing because you guys don't have a six since the humor like me.  But anyways, so that's what happens.  Then the sociopath, right?  The corporate because they really don't care.  They don't have a personality.  Their responses, thank you.  Though you're probably wrong, we will have some of our outsourced managers put ten tards  on it right away and never get back to you.  That's typically how it goes, right?  Actually, in this case, they did respond with their generic message right away.  So anyways, so a month later, hey, can I get a status on, you know, that ticket I submitted,  number 99, whatever.  And then you get a response, hey, me, Josh, 4379, I see not what you say.  I like gummy bears.  Ticket closed.  Basically meaning that whatever you just told us is crap and have a nice day.  So, okay, cool.  So this is their actual response that they sent back.  So basically they're telling us that it's nothing.  And then they tell us at the end here, hey, why don't you try this GTC thing because that  will just send the shit to you in clear text.  So thanks, Apple.  So we're going to go ahead and start our next attack.  Wow, Apple, thanks.  I don't know what to say.  It's early Christmas.  I mean, I'm not sure what's going on there.  But with all this said, we actually were experimenting with GTC before they even said anything, but  we just thought that was absolutely hilarious that they were giving us our next attack.  So what's GTC?  Well, GTC basically replaces the portion of the inner authentication that's in this  chat.  And it was a protocol that was developed by Microsoft and Cisco for PEEP version one.  And it was created basically for token cards and one-time passwords.  So you guys have probably seen those secure ID cards.  You can kind of see them on the page there.  If you've ever worked for a major corporation, I'm sure you've seen something like this or  played lots of video games these days.  They're giving them out like handy these days.  It's very similar to PEEP version zero with MSChat v2, except it doesn't have a peer challenge.  So a lot of it, I'm not going to go over the whole interaction again because it's all the  same except instead of the dual challenge and all of that stuff, it just sends over the  one-time password.  So it's similar in operation in that regard.  And so you guys remember what I said about the server not actually telling the clients  what kind of password and username it was asking for?  Well, this is one of those areas where it might come in handy, right?  If your client pops up and says, give me username and password, you're like, oh, that must be  my username and password from my NT login, right?  Why wouldn't it be?  It doesn't say one-time password.  It doesn't say give me your token card.  It just says, give me your username and password.  And this is kind of a weird, funky thing with clients.  We'll get into here in a second.  And think about how we can use that to our advantage.  I'm sure all your brains are turning there with that.  It's probably pretty obvious.  But let's take a look at it.  So this is our next attack.  It's called the peeping Tom.  Basically, the same kind of setup.  There's an AP in here you don't see, but you've got your client in this case.  It can be an Android or an iOS device.  The last attack was iOS only.  And just before I get into this attack, this doesn't invalidate MSChat v2.  And I think that's kind of what Apple was saying.  But for some reason, you know, peep version 1 leaves or peep version 2 comes out and  people decide they don't want to support GTC or something anymore.  Apple still hasn't fixed their problems.  So that's still a valid attack vector.  Just because this is out doesn't mean another vector is not open.  Something about front doors and back doors and anyway.  So what happens with our first attack here is we replace the radius server with an attack  server just like the other one, exactly the same.  The server requests, well, you do the identity thing right in the beginning where it sends  over the identity just like in MSChat v2.  The server says, send me one-time password.  And again, the client is already interacting with the user.  So the client just for some reason is like, oh, okay, well, I've already got the password  that he entered.  Why not?  Let's send that over.  So the client responds with, sure, this is a GTC password.  Why not?  I just asked the client for username and password.  So the radius server obviously in this attack instance, we don't actually know the password.  So GTC fails and says no password for user.  We don't care where the radius server is patched and it doesn't care what it gets.  It's going to send success anyway.  So it's a little short of the MSChat v2, but the server sends over TLV success anyway and  says, okay, your password looks good.  And the client is like, sure, I trust you.  Why not?  I send over the password.  I'm not authenticating that you know it.  It's a one-time password.  Why would I do that anyway for a one-time password?  And the client accepts and responds to TLV success and we have a full connection there  and a full connection is established.  And at this point, we can do all kinds of things.  We already have the password, which I'll show you in a second, but you could use SSL strip  or any of your normal men in the middle attacks that you might want to do against a client  after you get him to connect to you.  And so once again, we're extremely excited and dancing because we got the client to attach  to us.  Great.  Okay, great.  Everyone's excited about that.  Yeah, yeah, yeah.  Jim liked his video better.  Peanut Butter Jelly Time is old school, right?  Okay.  So what does the client look like in this instance?  Again, this works on iOS, but I'm going to use an Android device because something different  happens here with Android.  See if you guys can catch on what it is that's missing from this that was in the MSChap attack  with the client.  So the first thing that happens is, right, DefCon secure.  You guys all use the DefCon secure network this weekend, right?  Yeah, right.  So that was MSChap E2, just saying.  Anyway.  Great.  So we connected DefCon secure.  It's peep, awesome, you know.  Let's type in our username and password.  Again, it just says identity on Android, but whatever.  Most people think of that as their username and password.  And bam, we're connected.  So what's missing here?  You.  That's right.  There is no acceptance of the cert.  Our cert's bogus.  It's example.com or goofball.com or whatever.  Dooshier.com.  Android doesn't actually ask you to accept a cert, which is interesting because that  means later there's no user interaction.  So this client interaction would change.  If they've already connected to the corporate network or DefCon secure network and then  they connect to your evil twin, it's a different cert, but Android doesn't care, accepts it  anyway and just sends the password right on over.  Okay.  Awesome, right?  I mean, anyway.  Anyone see this this weekend at all on the DefCon network?  Not one person?  Well, we saw it a couple of people's networks.  You know, shameless plug for our TBA talks since no one had any idea that we were even  in here and what we were doing.  So we basically took a ‑‑ with one of my buddies down here that helped me.  You can raise this hand if you want to.  That's a notoriety.  We basically took a Raspberry Pi and used our same attack tools in a slightly different  configuration and basically just set up a captive portal that anytime somebody connected  to us instead of DefCon secure, they got this captive portal page that popped up and said,  hey, Jim doesn't know about this yet.  This is a surprise for him.  I took a lot of his work to do this, but I was going to fill him in later.  He came a little late.  Convenient for you.  Yeah, convenient for me.  But you know, it's promoting for us.  So anyway, that's what we were doing there.  So clear text anyway.  So where did we get the password in this particular instance?  We didn't have a captive portal.  Well, gee, radius, it was totally awesome for you to put your clear text passwords in your  debug file for us.  Cool.  That's kind of weird, right?  But if you think about it, it's a one-time password.  So if somebody sees it in a radius debug, what does it really matter?  Well, unless it's an actual MSChap V2 password that somebody mistaken for a one-time password.  Because again, the way the clients are developed, and I know I keep going back to this, but  this is a big thing.  The way the clients are developed, they just ask you for username and password.  You don't have any indication on exactly what they're looking for.  So that's a big deal there.  And again, this is actual screenshot from this weekend from the DefCon secure network.  I blanked out the passwords because I don't know why, who cares.  But I did anyway.  There's my test one in there.  That one's not blanked out.  But I don't know if anybody notices their password.  We've got an MAA in there and a W. Gretz user and a RFDESO.  Anyway, so that was from this weekend.  Just to show you just another example.  I just want to say I had nothing to do with his attack that he did today or over the weekend.  Sure, sure.  You say that now.  So let's talk about it.  Let's do a recap on exactly what happened here.  What does it work on?  So PEEP version one works on anything that GTC, that PEEP version one works on natively.  So that includes things like iOS and OS X again, so your actual Mac computer or your personal  device.  It works on Android again without assert at all, which is a huge deal in these attack  environments because it just sends you that password right on over.  I don't care if it's a one-time password.  Here's my goodies.  Unix will work, but the user is really going to have a lot of interaction here.  They're really going to see what's going on a little bit more with, say, like Ubuntu or  something.  I didn't do an exhaustive test on all of the different platforms out there, but with Ubuntu,  the attack would work.  But typically, I'm just going to say it outright, Linux users typically have a little bit more  about what's going on and why is that, why is that, say, butthole.com instead of example.com  or whatever it's supposed to.  Windows, there's no native.  If you know this, the P version 1 was developed by both Cisco and Microsoft, there's no actual  native support.  So somebody would have to install a supplicant or some kind of other software in order to  get P version 1 and Windows to work.  But again, that wasn't really our focus.  Our focus here is execs or people that just want to bring in their phones or whatever  mobile device or whatever device they have, they're bringing their own device, bring their  own disaster kind of crap and connect up to the network because that's who they are and  they can.  So that was really the focus here, but again, it doesn't really work on Windows for once  ever, right?  That's kind of a rare thing, but whatever.  No cap to portal required, right?  The man-middle-tack is trivial because it includes clear text passwords.  We don't have to do a cap to portal.  We could in this instance, I use it to advertise, but you could just serve them off to the Internet  or even more fun, you could have them connect to Def Con secure and serve them off to regular  Def Con because that's fun.  Sorry.  Anyway, instant capture of MSChab v2 passwords on iOS devices after the user accepts the  cert from the Evil Twin.  So on iOS, you will actually have to accept the cert, so it won't just happen in their  pocket, right?  I mean, we were doing this with friends of ours that were around, just kept saying their  password over and over and over again because they were on Android, but if you're in iOS,  it'll actually pop up and say, I don't recognize this cert.  And most people are like, yeah, I want my porn.  Give me access, okay?  So anyway.  So we're going to go into our demo here and the tool that we spend a lot of time on.  I'm going to hand it over to Jim because he's going to give you the intro and then  we'll pull the tool.  Cool.  You're going to pull it up?  So anyway, so things you'll need to run this attack.  You're going to need some type of Linux system.  We've used Ubuntu 1204, both in the server and the desktop versions work great out of  the box.  So if you want to download those, you can.  Any Wi-Fi adapter is needed.  The alpha version there is the one that we've used.  The important thing is we're using host AP in our tool set.  So if as long as your card is supported by host AP, it should work just fine.  Our custom patch that we made, it just basically goes in and changes some of the modules built  into radius, the PAP module and the MS-Chap B2 module to send the right stuff over to these  clients and get them to establish the full connections.  So you want to download that.  And then the LootBooty Wi-Fi tools is just a tool set that we developed.  We wrote it in Ruby and I always, people always ask, well, why the hell did you guys use Ruby?  So Ruby basically, to me it's like the canvas for people that can't draw because I suck  at coding.  So you could take a giant shit on the canvas and smear it around with your hands and it  always works.  And once you guys download the tool and you look at the code, you're going to go, now  I know why he said that because he does suck at coding.  And I do.  I just have enough energy to make things work.  I don't do it right by any means.  So here you want to take this?  Yeah.  Is that mic working?  Hello.  Yes, sweet.  So Josh is going to pull up our live demo here and we encourage you guys to try this.  Those of you that were not smart enough to turn your phones off before you came in.  This is really meant to use in a VM, by the way.  You probably don't want to run this just the way it's set up right now.  I mean, you can just download and look at the code and do it however you want like we  did on a Raspberry Pi.  But anyways, it's a menu driven system.  So we've got two of the attacks built into there, the two attacks that we talked about  today.  The first one is ‑‑ I can't even see it from over here.  So the peeping Tom attack.  We're doing that first.  We're going to do the Iponer first.  So you go ahead and select option two.  It's going to tell you a brief description of what the attack is going to do.  So you kind of have an idea of what's going on.  Can you guys see that at all?  Okay, let's make the font bigger here.  Sorry.  There we go.  Jerk.  That's right.  How about that?  Is any better?  Even bigger?  I'll say.  Okay, we'll try it.  Huge!  I know you can ‑‑ Size matters, right?  Size matters.  Huge.  Says the lady in the front right here in the stripe skirt.  This is as big as it goes, though.  No more medicine for me.  Anybody notice her limp when she walked in the room today?  That was me.  Just saying.  Use your imagination.  Team, my buddy.  Jesus.  It was this crap they made me drink.  You took one from the team for me, too.  That was yours.  You put me over the edge.  So anyways, menu driven system, cool pictures, asky art, we like that.  How many people like colorize with Ruby?  Nobody.  Thank you.  It looks really cool, though, right?  Old school, kind of neat.  Josh likes colors.  So start.  How hard is that, right?  You type in your wireless interface, in this case we're using WLAN1.  We're going to tell it the network name that we want to clone.  Whatever company you're working for, you want to type that in there.  We're using my computer.  My company rules.  My company rules.  When you see the cert, connect to it, please.  Seriously, we're not going to steal your stuff.  If you want to spoof a MAC address, you can.  We put that functionality in here because it's fun to do.  If you just hit enter, it's going to take whatever your card's default MAC address is.  You can select the channel if you'd like.  If you hit enter, it's going to default to nine.  I don't know why I picked nine.  I just did.  But anyways.  So it's going to go ahead and start a bunch of stuff.  What it's starting is it's starting a free radius.  If you guys have ever used that, on the top left there, that's your free radius.  On the bottom left corner, it's your web server.  That's going to show you the captive portal.  That's all in Ruby as well.  It's using things called web brick.  You'll see as people are trying to hit your portal.  Over on the right-hand side, you're going to see host AP.  That's basically if you want to see from an access point standpoint, you're going to see  all the people associating with your access point.  Their MAC addresses and those kinds of information.  The big screen in the middle is basically your captive portal creds, which is what you're  waiting to pop up.  That's when people have made the connection.  They've accepted your cert.  They've been forwarded to your captive portal.  And then they're going to type in their credentials again.  So hopefully somebody is doing it.  It looks like we've got plenty of activity here.  I will say you can type in whatever you want.  So if you want everybody to see it, go ahead and do it now.  Just try not to make it totally horrible.  And again, this is iOS only.  So if you're trying this with your Android device, it won't work because MS-Chap v2 vulnerability  is only hacked.  I'm a loser.  What is that?  You're not a loser.  You're good.  You're good.  Well, nobody's done something really offensive.  Bring it.  Yeah.  Well, yeah.  I mean, this is the kind of place you'd expect to be.  Nobody's been afraid.  You're afraid, right?  So this is it.  If you're doing a penetration test in a corporate environment that's using WPA2 Enterprise,  which most of them do, you know, you spend this tool up and you wait 10 minutes or 15  minutes until...  Somebody fucked your mom, Jim.  Oh.  I fucked your mom.  I know I've tried to talk her to her about that a few times, but she does her own thing.  I encourage her.  Go for it.  Good for you.  Remember to do the pole and pray.  Okay?  Let's do the other two.  All right.  So the next attack is the peeping Tom one.  So the first one only works in iOS and OXS because that's the only people that are screwing  up MS-Chap v2 at this point in time.  So the second attack is peeping Tom.  That works on basically everything that supports GTC.  So the same type of thing.  You hit start.  Yeah.  Let's interface it.  You've got plugged into your machine.  That's my company rules, right?  My company rules is the...  My company rules, yeah.  You're right.  And if you want to spoof a MAC address, no, we're not going to in this case.  We go ahead and hit enter.  We don't care what channel we're using.  And basically the same things are starting up.  You've got your radio server starting up so you can see what's going on from that perspective.  You've got your AP starting up so you can see from that perspective.  And then you've got your GTC passwords.  The cool thing about this, so if you've ever connected to my company rules before and you've  accepted the cert or whatever, it's automatically going to send your stuff over now to this  one because your Android devices are going to ask you to set the cert.  It's just going to automatically send us your stuff.  Yeah.  And all you people that are already connected with iOS, as soon as we spun this up, it automatically  sent your password over without doing anything because you've already accepted that same  cert, right?  Otherwise you would have to accept the cert.  But this is just a demonstration.  Holy s***, I like the monkey balls.  Who did that?  Raise your hand.  You're my hero.  All right.  You're my monkey balls.  We love you.  Thank you.  So anyway, yeah, I mean it's just a great way to see exactly how the attack works right  in a row, right?  First attack was you logging into your company.  The second attack is no ‑‑ it's not even asking you for your credentials again.  It's just logging in.  If you had an iOS device and you did that.  So how many people are familiar with Air Crack, sweet?  Everybody's used that, right?  You know that the thing they got were just automatically response to any probe request.  So imagine if you were just responding to anybody's probe request in this scenario that  connected to a corporate network before, you know, and you're spinning up a fake corporate  network, it's going to automatically start sending you their logins and passwords that  they use in the past, which is kind of a big deal.  Just saying.  Yeah.  So anyways, I'll pass you back over here to Joshy Poo, the guy that didn't drink his  alcohol.  Boo.  Boo.  Don't hate me.  I'm sorry.  You could beat me all later, I swear.  We got five minutes, Homs.  Okay.  I get that right.  Oh, you can just do it.  You can take my word for it.  All right.  Where are we?  Let's see.  We're beeping.  All right.  How about that?  Okay.  So let's talk a little bit about how we came about with this.  What was our goal and how do we achieve it?  So historical perspective, the first thing we decided was, wow, you know, Josh right,  and who's the guy that did the divide and conquer talk?  Anyway, Moxie, it was Moxie, right?  I think anyway.  Yeah, anyway, so there's been a lot of really good talks on how to crack passwords from  WPA2 or crack the actual hash.  And I don't have access to a giant web infrastructure or giant virtual infrastructure online or 10,000  GPUs or 10,000 PS2s or whatever the cool kids are doing these days.  So we really wanted to make it easy and we're just like, you know, we're lazy, cracking  caches is too hard.  There's got to be another way to do this.  Can we just trick the client into giving it to us?  That way, establishing some kind of full connection and maybe just, you know, hand it over directly  to us so we don't have to crack it.  Obviously that's what you guys just saw.  So then we started going down the path of how WPA2 works.  Well, like you guys saw, what if we just accepted everything that Radius actually got sent and  sent it back?  Well, then you saw that in that, there was actually some problems with that.  We're in this chat B2 actually worked correctly and just dumped the connection.  So we started playing with that idea of, you know, what if Radius just said everything  was okay?  Can we trick the client somehow into making a full connection with us and then do something  with them later to get the password?  And so basically we started with some past work.  Josh writes some really good work on patching Radius to actually output the hashes directly  in the Radius Debug file so then you can take those hashes and try to crack them offline  or do one of the other different attacks or brute force it or whatever you want to do,  which again was too hard for us.  But we started kind of with that and then we moved on from there and said, well, you  know, what else do we need to do with Radius?  And I basically put Jim in a little box and I didn't let him come out for air for two  or three weeks, a month, something like that, a month.  And I started going through every single module and we said, well, what about that one?  What about that one?  What if we send this back here?  And a lot of people seem kind of interested in that and how we figured that out.  And neither of us are coders at all, right?  We started with somebody else's work.  We didn't want to crack the hashes.  We did this tool in Ruby that's really kind of scripty.  So how can we do this to make this easy?  And again, starting with this work from ‑‑ great work from others.  And then yielded unexpected discoveries, right?  We ended up finding a vulnerability as far as we know for iOS that has never been reported.  You know, when we told Apple about it, obviously they told us to get stuffed, but in so many  words.  But you know, that it was just random.  I really encourage you guys that are interested in this kind of stuff to test things that  people say work, right?  Don't have to necessarily write a buffer overflow or stand in your head and do naked  cartwheels or whatever it is to take you to do where you want to go.  But just test things that you think should work that way.  If they say it should work that way, test it and make sure.  There were times ‑‑ I was like, well, I missed chat, V2 doesn't work that way.  There's no way that will work.  But here it is, undiscovered discoveries here.  So you know, no, we didn't invent time or the flux capacitor or anything really cool  like that.  But what we did come up with is this patch.  Again, I put him in this box and he came up with this crazy patch for radius that allowed  us to test this and allowed us to see what would happen when we just accepted everything  in certain ways.  And so that was where the meat and potatoes of what we're giving to you guys today other  than anybody ever set up wireless attacks.  It takes some time.  One minute.  Okay, good.  Perfect.  It can take some time to set that stuff up.  So what we're giving you today is the patched so you can test this against your own infrastructures  or wherever else you want to test it.  And some easy ways to set up the tools really, really quickly.  So I'm going to pass over here to Jim to the last slide.  He's going to tell you where to get some of this stuff.  The last 30 seconds.  So lubuddy.com, it's basically just going to forge you on to our GitHub site.  You can download the tool.  You can download the patch.  It has an installer script that you can run.  It's called sysprep.  It's basically just going to do an app get and download some of the libraries that you're  going to need and just make things a lot easier for you.  But again, read the code.  Make sure you understand what's going on before you run it against your guys' own corporate  environments and all that jazz.  I promise it won't send your passwords over to us.  You should check, though.  Yeah, literally check.  And then the picture is just a jab at what's going on in the media today.  You know, stop spying on me.  I don't do anything cool.  I promise.  Anyways, that's our talk.  We appreciate you guys taking the time to listen to us.  Thank you.  Thanks.
DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_0_167.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_168_731.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_732_995.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_996_1055.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_1056_3119.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_3120_3623.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_3624_7139.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_7140_22319.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_22320_22943.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_22944_23663.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_23664_26963.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_26964_28487.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_28488_28727.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_28728_29063.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_29064_29351.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_29352_30875.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_30876_31019.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_31020_32111.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_32112_39515.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_39516_39767.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_39768_40403.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_40404_40679.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_40680_47927.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_47928_50531.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_50532_50747.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_50748_50831.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_50832_51059.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_51060_51107.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_51108_51263.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_51264_51323.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_51324_52055.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_52056_52175.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_52176_52511.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_52512_54419.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_54420_55799.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_55800_55919.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_55920_56003.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_56004_57455.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_57456_57647.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_57648_59423.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_59424_59495.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_59496_60803.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_60804_61271.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_61272_66179.png DEF_CON_21_-_Djwishbone_and_PuNk1nPo0p_-_BYO_Disaster_Ze-KIKo2QQ4_66180_68577.png
So anyway, our talks on we call it B.O.I.O. disaster and why corporate wireless security still sucks. A little bit about us. Let me push some buttons. Anyways, my name is James. I also go by punk and poop online back in the old air, sea days and stuff. Independent security researcher, just an all around nerd, boring guy. And with me I have Josh Hoover here, the guy that pooped today. Can you hear me? No, you can not. You're talking on us. That's fine. I'll switch over here. Yeah, I'm Josh. I've been coming to DEF CON since, well, since I had hair and some of my friends over here were just starting to grow hair. So we've been here for quite a while. Privilege to be here. Thank you for coming to our TBA talk. This picture, the gym selected of me is supposed to be kind of a joke. Did you guys read our profiles at all online? You probably can't see in the book, but online. Anyway, there's a funny profile I wrote for Jim and this is his way of getting back at me. I told him to pick any random picture he could find on Facebook. So that's the evil one he picked of me. So anyways, at the end of the day we're just nerds with random ideas and inconsistent results. That's been the story of our lives. So what we're going to talk about today is we're going to show you some ways to obtain clear text credentials without cracking a single hash for a PIP-enabled WPA2 enterprise networks. There's been a lot of research and work in the past that is involved gathering hashes and cracking them offline using like brute force dictionary attacks and those kind of things. We're pretty lazy. We don't have time or want to spend a lot of time cracking hashes. So our whole thought was to come together and try to find an easier way, a faster way of capturing clear text credentials to gain access to networks. Secondly, we're going to release a tool that kind of automates the whole process and does things for you right out of the gate really fast. So if anybody's done these attacks in the past to set up the interfaces and all that, it can be kind of time consuming. So we've kind of automated that whole process for you. How we're going to do this is we're going to explore a new functionality issue and I'll get into that more later that we found with how iOS and OXX devices are handling MSChat v2. Secondly, we're going to demonstrate the use of EAPGTC as an inner authentication mechanism in place of MSChat v2. So I'll go ahead and give it to Josh here and he's going to kind of take you through some of the technicals for MSChat v2. So how many people here have showed hands that have ever set up a WPA2 enterprise network or know the ins and outs of that? You shouldn't, but anyway, that's great. That's what that guy said right there. So it looks like there's a fair amount of you that haven't yet. So I'm going to kind of go over some of the technical details on exactly what our research was looking at. I'm sure most of you have set up a WPA2 personal at home where you set a pre-shared key of some kind and you gave it a sit and you connected to it and you knew what the password is and you signed into it. Basically, WPA2 enterprise just adds one extra component to that, usually a back end authentication server of some kind. In this particular instance, it's the radius server box you see on your right, I guess, of the screen. And that just adds another layer of the indication so you can authenticate every single client that connects to your network instead of just having one key that you'd use maybe at your home network. So you have a client that you see there on the left, an AP in the middle, and then we're adding an extra component for WPA2 enterprise, which is the authentication server. In this particular instance, it's going to be a radius server, but there are other options there for different kinds of servers, but this is what we're centering on for the MSChat V2 and GTC stuff. And it's a lot of what you'll see in enterprise-level networks and crazy people like us like to run this kind of thing at home for some weird reason. So what's the first thing that happens when you connect to an AP, right? I mean, most people are familiar with that, right? You pick your SID and you connect right up to it. You pick your network name there and that's pretty easy. I'm going to blow your mind with technical details here, right? I'm not going to go into that portion of it, but it's worth mentioning that this is the first layer of attack for a lot of people that want to set up what's called an evil twin network. And basically what you're doing is you're mirroring the exact same SID that your target is using and hoping that clients will connect to you instead of to the actual AP. And so that's the first layer of attack called the evil twin. And that has to do with the dangerous. These guys are going to be very angry at me because I actually don't drink, so. My Jim's got to drink double because I can't drink, so. You guys can throw things at me instead if it makes you feel better, though. No way. We're here to help you. Here's for you. Here's for your co‑speaker. You know how many times in my career I've had to take one for the team for this guy? And also, as you may be familiar, raise your hand if this is your first F‑con. Why is it everybody's new? Wait, why are we pointing at him? All right. You get up here. That's her first F‑con. And the lady down here with the striped dress on. I got to suffer your suffering, too. Wait, wait, wait. What are you doing? Hey, we don't have people up here. Where's mine? Two more. Bear with us. They know it was my first time. They know. Did you pick it up from the bar? I know it's a double. No, we did not do that last time. I tried. What, we got more? Geez, all right, everybody, come on. We're actually out of coffee, so. All right. To all of you newbies, welcome. I'm sorry, your time is up now. Thanks, Ravines. It's already coming out the other end. I have no idea what I was doing. Where am I? Drink one? No. So, association stuff, right? We got the shots covered. Okay. So, association stuff. We're connecting to Evil Twin, blah, blah, blah. That's the first layer attack. We're excited about that. Let's move on. The next portion that happens in WPA2 enterprise is what's called an EAP proposal. What's EAP? EAP is extensive authentication protocol. Basically, that's just a fancy acronym for a methodology or a framework that's used for authentication of all kinds of services. This particular service is going to be Wi-Fi. It allows you to add user name and password or certificates or one-time password, something like that to some kind of service. The first thing that will happen here in this proportion is that the AP is going to request identity from the client. The client gets a pop-up on most clients that says nothing more than user name and password. That's all it says. That will be important later. We haven't really established exactly what kind of authentication we're even using yet. So, anyway, the client sends that over. Doesn't actually send the password over yet, but does send over the identity, which in this case is the user name or some kind of login name. This is another layer of attack that a lot of people like to use because now you could just stop here if you wanted and just gather user names all day long. That's boring. We want passwords. We don't want to have to crack them. We don't have to brute force it. That only gets us one step. So after it sends it over to the radio server, the radio server says, okay, that's good. It's going to send over what's called a peep start. So what's peep? Peep is protected extensible authentication protocol. And basically that's just a fancy way of protecting EAP. So, unfortunately, EAP by itself isn't inherently secure. So if you were sending over hashes or whatever you're sending over using just regular EAP, you can pick them up usually over the air because at this point there's no encryption at all at this point. So you could pick up anything. And so this is a way to protect that data. What peep does is it makes what's called an outer authentication and inner authentication. The outer authentication is not very fancy. It's just an encrypted tunnel. And the inner authentication is the actual users or clients information. So it's attempting to protect that information inside of an encrypted tunnel, which is great if you're sitting on the outside and you're just sniffing it, but if you're the evil twin, they're sending it all to you. But you've got to make sure all this stuff happens otherwise the client's going to freak out and it's not going to send you its credentials. And it's goodies that you want to get so you don't have to goodies, except word. So what happens next? So anyway, the outer authentication happens next. Again, part of peep. I'm not going to do a lot of technical details here. It's TLS setup stuff. So you guys can look up TLS if you're not familiar with it. But there's a server search that's on the radio server that gets sent over and it establishes a TLS tunnel in order to start sending over all the goodies, all the good authentication portions of whatever you happen to do. So after that, you go into the inner authentication portion. That's inner eep. In this particular instance, we're going to be talking about MSChap v2. Now, v2 differs from v1 and I'll explain that in a second. But MSChap is generally used for NT or domain or whatever, Windows login. So username and password. It's a way to allow people to use that in order to log into a wireless network. So this is kind of important for a lot of enterprises out there because they want to make it easy. They don't have to worry about passwords or have to worry about key management or people want to bring in their BYOD devices and just connect up to the network and this enables them to use their normal login that they would use on the corporate network or whatever network they're using. So the first thing that happens in this inner authentication portion is what's called ‑‑ oh, sorry. It just sends the identity again. Actually sends the identity again over to the radio server. So it requests it and sends it. Yeah, great. We've already got that. That's something new. So the first thing that happens from the radio server, it sends over a challenge. It must have a V2 challenge. The client takes this challenge and takes its password and makes a hash from it. And then it sends it back to the radio server. Now, an important part of V2 over V1 is that there's a dual authentication happening here. Both the client and the radio server want to make sure that each other actually knows the password. So the radius creates a challenge and sends it over to the client and says, hey, here's a challenge, use this challenge portion to create a password for me, a hash, and send it back to me. And the client says, okay, no problem. I will take that challenge, my password, create a hash, send the hash over to you. It's a hash. There's lots of people here that can tell you how to crack those, but we're lazy and we still consider that too difficult for our small minds. So it'll send that back over with an actual challenge of itself and say, okay, here's my hash, but I want you to tell me that you know my passwords. Here's my own challenge. Create this challenge, hash it with whatever you think is my password, and send it back to me. So the race says, okay, if I do actually have your password, I'm going to do that and I'm going to take your challenge and send a response back to the client. At this point, the client looks at it and says, okay, does this match? If it does not match, it's supposed to drop the connection at this point, which may or may not happen as we see here going on. But this is an important part of V1 versus V2. Microsoft and Cisco specifically created this in order to try to circumvent some of what's going on here in the attacks you'll see here in a second by making sure the client says, well, I'll give you my hash, but I'm not going to connect until I'm sure you actually know my password. So again, if that does work and it does actually know the password, then the radius server will take that. It'll make its actual response and say, okay, your password was successful. Here's the response to your challenge. The client looks at that and says, okay, you do actually know my password, no problem. Let's send over a success to the radius server. The radius server says, great, we're all good. Let's start our connection. It sends over what's called an EAP-TLV success. The client acknowledges that and we're golden. So the inner authentication has happened correctly. Again, this is with MSChat V2. So what happens next is basically just an EAP success portion here. We're installing some special keys onto the AP to start up the actual encrypted network connection so they can get the rest of their IP address and everything that they need to in order to get access to the actual network. And again, I'll blow your mind here with some really fancy technical details, finishing the connection stuff. I won't really go into that. But again, what we're really concentrating on here in our attack is the inner authentication portion because we want the password. We want them to make a full connection to us so we need to convince them that we know the password. We want them to send the password to us anyway. And so this is where our research is really focused. Anybody who's done ‑‑ how many people out here do security research other than showing up to DEF CON? I guess that's considered security research, right? So a few of you, you're probably familiar with how difficult this can be, especially if you run into stuff like this where you're trying to get a full connection and MSChat is hitting you in the face and saying, no, you can't have that connection and you try again and it hits you in the face and whatever happens. So we found this funny little video that kind of reminds us ‑‑ some of you have probably seen this before, kind of reminds us exactly what this feels like. Yeah, it's not a whole lot of fun, but, you know, she's okay. So you'll be okay too. You know, you take a few hits in the face, you know, you can get back up and she actually did get back up and she had to finish this. But anyway. So that's a little overview, quick overview of the way that our research ‑‑ exactly what our research is looking at technology was. I think everyone loves that video. Okay, Jim, I'm going to pass over Jim here and he's going to tell you about our actual first attack. Thank you for sitting through all of that technical detail. All right. So, you know, I have to say that I purposely only had like three drinks when I was coming to. That's just to take the edge off. So the crap that they just gave me just kind of pushed me over my edge. So I'm going to do my best to get through these slides. So anyways, the first attack. We call it the iPoner because it's central around iOS and OXX devices. On the left side there you see the mobile device of phone and then on the right side we have the actual radio server. We didn't put the AP in the middle but if you can imagine, there's obviously an AP in the middle of this thing. So we've ‑‑ the radio server is a patch version that we wrote that kind of puts the exploit into there. Kind of like what Josh Wright's done in the past with his patch for radius for capturing hashes and cracking those offline. We kind of did the same type of thing in a different ‑‑ I guess a different way. But anyways, the first thing that happens is the server challenges the client like what Josh was talking about earlier. The client gets that. It's going to send its MSChap response back along with its peer challenge. And that peer challenge is basically the client's way of authenticating the server to itself. It's basically to make sure that both people have knowledge of the clear text credentials. So once the server gets that in response, it's going to look in its database and obviously as the attacker, we don't know what the user's password is at this point. So we have two choices. We can either tell them, cool, your password is good or hey, your password is wrong. So the first thing we tried obviously is we accept everything. And if anybody has used the patches that have been out in the past, they've been designed to say success for everything. Any password you send it is going to send a success in response. When we do that, the peer challenge doesn't match for all devices. It looks it up in its database and says, hey, you're full of crap. What you sent me back is wrong. And typically it drops a connection or it sits in kind of a limbo state. It won't actually establish a connection to the network, which is what we're after. So we start over. You know, we actually tried a lot of things, but we're consolidating this into the one that worked for you guys at stake. But anyways, so we reject the password. We just tell them, yep, what you sent me is incorrect. So the server then sends a TLV success at the end. So we tell the user send us this password, we send it back saying, no, whatever you sent me is incorrect. Expecting the client to drop the connection. For some reason, IOS and OXX devices don't drop the connection. So we follow that up with a TLV success, basically telling the client that everything's good. We're going to go ahead and finish this connection and I'll send you a DHCP address and start sending you network services. OXX devices go, well, you know, I don't really know what this means, but okay, cool. We're good. So right. So the client sends us a TLV success at that point, meaning that they're ready for a DHCP address and everything else is going on. So the client checks for a captive portal. Another crappy thing about your IOS and OXX mobile devices, most devices, when you're connecting to a secured wireless network, it knows that there's not a captive portal. So there's no reason to send a probe out saying there's a captive portal there. IOS and OXX devices don't do that. They send that probe no matter what. So what we do is we capture that probe and say, sure, there's a captive portal on your secured network that you don't need. And we forward that on. So basically, we send them the captive portal, which is an HTTP, right? They type in the password again and we get it in clear text. That's how the attack basically works. We're very happy. So right. So we're not... So from a user's perspective, you know, what does this look like from your mobile phone? So you get some manager that brings his personal phone to work and he wants to check his email because he's late for a meeting, all that jazz, even though he knows it's not allowed, but he doesn't care. He's a manager, right? So he pulls up his iPhone, he's looking at it, like Manny right here in the front, Tony and Manny right here, like those guys. Anyways. So you got your MSChep test network. That's what we're calling it in this case. So you select it. It prompts you for your username and password like you're used to. You type that in. It's going to pop up a cert, right? How many users always accept a cert no matter what it says? It could say you're a douchebag on the cert and they'll say, okay, cool, I'll accept it. So it really doesn't matter what you put there. Most people just click okay. So the next thing they see is this captive portal login. You can make this login look whatever you want, but we just took a standard one. So the very next thing pops up like, oh, what the hell, I already typed it in. Maybe I got my password wrong. So they type it in again. And basically that sends us over to your passwords in clear text. This last screenshot is what it looks like from an OS X device like your laptops, your Apple laptops. It actually tells you that you have authenticated via MSChap, me too, when obviously we just showed you that that's not accurate. So at the end of the day, you're getting your clear text passwords. You have a full man and middle connection at this point. So the sky is basically the limit. You can do whatever you want with them at this point. So a recap of basically the attack that we just went through. So the subliquents on OS X and iOS devices, they don't appear to be handling MSChap v2 properly. They don't require that you send it as success or just they're not paying attention to it for whatever reason. They don't really know. But basically at that point, so much for mutual authentication. MSChap v2 is there specifically for mutual authentication. In this case, it's not working. So we're bypassing that inner authentication mechanism. We can say whatever we want at that point and we're just letting it go through and then establishing that connection. We're trapping a captive portal, probe requests, it's defaultly sent by these mobile devices and just forwarding them onto our malicious captive portal. Like you would if you were mimicking a hotspot network at Starbucks or someplace like that. Not that we've done that, but just saying. And then the users enter their credentials again and it's an HTTP so it's going to be sending clear text and we're there to capture them. Oh, I love Apple. So anyways, I'm going to ‑‑ or actually the next slide here. So we'll talk about responsible disclosure. I'm going to say first off responsible disclosure because Josh gives me crap all the time when I tell him how. I really feel about it. But it's a good thing and we encourage people to do that. It's kind of like telling a kid in elementary school that you're going to tell on him before you tell on him, right? He's in trouble. You're just, I'm going to tell. You know, so whatever. So anyways, so here's how it went in this particular case. So we found a new issue. We're going to report it up the chain. Typically what happens is, hey, I discovered this thing that exposes your back door and I urge you to patch it before someone dumps a nasty payload in it. Nobody's laughing because you guys don't have a six since the humor like me. But anyways, so that's what happens. Then the sociopath, right? The corporate because they really don't care. They don't have a personality. Their responses, thank you. Though you're probably wrong, we will have some of our outsourced managers put ten tards on it right away and never get back to you. That's typically how it goes, right? Actually, in this case, they did respond with their generic message right away. So anyways, so a month later, hey, can I get a status on, you know, that ticket I submitted, number 99, whatever. And then you get a response, hey, me, Josh, 4379, I see not what you say. I like gummy bears. Ticket closed. Basically meaning that whatever you just told us is crap and have a nice day. So, okay, cool. So this is their actual response that they sent back. So basically they're telling us that it's nothing. And then they tell us at the end here, hey, why don't you try this GTC thing because that will just send the shit to you in clear text. So thanks, Apple. So we're going to go ahead and start our next attack. Wow, Apple, thanks. I don't know what to say. It's early Christmas. I mean, I'm not sure what's going on there. But with all this said, we actually were experimenting with GTC before they even said anything, but we just thought that was absolutely hilarious that they were giving us our next attack. So what's GTC? Well, GTC basically replaces the portion of the inner authentication that's in this chat. And it was a protocol that was developed by Microsoft and Cisco for PEEP version one. And it was created basically for token cards and one-time passwords. So you guys have probably seen those secure ID cards. You can kind of see them on the page there. If you've ever worked for a major corporation, I'm sure you've seen something like this or played lots of video games these days. They're giving them out like handy these days. It's very similar to PEEP version zero with MSChat v2, except it doesn't have a peer challenge. So a lot of it, I'm not going to go over the whole interaction again because it's all the same except instead of the dual challenge and all of that stuff, it just sends over the one-time password. So it's similar in operation in that regard. And so you guys remember what I said about the server not actually telling the clients what kind of password and username it was asking for? Well, this is one of those areas where it might come in handy, right? If your client pops up and says, give me username and password, you're like, oh, that must be my username and password from my NT login, right? Why wouldn't it be? It doesn't say one-time password. It doesn't say give me your token card. It just says, give me your username and password. And this is kind of a weird, funky thing with clients. We'll get into here in a second. And think about how we can use that to our advantage. I'm sure all your brains are turning there with that. It's probably pretty obvious. But let's take a look at it. So this is our next attack. It's called the peeping Tom. Basically, the same kind of setup. There's an AP in here you don't see, but you've got your client in this case. It can be an Android or an iOS device. The last attack was iOS only. And just before I get into this attack, this doesn't invalidate MSChat v2. And I think that's kind of what Apple was saying. But for some reason, you know, peep version 1 leaves or peep version 2 comes out and people decide they don't want to support GTC or something anymore. Apple still hasn't fixed their problems. So that's still a valid attack vector. Just because this is out doesn't mean another vector is not open. Something about front doors and back doors and anyway. So what happens with our first attack here is we replace the radius server with an attack server just like the other one, exactly the same. The server requests, well, you do the identity thing right in the beginning where it sends over the identity just like in MSChat v2. The server says, send me one-time password. And again, the client is already interacting with the user. So the client just for some reason is like, oh, okay, well, I've already got the password that he entered. Why not? Let's send that over. So the client responds with, sure, this is a GTC password. Why not? I just asked the client for username and password. So the radius server obviously in this attack instance, we don't actually know the password. So GTC fails and says no password for user. We don't care where the radius server is patched and it doesn't care what it gets. It's going to send success anyway. So it's a little short of the MSChat v2, but the server sends over TLV success anyway and says, okay, your password looks good. And the client is like, sure, I trust you. Why not? I send over the password. I'm not authenticating that you know it. It's a one-time password. Why would I do that anyway for a one-time password? And the client accepts and responds to TLV success and we have a full connection there and a full connection is established. And at this point, we can do all kinds of things. We already have the password, which I'll show you in a second, but you could use SSL strip or any of your normal men in the middle attacks that you might want to do against a client after you get him to connect to you. And so once again, we're extremely excited and dancing because we got the client to attach to us. Great. Okay, great. Everyone's excited about that. Yeah, yeah, yeah. Jim liked his video better. Peanut Butter Jelly Time is old school, right? Okay. So what does the client look like in this instance? Again, this works on iOS, but I'm going to use an Android device because something different happens here with Android. See if you guys can catch on what it is that's missing from this that was in the MSChap attack with the client. So the first thing that happens is, right, DefCon secure. You guys all use the DefCon secure network this weekend, right? Yeah, right. So that was MSChap E2, just saying. Anyway. Great. So we connected DefCon secure. It's peep, awesome, you know. Let's type in our username and password. Again, it just says identity on Android, but whatever. Most people think of that as their username and password. And bam, we're connected. So what's missing here? You. That's right. There is no acceptance of the cert. Our cert's bogus. It's example.com or goofball.com or whatever. Dooshier.com. Android doesn't actually ask you to accept a cert, which is interesting because that means later there's no user interaction. So this client interaction would change. If they've already connected to the corporate network or DefCon secure network and then they connect to your evil twin, it's a different cert, but Android doesn't care, accepts it anyway and just sends the password right on over. Okay. Awesome, right? I mean, anyway. Anyone see this this weekend at all on the DefCon network? Not one person? Well, we saw it a couple of people's networks. You know, shameless plug for our TBA talks since no one had any idea that we were even in here and what we were doing. So we basically took a ‑‑ with one of my buddies down here that helped me. You can raise this hand if you want to. That's a notoriety. We basically took a Raspberry Pi and used our same attack tools in a slightly different configuration and basically just set up a captive portal that anytime somebody connected to us instead of DefCon secure, they got this captive portal page that popped up and said, hey, Jim doesn't know about this yet. This is a surprise for him. I took a lot of his work to do this, but I was going to fill him in later. He came a little late. Convenient for you. Yeah, convenient for me. But you know, it's promoting for us. So anyway, that's what we were doing there. So clear text anyway. So where did we get the password in this particular instance? We didn't have a captive portal. Well, gee, radius, it was totally awesome for you to put your clear text passwords in your debug file for us. Cool. That's kind of weird, right? But if you think about it, it's a one-time password. So if somebody sees it in a radius debug, what does it really matter? Well, unless it's an actual MSChap V2 password that somebody mistaken for a one-time password. Because again, the way the clients are developed, and I know I keep going back to this, but this is a big thing. The way the clients are developed, they just ask you for username and password. You don't have any indication on exactly what they're looking for. So that's a big deal there. And again, this is actual screenshot from this weekend from the DefCon secure network. I blanked out the passwords because I don't know why, who cares. But I did anyway. There's my test one in there. That one's not blanked out. But I don't know if anybody notices their password. We've got an MAA in there and a W. Gretz user and a RFDESO. Anyway, so that was from this weekend. Just to show you just another example. I just want to say I had nothing to do with his attack that he did today or over the weekend. Sure, sure. You say that now. So let's talk about it. Let's do a recap on exactly what happened here. What does it work on? So PEEP version one works on anything that GTC, that PEEP version one works on natively. So that includes things like iOS and OS X again, so your actual Mac computer or your personal device. It works on Android again without assert at all, which is a huge deal in these attack environments because it just sends you that password right on over. I don't care if it's a one-time password. Here's my goodies. Unix will work, but the user is really going to have a lot of interaction here. They're really going to see what's going on a little bit more with, say, like Ubuntu or something. I didn't do an exhaustive test on all of the different platforms out there, but with Ubuntu, the attack would work. But typically, I'm just going to say it outright, Linux users typically have a little bit more about what's going on and why is that, why is that, say, butthole.com instead of example.com or whatever it's supposed to. Windows, there's no native. If you know this, the P version 1 was developed by both Cisco and Microsoft, there's no actual native support. So somebody would have to install a supplicant or some kind of other software in order to get P version 1 and Windows to work. But again, that wasn't really our focus. Our focus here is execs or people that just want to bring in their phones or whatever mobile device or whatever device they have, they're bringing their own device, bring their own disaster kind of crap and connect up to the network because that's who they are and they can. So that was really the focus here, but again, it doesn't really work on Windows for once ever, right? That's kind of a rare thing, but whatever. No cap to portal required, right? The man-middle-tack is trivial because it includes clear text passwords. We don't have to do a cap to portal. We could in this instance, I use it to advertise, but you could just serve them off to the Internet or even more fun, you could have them connect to Def Con secure and serve them off to regular Def Con because that's fun. Sorry. Anyway, instant capture of MSChab v2 passwords on iOS devices after the user accepts the cert from the Evil Twin. So on iOS, you will actually have to accept the cert, so it won't just happen in their pocket, right? I mean, we were doing this with friends of ours that were around, just kept saying their password over and over and over again because they were on Android, but if you're in iOS, it'll actually pop up and say, I don't recognize this cert. And most people are like, yeah, I want my porn. Give me access, okay? So anyway. So we're going to go into our demo here and the tool that we spend a lot of time on. I'm going to hand it over to Jim because he's going to give you the intro and then we'll pull the tool. Cool. You're going to pull it up? So anyway, so things you'll need to run this attack. You're going to need some type of Linux system. We've used Ubuntu 1204, both in the server and the desktop versions work great out of the box. So if you want to download those, you can. Any Wi-Fi adapter is needed. The alpha version there is the one that we've used. The important thing is we're using host AP in our tool set. So if as long as your card is supported by host AP, it should work just fine. Our custom patch that we made, it just basically goes in and changes some of the modules built into radius, the PAP module and the MS-Chap B2 module to send the right stuff over to these clients and get them to establish the full connections. So you want to download that. And then the LootBooty Wi-Fi tools is just a tool set that we developed. We wrote it in Ruby and I always, people always ask, well, why the hell did you guys use Ruby? So Ruby basically, to me it's like the canvas for people that can't draw because I suck at coding. So you could take a giant shit on the canvas and smear it around with your hands and it always works. And once you guys download the tool and you look at the code, you're going to go, now I know why he said that because he does suck at coding. And I do. I just have enough energy to make things work. I don't do it right by any means. So here you want to take this? Yeah. Is that mic working? Hello. Yes, sweet. So Josh is going to pull up our live demo here and we encourage you guys to try this. Those of you that were not smart enough to turn your phones off before you came in. This is really meant to use in a VM, by the way. You probably don't want to run this just the way it's set up right now. I mean, you can just download and look at the code and do it however you want like we did on a Raspberry Pi. But anyways, it's a menu driven system. So we've got two of the attacks built into there, the two attacks that we talked about today. The first one is ‑‑ I can't even see it from over here. So the peeping Tom attack. We're doing that first. We're going to do the Iponer first. So you go ahead and select option two. It's going to tell you a brief description of what the attack is going to do. So you kind of have an idea of what's going on. Can you guys see that at all? Okay, let's make the font bigger here. Sorry. There we go. Jerk. That's right. How about that? Is any better? Even bigger? I'll say. Okay, we'll try it. Huge! I know you can ‑‑ Size matters, right? Size matters. Huge. Says the lady in the front right here in the stripe skirt. This is as big as it goes, though. No more medicine for me. Anybody notice her limp when she walked in the room today? That was me. Just saying. Use your imagination. Team, my buddy. Jesus. It was this crap they made me drink. You took one from the team for me, too. That was yours. You put me over the edge. So anyways, menu driven system, cool pictures, asky art, we like that. How many people like colorize with Ruby? Nobody. Thank you. It looks really cool, though, right? Old school, kind of neat. Josh likes colors. So start. How hard is that, right? You type in your wireless interface, in this case we're using WLAN1. We're going to tell it the network name that we want to clone. Whatever company you're working for, you want to type that in there. We're using my computer. My company rules. My company rules. When you see the cert, connect to it, please. Seriously, we're not going to steal your stuff. If you want to spoof a MAC address, you can. We put that functionality in here because it's fun to do. If you just hit enter, it's going to take whatever your card's default MAC address is. You can select the channel if you'd like. If you hit enter, it's going to default to nine. I don't know why I picked nine. I just did. But anyways. So it's going to go ahead and start a bunch of stuff. What it's starting is it's starting a free radius. If you guys have ever used that, on the top left there, that's your free radius. On the bottom left corner, it's your web server. That's going to show you the captive portal. That's all in Ruby as well. It's using things called web brick. You'll see as people are trying to hit your portal. Over on the right-hand side, you're going to see host AP. That's basically if you want to see from an access point standpoint, you're going to see all the people associating with your access point. Their MAC addresses and those kinds of information. The big screen in the middle is basically your captive portal creds, which is what you're waiting to pop up. That's when people have made the connection. They've accepted your cert. They've been forwarded to your captive portal. And then they're going to type in their credentials again. So hopefully somebody is doing it. It looks like we've got plenty of activity here. I will say you can type in whatever you want. So if you want everybody to see it, go ahead and do it now. Just try not to make it totally horrible. And again, this is iOS only. So if you're trying this with your Android device, it won't work because MS-Chap v2 vulnerability is only hacked. I'm a loser. What is that? You're not a loser. You're good. You're good. Well, nobody's done something really offensive. Bring it. Yeah. Well, yeah. I mean, this is the kind of place you'd expect to be. Nobody's been afraid. You're afraid, right? So this is it. If you're doing a penetration test in a corporate environment that's using WPA2 Enterprise, which most of them do, you know, you spend this tool up and you wait 10 minutes or 15 minutes until... Somebody fucked your mom, Jim. Oh. I fucked your mom. I know I've tried to talk her to her about that a few times, but she does her own thing. I encourage her. Go for it. Good for you. Remember to do the pole and pray. Okay? Let's do the other two. All right. So the next attack is the peeping Tom one. So the first one only works in iOS and OXS because that's the only people that are screwing up MS-Chap v2 at this point in time. So the second attack is peeping Tom. That works on basically everything that supports GTC. So the same type of thing. You hit start. Yeah. Let's interface it. You've got plugged into your machine. That's my company rules, right? My company rules is the... My company rules, yeah. You're right. And if you want to spoof a MAC address, no, we're not going to in this case. We go ahead and hit enter. We don't care what channel we're using. And basically the same things are starting up. You've got your radio server starting up so you can see what's going on from that perspective. You've got your AP starting up so you can see from that perspective. And then you've got your GTC passwords. The cool thing about this, so if you've ever connected to my company rules before and you've accepted the cert or whatever, it's automatically going to send your stuff over now to this one because your Android devices are going to ask you to set the cert. It's just going to automatically send us your stuff. Yeah. And all you people that are already connected with iOS, as soon as we spun this up, it automatically sent your password over without doing anything because you've already accepted that same cert, right? Otherwise you would have to accept the cert. But this is just a demonstration. Holy s***, I like the monkey balls. Who did that? Raise your hand. You're my hero. All right. You're my monkey balls. We love you. Thank you. So anyway, yeah, I mean it's just a great way to see exactly how the attack works right in a row, right? First attack was you logging into your company. The second attack is no ‑‑ it's not even asking you for your credentials again. It's just logging in. If you had an iOS device and you did that. So how many people are familiar with Air Crack, sweet? Everybody's used that, right? You know that the thing they got were just automatically response to any probe request. So imagine if you were just responding to anybody's probe request in this scenario that connected to a corporate network before, you know, and you're spinning up a fake corporate network, it's going to automatically start sending you their logins and passwords that they use in the past, which is kind of a big deal. Just saying. Yeah. So anyways, I'll pass you back over here to Joshy Poo, the guy that didn't drink his alcohol. Boo. Boo. Don't hate me. I'm sorry. You could beat me all later, I swear. We got five minutes, Homs. Okay. I get that right. Oh, you can just do it. You can take my word for it. All right. Where are we? Let's see. We're beeping. All right. How about that? Okay. So let's talk a little bit about how we came about with this. What was our goal and how do we achieve it? So historical perspective, the first thing we decided was, wow, you know, Josh right, and who's the guy that did the divide and conquer talk? Anyway, Moxie, it was Moxie, right? I think anyway. Yeah, anyway, so there's been a lot of really good talks on how to crack passwords from WPA2 or crack the actual hash. And I don't have access to a giant web infrastructure or giant virtual infrastructure online or 10,000 GPUs or 10,000 PS2s or whatever the cool kids are doing these days. So we really wanted to make it easy and we're just like, you know, we're lazy, cracking caches is too hard. There's got to be another way to do this. Can we just trick the client into giving it to us? That way, establishing some kind of full connection and maybe just, you know, hand it over directly to us so we don't have to crack it. Obviously that's what you guys just saw. So then we started going down the path of how WPA2 works. Well, like you guys saw, what if we just accepted everything that Radius actually got sent and sent it back? Well, then you saw that in that, there was actually some problems with that. We're in this chat B2 actually worked correctly and just dumped the connection. So we started playing with that idea of, you know, what if Radius just said everything was okay? Can we trick the client somehow into making a full connection with us and then do something with them later to get the password? And so basically we started with some past work. Josh writes some really good work on patching Radius to actually output the hashes directly in the Radius Debug file so then you can take those hashes and try to crack them offline or do one of the other different attacks or brute force it or whatever you want to do, which again was too hard for us. But we started kind of with that and then we moved on from there and said, well, you know, what else do we need to do with Radius? And I basically put Jim in a little box and I didn't let him come out for air for two or three weeks, a month, something like that, a month. And I started going through every single module and we said, well, what about that one? What about that one? What if we send this back here? And a lot of people seem kind of interested in that and how we figured that out. And neither of us are coders at all, right? We started with somebody else's work. We didn't want to crack the hashes. We did this tool in Ruby that's really kind of scripty. So how can we do this to make this easy? And again, starting with this work from ‑‑ great work from others. And then yielded unexpected discoveries, right? We ended up finding a vulnerability as far as we know for iOS that has never been reported. You know, when we told Apple about it, obviously they told us to get stuffed, but in so many words. But you know, that it was just random. I really encourage you guys that are interested in this kind of stuff to test things that people say work, right? Don't have to necessarily write a buffer overflow or stand in your head and do naked cartwheels or whatever it is to take you to do where you want to go. But just test things that you think should work that way. If they say it should work that way, test it and make sure. There were times ‑‑ I was like, well, I missed chat, V2 doesn't work that way. There's no way that will work. But here it is, undiscovered discoveries here. So you know, no, we didn't invent time or the flux capacitor or anything really cool like that. But what we did come up with is this patch. Again, I put him in this box and he came up with this crazy patch for radius that allowed us to test this and allowed us to see what would happen when we just accepted everything in certain ways. And so that was where the meat and potatoes of what we're giving to you guys today other than anybody ever set up wireless attacks. It takes some time. One minute. Okay, good. Perfect. It can take some time to set that stuff up. So what we're giving you today is the patched so you can test this against your own infrastructures or wherever else you want to test it. And some easy ways to set up the tools really, really quickly. So I'm going to pass over here to Jim to the last slide. He's going to tell you where to get some of this stuff. The last 30 seconds. So lubuddy.com, it's basically just going to forge you on to our GitHub site. You can download the tool. You can download the patch. It has an installer script that you can run. It's called sysprep. It's basically just going to do an app get and download some of the libraries that you're going to need and just make things a lot easier for you. But again, read the code. Make sure you understand what's going on before you run it against your guys' own corporate environments and all that jazz. I promise it won't send your passwords over to us. You should check, though. Yeah, literally check. And then the picture is just a jab at what's going on in the media today. You know, stop spying on me. I don't do anything cool. I promise. Anyways, that's our talk. We appreciate you guys taking the time to listen to us. Thank you. Thanks.
over here. Yeah, I'm Josh. I've been coming to DEF CON since, well, since I had hair and some of WPA2 enterprise networks. There's been a lot of capturing clear text credentials to gain access that happens when you connect to an AP, right? I mentioning that this is the first layer of attack unfortunately, EAP by itself isn't inherently using. So the first thing that happens in this something new. So the first thing that happens problem. Let's send over a success to the radius overview, quick overview of the way that our attack. Thank you for sitting through all of that looking at it, like Manny right here in the interaction. So this client interaction would about this yet. This is a surprise for him. I took a lot of his work to do this, but I was that now. So let's talk about it. Let's do a that GTC, that PEEP version one works on You're afraid, right? So this is it. If you're somehow into making a full connection with us and that way. There's no way that will work. But here