>> Hello! Thank you for making it through to our talk at the last  day. Oh, I should probably not run that stuff before I give you a disclaimer.  So we're going to be talking about improvements in attacking client devices on Wi- Fi networks, so rogue access point or evil AP stuff. And this year is the ten year anniversary of when Karma attacks was first released.  And there's a lot of work that needs doing and that's what this talk is about. Some of you might recognize the logo we put up there, after Heart Bleed, we realized that every tool needs a logo.  You can't just write code anymore, you have to have a logo.  So, Facebook writes hack on everything and they sort of sent this out in an email invite, so I hacked their logo to make a logo for our thing, I thought that was appropriate.  But thanks to Facebook for not suing us yet. Okay, so we're going to be talking about Wi- Fi at Def Con and we got live demos, so it's guaranteed to do terrible things at some point.  We'd like to not do terrible things to you, so please turn off your Wi- Fi if you don't want to be part of any potential terrible things.  If you choose not to turn off your Wi- Fi and you stay in this room, we take that as consent that you're ok with it. That said, we're not going to be showing people's passwords, we've got demos of our devices and things like that.  Standard disclaimer.  Hi, I'm Dominic, this is Ian.  We work for a small company in South Africa called Sensepost.  A Pen Testing firm that has been going for about 14 years.  Those are our contact details. Our first name at sensepost.com if you want to get a hold of us.  We like talking about this and our happy to continue the conversation and we're also at Twitter at those handles.

Alright, so the ubiquitous why Wi- Fi or justification for our research slide.  I think we all understand that Wi- Fi is pretty valuable. People when they start hacking, the first skinny project, you go buy yourself a pineapple and turn it on and if you at Def Con, you get owned.  I don't know if you saw that.  SO it's pretty fascinating, we were worried that the volms and that stuff might -- because of some commonality exists in ours, thankfully it doesn't, but we suspect we spotted it every now and again, just massive amounts of shell code stuff flying through the sky and so who ever that is, nicely done.  But I think -- so Wi- Fi gives you pretty cool stuff. We know that these things are ubiquitous, they're sitting in our pockets, we've all got them on us and they are all connected to cloud services with tons of valuable information, be it your corporate information or your personal information.  So we want to hack the Wi- Fis.  They're everywhere and they give us useful stuff.  And the promise of hacking Wi-Fi is that you get creds from the sky.  Manna from Heaven.   There's vulnerabilities that have existed at every layer and we can own Wi- Fi devices on almost every layer of the ozone model.  And we should have creds falling from the sky.  So you can spoof devices into connecting to your network with rogue AP attacks.  If there's a secure network that you can try and crack those creds.  WPA handshake cracking or EAP cracking then you get corporate creds.  Once you are on the network you can man in the middle them and get passwords like Doug Song released this stuff in 2000, Robert Graham released his hamster and ferret stuff in 2007, we had Fire Cheet in 2010 there are lots of tools released to give you passwords once people have connected.
And then we've got stuff to try to mess with protection so we can get around SSL using SSL strip and Moxie's tools.  So technically at every layer we've got these vulnerabilities.  Why can't we walk around with passwords filling up the database somewhere?  The reality these days is kind of far from that, there's no Manna falling from Heaven.  You can run this stuff and you will get maybe the odd noob whose still checking mail over pop without certificate validation.  You really don't get a bunch of credentials flying out of the sky.  And to try to get a lot of credentials, you have to put a lot of work in.

