>> 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. 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]