So if you look at the Karma attacks which we are going to look at in a bit, those things don't work as well as they used to, and we'll get into that, ten year anniversary.  With things like cracking WPA handshakes and cracking EAP networks, those things have not kept up- to- date with our ability to crack stuff and the speed of which we can do that. And if you look at the man in the middle stuff, Doug Song released D-Sniff in 2000, and if you want to capture MSN credentials, going with the MSN messenger, those things are great. But nobody uses MSN messenger any more.  And then things like HSTS and certificate pinning have come along and messed with our ability to man in the middle as well.  So we wanted to fix that. So we're releasing a set of tools today, we're calling it the Manna toolkit. We're calling it Manna because of the Manna from Heaven thing and we're trying to figure out what a decent acronym would be. Something that made that make sense.  And we thought of something lame, like man in the middle and network attack toolkit. And we thought ok, that's possible, we'll go with it. Somebody yesterday suggested we call it -- many are now active.  Which we thought was a pretty cool blame.  I don't know if you're here, so we decided we're going to call it, many are now active.
Okay, so before we look at Karma attacks, this is a targeted primer about Wi- Fi.  First off we are talking Wi- Fi, we're not talking 3G, GSN, Bluetooth, NSC, anything like that. 80211 ABGNAC stuff.  In Wi- Fi, you have three types of packets.  You have management data and control packets. The control packets are the kinds of things that prevent RF collisions and allow lots of devices to talk RF at the same time and get decent throughputs. And data packets are the stuff that carries the data you are sending over the network.
Management packets are the ones we're interested in. And in particular there are three sets of packets, probe requests, probe responses and beacons. So when your device looks for a network, when you open up your phone and you look at available Wi- Fi networks or do it on your laptop, this is what happens.  Your device sends out a broad cross probe request and then all of the access points nearby say, hey, I'm this network and I'm available.  And that's a probe response coming back.  Now when you connect to a network, this happens. Well, something slightly more complicated than this, this is the simplified version.  You send a directed probe request which is different from a broad path probe request in that you are looking for that specific network and it will respond to that directed probe request and you get an association.  So if you have played with the aircrack suites and you have run fake off with air replay, that's what this is.  And you get that association ID to reach the end of this process.
So current Karma attacks, the stuff released by Dino and Shawn in 2004, and they target this aspect of the association.  So if something tries to associate to a network with a directed probe, they will respond --  But they don't target this part of the whole thing.  And what ends up happening is if you look at - -  sorry - -  I'm jumping ahead a little. Anyway. So if you look at problems that happen, if you run Karma these days, it doesn't work as well. So if you take like a standard Android device, this is a Nexus running the latest one, it will show you a list of networks that are available, but it's not necessarily directed probing for those networks.  So Karma won't know to respond to that stuff.  So if you have a home network saved there, you can click on it, but it will say your home network is not here, so I'm not going to try to associate and send that off.  So we need to fool those devices into thinking that network is here. I'm going to jump back a little. So in South Africa as kids, we play a game in the pool called Marco/Polo. We asked some people in the conference if they have heard of Marco/Polo and they say they have, not the explorer, the game.  I apologize if this is a localized reference.  But the way the game works is, some kid closes his eyes and he is it and he shouts out Marco and then everybody nearby shouts out Polo and he has to try and catch them.  So he has to acoustically locate them.  So this works well for Wi-Fi.  So imagine that your client device when it sends out a broadcast probe is shouting Marco and all of the access points are responding, shouting Polo with their network name.
So that's -- what Karma relies on is the fact that we can't tell the difference between one person saying polo, home network, and another person saying polo home network.  And that's built into the pro -- the way Wi- Fi works.  It's your corporate networks, you're going to have hundreds of APs spread across your campus, you need to be able to have lots of BSS, BSSIDs advertising the same ESSID so that you can roam around and connect to lots of different things.
And the places where authentication happens is after the association.  That's where you do your EAP stuff where you do your WPA stuff. So before then, it's completely unauthenticated and you can spoof it and nothing knows -- is any the wiser.  The other aspect that makes Karma work is that devices have preferred network lists on them.  So when you connect to a network and you choose save that network or remember it, that gets stored as a preferred network.  And one of the problems that devices have, is that they probe out for these networks even when they shouldn't.  They should just be sending out a broad burst request and looking for networks nearby, but for a variety of different reasons on different devices, they will send directed probe requests saying, hey, home network, are you here?  Hey, home network, are you here?  Just shouting out Marco.
So the modern implementations of Karma these days, so the guy on your right is Robin Wood -- DigiNinja, he wrote the first patches for Karma for host APD which is the open source and access point software and that's the stuff that's used on the pineapple, although they released a new version of pineapple stuff yesterday, so it's slightly changed now.  The guy on the right is, I can never pronounce his name, Thomas d'Otreppe.  I'm sorry if he is here and I'm butchering it. He is the guy that wrote the aircrack suite and the airbase MG tool implements Karma in software mode.
>> Right, hi everyone, as Dominic said, my name is Ian de Villiers.  Believe it or not this little note is actually stuck up on my wall at the office because I really battle with host APD.  It seems that the developers follow that old thing about not commenting the code because if it was difficult to write, it should be difficult to read. 
I've also got to say it's a bit disappointing, I'm doing my first presentation at Def Con and I'm forced to use Windows.  We presented yesterday and Linux just didn't want to work with the projectors and stuff, so I thought -- I'd be safe, but anyway.
In any case, there a big thing that Dominic pointed out, in order to successfully start getting devices to associate with our rogue access points, our access points are going to have to respond both to directed probe requests as well as broadcasts. So literally what we did is we did quite a bit of work on the actual hostapd code and we added components, essentially just a bunch of hashes and stuff -- patch tables where we restored the list of networks that devices had probed for on a per device used.  So if Dominic's phone is probed for three networks, we would store that and then later on we'd respond for broadcasts with that.   And this literally would mean that devices would potentially start noticing that networks were open and would start connecting to them.
So to give you an idea over here, I'm just going to display over here -- yeah, one thing, we are going to fire this up now, as Dominic said right at the beginning, the disclaimer, if you have your Wi- Fi on, you'll probably see networks that you associated with previously will start becoming available as I go through the talk over here.
In any case, on the screen, we have a screen cast of an Android device, we can see a couple of networks connected to previously, so post mana, et cetera, et cetera, they all stored -- the Flamingo Rooms is currently available over there.  And then literally, we are going to fire up Mana and on the left hand screen we're going to fire it up and you will see a bunch of output from it and that is where it's storing a direct probe request for specific devices.
And when we come along over here, our previously saved network is now obviously is now available and it's attempting to connect to the thing and we can carry on and it's actually connected. This is following the same logic as normal in terms of it follows the new logic we implemented that being, that we've stored the direct probe request and then responded to the broadcast, hello, we're here.  And the device is actually going to connect.
If this gets further and we just delete that network and we create a new one, then you will see more how the original Karma attacks worked.  So, we delete that, we're going to create a network, and then it's going to say, hello, are you there?  We're going to call the network Manna Sensepost, we haven't connected to it before, and we're going to connect to it almost immediately. It just makes it very easy.  There we go.  And so we've connected. 
>> Sorry, I'm laughing at some of the messages that some of you are choosing to send us in your network names.  Thank you. All right, so the implication there is that Karma starts working much better than it used to.  We're now responding to those broadcast requests based on the view of the PNL that we can build up from your device.  So if you have Wi-Fi on now, we're not running anything malicious other than just sending out the Karma stuff, it's pretty busy at the moment.  But you should see some networks specific to your device showing up.
Now one of our colleagues who is sitting down in the front here, Glenn, he presented in this track yesterday around this time on practical ariel hacking surveillance and a tool kit that he built called Snoopy. And what Snoopy does is it looks at these probe requests that you are sending out and it builds up a location history of where you've been.  So based on your network name, if that's unique and it's been driven into the database can find out where you are.
So stuff like Snoopy and creepy ass retailers using this to track people around and other things have led to a reduction in the number of probes, directed probes that these devices send out send out. Because technically these devices don't need to send a directed probe out other than when it is actually associating to the network.
So in the case of IOS, the number of probes it sends out for open networks has been dramatically reduced.  And even the number of probes it sends out for hidden networks has been reduced which I will come back to in a moment.  In the case of Android devices, they've actually pushed the patch to WPS applicant which is the thing that associates to networks and to limit the number of probes that gets sent out. That will get built into Android at some point in the future.  So we expect to see even fewer probes coming down the line. 
So when I was trying to figure out why IOS devices weren't probing for hidden networks, because that's weird. Hidden network, it's not broadcast on the SSID.  If you send out -- I mean on beacons -- if you send out the broadcast probe request it won't respond saying, hi I'm this network.  You have to know the network name and do a directed probe for that network and it will respond. 
So what that means is if you have any hidden networks in your PNL on your devices, basically your device runs around going, hey network are you there, hey network are you there, hey network are you there. So how had Apple figured out to not do that?  Like it's impossible.  I spent a bunch of time building Faraday Cages trying to see if they were maybe they were using location history and then realizing I don't know math and can't build a Faraday Cage to save my life and tin foil works much better.
And we eventually figured out that what Apple does is if there is at least one hidden network nearby then it will probe for its hidden networks.  But if there is no hidden networks nearby then it won't probe for hidden networks.  So easy win if you weren't using stuff like Snoopy or your trying to look for probes or you want to make your Karma attacks work better you must have a hidden network nearby. 
>> Right, so what we did then is we thought about this because there were a couple of things one could do.  One could either run a hidden network or we also thought about broadcasting hidden network frames alongside the beacon and so on and so forth, that's not implemented yet, or alternatively de-offing users and having them rescan which could potentially be problematic, it's really easy, but problematic from other aspects.
Eventually what we thought was because different devices react in different ways and the large number of people these days carry more than one Wi-Fi device around with them, which would probably have different levels of stealthness, if I can put it that way.  What we thought we would actually go along and implement something else.  You remember earlier when I was talking about Karma with the -- device view of networks that it actually probes for, we decided, actually let's skip this.  If there's anybody out there, we're going to go through every network that we've actually collected from any device and we're going to broadcast it.   And it actually makes our Karma attack significantly better.  So if I skip back to the videos and I go to Karma now, it's basically a configuration setting.  It's not enabled by default because it's really noisy. And we start running the actual Karma engine.
What we're going to see is on our right hand side we have our Android application there's only one open network, but as Karma starts picking up more and more networks from other devices nearby that list is going to grow substantially.  And all of the sudden you start seeing a whole heard of them and unfortunately that tablet that I was screen casting this from is a bit longer than my screen, but there are a lot of them. And they just sort of carry on coming up and so on and so forth.  It really improves the success of our Karma attacks.
>> So I'm running that at the moment, if you are looking at your Wi-Fi device, you will see that. But the problem is, it ends up trying to generate more packets than this card can -- or frames -- that this card can send out in a reasonable timeframe and there's lots to view.
>> It might work for a bit and then it will probably fall over and start working again. It's working.
>> Okay, so up until now what we did is we fixed Karma.  Karma is ten years old, it wasn't working so well, it now works much better.  We field tested this and we're prepared to stand by that.   We're releasing this tool at the end of the talk, you can take it and have new Karma attacks that work much better.   But then we wanted to --
[Applause]
>> In a fine tradition of over promising and under delivering, we thought what else can we put in our Def Con abstract that will make it look cool?  So we thought let's make ridiculous claims about secure networks and see if we can live up to them.  So Karma attacks work only on open networks, you need the network to be open.  Secure networks, so that's WPA networks, or pre-shared key networks, or stuff like 8021X are juicy targets. They, on the one hand provide you credentials and on the other hand, if you can actually get them to connect, you get man in the middle -- the benefits of the man in the middling someone.  So we spent some time working on extending that.  And Ian just gave me a meaningful look which makes me think that -- here we go -- the meaningful look meant I forgot something.
So when you have a secured network in your PNL list, different devices behave in different ways.  Let's say an Android device probes out for a hidden -- not a hidden network, a secured network. Right now current versions of Karma and Karma running in open mode only our version, will send a response, but the devices match the network based on the security settings and the name. So they are not going to auto associate to those networks.  They see it as a different network.  So what that means is that if we want devices to automatically connect, when they are in people's pockets, we want them to automatically connect to us. We don't want them to have to click on the network to just connect.  That's not going to happen. And even if they do click on the network to connect, different devices give you funny warnings.  Like on an Apple -- on an OSx device it will tell you, this used to be a WPN network and now it's open that's wired are you sure you want to continue.  Android shows it as a completely different network and things like that.  So we spent some time thinking about how to deal with that.
>> So one of the things I came up with was well, we came up with was basically is we decided if there's no certificate validation on a device, then it actually could theoretically be quite easy to get them to actually connect and look at cracking things.  Now the big thing is previously people have relied on Pre Radius written by Joshua Wright and Brad Antoniewicz. I hope I got that right.  But what we've done, we've actually ported some patches by Brad into hostapd so we've now got our own Radius server and so it's all incorporated to make it a little bit easier. Nice. So we're rather tethered over here. Anyway.
But in any case, if we look at WPA2, we only got to capture the first two parts of the authentication and pass them off to some other cracking tool and then what we thought we would do is look at automatically crack and add EAP credentials into our hostapd config.  So the reason for that is just as Dominic pointed out is very much -- firstly we've got to Radius server built into the thing, point number one.  Point number two is you are talking normally about slightly more high venue credentials, it's not someone's WPA2 personal at home etc, etc, it's normally going to be a corporate or something similar.  Plus you have the benefits of actually being able to man in the middle that specific device, so that makes it really, really, really juicy.  If we have a look at this, we have a video over here again.  There's a bunch of stuff happening.  There's two windows open over here.  Just explain quickly, the bottom left hand one, and unfortunately, the screen is a bit compressed so I hope it's going to be clear enough, is where I am going to tail our EAP users file so we can see when users get added.
The top list is the output from hostapd and I'm going to stop here a bit later as the crack and add process actually works.  And on the right hand side, we have an Android device with a secure network configured.  Now if we actually skip through this, have a look at the network config -- The identity, the user, password, et cetera, et cetera.  And we'll skip on ahead a bit and now we tail the users file. That's basically pretty much the default one.  I've got nothing past the final entries in that. And I just want to keep an eye on the time here because it's -- so literally I started this app now and we'll see our device is almost immediately going to connect, about now.
Yeah, it's really already come through, I actually missed it. If we have a look on the top left, we've got output from crackapd, which sort of says credentials cracked user Peap, TTLS, password and we have a new entry in our EAP users file.  And if we let this carry on, you will see it says it's going to connect pretty much now.  There we go obtaining IP address and it's now connected.  Now how it all works currently is literally from hostapd, I just write up -- create a -- when the application starts and I write from there. But the cracking is actually taking place using generic tools.  In my case I'm using Asleep with the standard Charlie Linux BrockU word list.  But the script itself is implemented in Python it just makes it easier -- people want to go along and start looking at cloud based cracking providers or something like that. It makes it easier to extend that. You have to say depending on the complexity of the password, it might not crack as fast as this one.  This one's user was password so it would naturally crack virtually immediately.  But it could take, if it's crackable it could even take a significant amount of time. 
>> So the implication there is two-fold.  The one is we took free-Radius WPE which was released in 2008 and has not been really updated much since and that's not integrated within this toolkit.  You don't have to run a separate tool, that stuff will all work for you.  And then the other thing we did is also crack an add as Ian pointed out, so you can hopefully get -- start man in the middling people.
So up to now what we did is we focused on improving Karma attacks.  The broadcast stuff and trying to deal with things like loud mode, trying to deal with secure networks.  But to really make this stuff count, like if we just left it there and it's kind of a technical -- it doesn't fulfill the promise of creds falling from the sky, Manna from Heaven.  So we realized we need to look at the man in the middle side.  Now here we have relied a lot more on lots of other people's tools.  We built some of our own.  But the problem is there are so many different tools out there and you never really sure which of the ones that are going to work best for you and with the current configuration and the way devices work and the new stuff that's coming out like HSTF, and certificate pinning, some of that stuff just doesn't work.  I mentioned it in the beginning that it doesn't work as well. So we spent some time trying to put together a configuration that would give us really nice results when man in the middling and give us the credentials from the sky.  So up to now we are just getting the EAP credentials.  What else can we get?
So the first thing we used is a tool by a guy name Daniel Roethlisberger.  Once again I'm sorry if I'm messing it.  That's why there is a hamburger there.  So I could remember his name.  This is a tool called SSLSplit. If you want to man in the middle SSL connections, I highly recommend this tool.  It's scalable, it can do non HTTP protocols and it wraps the output out into useful formats.  It's a really cool tool.  The Mana toolkit uses this to do a lot of heavy lifting, we didn't make any changes to it. The next thing we looked was different configurations for different situations.  Most people when they are man in the middling will rely on Natting or some kind of upstream connection that they  are literally sitting in the middle of.  But it's really useful to be able to do this stuff in places where people have left their Wi-Fi on, but haven't -- but there isn't necessarily an upstream connection.  Like if you are a visitor in a foreign land and you don't have a data bundle. Or an airplane or down a mine, something like that, lots of people leave their Wi-Fi on in airplanes when they're not supposed to.
So a lot of devices will do these checks to check if they are on line or if there is a captive portal.  Apple devices and more recently Android devices try and get trixie.  So Google will make a request to something called generate 204 and expect a HTTP 204 response back.  So to make it think it's on line, you have to try and respond to these different things.  Apple gets particually tricky, they make a random request to a random URL on one of two hundred different hosts which chooses randomly with two different user agents just to check that it's not being locked based on user agents.  So we built a bunch of stuff that deals with all of this, Apache Vhost it's built into the Manna toolkit that'll help you deal with it. And the reason it's interesting is because of stuff I'm going to talk about just now, where you can push malicious certificates to devices to make your man in the middle work much better.  There's an option with this stuff, in the toolkit to have that happen as it connects to the network.
So one of the ways we can get creds, one of the easy ways is to have a malicious captive portal and we'll show you the demo and it's a bit lame, it says log into your Google creds, and hopefully somebody will do that, but all of you guys would be far too smart for that I'm sure.  But it also gives us the ability in the upstream mode to start getting some credentials from people and it gives us a place that we can push out our malicious certificates which I'll show in a bit.
So if you're going to be man in the middling stuff on these devices, it's really useful if there's a certificate in their root store that you have the private key for.  But we're not Law Enforcement or the Government of Tunisia, so we don't get to do that to our population.  And we have to try and convince people to put those certificates on there. And that's supposedly quite difficult, right?  Actually, it's ridiculous easy.  And I think people should maybe taken to task for how easy it is.  If you send an Android or IOS device a .cer file. C-E-R.  It doesn't even have to have the right mime type.  Then they will helpfully offer to add that to their root CA store.  Like over HTTP.  So if they are doing their captive portal network request and they receive a dot server instead of an HTML file, they'll be like, hey, you're sending me a certificate.  Why don't I add that to my root CA store?  You need to type in your password granted, so there is an element of them warning you.  But it just feels like that should be a harder thing to do.  Like somebody in corporate IT should have to go and do that, or you need to like work for it, not you can just send it. And in Apple's case you can even push malicious iOS configs over there in the exact same way. Once again you have to type in their four digit password.  But some users are going to fall for that and given that it gives us a root CA on their device it's totally worth it.
The next thing is HSTS.  HSTS stands for HTTP strict transport security.  Three acronyms I can remember.  Four, it blows my RAM.
So HSTS is something to defeat tools like SSLStrip. And what SSLStrip relies on is that if you type in something like Google.com, you didn't type in HTTPS://Google.com because you are my mother.  She is a very smart lady, but she's not going to type that stuff in. So you're going to hit the page on HTTP at which point you'll get a redirect to HTTPS.  So SSLStrip, stuff -- previously, it will just prevent that redirect and serve things over HTTP and rewrite links to HTTP.
With HSTS, a site can configure that will basically send a directive to your browser that will say, always access me via SSL. So even if you type in accounts.Google.com, or HTTP://accounts.Google.com, your browser will still go to accounts of Google over SSL without ever hitting -- playing clear text HTTP.  So things like SSLStrip don't get an opportunity to work there and it gets very difficult to man in the middle.
But there was this guy, Leonardo MVE who presented at Black Hat Asia this year, who had this awesome idea for getting around HSTS.  And it works really well, so we implemented it.?And it's one of the things we are releasing in the Manna toolkit.  But, it's his work, all credit goes to him. We just made some changes to make it work slightly better.
>> So, I'm going show you some demos of how those things fit together.  So it's the same set up as up to now, we have the tablet on the right and we have chrome open and we're running in no upstream mode.  So if you try to go to a page that we haven't faked, it's going to take you to our captive portal. And we're going to go to foo.com.  And it takes us to our fancy captive portal and you'll notice it asks you to log in and it's got a drop down for different services like Google or Facebook and the hopes that somebody is going to be a dork and just type their details for one of those things in.  Creds from the sky. Ok.  So, we're going to type some creds in there and we've created a bunch of accounts for the purpose of these demos.  Somebody types it in and it will send it as a get request over plain HTTP.  We can just pull that from our Apache logs which is where we're storing all of that.  If we look in our Apache logs, there it is his username and his password on the right hand side. So that's really straightforward.  But now if we wanted to actually get his Google creds when he went to Google, what we can do is implement this HSTS bypass.  So you will notice we went to Google.com, but it's redirected to quadw.Google.com, now quadw.Google.com it's not a real domain, and because it's not a real domain there's no HSTS policy for it saved in your Browser. So this requires two things. One is it requires a DNS proxy which Leonardo wrote that will do this exchange.  So you're trying to go www.Google.com, actually go to four w's but to return the proper result and the modified version of Moxie's SSLStrip that once again Leonardo wrote and that will serve the right content, strip out HTTPL, HTTPLL. In this instance, we're not actually using that because this is in upstream mode we can control the full interaction so we can create a VHost for quad w.Google.com and later on we'll show you it running in nat with that stuff happening live.
So now we have rewritten the link so that if you click sign in on the right, which would normally redirect you to accounts.Google.com, it once again keeps us on the quadw.Google.com domain, and with the live nat stuff it will redirect you to accounts.Google.com.x  And now we type in the same credentials, we've edited the get request, it's in clear text and it's going to show up in our Apache log just the same as the other one.
But then the last thing is this malicious certificate side loading. There is the username and password showing up in the get request.  Ok so that's the second way we can get -- the third way we can get creds from the sky easily.  
So lastly we're now going to try the certificate side loading. We're going to go back to foo.com, a site that doesn't exist with our portal.  And you will notice it's got this helpful let us auto configure the network for you.
Ten minutes, thanks.
If you click on that, it pushes that cer file to you and chrome helpfully pops up a prompt saying, what do you want to call this new root CA with a healthy add for you?  You can type in anything and you click ok and you have a root CA sitting on your device.  Like, it shouldn't be that easy.
So if the user makes the mistake of believing us, clicking on that and clicking okay. And then it kind of comes down to how good your social engineering is I guess then.
What it does, to their credit due, in the top left hand corner you will see a warning pops up which says, warning this network might be monitored by a third party because our root CA is not signed.
So those are three ways in which we can improve the state of man in the middling after we have gotten things connecting to our device.
>> Great, so those that were Glenn Wilkinson's talk yesterday about aerial surveillance, etc, etc.  You would heard a reference to FireLamb, but in any case, FireSheep no longer works, etc, etc, so Glenn quite a while ago wrote a tool called FireLamb, which is basically a Python script.  That sort of can capture cookie information, that parses out cookies made by requests made from specific machines and literally creates new Firefox profiles with the cookies stores for every device that's actually gone through or all the traffic that's been sniffed or loaded from a packet capture file.
We used a modified one in terms of it, in terms of Mana because obviously a large chunk of our information is actually still traversing the network encrypted.  All be it through SSLSplit etc, etc.  So obviously FireLamb isn't going to work, so we have quite a lot of modifications to actually parse -- not a lot of modifications, but just to parse the cookie information out of the SSLSplit logs.
And this basically gives us -- because now, obviously, we have spoken about credentials, we can get that using all of these specifics thing.  But in terms of that session IDs and cookies, etc, etc, are also some form of access token and they are obviously very important.
So we've implemented FireLamb inside the Mana toolkit as well and let's give you a demo of that.  So, it's quite a long demo, so I'm probably going to skip a head a little bit with this one, at some places.  But in any case, if we go through here, this one has got a bad certificate loaded, this is all stripped, we are man in the middling all over the place.  So first thing we're going to do is we're going to go to accounts.com, this is the real Google.com.  Accounts.Google.com.  We're just MITMing it at this specific point.  And we signed on and we can see that it says Andrew Hacker, Hacker that's the profile page etc, etc.
And that's not enough, so we'll skip forward and we'll sign on to Facebook as well.  A Hacker 1337.  What's nice to note over here you will see we've actually -- Facebook also implements HSTS so we've got the same trick implemented and we've actuall signing on to quadw.Facebook.com as A Hacker, which is awesome and then we can sign on using a password. And I'm going to skip ahead here a bit. I believe he creates a post to --
>> His mother.
>> Hello mom what is you maiden name?  And then he sends a mail etc, etc. All of this information is being captured at some specific point.  But the big thing over here is if I sign on to my Charlie Linux which is doing all of this work, in this case I'm now going to be running FireLamb to actually have a look at this. I'm going to hit space here.  You see what it's gone and done is it's created a bunch of output directories.  Now all of those output directories -- what they implemented -- are actually Firefox profiles.  In my case I'm interested in output directory number 6 and I can actually go along and enter 6 at this point and it's going to fire a Firefox using that actual profile, which means I'll have access to all those cookies, I'll have a link to a whole bunch of pages he's actually recently visited.  So let's pick on accounts.google.com, we are using the same cookie he was using a couple of minutes ago, so we now actually have signed on to it -- well signed on, we've been impersonating him on accounts.Google.com as Andrew Hacker.
[Applause]
>> And now we can set them and go back a bit and we'll go on to, in this case, it's strange, the host name is actually pixel.Facebook.com, and not trip W.  But if we click on that, we get the same effect.
>> Any moment now.
>> Any moment.  There we go.  So we have actually authenticated, well impersonated him on Facebook at this point.  Now we made a couple of changes to FireLamb once again, in the meantime we are pulling out a whole bunch of creds, which obviously aren't cookies, etc, etc.  But they stored all over the place in these SSLSplit files.  Which hasn't all been completed by the time we recorded this demo.  So I'm just going to skip forward a little bit over here. The other example is basic auth for -- and I know that's not that one. Somewhere over here we've got basic auth for mail.
>> Uh- oh. I think that is time.
>> But in any case, even the clear text mail, everything is stored in there and that is all over there.
[Laughter]
>> So I'm sure many of you have seen this before.  These two fine gentlemen and I use that term very loosely, have never spoken at Def Con before.  So what does that mean they do?
>> Shots!
[Applause]
>> You go, that's right, they drink!  Oh, not yet.  I have to get my shot of water.
[Laughter]
>> Thank you so much for joining us and congratulations for our first timers.  And everyone give them a huge round of applause.
[Applause]
>> Hey, feel free to go about your business -- Hey, they're not done yet!  Feel free to go about your business.
>> Thank you.
>> Okay, so somebody was shouting, where can we get it?  We have not posted the code up there yet, we just need to switch it over to the public repositories. But they'll all be there.  So you can see there are a ton of tools that we messed with, and so Mana is the main thing that ties it all together. The others are tools that we have written or contributed to and made changes.  And in other tools like SSLSplit we're using that vanilla -- there just configurations in Mana.
So the net results of all of this stuff is that we think, and we run it, it works, we get creds falling from the sky.  There are still places in which people are protected, so this isn't something that's necessarily inherent.  You can still run secure, but there's lots of ways in which people can make mistakes.  Even though we're supposedly savvy to this, we keep catching ourselves, we forget to turn off our Wi-Fi, so you see your home network show up, next thing you see some of your creds coming and it can be a real pain.  So if it starts working against us, it works even better against potential victims.  So that's us.  Thank you very much for your time and patience. That's where you can get the info.
>> Thank you very much.
[Applause]